Previous Front Browser Tab is an AppleScript command. AppleEvents are notoriously slow. So I'm afraid this is not overly surprising.
You could use Select Menu instead of change tab, but that would use the Accessibility API, and sadly, that is also notoriously slow.
Alternatives that might be faster would be:
- Use the System shortcuts to change the keyboard mapping for moving to the previous tab.
- Simulate the keystroke to move to the previous tab.
Given that this macro induces the following simulated events from Keyboard Maestro to be added to the event queue:
There is no way to get “@Title” except by:
- one of the delete characters getting missed
- or you typing an extra character after the trigger (eg a space)
- or the system translating the lj into something else via a system shortcut.
Command-V pasting will often be slower than typing a few characters, but then typing a large number of characters will be slower as well. In either event they will be slower than the system shortcut system which can insert the characters directly into the field without using the clipboard, the menu, or any kind of AppleEvent communication.
This is covered elsewhere. Since Microsoft decided that it would be a good idea to make available an image of anything you copy in about twenty different image formats (including very expensive PDF) every time you copy anything, and since Keyboard Maestro records the clipboard faithfully, there is a lag. Either Microsoft will have to change this, or you will have to exclude Microsoft apps from the Keyboard Maestro clipboard history (Preferences ➤ Excluded) or turn off Keyboard Maestro’s clipboard history (Preferences user manual section), or I will have to adjust Keyboard Maestro to not faithfully record the clipboards produced by Microsoft applications.