For automatic screen locking after a timeout, I have the following line in my X11 window manger autostart file:-
# setup for xidle and slock
xidle -se -program "/usr/local/bin/slock" -timeout 300 &
After 300 secs of input device inactivity the screenlock program 'slock' is activated. If a random pigeon flies in the window and pecks at the keyboard (which happens quite often round here), the screen is locked. Of course you can choose a shorter inactivity timeout if you like.
With kern.vt.suspendswitch = 1, on resume xidle guarantees to start the screenlock before anything else is visible on the screen. However, performing a suspend-resume when kern.vt.suspendswitch=1 also breaks gpu hardware acceleration on resume, at least on intel integrated graphics using crocus DRI driver, which is a common setup. At least, that is what I have seen, in the limited testing I have done. On 14.0-RELEASE. Which is not ideal.
With kern.vt.suspendswitch = 0, suspending then resuming the system does not break gpu graphics acceleration, at least on my system, but with the caveat that whatever was on the screen at the time of the suspend will be momentarily visible for around 5 secs after the resume, before the screenlock is activated. So the random pigeon who just happened to peck the Fn key to resume the system will see what was on the screen at suspend time, for a short time. The pigeon doesn't actually have any access, he can't type a command, but he can see what was on the screen, for a few seconds. Then the screen lock overwrites the screen. Well; that's what happens on my box, anyway.
My solution for this, when running with kern.vt.suspendswitch=0 to prevent my gpu hardware accel from being clobbered after resuming from suspend, is to optionally switch to an empty X11 virtual desktop before suspending, depending upon what is on the screen. It's not really perfect.