|Summary:||REGRESSION (r225789): 35% regression in cold time-to-first-load by enabling service workers|
|Product:||WebKit||Reporter:||Tim Horton <thorton>|
|Severity:||Normal||CC:||aestes, ap, beidson, cdumez, ggaren, rniwa, simon.fraser, webkit-bug-importer, wenson_hsieh, youennf|
|Version:||WebKit Nightly Build|
Description Tim Horton 2017-12-18 03:01:08 PST
Created attachment 329646 [details] test app Steps to Reproduce: 1. Run the attached test app. 2. Revert r225789. 3. Run the attached test app again. Expected: Relatively similar results. Actual: GlobalCold Navigation Time goes up by 35% (for me, ~330ms -> ~450ms) This measures the time it takes to load about:blank in the first WKWebView in a given UI Process. Other metrics (subsequent views, etc.) don't similarly go up, so this has to be a fixed one-time cost of some sort. I haven't looked at traces yet.
Comment 1 Tim Horton 2017-12-18 03:03:12 PST
> Other metrics (subsequent views, etc.) don't similarly go up, so this has to be a fixed one-time cost of some sort. Actually, not true, they just go up by much less (5-10%)
Comment 3 Chris Dumez 2017-12-18 14:25:14 PST
Could be due to the fact that we have to wait for the SW database to be read from disk before we can serve the first load.
Comment 4 Chris Dumez 2017-12-18 14:35:39 PST
(In reply to Chris Dumez from comment #3) > Could be due to the fact that we have to wait for the SW database to be read > from disk before we can serve the first load. (and reading the SW database also requires the StorageProcess to be launched.
Comment 5 youenn fablet 2017-12-18 14:39:38 PST
We can probably easily optimize the case of non HTTP/HTTPS main pages. We know about:blank will never get intercepted.