This does NOT mean you should start stuffing every possible JavaScript file into a service worker cache. There is still a parse+compile cost — you just pay it up-front when the service worker is installed instead of later.
-
-
Show this thread
-
You don’t want to parse+compile code your users potentially won’t even use. Only cache the bare minimum, and load+cache the rest on-demand.
Show this thread
End of conversation
New conversation -
-
-
I was wondering if this happened the other day, and suddenly I read the answer the question I didn't ask! Does this also happen on mobile?
- End of conversation
New conversation -
-
-
In the very unlikely event of fetching a JS file to parse as a string would it have to fetch it again?
-
Are you talking about fetch as string + eval? We have a different mechanism for eval, the “eval cache” which is basically bytecode caching for eval’d strings: https://cs.chromium.org/chromium/src/v8/src/compilation-cache.cc?l=275-303&rcl=8ec122ba9de3abc2480c797adb6313b23fe08e05 …
End of conversation
New conversation -
-
-
does link rel=preload trigger this behavior as well? (could it?)
-
Only for hot runs. The article explains it.
End of conversation
New conversation -
-
-
Correct me if I am wrong, but I think devtools does expose parse information. You just have to press shift 34 times and pet a turtle on the belly 13 times during a blood moon 3 Sundays in a row. cc
@paul_irishpic.twitter.com/CUXgO8BwRY
-
I think this is unrelated to Runtime Call Stats. It's exposed in the code-cached case, but not very discoverable right now: https://bugs.chromium.org/p/chromium/issues/detail?id=769166 … + https://bugs.chromium.org/p/chromium/issues/detail?id=912581 … I wonder if we should update the blog post. +
@leszekswirski - 2 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
JavaScript, HTML, CSS, HTTP, performance, security, Bash, Unicode, i18n, macOS.