15 ms·

We rendered a million web pages to find out what makes the web slow

182 points by simonpure 6y ago

Grustaf 6y ago
Is it “ads”?
- fckthisguy 6y ago
  It is!
Santosh83 6y ago
Ads are usually the number one culprit why simple "news" pages take sometimes dozens of seconds to finish loading, (and in some egregiously engineered designs, the page is unusable until every last script/ad and font has loaded), and spawn several processes and consume hundreds of megabytes of memory and utilise 50% of your i7/i9 3000MHz CPU, all for displaying a news page or an article. The JS for actual essential site functionality often pales in comparison to the assets and scripts activated by ads, which simultaneously track you.
- mjevans 6y ago
  Also the accursed videos every site wants to cram down your throat. No no no. Mostly text, MAYBE some images.
  - EForEndeavour 6y ago
    Anyone who directs their web team to implement a floating picture-in-picture autoplay video whose pause and close buttons either render late or don't work at all deserve a special place in hell.
  - krylon 6y ago
    There used to be an add-on (or was it even built-in?) to block loading videos and images unless explicitly requested by the user. I sometimes still miss that, especially on mobile.
- underwater 6y ago
  It's not just the ads. Tag managers are the scourge of performance. Marketing folk just want to stuff them full with dozens of analytics services and third party integrations. And they want to do that without involving pesky engineers. Some, like Google Optimize, tell you to to clobber performance by hiding all content on your page using CSS until their code has loaded and run.
- tabtab 6y ago
  In other words, ads and tracking are given priority over content. Welcome to Capitalism!
sneak 6y ago
> There's a handful of scripts that are linked on a large portion of web sites. This means we can expect these resources to be in cache, right? Not any more: Since Chrome 86, resources requested from different domains will not share a cache. Firefox is planning to implement the same. Safari has been splitting its cache like this for years. [most of the top common resources are Google (and FB) ad tracking] I read this as Google is willing to spend millions upon millions to move huge amounts of additional unnecessary network traffic to make sure only they can reliably track most people across the whole of the web.
- minitoar 6y ago
  Gotta spend money to make money
- ivanbakel 6y ago
  Even if Google didn't have a stake in targeted advertising, shared caches lead to easy identification - browsers have a duty to close off any avenue by which users can be tracked.
- damagednoob 6y ago
  I don't use any externally hosted scripts on sites I develop. Security is part of the reason but the bigger problem I find is tying uptime to somebody else whom I have no control over.
dubcanada 6y ago
What is Amazon Publisher Services, is it a tracking script or something? I've never heard of it.
- tyingq 6y ago
  Basically their version of AdSense. Integrate Amazon shopping ads into your content.
SimeVidas 6y ago
Off topic: I haven’t visited one million websites (yet), but I can already tell you that your sticky header is annoying.
- ben509 6y ago
  Sticky Ducky is a nice plugin for that.
mfontani 6y ago
And... surprise! It's analytics, tracking, and advertisements!
- deleted 6y ago
  [deleted]
- Kaotique 6y ago
  Improve the web and the world: remove all garbage third party javascript from your site.
  - Mauricebranagh 6y ago
    Its more the CopyPasta of god knows how many JavaScript frameworks.
    - underwater 6y ago
      It's really not. I ran the website for a large news org. Even without ads third party JS was loading twice as many bytes as our React and first party code. The YouTube embed, alone, was larger than our entire first party JS. What are you going to do as an engineer? Tell sales that expensive marketing solution they bought isn't going onto the site because it loads too much JS?
      - Mauricebranagh 6y ago
        There is that as well - you must have much better developers than most sites. And some times you have to let things fail and then explain why it di and then do it right
  - fckthisguy 6y ago
    I did just that and it's surprisingly heart warming to know my site could run on a calculator if need be. No JS, no tracking, no nonsense. 100% content.
- georgeecollins 6y ago
shadowgovt 6y ago
The speed correlation with HTTP 0.9 and HTTP 1.0 is interesting. While it is probably more the case that newer protocols are serving newer content which is slower for myriad reasons, I find myself wondering if there are interesting correlations regarding what's being served by older protocols. Is it the case the content on the older protocols is living in an intersection of mission critical to somebody (so it has never gone away due to simple lack of maintenance) and either sufficiently functional as is that nobody has seen a need to upgrade its infrastructure, or too deeply tied into a consumer that assumed quirks of a protocol for upgrading to be tractable? It would be interesting to get a drill down on what is being served on those protocols.
- joshspankit 6y ago
  I would read that followup article.
- giantrobot 6y ago
  I'd be willing to bet (a very small sum) that the HTTP 0.9 and 1.0 servers encountered are app servers/frameworks. They're simpler to implement than HTTP 1.1 and don't set expectations on the client they can't meet. When you've got a fleet of machines behind load balancers you don't need things like a Host field to support vhosts since it's one site to a host. You also don't need pipelining because each connection is a one and done operation.
superkuh 6y ago
It's in the domain name: catchjs. The reason that the web is slow now is javascript. That is, treating a webpage like an application instead of a document. This analysis just assumes all websites are JS-application monsters and only differentiates between them. It misses the point. What makes it even slower is the practice of serially chain loading JS from multiple domains. Once you're 3 deep in that it doesn't matter how 'fast' your webserver is or how fast and clean your JS code is, the serial loading will slow things to a crawl.
- k__ 6y ago
  I don't know what kind of web you are using. But The sites I'm visiting on a daily basis are, in fact, applications and not documents. Slack, Asana, GitHub, Gravit Designer, Google Docs/Sheets/Mail...
  - phreeza 6y ago
    The sad reality is that many of these actual applications load faster than pages that could really just be pages but still load vast amounts of JS...
    - k__ 6y ago
      Yes. Probably because people who create "real apps" and not just "docs on steroids" know what they're in for right from the start. If you start with a doc, you can get the feeling that there is much more headroom than there actually is.
    - jug 6y ago
      Static website generators in contexts where they make sense (heaps of the web) are still criminally underused. :-(
  - superkuh 6y ago
    Of those I only go to github. And for now it still works without javascript execution. Sites that want or have to serve everyone do not use the web as an application because they know it doesn't work. Gov.uk and amazon.com for example went out of their way to work for all people of the world. And Gov.uk has found approximately 1 in 96 actual people do not have JS turned on[1]. For fancy businesses with other businesses as their end users you can get away with not supporting everyone. It doesn't effect their income so it doesn't matter. But the reality is that JS-application sites fail 1% of users and for actually serving everyone that 1% matters. [1] https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out-on-javascript-enhancement/ https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...
ffpip 6y ago
https://ublockorigin.com https://ublockorigin.com Install this wonderful extension to save hours of your time and gigabytes of your bandwidth.
- kowlo 6y ago
  Any good alternative for Safari? I knew I would get alternative browser recommendations because of my phrasing... but I was also looking forward to them!
  - hetspookjee 6y ago
    Firefox. But kidding aside, for what I've found on adblocks for Safari you need to pay and I believe those are quite inferior in blockage to uBlock.
    - S_A_P 6y ago
      Have to agree here. I actually quite like safari, but cant use it due to no uBlock Origin which is unfortunate. uBlock and Facebook Container have made all the difference for me.
    - jws 6y ago
      If you are in the "I wish Safari blocked ads" boat but don't know where to go, let me recommend an out… There are a lot of reasonable choices, I've been using Wipr for years. It does a good job of blocking ads and costs about $2. There are macOS and iOS versions, they update their lists, and because of the architecture have no access to your browsing so can never be tempted to start farming you. (No affiliation, I haven't done an extensive comparison, but this one works and isn't expensive and you can stop worrying about what to do if you do this now.)
    - deleted 6y ago
      [deleted]
  - hpoe 6y ago
    I find Firefox to be a great alternative for Safari. I joke but from what I know it is only available for Firefox and it either will soon stop working/does not work on Chrome.
wruza 6y ago
Skimming through the article didn’t give a meaningful tl;dr - it’s complicated and there is no prevalent answer. Personally I got two (naive) things: - latency is bad, do a single request at start - don’t use jquery - ui frameworks are not part of the issue(?)
- franga2000 6y ago
  jQuery really isn't a problem - it's just a light-ish wrapper around the native JS APIs. The problem is JS itself or rather the fact that it's used where it really shouldn't be.
  - mjevans 6y ago
    jQuery isn't the problem as much as jQuery "needing" to exist is the problem. Developers still have to make webpages that work with customers that are stuck on old phones which will never see another firmware update, corporate desktops that have some forsaken frozen copy of IE6 that gets used for some legacy corporate platform (and then end users either don't or actually aren't allowed by IT/security to use any other browser), people with PCs that 'still work' (and if you're lucky have Windows XP with whatever it came with)... etc. Generally we can't have nice things because that legacy cruft is going to be around until all of that legacy falls over and dies so hard that even laypeople consider it laughable to assume it still works. It's got to be like those old blenders or fans... wait they still work; we're cursed forever. Want the Internet to be fast? jQuery is a defacto standard that needs to be made native in browsers and then when called for not loaded as script but already existing as native code and management models.
    - franga2000 6y ago
      Are those legacy-supporting sites really the slow ones though? Targeting old software usually also means targeting old hardware, so those sites tend to perform reasonably well (and in general, old browsers didn't give developers many options to slow things down). The problem really starts once developers can start ignoring old platforms and (ab)using the full power of a modern browser. The problem isn't any specific library, but the mindset developers use to develop web sites/apps. Bundling 20 dependencies and 10k lines of "compiled" JSX into one giant 5MB uncachable blob that needs to get parsed in its entirety, then shoot some requests off then need to complete, be parsed, then compile some HTML and CSS that then need to again get parsed by the browser and then finally, the the browser's rendering engine gets to start laying things out and drawing the first pixels - that is the problem. The browser is a document viewer, not an application runtime, so you should be giving it documents, not programs. Yes, JavaScript is necessary, but just like you shouldn't be using HTML for layout and CSS for content and graphics (although CSS-only art is impressive!), you shouldn't be using JavaScript for content and styling.
Kaotique 6y ago
It really shows why big tech own the keys to the internet. We hand them all our browsing history.
- wruza 6y ago
  The sites we visit do. I didn’t tell spammers my phone number either, but every org that requires that field to be filled thinks it has an obligation to sell it to them. Skipping few steps, it is trust problem. We don’t trust each other, thus some money should be spent on being top trusted and top wanted at open markets/serps. We have to trust big tech because staking money is the only way to the trust and biggest money concentrates at big tech. What should be done?
matylla 6y ago
This reminds me of an experiment [1] we run a couple months back. We crawled top 100 Alexa websites and check the bloat in the images served to billions of users. [1]: https://optidash.ai/blog/optimizing-images-on-the-worlds-top-100-websites https://optidash.ai/blog/optimizing-images-on-the-worlds-top...
- tyingq 6y ago
  That's really cool. It would be interesting to see what that 32% savings adds up to both for typical market bandwidth and AWS like egress rates. Curious, did your comparison ensure that none of the images lost any detail, etc? Or how much "lossiness" did you introduce to get the 32%?
  - matylla 6y ago
    Thanks for chiming in. It's a perceptually lossless optimization and recompression. We use saliency detection (trained on an eye-tracker) which tells us where the human vision system would look in the images and optimise those fragments (heatmaps) using our own comparison metrics. If you're interested in the details shoot me an email to przemek [at] optidash [dot] ai
- PeterWall 6y ago
  Thank you for sharing this. It's interesting to see that even these big websites potentialy still have a lot of room for improvement for their loading times.
tyingq 6y ago
JQuery being more prevalent than Google Analytics is a surprise to me.
- yurishimo 6y ago
  jQuery is a default dependency for many WordPress blogs. Not all of those are run by folks who want/care about analytics.
  - tyingq 6y ago
    Sure. I was assuming that culling to the "top million" would skew things in favor of GA. Clearly it didn't, but I was surprised. And you're probably right. All those Wordpress instances does drive a lot of the stats.
  - joshspankit 6y ago
    I had hoped at some point in the breakdown that they differentiated between Wordpress and.. everything else I guess. Wordpress itself probably skewed the numbers significantly.
- mschuetz 6y ago
  This is a good page that shows why JQuery isn't going away anytime soon: http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/
eric_trackjs 6y ago
Off-topic but I'd never heard of CatchJS before. As the founder of TrackJS[1] I can't help but feel they were heavily inspired by our product... almost too inspired considering their logo and marketing copy. (We've been around since 2014, so we pre-date them by 4 years) [1] https://trackjs.com https://trackjs.com
- morgosmaci 6y ago
  Wait a company logo about javascript that uses {}? Maybe thrown into a single color circle? Mild Shock. Edit: I will give you that their web page header and pricing looks very similar.
  - lars 6y ago
    Lars from CatchJS here. Anyone can go on archive.org and verify that they changed their color scheme and header to ones very similar to CatchJS in Feb 2020, after CatchJS had used that look for 2 years. Thank you for also pointing out the pricing page, where the same is true. I've now received a cease and desist from their attorney stating that the looks are too similar. It's nice that they've paid for an attorney to make my point for me, but they seem to have mixed up who did what here.
- trevor-e 6y ago
  You both have an incredibly generic logo/header/copy template so I'm not really sure what you're trying to imply. Your site copies the format of Stripe and they were around in 2010, pre-dating you by 4 years.
joosters 6y ago
The article talks about a million web pages, but it's actually the top million domains. This is an important difference because the top sites could be completely different to the web pages that we view. For example, Facebook is probably high up the list. But which Facebook page do they measure? The 'front page' of a non logged in user, presumably? That would be vastly different from the majority of FB users. Likewise, Wikipedia is also an extremely popular site. But surely most users are looking at specific pages of interest, and not just the front page?
btbuildem 6y ago
My guess would've been 1) ads / tracking and 2) bloated JS frameworks.
randompwd 6y ago
It's a blog article yet has no date on it. Why are these sites so obnoxious and secretive. Let us know when the blog was written. 34 days ago: https://news.ycombinator.com/item?id=25517628 https://news.ycombinator.com/item?id=25517628 (115 comments) https://itnext.io/we-rendered-a-million-web-pages-to-find-out-what-makes-the-web-slow-72bbba9ade96 https://itnext.io/we-rendered-a-million-web-pages-to-find-ou... (Dec 22, 2020 - repost from CatchJS) WRITTEN BY Lars Eidnes Chief error catcher at https://catchjs.com https://catchjs.com
ibraheemdev 6y ago
Previous discussion: https://news.ycombinator.com/item?id=25517628 https://news.ycombinator.com/item?id=25517628
dvfjsdhgfv 6y ago
...and we discovered it's JavaScript. Most of it being just tracking code.
jzer0cool 6y ago
How about a standard how heavy the site (and other meta details) before it is loaded within the html spec? In this way, a user can opt out to continuing to browsing with details from say a short response header. Is something like already proposed anywhere, or not really a solution to the problem — thoughts?
spankalee 6y ago
dominteractive isn't a good metric for this. Many sites are perceivably slow because of rendering work they're doing after dominteractive. They should be looking at a more user-centric metrics like Largest Contentful Paint: https://web.dev/lcp/ https://web.dev/lcp/
jiveturkey 6y ago
a million? is that a lot?
bluesmoon 6y ago
This study is flawed for a few reasons that I'd mentioned to the author when it was first published, but they ignored my comments. The main problem is that they confuse DOMInteractive for Time To Interactive. The two events are very different. DOMInteractive is a legacy event that refers to the time when JavaScript can safely interact with the DOM. This really has nothing (or very little) to do with user experience. Time to Interactive, on the other hand, is the time when a user can expect the page to respond quickly to interactions (clicks, scrolls, keypresses), ie, these user interactions should have no user perceivable latency. This is not a metric that has a corresponding browser event. It requires a bunch of post-processing based on various events. The researchers have made no attempt to calculate TTI. Source: I've been working in this area of research for 15 years.
- Abishek_Muthian 6y ago
  > I've been working in this area of research for 15 years Is the outcome of the research by CATCHJS different from what you have learnt?
  - bluesmoon 6y ago
    Some recent results are at https://tech.bluesmoon.info/2020/11/understanding-emotion-for-happy-users.html https://tech.bluesmoon.info/2020/11/understanding-emotion-fo...
- andrewmcwatters 6y ago
  What way would you suggest measuring this? Duration between TTFB and when user events first get pumped?
  - bluesmoon 6y ago
    The simplest way to measure impact on users would be to just use boomerang which gets you all of this out of the box: https://github.com/akamai/boomerang https://github.com/akamai/boomerang To do it yourself, you need a combination of PainTiming and measuring LongTasks or study the periodicity of setInterval/requestAnimationFrame The above works for synthetic as well as real users. If you're able to measure real users directly, then you'd also want to look at Input Delays, Rage Clicks, Dead Clicks, Missed Clicks, Scroll Jank.

182 points by simonpure 6y ago

Grustaf 6y ago

Is it “ads”?

fckthisguy 6y ago
It is!

Santosh83 6y ago

Ads are usually the number one culprit why simple "news" pages take sometimes dozens of seconds to finish loading, (and in some egregiously engineered designs, the page is unusable until every last script/ad and font has loaded), and spawn several processes and consume hundreds of megabytes of memory and utilise 50% of your i7/i9 3000MHz CPU, all for displaying a news page or an article. The JS for actual essential site functionality often pales in comparison to the assets and scripts activated by ads, which simultaneously track you.

mjevans 6y ago
Also the accursed videos every site wants to cram down your throat. No no no. Mostly text, MAYBE some images.
- EForEndeavour 6y ago
  Anyone who directs their web team to implement a floating picture-in-picture autoplay video whose pause and close buttons either render late or don't work at all deserve a special place in hell.
- krylon 6y ago
  There used to be an add-on (or was it even built-in?) to block loading videos and images unless explicitly requested by the user. I sometimes still miss that, especially on mobile.
underwater 6y ago
It's not just the ads. Tag managers are the scourge of performance. Marketing folk just want to stuff them full with dozens of analytics services and third party integrations. And they want to do that without involving pesky engineers. Some, like Google Optimize, tell you to to clobber performance by hiding all content on your page using CSS until their code has loaded and run.
tabtab 6y ago
In other words, ads and tracking are given priority over content. Welcome to Capitalism!

sneak 6y ago

> There's a handful of scripts that are linked on a large portion of web sites. This means we can expect these resources to be in cache, right? Not any more: Since Chrome 86, resources requested from different domains will not share a cache. Firefox is planning to implement the same. Safari has been splitting its cache like this for years. [most of the top common resources are Google (and FB) ad tracking] I read this as Google is willing to spend millions upon millions to move huge amounts of additional unnecessary network traffic to make sure only they can reliably track most people across the whole of the web.

minitoar 6y ago
Gotta spend money to make money
ivanbakel 6y ago
Even if Google didn't have a stake in targeted advertising, shared caches lead to easy identification - browsers have a duty to close off any avenue by which users can be tracked.
damagednoob 6y ago
I don't use any externally hosted scripts on sites I develop. Security is part of the reason but the bigger problem I find is tying uptime to somebody else whom I have no control over.

dubcanada 6y ago

What is Amazon Publisher Services, is it a tracking script or something? I've never heard of it.

tyingq 6y ago
Basically their version of AdSense. Integrate Amazon shopping ads into your content.

SimeVidas 6y ago

Off topic: I haven’t visited one million websites (yet), but I can already tell you that your sticky header is annoying.

ben509 6y ago
Sticky Ducky is a nice plugin for that.

mfontani 6y ago

And... surprise! It's analytics, tracking, and advertisements!

deleted 6y ago
[deleted]
Kaotique 6y ago
Improve the web and the world: remove all garbage third party javascript from your site.
- Mauricebranagh 6y ago
  Its more the CopyPasta of god knows how many JavaScript frameworks.
  - underwater 6y ago
    It's really not. I ran the website for a large news org. Even without ads third party JS was loading twice as many bytes as our React and first party code. The YouTube embed, alone, was larger than our entire first party JS. What are you going to do as an engineer? Tell sales that expensive marketing solution they bought isn't going onto the site because it loads too much JS?
    - Mauricebranagh 6y ago
      There is that as well - you must have much better developers than most sites. And some times you have to let things fail and then explain why it di and then do it right
- fckthisguy 6y ago
  I did just that and it's surprisingly heart warming to know my site could run on a calculator if need be. No JS, no tracking, no nonsense. 100% content.
georgeecollins 6y ago

shadowgovt 6y ago

The speed correlation with HTTP 0.9 and HTTP 1.0 is interesting. While it is probably more the case that newer protocols are serving newer content which is slower for myriad reasons, I find myself wondering if there are interesting correlations regarding what's being served by older protocols. Is it the case the content on the older protocols is living in an intersection of mission critical to somebody (so it has never gone away due to simple lack of maintenance) and either sufficiently functional as is that nobody has seen a need to upgrade its infrastructure, or too deeply tied into a consumer that assumed quirks of a protocol for upgrading to be tractable? It would be interesting to get a drill down on what is being served on those protocols.

joshspankit 6y ago
I would read that followup article.
giantrobot 6y ago
I'd be willing to bet (a very small sum) that the HTTP 0.9 and 1.0 servers encountered are app servers/frameworks. They're simpler to implement than HTTP 1.1 and don't set expectations on the client they can't meet. When you've got a fleet of machines behind load balancers you don't need things like a Host field to support vhosts since it's one site to a host. You also don't need pipelining because each connection is a one and done operation.

superkuh 6y ago

It's in the domain name: catchjs. The reason that the web is slow now is javascript. That is, treating a webpage like an application instead of a document. This analysis just assumes all websites are JS-application monsters and only differentiates between them. It misses the point. What makes it even slower is the practice of serially chain loading JS from multiple domains. Once you're 3 deep in that it doesn't matter how 'fast' your webserver is or how fast and clean your JS code is, the serial loading will slow things to a crawl.

k__ 6y ago
I don't know what kind of web you are using. But The sites I'm visiting on a daily basis are, in fact, applications and not documents. Slack, Asana, GitHub, Gravit Designer, Google Docs/Sheets/Mail...
- phreeza 6y ago
  The sad reality is that many of these actual applications load faster than pages that could really just be pages but still load vast amounts of JS...
  - k__ 6y ago
    Yes. Probably because people who create "real apps" and not just "docs on steroids" know what they're in for right from the start. If you start with a doc, you can get the feeling that there is much more headroom than there actually is.
  - jug 6y ago
    Static website generators in contexts where they make sense (heaps of the web) are still criminally underused. :-(
- superkuh 6y ago
  Of those I only go to github. And for now it still works without javascript execution. Sites that want or have to serve everyone do not use the web as an application because they know it doesn't work. Gov.uk and amazon.com for example went out of their way to work for all people of the world. And Gov.uk has found approximately 1 in 96 actual people do not have JS turned on[1]. For fancy businesses with other businesses as their end users you can get away with not supporting everyone. It doesn't effect their income so it doesn't matter. But the reality is that JS-application sites fail 1% of users and for actually serving everyone that 1% matters. [1] https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out-on-javascript-enhancement/ https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...

ffpip 6y ago

https://ublockorigin.com https://ublockorigin.com Install this wonderful extension to save hours of your time and gigabytes of your bandwidth.

kowlo 6y ago
Any good alternative for Safari? I knew I would get alternative browser recommendations because of my phrasing... but I was also looking forward to them!
- hetspookjee 6y ago
  Firefox. But kidding aside, for what I've found on adblocks for Safari you need to pay and I believe those are quite inferior in blockage to uBlock.
  - S_A_P 6y ago
    Have to agree here. I actually quite like safari, but cant use it due to no uBlock Origin which is unfortunate. uBlock and Facebook Container have made all the difference for me.
  - jws 6y ago
    If you are in the "I wish Safari blocked ads" boat but don't know where to go, let me recommend an out… There are a lot of reasonable choices, I've been using Wipr for years. It does a good job of blocking ads and costs about $2. There are macOS and iOS versions, they update their lists, and because of the architecture have no access to your browsing so can never be tempted to start farming you. (No affiliation, I haven't done an extensive comparison, but this one works and isn't expensive and you can stop worrying about what to do if you do this now.)
  - deleted 6y ago
    [deleted]
- hpoe 6y ago
  I find Firefox to be a great alternative for Safari. I joke but from what I know it is only available for Firefox and it either will soon stop working/does not work on Chrome.

wruza 6y ago

Skimming through the article didn’t give a meaningful tl;dr - it’s complicated and there is no prevalent answer. Personally I got two (naive) things: - latency is bad, do a single request at start - don’t use jquery - ui frameworks are not part of the issue(?)

franga2000 6y ago
jQuery really isn't a problem - it's just a light-ish wrapper around the native JS APIs. The problem is JS itself or rather the fact that it's used where it really shouldn't be.
- mjevans 6y ago
  jQuery isn't the problem as much as jQuery "needing" to exist is the problem. Developers still have to make webpages that work with customers that are stuck on old phones which will never see another firmware update, corporate desktops that have some forsaken frozen copy of IE6 that gets used for some legacy corporate platform (and then end users either don't or actually aren't allowed by IT/security to use any other browser), people with PCs that 'still work' (and if you're lucky have Windows XP with whatever it came with)... etc. Generally we can't have nice things because that legacy cruft is going to be around until all of that legacy falls over and dies so hard that even laypeople consider it laughable to assume it still works. It's got to be like those old blenders or fans... wait they still work; we're cursed forever. Want the Internet to be fast? jQuery is a defacto standard that needs to be made native in browsers and then when called for not loaded as script but already existing as native code and management models.
  - franga2000 6y ago
    Are those legacy-supporting sites really the slow ones though? Targeting old software usually also means targeting old hardware, so those sites tend to perform reasonably well (and in general, old browsers didn't give developers many options to slow things down). The problem really starts once developers can start ignoring old platforms and (ab)using the full power of a modern browser. The problem isn't any specific library, but the mindset developers use to develop web sites/apps. Bundling 20 dependencies and 10k lines of "compiled" JSX into one giant 5MB uncachable blob that needs to get parsed in its entirety, then shoot some requests off then need to complete, be parsed, then compile some HTML and CSS that then need to again get parsed by the browser and then finally, the the browser's rendering engine gets to start laying things out and drawing the first pixels - that is the problem. The browser is a document viewer, not an application runtime, so you should be giving it documents, not programs. Yes, JavaScript is necessary, but just like you shouldn't be using HTML for layout and CSS for content and graphics (although CSS-only art is impressive!), you shouldn't be using JavaScript for content and styling.

Kaotique 6y ago

It really shows why big tech own the keys to the internet. We hand them all our browsing history.

wruza 6y ago
The sites we visit do. I didn’t tell spammers my phone number either, but every org that requires that field to be filled thinks it has an obligation to sell it to them. Skipping few steps, it is trust problem. We don’t trust each other, thus some money should be spent on being top trusted and top wanted at open markets/serps. We have to trust big tech because staking money is the only way to the trust and biggest money concentrates at big tech. What should be done?

matylla 6y ago

This reminds me of an experiment [1] we run a couple months back. We crawled top 100 Alexa websites and check the bloat in the images served to billions of users. [1]: https://optidash.ai/blog/optimizing-images-on-the-worlds-top-100-websites https://optidash.ai/blog/optimizing-images-on-the-worlds-top...

tyingq 6y ago
That's really cool. It would be interesting to see what that 32% savings adds up to both for typical market bandwidth and AWS like egress rates. Curious, did your comparison ensure that none of the images lost any detail, etc? Or how much "lossiness" did you introduce to get the 32%?
- matylla 6y ago
  Thanks for chiming in. It's a perceptually lossless optimization and recompression. We use saliency detection (trained on an eye-tracker) which tells us where the human vision system would look in the images and optimise those fragments (heatmaps) using our own comparison metrics. If you're interested in the details shoot me an email to przemek [at] optidash [dot] ai
PeterWall 6y ago
Thank you for sharing this. It's interesting to see that even these big websites potentialy still have a lot of room for improvement for their loading times.

tyingq 6y ago

JQuery being more prevalent than Google Analytics is a surprise to me.

yurishimo 6y ago
jQuery is a default dependency for many WordPress blogs. Not all of those are run by folks who want/care about analytics.
- tyingq 6y ago
  Sure. I was assuming that culling to the "top million" would skew things in favor of GA. Clearly it didn't, but I was surprised. And you're probably right. All those Wordpress instances does drive a lot of the stats.
- joshspankit 6y ago
  I had hoped at some point in the breakdown that they differentiated between Wordpress and.. everything else I guess. Wordpress itself probably skewed the numbers significantly.
mschuetz 6y ago
This is a good page that shows why JQuery isn't going away anytime soon: http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/

eric_trackjs 6y ago

Off-topic but I'd never heard of CatchJS before. As the founder of TrackJS[1] I can't help but feel they were heavily inspired by our product... almost too inspired considering their logo and marketing copy. (We've been around since 2014, so we pre-date them by 4 years) [1] https://trackjs.com https://trackjs.com

morgosmaci 6y ago
Wait a company logo about javascript that uses {}? Maybe thrown into a single color circle? Mild Shock. Edit: I will give you that their web page header and pricing looks very similar.
- lars 6y ago
  Lars from CatchJS here. Anyone can go on archive.org and verify that they changed their color scheme and header to ones very similar to CatchJS in Feb 2020, after CatchJS had used that look for 2 years. Thank you for also pointing out the pricing page, where the same is true. I've now received a cease and desist from their attorney stating that the looks are too similar. It's nice that they've paid for an attorney to make my point for me, but they seem to have mixed up who did what here.
trevor-e 6y ago
You both have an incredibly generic logo/header/copy template so I'm not really sure what you're trying to imply. Your site copies the format of Stripe and they were around in 2010, pre-dating you by 4 years.

joosters 6y ago

The article talks about a million web pages, but it's actually the top million domains. This is an important difference because the top sites could be completely different to the web pages that we view. For example, Facebook is probably high up the list. But which Facebook page do they measure? The 'front page' of a non logged in user, presumably? That would be vastly different from the majority of FB users. Likewise, Wikipedia is also an extremely popular site. But surely most users are looking at specific pages of interest, and not just the front page?

btbuildem 6y ago

My guess would've been 1) ads / tracking and 2) bloated JS frameworks.

randompwd 6y ago

It's a blog article yet has no date on it. Why are these sites so obnoxious and secretive. Let us know when the blog was written. 34 days ago: https://news.ycombinator.com/item?id=25517628 https://news.ycombinator.com/item?id=25517628 (115 comments) https://itnext.io/we-rendered-a-million-web-pages-to-find-out-what-makes-the-web-slow-72bbba9ade96 https://itnext.io/we-rendered-a-million-web-pages-to-find-ou... (Dec 22, 2020 - repost from CatchJS) WRITTEN BY Lars Eidnes Chief error catcher at https://catchjs.com https://catchjs.com

ibraheemdev 6y ago

Previous discussion: https://news.ycombinator.com/item?id=25517628 https://news.ycombinator.com/item?id=25517628

dvfjsdhgfv 6y ago

...and we discovered it's JavaScript. Most of it being just tracking code.

jzer0cool 6y ago

How about a standard how heavy the site (and other meta details) before it is loaded within the html spec? In this way, a user can opt out to continuing to browsing with details from say a short response header. Is something like already proposed anywhere, or not really a solution to the problem — thoughts?

spankalee 6y ago

dominteractive isn't a good metric for this. Many sites are perceivably slow because of rendering work they're doing after dominteractive. They should be looking at a more user-centric metrics like Largest Contentful Paint: https://web.dev/lcp/ https://web.dev/lcp/

jiveturkey 6y ago

a million? is that a lot?

bluesmoon 6y ago

This study is flawed for a few reasons that I'd mentioned to the author when it was first published, but they ignored my comments. The main problem is that they confuse DOMInteractive for Time To Interactive. The two events are very different. DOMInteractive is a legacy event that refers to the time when JavaScript can safely interact with the DOM. This really has nothing (or very little) to do with user experience. Time to Interactive, on the other hand, is the time when a user can expect the page to respond quickly to interactions (clicks, scrolls, keypresses), ie, these user interactions should have no user perceivable latency. This is not a metric that has a corresponding browser event. It requires a bunch of post-processing based on various events. The researchers have made no attempt to calculate TTI. Source: I've been working in this area of research for 15 years.

Abishek_Muthian 6y ago
> I've been working in this area of research for 15 years Is the outcome of the research by CATCHJS different from what you have learnt?
- bluesmoon 6y ago
  Some recent results are at https://tech.bluesmoon.info/2020/11/understanding-emotion-for-happy-users.html https://tech.bluesmoon.info/2020/11/understanding-emotion-fo...
andrewmcwatters 6y ago
What way would you suggest measuring this? Duration between TTFB and when user events first get pumped?
- bluesmoon 6y ago
  The simplest way to measure impact on users would be to just use boomerang which gets you all of this out of the box: https://github.com/akamai/boomerang https://github.com/akamai/boomerang To do it yourself, you need a combination of PainTiming and measuring LongTasks or study the periodicity of setInterval/requestAnimationFrame The above works for synthetic as well as real users. If you're able to measure real users directly, then you'd also want to look at Input Delays, Rage Clicks, Dead Clicks, Missed Clicks, Scroll Jank.