GoogleChrome / GoogleChrome/lighthouse

Account for network requests made in `service_worker` targets

Open
#9,493 9 comments 3 reactions 0 assignees View on GitHub
feature P1.5
Dominant language
JavaScript
Stars
30.8k
Forks
9.8k
Avg merge
1d 14h
Merged PRs (30d)
20

Description

#### 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](https://github.com/GoogleChrome/lighthouse/issues/584) 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

Contributor guide

Open the contributing guide

Research direction

Start by reviewing the existing total byte weight audit and how `service_worker` targets are handled. Determine how install and activate requests can be observed, how compressed bytes should be counted, and what threshold should define success. Done means the audit reports Service Worker request weight and has agreed behavior for caching, IndexedDB, and Save-Data cases.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
performance, web-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.