Hi,
The plugin CSS and JS is not loaded on all of the back-end pages, only the ones that affect the plugin itself, you can check that via the plugin source.
The front-end is much different, as there is absolutely no way of determining which page contains the plugin shortcode, as shortcodes are registered in a later flow as the wp_head() is executed – thus would make it impossible to enqueue the plugin styles. Almost all plugins that use shortcodes work the same way, as it is not possible to determine if the shortcode has been used, until it is actually used, and it would not work properly without styling nor scripts.
You have two options there:
– You can either use the selective asset loading feature, so you can manually add which pages you need the plugin assets (css + js files):
– ..or you can use the asynch CSS loader feature, which waits for the plugin output and loads the CSS files asynchronously after.
I strongly recommend using options #1.
While admin_print_styles is not recommended, we use it for backwards compatibility and other reasons as well. If it’s used correctly, it does no harm whatsoever. We are planning to change that hook with it’s equivalent though.
All plugin styles are constructed in a very strict way to only affect elements within the search container, you can confirm that by checking the generated stylesheet files.
If the search speed has changed, that is most likely a server related issue/change, if you hadn’t changed anything in the configuration. You can try some of the best practices here, for the best possible search performance.