The impact of removing jQuery on our web performance

Post by recursive » Tue, Aug 16, 2022, 4:52 PM UTC

exodust wrote: post #209

youngtaff wrote: post #151

Earlier quoted context omitted.

Won’t work Browser caches are partitioned by origin so if a.com and b.com both use jquery from c.com then two copies of jquery will be cached one with a key of a.com/c.com and another with b.com/c.com

Have browsers always done this? I thought and heard that using a JS library from CDN is beneficial when users already have that same cached JS library from visiting other sites. But you're saying that's not a thing? So what's the benefit of using a CDN for jquery then?

Post by jorts » Tue, Aug 16, 2022, 5:11 PM UTC

GuB-42 wrote: post #188

fleddr wrote: post #154

The team at gov.uk is doing an excellent job regarding web performance, credit where credit is due. In many ways role model behavior. Still, the results are such a stretch as to not have that much meaning. They have to descent all the way to 2G to see any meaningful difference, and I'm assuming they are cold visits (typical in lab-based testing). For those exceptional users, this creates a difference from very poor (…

12 seconds down to 9 seconds is not negligible. What is negligible is 12 down to 11.999 seconds because you prematurely optimized. And even for "normal" users, shaving milliseconds matter. The general idea is that a UI should respond within 100ms to feel instantaneous. More than 1s and you interrupt the flow of thought. According to Google research, increasing page load time from 1s to 3s increases bounce rate by 32%…

Post by tryfinally » Tue, Aug 16, 2022, 5:16 PM UTC

teknopaul wrote: post #116

chrisweekly wrote: post #70

Earlier quoted context omitted.

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.

I sometmes like CLS, it makes it look like things are happening instead of feeling like a wait time. I recently used a simple templating mechanism elem = jquery.clone() ... elem.slideDown() And this renders bits of the page moving them as it does it; slideDown() is in jquery core. It used to be popular before that biz of rendering grey squares first got invented

Post by simonw » Tue, Aug 16, 2022, 5:23 PM UTC

codedokode wrote: post #137

simonw wrote: post #78

Earlier quoted context omitted.

I'm with you on fetch() requests not being able to be aborted, but I didn't think there were any other reasons to use XMLHttpRequest over fetch in 2022. I've been fetch() only for a few years as this point - what older browsers are you targeting that don't support fetch()?

Internet Explorer and older browsers support is important too. You must support browsers released within last 10 years and fetch is too new and experimental for this. I don't want to use something just because it is new and has no clear advantages over older technology.

Post by [deleted] » Tue, Aug 16, 2022, 5:42 PM UTC

dccoolgai wrote: post #190

fleddr wrote: post #154

The team at gov.uk is doing an excellent job regarding web performance, credit where credit is due. In many ways role model behavior. Still, the results are such a stretch as to not have that much meaning. They have to descent all the way to 2G to see any meaningful difference, and I'm assuming they are cold visits (typical in lab-based testing). For those exceptional users, this creates a difference from very poor (…

Exactly. It was cute for a few years, but these jQuery bashing thoughtpieces are so worn out now. As React and the long tail of frameworks slides into it's twilight years, it's clear in retrospect that jQuery was just a much more responsible and sound architecture (mostly because it cleaved to standards) than any of the things that spawned the 1000 "why I'm leaving jQuery for _this_" blogposts every day.