It’s so nice to know that someone still case about web performance. In a world where it’s quite normal to see website with static information and 1-5MB of compressed JS, which takes long time to load and makes your device hot
The impact of removing jQuery on our web performance
251–260 of 283 posts
Re: The impact of removing jQuery on our web performance
#252Earlier quoted context omitted.
Even as someone who's largely ripped out jQuery for vanilla JS I still totally understand why people use the API. Vanilla JS is terse comparative to jQuery short-hand syntax, especially for simple event bindings. Sure, I think jQuery these days is largely legacy developer ergonomics... I admit there are parts of those ergonomics that I miss. Especially when comparing it to modern tool-heavy transpiled/compiled/whatev…
> Vanilla JS is terse comparative to jQuery short-hand syntax, especially for simple event bindings. You mean "verbose" here, probably?
Ah yea you're right - I misspoke. Vanilla JS feels verbose, and jQuery feels more terse in regards to general syntax.
---
document.querySelector('#sel').addEventListener('click', (e) => {})
Feels way more verbose than the following:
$('#sel').on('click', (e) => {})
My bad - apparently the coffee hadn't sunk in yet ha.
Re: The impact of removing jQuery on our web performance
#253Earlier quoted context omitted.
fetch() can definitely be aborted, and what "older browsers" don't support fetch? You must be talking maybe about Internet Explorer 11, the only older browser that is still somewhat used (in Japan and public/old infra) that doesn't support it? https://caniuse.com/fetch
From that page, it appears that older versions of Android Chrome don't support fetch at all. I've seen stats that indicate that 5% of the U.S. population (to say nothing of other parts of the world) are still on Android Oreo (version 8), which wouldn't surprise me since older phones are basically locked in time.
Unlike on iOS, I don't think the browser version is tied to the operating system anymore? Besides the AOSP browser that no one uses
Re: The impact of removing jQuery on our web performance
#254Earlier quoted context omitted.
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%…
> Performance matters, a lot. Developers really don't care. They will claim otherwise with great conviction, but its all posturing and bullshit. If developers did care they would measure everything and challenge popular assumptions. Instead most developers want to randomly guess at what works and instead talk about tools. That's why most pages will never come close to being vaguely fast. 9 seconds is still really slo…
The folks who pay developers get what they pay for. Management sets priorities, not developers.
Re: The impact of removing jQuery on our web performance
#255That's nice but when you load the actual universal credit login page it needs nearly 400kb of reactjs - not sure about after that, don't have an account.. Some (most?) of the other gov uk sites have megabytes of js on them.. eg. https://coronavirus.data.gov.uk/details/testing?areaType=nat...
Yea, I was shocked they talk about stripping jQuery as if they have these super fast, snappy pages and then ... it's React. WHAT? React is a lot if things to a lot of people, but fast loading (on an underpowered device with bad connection, which are the conditions they're talking about) isn't one of them. When I imagine a grandma trying to login into a gov site and loading a meg of react related garbage which then runs like ass anyways, I want to punch a Zucc in his cold blooded alien dick.
Re: The impact of removing jQuery on our web performance
#256Earlier quoted context omitted.
> Vanilla JS is terse comparative to jQuery short-hand syntax, especially for simple event bindings. You mean "verbose" here, probably?
Ah yea you're right - I misspoke. Vanilla JS feels verbose, and jQuery feels more terse in regards to general syntax. --- document.querySelector('#sel').addEventListener('click', (e) => {}) Feels way more verbose than the following: $('#sel').on('click', (e) => {}) My bad - apparently the coffee hadn't sunk in yet ha.
OT note: sel.onclick=e=>{} works just fine. https://jsfiddle.net/39h5ynga/
Re: The impact of removing jQuery on our web performance
#257Earlier 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?
Safari has done it for a long time, Chrome and the others more recently.
Even back in 2012 people were raising the question of whether shared caching of libraries from the public JS CDNs was effective — due to too many different versions in use, and content being evicted from the browser cache sooner than most expected
Re: The impact of removing jQuery on our web performance
#258Earlier quoted context omitted.
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%…
Has anyone been able to reproduce this "Google Research" that is so often quoted? They have numbers related to conversion too. I know I'm sounding doubtful but bringing response time down a second or so isn't a magic potion for more money pouring in the door. Not that anyone should ignore performance. It's irresponsible to ignore perf. I just know from experience, when buying something on Black Friday at Amazon, if t…
The Google Research that is often quoted might have been well intended, but is grossly overstated and misused.
The thing with bounce rate is that you don't know WHY the user bounced nor did you know their intent. Typically analytics aren't even loaded yet. Sure enough I believe there to be a correlation forming as you dramatically increase page response time, but you still cannot attribute a high bounce rate to performance alone, which the often quoted line does imply.
Case in point, most of Google's properties don't even come close to their own performance guidelines.
Re: The impact of removing jQuery on our web performance
#259Earlier quoted context omitted.
In addition to which, jQuery was actual useful - React is just pure overhead with no real functionality.
React's core functionality is to manage the relationship between state and the dom. jQuery lets you imperatively manipulate the dom. They're different use cases; calling one useful and the other not isn't a very accurate representation.
No, React’s strength is to componentize your webapp, allowing several teams to work on objects that can be reused by each other.
Re: The impact of removing jQuery on our web performance
#260The 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%…
I need no convincing that performance matters, I'm a performance engineer by profession. You're kind of contradicting yourself. The numbers you use (100ms, 1s, 3s, etc) are well researched performance perceptions linked to our biology, in a way they are timeless guidelines.
That scale of attention span places both 9s and 12s in the exact same box: you've completely lost your user's train of thought.
Is 9s better than 12s? Obviously, yes. But that wasn't the point. My point was that there is such a thing as diminishing returns. If I were to follow your train of thought (performance absolutism), we should next optimize for WAP, if you're old enough to know what it is.