[wp-trac] [WordPress Trac] #36995: Support for Service Workers

[WordPress Trac]

#36995: Support for Service Workers
-------------------------+-------------------------------------------------
 Reporter:  bhubbard     |       Owner:
     Type:  feature      |      Status:  new
  request                |   Milestone:  Future Release
 Priority:  normal       |     Version:  trunk
Component:  General      |  Resolution:
 Severity:  normal       |     Focuses:  javascript, administration,
 Keywords:  needs-patch  |  performance
-------------------------+-------------------------------------------------

Comment (by westonruter):

 Replying to [comment:10 markjaquith]:
 > My main question is whether we think this will be rolled out to enough
 browsers (e.g. Mobile Safari doesn't have it yet) to be worth using
 '''before''' some support for multiple service workers is build into
 browsers.

 There's currently ~75% global browser support for service workers across
 Chrome and Firefox: https://caniuse.com/#feat=serviceworkers

 I can see that support is currently being worked on in Safari and Edge:
 https://jakearchibald.github.io/isserviceworkerready/

 > If we think multiple service worker support is years away (or not even
 going to happen), then it's smart to get ahead of this.

 Even if/when browsers support multiple service workers for a given scope
 it will still make sense to have a `wp_register_service_worker()` in the
 same way that it makes sense to have `wp_register_script()`: it provides a
 standard way to register a service worker script. This will then allow for
 the the service worker to be installed appropriately according to the
 target page, such as using
 [https://www.ampproject.org/docs/reference/components/amp-install-
 serviceworker amp-install-serviceworker] in AMP HTML.

 When/if multiple concurrent-scoped service workers are commonplace, then
 we can just remove the use of the script-concatenating endpoint and write
 out the script installation separately. That being said, this could be a
 good reason to use local filesystem '''URL''' as opposed to a filesystem
 path as that would allow us to eventually install the scripts directly. In
 other words, we could require assets be registered relative to the
 document root, just as `\WP_Scripts::$default_dirs` is used for
 concatenating for `load-scripts.php`. If a non-relative path is supplied,
 the call to `wp_register_service_worker()` could trigger a
 `_doing_it_wrong()`.

 > > could return a URL like `/wp-service-worker.js?scope=/wp-admin/`, with
 that path being registered via `WP_Rewrite`
 >
 > What about non-pretty permalinks?

 Yes, if non-pretty permalinks are active then this could instead just be
 `/?wp_service_worker=1&scope=/wp-admin/`, similar to what happens when
 interacting with the REST API with pretty permalinks disabled. Using a
 pretty permalink wouldn't be necessary actually.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/36995#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform