Use Service Workers (as grandchild of Gears) to bring back Turbo mode in admin

[westonruter]

Prior to WordPress 3.0 there was a "Turbo mode" in the WordPress admin which was used to cache scripts and stylesheets in the admin to speed up the experience. This Turbo mode depended on Google Gears. When Gears was discontinued the Turbo mode was also discontinued, and core switched to improving performance by concatenating scripts via load-scripts.php and load-styles.php. This has not been without problems, however. If there are too many scripts included then the URL could become too long in some browsers (though these browsers surely don't support service workers). Also this concatenation breaks the ability to reuse the cache for individual scripts. Google Gears was discontinued in favor of AppCache, and then AppCache has been deprecated in favor of Service Workers. The service worker is now capable of picking up the mantle of its grandfather Google Gears to bring back Turbo mode, and in a standardized way that does not require any browser plugins.

For history of Turbo mode, see:

• #6965: Google Gears support (WordPress 2.6)
• #11301: Remove Gears (WordPress 3.0)
• #20981: Remove gears-manifest.php and manifest.php (WordPress 3.5)
• WordPress.com post on Gears

For more, see WordPress Trac tickets mentioning “Gears” or “Turbo”.

[miina]

Started looking into options for restoring the "Turbo" mode.

One option could be disabling concatenation of the scripts and styles by a filter and then adding Workbox strategy for caching all the assets. Created a PR to demo this approach with run-time caching: #42

Note that it might make sense to create PHP-level API for Workbox and leverage that for the Workbox strategy instead of using the JS directly, however, this doesn't exist yet so used direct JS as of now in the PR.

Also, perhaps it would be better to precache all the admin assets instead. In this case we would need to dynamically list all the asset files in relevant directories and use the list with workbox.precaching.precache([ LIST_OF_ASSETS ]).

Thoughts?

[westonruter]

@miina Good.

Note that it might make sense to create PHP-level API for Workbox and leverage that for the Workbox strategy instead of using the JS directly, however, this doesn't exist yet so used direct JS as of now in the PR.

Yes, now that you have the use case of Turbo mode in mind this will inform some use cases for what the PHP API supports.

Also, perhaps it would be better to precache all the admin assets instead. In this case we would need to dynamically list all the asset files in relevant directories and use the list with workbox.precaching.precache([ LIST_OF_ASSETS ]).

And yes, this is the intention behind installing the ADMIN service worker on the login screen. The idea is that the admin assets could precache while the user is logging in so that once they do get to the admin all of the assets are already primed in the cache.

This may not necessarily negate the use of runtime caching as well, however. There will be scripts and styles which are registered and enqueued dynamically for individual pages, and those could be included in the cache as well. This would allow caching assets from themes and plugins and not just core. Nevertheless we need to be careful about caching assets that are changing. For example, if developing a plugin and making changes to a script, you wouldn't want to have to manually bump the script's version every time you want to test changes. At the very least the cache should be disabled if SCRIPT_DEBUG is enabled. Maybe that is already the case for the Gears implementation.

I think this is particularly a problem for the runtime cache. If using precaching, however, we could potentially obtain a md5 hash of each script in the manifest and this would eliminate the concern about the asset ver not being updated.