User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.59 Safari/537.36 Steps to reproduce: Go to https://codecombat.com and open the dev tools Wait for Service worker to install Reload the page Actual results: The requests made by service workers do not have the correct transfer size - "It just says Service Worker". For example, https://codecombat.com/javascripts/aether.js has transfer size set to service worker. Expected results: The size is correctly set to 11.36 MB but I would like to see the transfer size too.

Thanks for the report! The text for "Transferred" column is hardcoded here: https://dxr.mozilla.org/mozilla-central/rev/5e76768327660437bf3486554ad318e4b70276e1/devtools/client/netmonitor/requests-menu-view.js#1075 @Jarda: can we calculate real size of the request coming from service workers? Honza

When a request is handled by a service worker, no data are transferred over network by HTTP. The response is either generated by JS code or served from cache. The JS code in the service worker can issue another request and just forward the response, but that would show up as another independent request in the network monitor. The response size is in the "Size" column, and that's the only size information that's needed. "Transferred" makes sense only for HTTP responses, where the response could be base64-encoded, compressed etc. Inian, what additional information do you expect in the "Transferred" column that is not already in "Size"?

Maybe the "Transferred" column should say "(service worker)" or something when it's from SW and not over the wire. Similarly, when the response comes from the HTTP cache, the "Transferred" column could say "(cache)".

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #3) > Maybe the "Transferred" column should say "(service worker)" or something > when it's from SW and not over the wire. Similarly, when the response comes > from the HTTP cache, the "Transferred" column could say "(cache)". That's exactly what's happening now :)

Hey, The number being showed in the sizes column is after the data is un-gzipped. I expect the number in the transferred column to be the size of the asset actually transferred down the wire. For example, the asset https://codecombat.com/javascripts/esper.js shows a transferred size of 780 KB which is the size of the asset after it has been un-gzipped.

When I load the codecombat.com site, I see two requests for the ember.js file: 1. A fetch request issued by the service worker, for https://codecombat.dexecure.net/javascripts/esper.js. This request actually goes over the network, and shows transferred size of 128.57kB, and uncompressed size of 783.13kB. 2. A request issued by the page, for https://codecombat.com/javascripts/esper.js, intercepted by the service worker. No network traffic here, it's just two browser components talking to each other internally. Size is 783.13kB. Everything works as expected: - a script tag in the page caused a request to be issued - this request was intercepted by the SW, the interception code issued a fetch, shown as request #1 - after the fetch response arrived, SW sent a synthetic response back to the page, shown as request #2

Wow excellent..this has been fixed in the recent Developer build. This wasn't how it was working in the Developer edition when I filed the bug. Should reach the stable build soon I guess.

However, the page size is still being shown wrongly as 24.9 MB. See the attached screenshot. It is again considering the "size" instead of the "transferred size". Should I file another bug instead? https://www.dropbox.com/s/3rrffbky21htccy/Screenshot%202016-11-15%2017.55.40.png?dl=0

Oh yes, I was testing in Nightly, and there was a recent fix of the Transferred info in bug 1309523. Version 51 and later should be fixed. The performance pie chart shows the uncompressed sizes of the payload, not the network transferred sizes. That's probably not the expected behavior.

Yup, I would expect the pie chart to contain the transferred sizes of the assets to match the behaviour of pages without service workers.