CODEWITHSUNDEEP
javascriptservice-worker
Adam Rackis
Adam Rackis

Reputation: 83366

Understanding time stats in Chrome for Service Worker cached files

I'm trying to understand what the network tab in Chrome dev tools is telling me for cached files coming from Service Worker.

I'm seeing a cache hit get logged in the console (see the service worker code below), but the network tab is making it look like a regular network load. 230ms seems a bit big for a cache hit. And the value usually changes by a small amount (next load might be, say, 217ms) so it's not showing me the original time to load, when it was first cached, as I wondered.

enter image description here

The code registering the service worker is this

if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('swRoot.js').then(() => {
        console.log('registered');

        System.import('react');
        System.import('react-dom');
        System.import('a').then(({ a }) => console.log('value from a', a));
    }, err => console.log(err));
}

The entirety of swRoot.js is below

self.addEventListener('install', function(event) {
    console.log('INSTALLED');

    console.log('ADDING CACHE FILES');
    event.waitUntil(
        caches.open('v1').then(function(cache) {
            return cache.addAll([
                '/react-redux/node_modules/react/dist/react-with-addons.js',
                '/react-redux/node_modules/react-dom/dist/react-dom.js',
                '/react-redux/a.js'
            ]).then(function(){ console.log('cache filling success'); }).catch(function(){ console.log('cache filling failure') });
        })
    );
});

console.log('ADDING FETCH at root level');
self.addEventListener('fetch', function(event) {
    event.respondWith(
        caches.match(event.request)
            .then(function(response) {
                // Cache hit - return response
                if (response) {
                    console.log('cache hit', event.request);
                    return response;
                }
                return fetch(event.request);
            })
    );
});


self.addEventListener('activate', function(event) {
    console.log('ACTIVATE');
});

Upvotes: 0

Views: 666

Answers (1)

Jeff Posnick
Jeff Posnick

Reputation: 56114

This previous answer has some background on how to interpret service worker involvement with entries in the Network panel.

The screenshot you provided shows a response returned from the service worker, without any network involvement, so it presumably came directly from the cache. (If there was another entry not included in your screenshot, with a little gear icon next to it, then that would be a different matter.)

The ~200ms timing displayed in the Network panel reflects the total amount of time that elapsed between the page making the request and the page obtaining the response. When a service worker is involved, both making a request and processing the response can be delayed if the page's main thread is performing other tasks. In your example, I assume the main thread is busy evaluating and executing a bunch of JavaScript as a result of your System.import() calls, so the ~200ms of overhead would likely be explained by that.

The Chromium team is evaluating ways of removing the main thread from the request/response critical path, and that's being tracked at https://bugs.chromium.org/p/chromium/issues/detail?id=443374

Upvotes: 3

Related Questions