Address over-eager service worker installation and resource precaching

[westonruter]

The service worker for the admin currently precaches all registered script and styles upon installation of the service worker. This is surely overkill. WordPress Turbo mode only precached assets used on the edit screen, so we should consider doing the same. For other assets, a runtime caching strategy could be employed.

Similarly, for users who are visit the frontend of the site will currently get a service worker installed that precaches the header image (with its various sizes), background image, offline/500 error pages, and so on. When the user is on a slow connection or on a connection that is metered (including data saver mode), the precaching of assets is actually harmful. This is especially so for users who just visit a site as a one-off. The service worker is really the most key for returning visitors.

This being the case, in addition to checking the user's network connection, we should perhaps consider limiting SW installation to returning visitors, or wait to do the installation until the user has been on the site for a minimum amount of time.

[ChristophAI]

This is a hard thing to get right, especially for the frontend and in a generic way. Maybe consider a 'safe' default as outlined in your last paragraph, and expose admin choices so site admins can configure their site to be more aggressive about SW installation and precaching. With commensurate explanation text and warnings, of course.

[westonruter]

This is obsolete now as precaching is generally discouraged in favor of runtime caching by default. The integrations that precache assets (like header images, backgrounds, custom logo) are to be deprecated: #403.