GoogleChrome
Account for network requests made in `service_worker` targets
Provide a basic description of the audit
Check the total byte weight of assets fetched by a Service Worker upon installation and activation.
How would the audit appear in the report?
If a Service Worker is there, wait for its activation and check how many bytes were requested during install and activate events.
I guess some Service Workers might fetch more data than is then actually stored in the cache and/or IndexedDb. That's why checking the actual requested data (compressed) looks like the best option, because impact on data plan consuption seems more important than Cache space use.
The audit would pass if the total byte weight requested by the Service Worker is under a threshold yet to define. I think it could be twice the threshold for current page based total byte weight audit.
How is this audit different from existing ones?
The total byte weight audit just checks the weight of the page and its resources, without counting any request performed by the Service Worker.
What % of developers/pages will this impact?
No idea. Some sites fetch a lot of data during first visit, which feels bad. See link bellow for an example.
I don't think we have such data in CrUX unfortunately.
How is the new audit making a better web for end users?
I believe users should be warned if a Service Workers make a lot of request to pre-fill the cache. Even more if Save-Data is activated.
Better, I think it should require an action if the weight goes above the threshold. Such action could be in browser UI, but responsible web pages could also provide a "store for later offline use" button.
What is the resourcing situation?
No idea. I can help discuss it, test it, but I'm not sure I would be able to implement it.
Any other links or documentation that we should check out?
https://nicolas-hoizey.com/2017/01/how-much-data-should-my-service-worker-put-upfront-in-the-offline-cache.html
Something related to this confused me for a bit me today doing some automated performance testing. I was getting a bunch of "transferSize": 0 assets for web fonts in my lighthouse log. It turned out to be an early service worker registration that served the fonts from the service worker (even on first visit). The transferSize was accurate but hiding these offline assets from the total page weight is definitely inaccurate. Service Worker requests should show up in network-requests and should be included in the resource-summary audits!
It turned out to be an early service worker registration that served the fonts from the service worker (even on first visit).
That's unexpected, can you say more? How does a service worker serve any requests on the initial page load?
How does a service worker serve any requests on the initial page load?
If the SW calls clients.claim() to take control of the page and it starts caching early, I assume.
It is surprising Lighthouse isn't picking up that early network activity too, though. Do we auto connect to iframes but need to add SWs as well?
Do we auto connect to iframes but need to add SWs as well?
We autoconnect to any target that gets sent our way through autoattach but we only listen to network events from iframes.
https://github.com/GoogleChrome/lighthouse/blob/24b9c7c3de2ef3a4b69cb2db7e1b29676863054d/lighthouse-core/gather/driver.js#L313-L319
I'm not sure if service workers are surfaced via autoattach or not, but I would assume they should be.
I can share the logs if you’d like but it should be repeatable on https://www.netlify.com/products/
(I do have access to modify this page and fixing this early sw registration is on my radar)
Looks like this issue has been partially fixed: https://twitter.com/simevidas/status/1276936318023618564
At least in the "lighthouse" tab of Chrome devtools. It is not (yet?) in the remote audit launched by the extension.
And it unfortunately doesn't reduce any score.
BTW, I would not have put it in the performance score, more in another category, PWA or best practices.
Also, I'm not sure this is really the same as @zachleat 's own issue in https://github.com/GoogleChrome/lighthouse/issues/9493#issuecomment-643663847
cc @brendankenny as this is very target management related. :) also note Nicolas's last comment.
btw netlify.com/products is no longer a repro (doesn't seem to have a sw anymore). Not sure if still an issue, should confirm.
I don't think we have such data in CrUX unfortunately.
To help with coming up with a threshold, a first pass should probably be a diagnostic / invisible audit so we can get some data into HTTP Archive.
Does chrome itself not impose a hard-limit?
- [ ] Attach to service worker targets and listen for network requests
- Make sure we aren't double counting requests
- [ ] Add a cog/symbol/other ux to flag requests made by workers
