[acdha]

Note that WebPageTest supports repeat tests for exactly this reason - that closes the browser and restarts it without clearing the cache. Here’s what that looks like - it helps the first render a lot (0.5 vs 1s) but the largest paint is still 7s: better than 11 but still pretty slow.

https://www.webpagetest.org/result/220921_BiDcBJ_GQX/

One big thing to remember is that browser caching only works if you aren’t shipping updates frequently (bundlers have been an anti-pattern for many sites for the last few years) and aren’t storing too much. On mobile in particular a lot of sites load enough junk that they fall out of the cache. I use Twitter only via their web app and the page load time on a fast iPhone is still like 10 seconds or worse, when a well-optimized HTML page can be in the hundred of milliseconds.

[kyle-rb]

Browser caching is nicer with service workers - you can use the cached version and load/install the updated version in the background, so that the user can get the updated version on their next refresh.

[acdha]

That’s a nice improvement but it still hits the cache size issues and it creates some hard problems you have to get right (“why didn’t reload fix it?”).

Not everyone has the resources to support that level of investment and there’s a pitfall in the middle where you get the costs but don’t see the desired benefits.

[Self-Perfection]

That is way alternative frontends for bloated websites exist. For instance, one can read twitter via nitter, which uses zero JavaScript. Check how fast it loads: https://nitter.privacy.com.de/SpaceX/status/1571950786896330...