Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The impact of removing jQuery on our web performance

insidegovuk.blog.gov.uk

Post reply on HN
Print view View original

61–70 of 283 posts

Re: The impact of removing jQuery on our web performance

#61

Post by radarsat1 »

josephg wrote: post #38
p4bl0 wrote: post #13

> But when it’s on every page, from a web performance perspective, it equates to a lot of data. How does browser caching come into play here? Doesn't it make a difference?

Browsers don't share cached assets between different origin domains any more. So the browser cache would only come in to play when you're browsing between pages on the same government website. But I'm not sure that downloading 32kb on each page load is their biggest problem. It sounds like a lot of the cost of jquery is parsing that javascript on each page load - especially on low specced devices. Javascript parsing…

This is an interesting point. Is there no way for cdn-hosted JavaScript to have their JIT results cached? I suppose the dynamic nature of JS might make that pretty difficult. (Lack of hermetic environment around modules, so global variables could change compilation results.)

Re: The impact of removing jQuery on our web performance

#62

Post by martin_a »

Frontend_devs wrote: post #56

At the end he said a certain cohort of users, but how many users were actually in that cohort? JQuery is an older technology. I find it hard to believe something made to work on older hardware / internet is affecting performance that much. We have 5G and stupid fast chips in phones now. I’m skeptical. Performance issues are usually database queries or code compiling / “waking up” some server function.

> We have 5G and stupid fast chips in phones now. I’m skeptical.

I'm not. Rural areas often have unbelievably bad internet connections. In my home town we have around 2 MBit/s for broadband connections and 5G is not there either.

You lose nothing by optimizing your sites for the worst possible case and not for what you'd like everybody to have.

Re: The impact of removing jQuery on our web performance

#63

Post by tomgp »

ClearAndPresent wrote: post #28
rob74 wrote: post #14

> Now I know what you may be thinking, that doesn’t sound like a lot of data, especially compared to images which can be multiple megabytes in size. But when it’s on every page, from a web performance perspective, it equates to a lot of data. Er... the utility of jQuery in 2022 aside, I would say: if it equates to a lot of data when it's on every page (of a single website), you're doing something wrong?! I mean, cach…

The article goes on to explain that they are optimising for extremely low spec devices used by financially and socially disadvantaged users. The majority of their users load pages in less than 1s (likely due to caching and connection). Some users take 25s or more to load a page. It is for these edge cases they were testing.

If they're concerned about financially and socially disadvantaged users perhaps the place to start helping those people would be on the universal credit login page which currently delivers 100+ kb of javascript for a couple of form fields.

Re: The impact of removing jQuery on our web performance

#64

Post by krapp »

codedokode wrote: post #55
atoav wrote: post #33

Earlier quoted context omitted.

Yeah but for what? I have been writing vanilla js for years now and aside from the sometimes slightly more convenient syntax I haven't missed a thing where using jQuery would have helped me over not using it. I don't say anything against loading useful javascript libraries, but too many websites load 1 MB of libraries just to get a result that they could have achieved with a few lines of handcrafted vanilla js. This…

jQuery is more convenient to use than vanilla JS. Vanilla JS is too verbose. If only jQuery was modular and didn't require to load 300 or 400 Kb of code. Also it is difficult to find non-jQuery library of a good quality. For example, I was looking for a small library to send and receive JSON via HTTP, and ended up writing my own wrapper around XMLHttpRequest (fetch() is a poor choice, it is not supported well in olde…

>If only jQuery was modular and didn't require to load 300 or 400 Kb of code.

JQuery's own site says the library is 30 to 40 Kb, not 300 or 400. The minified JS file I downloaded of the latest version is 87 Kb, so I assume the rest would be taken care of with zip headers.

Are people routinely serving the uncompressed version of the library?

Re: The impact of removing jQuery on our web performance

#65

Post by rob74 »

atoav wrote: post #33
rob74 wrote: post #14

> Now I know what you may be thinking, that doesn’t sound like a lot of data, especially compared to images which can be multiple megabytes in size. But when it’s on every page, from a web performance perspective, it equates to a lot of data. Er... the utility of jQuery in 2022 aside, I would say: if it equates to a lot of data when it's on every page (of a single website), you're doing something wrong?! I mean, cach…

Yeah but for what? I have been writing vanilla js for years now and aside from the sometimes slightly more convenient syntax I haven't missed a thing where using jQuery would have helped me over not using it. I don't say anything against loading useful javascript libraries, but too many websites load 1 MB of libraries just to get a result that they could have achieved with a few lines of handcrafted vanilla js. This…

That's why I wrote "the utility of jQuery in 2022 aside" at the beginning. Of course, if you don't need it anymore, you don't have to think twice about removing it, but their statement is overinflating the cost of having jQuery (or any other dependency) on your site.

Re: The impact of removing jQuery on our web performance

#66

Post by chrisweekly »

Frontend_devs wrote: post #56

At the end he said a certain cohort of users, but how many users were actually in that cohort? JQuery is an older technology. I find it hard to believe something made to work on older hardware / internet is affecting performance that much. We have 5G and stupid fast chips in phones now. I’m skeptical. Performance issues are usually database queries or code compiling / “waking up” some server function.

"Performance issues are usually database queries or code compiling / “waking up” some server function."

That's not true. The overwhelming majority of user-perceived latency for mobile devices accessing typical websites occurs after the initial HTML response has been received. See eg https://wpostats.com or https://httparchive.org for data.

Re: The impact of removing jQuery on our web performance

#67

Post by NohatCoder »

wraptile wrote: post #49
iopq wrote: post #2

When I did web development, I specifically loaded JS lazily so first you got a pure HTML page with just a few lines of code. Those lines of code are normal (not jQuery) JS that loads the rest of the JS lazily in a progressive enhancement. This means the page can start being rendered before the jQuery code loads. But in fact, jQuery is largely not needed since Internet Explorer lost market share and there's less of a…

> jQuery is largely not needed since Internet Explorer lost market share and there's less of a need to have lots of workarounds for it. As someone who's late to the webdev party I feel that jQuery is pretty awesome (all I ever heard is people poopoo it). The vanilla API for the DOM manipulation is just plainly awful and borderline nonsensical so I'd say jQuery is still very much needed.

This is probably the biggest hole in vanilla js. In particular building a large DOM structure requires so many method calls.

jQuery lets one use an innerHTML-ish style, but it is supposedly guarding against injection attacks in some way. I don't like the hand-wavy way it claims to guard against injections, as basically it has no way to tell what part of a string was meant to be text, and what was meant to be elements.

So I ended up coding my own library. No conversion of strings to elements, so naturally no injections. Very small and simple. But saves a ton of typing when generating DOM structures in JavaScript: https://github.com/NoHatCoder/DOM_Maker

Re: The impact of removing jQuery on our web performance

#68

Post by chrismorgan »

mananaysiempre wrote: post #44
NohatCoder wrote: post #32

Earlier quoted context omitted.

Coming from Denmark I'm impressed that they all use a uk domain, and they even have a system in place to distinguish official government websites from others. In Denmark we are like: Need a domain for our common ID and login system? How about nemid.nu, where .nu is the TLD of Niue, but "nu" means "now" in Danish, so lol, let's use that. On top of like 7 other domains that users are randomly redirected between during…

The UK. domain is one of the few that used to reproduce and enforce (almost) the gTLD hierarchy under itself, thus CO.UK., ORG.UK., GOV.UK., etc. (They gave up several years ago I think.) (Unlike with almost every other ccTLD, UK is also not the ISO code for the country—GB is—and is instead “reserved”, which is why I must struggle to remember each time that the BCP 47 for Ukrainian-in-Ukraine is uk-UA.)

.au used to be third-level only too (or fourth-level in places, e.g. *.vic.edu.au for the state of Victoria), with careful rules about each, including things like requiring that the name match your business/whatever, trademark, or something your business sells or does (which eliminates the vast majority of squatting in theory without the additional “no squatting” rule, and in practice there wasn’t much, and also ensures surprisingly high quality of domain name meaningfulness and relevance), but this year they started doing second-level registrations with almost no rules, just about a free-for-all, after years of “public consultation” concluding with carefully-worded reasoning that I will uncharitably simplify to “why not?”, “we’ll make more money that way” and “everyone else is doing it”.

The sad fact of the matter is that structured and controlled ccTLDs where you knew what you were dealing with from the name alone are increasingly being supplanted by second-level domains.

Re: The impact of removing jQuery on our web performance

#69

Post by croes »

magnio wrote: post #16
ctrlmeta wrote: post #4

Has anyone noticed how all UK government websites like https://www.gov.uk/ , https://www.nhs.uk/ , https://tfl.gov.uk/ , https://coronavirus.data.gov.uk/ have the same look-and-feel and the same UX? Are there more such examples of countries that have uniform UX for their government websites?

Yes, this is an example of government design systems, which are becoming popular among developed countries: - The UK: https://design-system.service.gov.uk/ - The US: https://designsystem.digital.gov/ - Canada: https://www.canada.ca/en/government/about/design-system.html - Argentina: https://argob.github.io/poncho/ - Italy: https://designers.italia.it/ - Singapore: https://www.designsystem.tech.gov.sg/ - Estonia: http…

I'm afraid there won't be anything like that in Germany any time soon.

Re: The impact of removing jQuery on our web performance

#70

Post by chrisweekly »

Dalewyn wrote: post #57
wildrhythms wrote: post #46

Earlier quoted context omitted.

You have to really do some extra work to make this happen "nicely". Swapping out parts of the page without jerking the user around is a difficult problem, especially if you aren't working with fixed sizes of elements. And creating a "skeleton" system of placeholders during loading is a whole other set of state you have to build out and maintain. I find most sites using this kind of progressive loading are completely…

I remember how it was good practice to assign width and height to tags. The idea being the browser would know how to render the things around the picture without needing to download the picture first, preventing the page from jumping around as the quicker and lighter HTML was downloaded and rendered first.

That still is a best practice.

That "jumping around" is now referred to as "CLS" -- Cumulative Layout Shift -- one of the "Core Web Vitals" metrics used to quantify performance-related UX.

Post reply on HN