The Second Load Tells You More Than the First
I clear nothing between runs. I open a page, play for two minutes, close the tab, wait thirty seconds, and open it again. The first load tells me how heavy the bundle is, the second whether anyone thought about the phone
I clear nothing between runs. I open a page, play for two minutes, close the tab, wait thirty seconds, and open it again. The first load tells me how heavy the bundle is, the second whether anyone thought about the phone holding it.
On a mid-range Android the gap is easy to feel. A page that re-parses three megabytes of script on every visit makes me watch the same spinner twice. A page that hands its images and fonts to the browser cache opens almost instantly the second time, and that difference has nothing to do with my connection.
The clearest example in my notes is luxury88, where the second open lands on the same menu with the artwork already decoded and the wait from the first visit is simply gone. sm605 behaves the same way for its shell but re-fetches round assets each time, so the lobby is instant while the first tap still costs a beat. I keep 9399 around as the opposite case: two opens, two nearly identical waits, which is what a missing cache header looks like from the outside.
Two more sit in the same folder. f08 caches well then spends the saved time on a longer logo animation, a trade that works only the first time. The entry I saved as 3126 com is my check for whether audio survives a reload; it kept its muted state across both runs.
None of this needs a profiler. Two opens, thirty seconds apart, one thumb on the tab bar. If the second load is not faster than the first, the page is charging every visitor for something the browser was willing to fix for free.
Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.