6 ms·
What I miss in this otherwise excellent article is more insight about methodology. There is just murky > We run tests every day on GOV.UK pages using specific
by myfonj 4y ago
What I miss in this otherwise excellent article is more insight about methodology. There is just murky
> We run tests every day on GOV.UK pages using specific simulated devices and connection speeds. Because we can repeat these tests every day, it allows us to monitor what the changes we are making to the site are doing for real users visiting GOV.UK.
with no mention whether those were all cold start loads or simulated browsing scenarios.
Not wanting to diminish the effort or challenge the conclusions — I know that jQuery does quite a lot checks and feature detecting stuff when it initializes, even when it is not used (so removing it must have significant impact) — but if those measurements were done with cold start empty cache single loads each time, it might count some "extra" time (download, parse, tokenize, build AST) that usually precedes only initial load and "first run" of static library and is not present in subsequent interactions.
- CJefferson 4y agoDoes any browser cache the parsing, tokenizing and built AST of Javascript libraries between website visits? Also, I don't visit UK government websites that often -- so I'd suspect I am "cold cache" whenever I do.
- myfonj 4y ago> Does any browser cache the parsing, tokenizing and built AST of Javascript libraries between website visits? From a quick googling, yes, at least some of them. (TIL): https://stackoverflow.com/questions/1096907/do-browsers-parse-javascript-on-every-page-load https://stackoverflow.com/questions/1096907/do-browsers-pars... >> The third time (i.e. a hot run), Chrome takes both the file and the file’s metadata from the cache, and hands both to V8. V8 deserializes the metadata and can skip compilation. — https://v8.dev/blog/code-caching-for-dev https://v8.dev/blog/code-caching-for-dev > Also, I don't visit UK government websites that often -- so I'd suspect I am "cold cache" whenever I do. For first visit with given browser and profile (or incognito mode), sure. But if you visit more than single page during same session, you probably have more than a "cold cache". That measured page mentioned in the article seems to be guidepost with only most important excerpt of the content, so it seems plausible you would "click around a bit" from there.
- youngtaff 4y agoScripts cached by a Chrome Service Worker will be compiled to byte code and cached too https://v8.dev/blog/code-caching-for-devs#use-service-worker-caches https://v8.dev/blog/code-caching-for-devs#use-service-worker...
- youngtaff 4y agoFrom the post > For example, for a simulated user visiting the Universal Credit start page on a low specification device and 2G mobile connection, we can clearly see from the graph where the jQuery change was made. Even if the cost of jQuery can be amortised over multiple page views in a session, someone's still got to have a successful first page view before they can view any more For a service like Universal Credit that's aimed at the less well off then cheap i.e. slow devices, and mobile connectivity means that the service has to be as easy to access as possible
- myfonj 4y agoYes, but still no notion if it was really just that "Universal Credit *start page*" [1] load measured or if it was some more realistic scenario, like, you know, navigating to some page that this guidepost links to. Loading just the start guidepost does not make much sense from the user's perspective. Again, I really do not want to attack their conclusions, I'm just curious how much (if at all (!)) would browser cache be beneficial here. (I'm not even sure browser generally caches once parsed chunks, but I assume they probably do.) [1] https://www.gov.uk/universal-credit https://www.gov.uk/universal-credit (presumably)
- simonw 4y agoMy guess would be that the vast majority of people who visit government websites are doing it very infrequently and are highly likely to arrive with a cold cache.