41–45 of 45 posts
For anyone thinking that this is an insignificant saving of "only" 32kb, it's really important to remember that many of the site's users will be amongst the poorest in society. Many of them will be accessing it using the oldest, slowest devices; things far slower than the average HN reader's last few phones. Anything that can be done make the site work better for them is worth the effort. Terence Eden has a really go…
For anyone thinking that this is an insignificant saving of "only" 32kb, it's really important to remember that many of the site's users will be amongst the poorest in society. Many of them will be accessing it using the oldest, slowest devices; things far slower than the average HN reader's last few phones. Anything that can be done make the site work better for them is worth the effort. Terence Eden has a really go…
If you load www.gov.uk, you'll see it's loading several fonts (each of which is roughly equal to the size of jquery), google analytics, several javascript bundles, and other crap. It is far from simple effective HTML as described by the link. jQuery is probably the least of their problems. And ironically, the blog with the jquery article on it loads jquery! I realize it's not part of the same site.
"jQuery is probably the least of their problems" : they also explicitly said that removing it was a low-priority background task, yet I like that mindset where they care about people having low-bandwidth or low-end devices "removing jQuery means that 32Kb of JavaScript has been removed from the majority of pages on GOV.UK. GOV.UK is already quite fast to load and for many users this will make no noticeable difference. However, the change for users on a low bandwidth connection or lower specification device will be much more noticeable, resulting in significantly improved page download speed and performance"
Earlier quoted context omitted.
>For a government entity, an unreasonably large amount of their work is on GitHub. Perhaps GitHub shouldn't be the venue, but I think you have that backwards. Most government entities share unreasonably little of their code.
Yea my bad! I mean that "an unreasonably large amount of their work is publicly available."
But it is surprising to see!
They presume a "problem" is loading 32KB of data and the fix was spending a lot of tax dollars to replace it? Insane.
It's an accessibility problem. GOV.uk is the official government website that contains key information that must be made available to every UK resident. If shaving off 32K of JavaScript makes the website easier to load for people with extremely bad hardware, then it's worth it. BTW, the UK doesn't use dollars.
They presume a "problem" is loading 32KB of data and the fix was spending a lot of tax dollars to replace it? Insane.
They do not "presume" anything. They state clearly that the old version of the library was causing performance problems. They also state that 32k is noticeable on slow connections, which it absolutely is. In fact, on unstable connections, it can mean the difference between the site loading and not loading. Reliability is critical for government services. They also mention that the work improved the codebase and the d…
> We’ll provide more detail about exactly what that means in the next blog post.
The whole premise of the article is conjecture until we see the performance numbers presented. The claim is that removing a one-time load 32kB library is useful to page load times and user experience for low end users. It has ZERO specifications or performance numbers cited.
Besides which, the net effect of more data on a page is that it takes a little longer to load the page. For someone who has a slow phone, they are conditioned to this through use of other sites (or even clicking on the housing link at the top of the UK Gov site and waiting for a 360kB image to load). What is the advantage of speeding it up for them for a single site they may or may not use?
Will we also take it upon ourselves to justify anything that makes them click on the wrong link and have to wait to go back? Unlikely.