> 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
Yes, 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.)
My 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.
> 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