audit: Service Worker boot-up time is high

[addyosmani]

If Service Worker boot-up time is high (200-500ms+?) and if the Service Worker doesn't respond to navigation requests, we could suggest using navigation preload to address this issue.

In some situations, service worker boot-up time can delay a network response. Navigation preload fixes this by allowing you to make the request in parallel with service worker boot-up.

Since launching this feature, we've seen teams running into SW boot-up time issues shave 1 RTT + hundreds of milliseconds off by adopting navigation preload, but it's worth discussing the hows of this audit further with folks like @jeffposnick.

If both of these issues are true, we can point developers to some of our guidance for addressing this

• https://developers.google.com/web/updates/2017/02/navigation-preload
• https://developers.google.com/web/fundamentals/architecture/app-shell

as potential improvements. If the app in question is already a single-page app, the AppShell idea might be a more achievable goal.

[addyosmani]

@brendankenny @paulirish @patrickhulce tentatively assigning this to Ward as part of the next sprint. Would be interested in your take on whether this audit is worth being explored.

Once we have a rough feeler from you, we'd be happy to spend time on the new audit process to try exploring if this is an issue that would justify any additional runtime costs adding in the audit.

[jeffposnick]

Here are a few thoughts:

• Using service worker boot-up time as a triggering criteria strikes me as difficult to do in a meaningful way. After installation, everything a SW needs to run is cached locally as parsed JS, so the network doesn't come into play. My gut says it's uncommon for a service worker to do a lot of work at startup, outside of an event listener. Boot-up time isn't negligible, but I'm not sure why there'd be much variation between two service worker scripts on a given browser, meaning that either all scripts or no scripts are likely to meet the criteria, depending on how high or low the cutoff is.

• A service worker that responds to a fetch event for navigation requests with event.respondWith(fetch(event.request)) could also benefit from using navigation preload. So I think the other triggering criteria should be "service worker doesn't respond to navigations or service worker responds by making a network request for the same URL".

[patrickhulce]

My thoughts: I can definitely see this being a good thing to catch.

I'm not convinced though that this is worth surfacing in the report given the ecosystem today and (lack of) familiarity with service worker lifecycles. We recently identified a consensus opinion that the report is too detailed/technical and difficult for the typical developer to understand everything that's going on as it is, and it feels like throwing in a gotcha detail on top of SW at all risks bringing us further down that road. It seems like this is something that we likely want to be solved by workbox/library authors for the common case?

Put differently, do we have good answers to our new audit criteria questions around what percent of developers this is likely to help vs. the complexity it adds to the report and audit logic?

[paulirish]

I'm concerned this would point the finger at Workbox pretty often, which is akin to PSI complaining about your Google Analytics cache time.

If and when Workbox has this on by default, then we can make this happen in Lighthouse. Workbox issue: GoogleChrome/workbox#835

How's that sound?

[paulirish]

Closing until workbox (or any other major SW tooling) makes navigation preload easy to do. Will happily reopen then.

[jeffposnick]

Revisiting this as it came up again recently in a discussion with @mdiblasio.

Workbox now has support for enabling and using the navigation preload response: https://developers.google.com/web/tools/workbox/modules/workbox-navigation-preload

[jeffposnick]

CC: @slightlyoff as we were recently discussing this.

[adrianaixba]

As per Chrome’s updated Installability Criteria, Lighthouse will be deprecating the PWA category in the next upcoming release. For future PWA testing, users will be directed to use the updated PWA documentation. Marking this as closed!