There are a bunch of different things you can try, and sometimes it’s just a matter of trial and error, but you should be able to get some improvement. 
Local vs cloud
First, just to get this out-of-the-way, at the present time no custom code runs locally, which means nothing with core or webcore runs locally. In fact, the only things which do run locally are smartlighting (and then only if all of the individual device type handler is being used are also running locally) and a few bits of smart home monitor. That’s it. Not even routines run locally.
However, that said, some people have found that cloud-based operations run faster than local operations. I know that doesn’t make any sense, but has been reported by more than one person, so it’s just something you need to try and see for yourself. 
You can check and see what’s running locally by looking at your account in the IDE. I’m tired this morning so I will leave it up to other people to explain how to do that if you don’t know.
How Fast is fast?
Most Z wave manufacturers aim for a lighting standard of two second response time or better. However… that’s the time from the switch to the hub or the time from the hub to the switch. In your case, since you have two devices, you can double that. So up to four seconds would probably still within “specified parameters.”
Two seconds fits what we call in engineering the “conversational pause” which means it’s acceptable to most people when they push a button and then the event occurs.
However… lighting is one of the exceptions. People do not want to be standing there in the dark. So there are some companies, and Lutron is one of them, which engineer lighting to a 500 ms standard ( half a second). That’s when it starts to feel “instantaneous.” But Lutron is an engineering company that only does lighting devices. Their switches are compatible with SmartThings if you also get their SmartBridge, but the zwave companies have stuck with the two second standard, mostly because of the mesh topology.
So a reasonable goal for your scenario would be a maximum of four seconds, although we would expect to do a little better than that most of the time. I don’t think you’re going to hit “instantaneous,” though.
Zwave repair
First things first, regardless of whether your rules are running locally or in the cloud, running a zwave repair utility will make sure that all of your devices are using the most efficient message routes. This utility only applies to Z wave devices. All it does is tell each of your Z wave devices to look around and see if they have any new neighbors and rebuild their neighbor tables.
Anytime you add a new repeater device, which includes most mains powered Z wave devices such as wall switches and plug-in pocket sockets, you need to run the repair or the other neighbors won’t even know that it has joined the network so they won’t use it for message routing.
The utility itself should complete pretty quickly, but then it takes the individual devices a while to finish the neighbor surveys so you may not see improvements until the next day.
Just running this utility will often solve a lot of apparent lag problems. So try that first.
Do you have enough repeaters?
Sometimes lag happens because you get traffic bottlenecks on your network, just like you sometimes see on the highway. If you don’t have enough repeaters and all your devices are trying to use the same one, it can take messages longer to get through to the hub. So sometimes just adding one or two additional repeaters in strategic spots will reduce lag elsewhere on the network. Again, anytime you add a repeater or physically move a Z wave device you should run Z wave repair utility to get all the neighbor tables up to date.
do you have devices doing frequent energy reporting? Or other polling?
Z wave was designed for very tiny messages sent infrequently. Your classic lightswitch scenario where the light itself might only send a message to or three times a day and the message would be very short. It is a low energy low traffic design.
That worked great right up until people got phone apps. And now suddenly everybody wants to know every minute or every second of the day exactly what all their devices are doing. 
So they start adding polling or reporting on top of the standard zwave functions.
There is no quicker way to cripple a mesh network. There was one community member who was able to improve latency throughout their entire house just by removing one plug-in pocket socket that had been set to do energy reporting every second. (Remembering, again, that if you move or remove a repeating device, you should run the Z wave repair afterwards to get the neighbor tables updated.)
So take a look at your device settings if you have any energy monitoring devices and look to see if you have added any polling or refreshes from the software side and see if there’s any of that you’d be willing to do without. Run your Z wave repair when you’re all finished making adjustments, and then see starting the next day if you are getting better response time when once you’ve lightened the traffic load.
Consider zwave direct association
After you’ve tried all of the above, if you still don’t have acceptable response time, you can consider Z wave direct association. If your light Switch supports it, then you can configure it so that when the switch is turned on or off it will send a message directly to the pocket socket to turn on or off without the message having to go through the hub first.
As you might imagine, this tends to be the quickest setup. But it does introduce some problems as well, which is why we put this last on the list.
First, there’s no way to put any rules around this – – it will just happen every single time. So you couldn’t have a rule that said “if I turn the switch on between sunset and midnight, then turn the pocket socket on, but if I turn the switch on between midnight and sunrise, only turn on a nightlight instead.”
That’s because when you use direct Association, you have linked those two devices without going through the hub at all. It’s not stopping for any rules. Switch on, pocket socket on. Period.
Also, if you use direct association, because the hub doesn’t know about it when it happens, your app will be somewhat out of sync with your devices for a little while. That might be a matter of a few seconds, it might be a couple of minutes. (And usually right around now someone suggests adding polling to keep the app up-to-date which, just don’t. 
If the reason isn’t obvious, go back up and read the section on polling above.)
Neither of those issues are necessarily disqualifying for this method, you just need to know that the issues exist and decide whether they fit your particular use case.
So those are the main things you can do. There are some other options as well, but they would involve either changing out the devices or getting really complicated so let’s stick with this for now.