7 ms·

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

187 points by KukiAirani 6y ago

zerop 6y ago
One more point I observed while UI performance debugging earlier: Even though JS are cached by browsers, still loading them from disk (cache) to memory during page load is actually slow. Of course it also depends on machine capacities.
- NavinF 6y ago
  Hmm I wonder if there's a way to debug that. On a fast 1G internet connection and fast NVMe disk, the only status message I see on slow web pages is "waiting for cache". Maybe this is a chrome bug
  - jeffbee 6y ago
    That is a Chrome UI quirk. It's actually waiting on some subsequent action that doesn't bother clearing the status message.
chrismorgan 6y ago
I’m curious about the HTTP/0.9 stuff. Last time I checked (four or five years ago, by making a trivial HTTP/0.9 server, as the first step of a “writing HTTP servers” tutorial series that never materialised), Firefox either wouldn’t render the output at all, or would render it as though it had been a text/plain response (can’t remember which it was). In other words, it’s not a real web page. I would expect precisely zero occurrences among the top million pages, not the thirty that 0.003% indicates. I think it’s far more likely (p≅0.9999) that these indicate some sort of error. (For those unfamiliar with it, HTTP/0.9 is the label for a protocol where the client opens a TCP connection to the server and sends “GET /”, and the server responds with the body, verbatim, and closes the connection. No status codes, no headers, nothing.)
- gnfargbl 6y ago
  With any large-scale scan dataset like this, noise is inevitable. Legitimate use of HTTP/0.9 in consumer-facing web servers is exceptionally unlikely, but there are all sorts of scenarios which could have led HTTP/0.9 responses to bleed into the data. For instance, here is an untested hypothesis: ~30 of the hostnames on the list have abandoned DNS A records, pointing to EC2 servers. Those EC2 IPs have since been repurposed as honeypots of some kind. The honeypots present themselves as HTTP/0.9, in order to look more like low-grade IoT devices. That hypothesis is almost certainly wrong, but you could quickly invent another and at some point one of them will be correct. The internet is just a very messy place.
ffpip 6y ago
Use an adblocker. I save about 25 gigs and hours of my time every month. * https://www.ublockorigin.com https://www.ublockorigin.com * I block much more than ads.
- iamlolz 6y ago
  Out of curiosity, what else do you use it for?
  - kubanczyk 6y ago
    Not a parent, but it's super-easy to block any element I find distracting with about two clicks. For example looking at en.wikipedia.org I can just remove that COVID box. Scalable? No. Smart? Eeeyuh... Satisfying? Hell yes.
    - rektide 6y ago
      power & freedom, the things native apps never ever permit us.
    - SV_BubbleTime 6y ago
      Right, I’ll often make design choices to remove a whole div I don’t need. Your most recent stories I might be interested in that takes up 20% of my screen? No thanks!
  - goodcharles 6y ago
    Blocking Drift Chatbots (those annoying things that change Title in browser windows, make noise, obstruct page content)
  - rasz 6y ago
    You can use ubo filters to overwrite styles, saves you one extension
  - jpcooper 6y ago
    YouTube comments.
ArtWomb 6y ago
Not scope of this analysis, but my #1 regression is large PDF in tabs. It such a standard part of the web experience, especially in sharing academic research, that it feels like a legit pain point in dire need of an upgrade.
- mhh__ 6y ago
  I think the issue for me isn't so much the PDF itself but the way that the way it first never appears quite fit's my eyes, and scrolling around is unpleasant.
- tylerrobinson 6y ago
  Can you elaborate on the pain point here? I like how PDFs open in a new tab in Chrome but I’d like to understand what you have a problem with.
jokoon 6y ago
Burn the DOM with fire. I'm so allergic to it. I'd rather write my own 2D tile tree format, with a simple flex-like rendering layout, than to work with HTML and expect reliability. HTML was never designed for interactive applications. The historic reality is that HTML served as a "backdoor"/gateway to let the linux community compete with microsoft: linux devs could ship their code for windows clients. Now, HTML webapps cannot run properly on a mobile platform without depleting expensive batteries. So each mobile platform are making bucks on the back of developers who have to work twice as hard. I have very high hopes that webassembly could somehow solve all those problems, but there are several problems: * Not all browser vendors like WASM and I doubt that any WASM progress would be supported equally. * WASM toolchains are not really mature for most languages. Compiler makers don't have a lot of incentive working with WASM. * The DOM would still exist.
- ajuc 6y ago
  > I'd rather write my own 2D tile tree format, with a simple flex-like rendering layout, than to work with HTML and expect reliability. I suspect you'd quickly find there's a lot more complexity there than you predicted. Anyway - if that's what you want check out Qt + QML. You can do it badly, but when you use it well it's the best declarative UI framework I know.
- rektide 6y ago
  what would hacker news here be helped by by removing the dom? do you think this website would be better with your solution? why?
  - rektide 6y ago
    fwiw there's almost nothing on the dom in this article. I'm quite tired of the hot air pointless uneducated uninformed web bashing. I don't know why the web attracts such angry angry people but for all the complaining the grandparent post is about as real of a counter-idea to the dom as I have ever seen. what we do with the web is often bad. fully agreed there are terrible experiences everywhere. but starting fresh, starting with different source materials, different rendering data structures: I don't think that targets at all what is wrong. so I just see such complaining as misdirected, complaints against a pop culture that instead focus on the tech that allows that pop culture. and I see it as sabotaging the best tech humanity has going, the freest most expressive most versatile data we've got that we often yes use quite poorly. but that we do get better at. that we continue to evolve our architectures of use around. and I see such grumbles as undermining this great thing, while supporting something limited & domineering & utterly in corporate control, something apart from the greater connected cyberspace: native (awful) apps.
ableal 6y ago
> tracking every conceivable performance metric Technically it's not a metric for one-of rendering, but memory leaks by an open browser tab have bugged me a bit lately. Safari does a per URL report in MacOS, and the ancient MacBook with "only" 8GB RAM gets a tad hot and bothered when a local PC store page runs up a 1.5 GB tab just sitting there, GMail snarfs 1 GB if not opened in a fresh tab once in a while, etc.
rasz 6y ago
I can guess without reading: 1 ads 2 client side rendering. Youtube nowadays is 400-1000 kilobytes of Json + ~!8! megabyte of javascript(1). Pre Polymer (YT client side rendering engine update) you would receive 50KB of pre rendered pure HTML that would display instantly. Nowadays scrolling comments results in seeing them appear one by one while browser struggles with constant DOM updates. 1) >7MB desktop_polymer_inlined_html_polymer_flags.js + 1.6MB base.js Edit: After reading the article >Top linked URLs That's amazing. I've got the same combination on my luggage ^^^^^ tracking blocker, every single one of those (even the yt iframe one). Nothing bout ads or tracking. >What marketing strategies does Itnext use? Get traffic statistics, SEO keyword opportunities, audience insights, and competitive analytics for Itnext. oh, Itnext is all about that user tracking
- SV_BubbleTime 6y ago
  > Judging by this top 10, our browsers are mostly running analytics, ads, and code to be compatible with old browsers. Exactly as anyone should have expected.
- jakelazaroff 6y ago
  And you'd be wrong. SPA frameworks are almost entirely absent from this list. HN discourse would have you think single-page apps are pervasive, but they're only on a tiny fraction of websites: https://css-tricks.com/how-the-web-is-really-built/ https://css-tricks.com/how-the-web-is-really-built/
  - BrianOnHN 6y ago
    Given that most public-facing websites want to benefit from SEO, it doesn't make sense to build a SPA for those websites. I'd bet the majority of developers working on SPAs are doing so for internal dashboards/tools.
    - jameslk 6y ago
      You can render SPAs before the page loads, which eliminate any potential issues with SEO. This is how it should be done and the approach frameworks like Next.js take.
thefz 6y ago
Don't tell me: it's mostly ad media, and then a bunch of .js packages.
superkuh 6y ago
It's pretty obvious. Javascript. Web applications that display text and media are slow. Web documents that display text and media are fast.
jameslk 6y ago
It seems web performance is one of the least understood topics, even for engineers. Unfortunately even this author makes the mistake of confusing DOM Interactive[0] with Time to Interactive[1]. And yet this is a better analysis than what I often see repeated backed with no evidence. For example, the myths about page weight and big SPA JS websites being the source of web performance issues is one I see so frequently here. Even in this thread others have started to claim the problem is all JS (take a closer look at the article). And it's good to see some actual data to back what I actually have seen optimizing many websites myself (spoiler: a lot of badly performing sites use jQuery). For speed (which is also a complex subject that can't be captured in one metric[2]), the problem isn't page weight or JS frameworks, it's network latency[3]. Because you can't optimize the speed of light. This is especially true for websites that connect to many different origins (usually for different types of analytics services) and for many things related to the critical render path[4]. The issues I see most often are not the huge frameworks loading, but inefficient loading of all resources, especially those that will affect user-centric timing metrics. I frequently see many render-blocking CSS and JS files loaded which increases First Contentful Paint. I see images, script code, and other resources that affect below-the-fold content loaded before above-the-fold content and resources. And of course my favorite: above-the-fold content loaded with JS. These affect Largest Contentful Paint. Etc etc. Of course we can all claim the problem is something else and collectively decide to switch to server-side rendering as an industry but this won't fix issues with web performance. Understanding how browsers load pages and how your users perceive the load will. 0. https://developer.mozilla.org/en-US/docs/Web/API/PerformanceTiming/domInteractive https://developer.mozilla.org/en-US/docs/Web/API/Performance... 1. https://web.dev/interactive/ https://web.dev/interactive/ 2. https://developers.google.com/web/fundamentals/performance/speed-tools#common_myths_about_performance https://developers.google.com/web/fundamentals/performance/s... 3. https://www.speedshop.co/2015/11/05/page-weight-doesnt-matter.html https://www.speedshop.co/2015/11/05/page-weight-doesnt-matte... 4. https://developers.google.com/web/fundamentals/performance/critical-rendering-path https://developers.google.com/web/fundamentals/performance/c...
- nicoburns 6y ago
  Yep, we have an SPA at work. It's not even small - around 2MB - but it loads, parses, and renders almost instantly (say <300ms - not bad for a complex app). However, in practice users don't get into the app for a couple of seconds. This is due to it making several slow network requests to check auth and load data before letting you in. I have a WIP branch that caches things locally, but my boss tells me that the app is fast enough and I should be working on other things. And I'm loathe to sneak it in without proper testing as caching is something that has a tendency to break in horrible ways if you're not careful.
Log1x 6y ago
Original article: https://catchjs.com/Blog/PerformanceInTheWild https://catchjs.com/Blog/PerformanceInTheWild
bumblebritches5 6y ago
tldr: jQuery
ru552 6y ago
https://catchjs.com/Blog/PerformanceInTheWild https://catchjs.com/Blog/PerformanceInTheWild — actual link to the people that did the study. Itnext.io just ripped it off with a small credit at the bottom.
- NicoJuicy 6y ago
  Perhaps dang can change the link to https://catchjs.com/Blog/PerformanceInTheWild https://catchjs.com/Blog/PerformanceInTheWild
  - a1369209993 6y ago
    From 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... , in case anyone later wants to know.
- jefozabuss 6y ago
  From what I see it wasn't "ripped off" if the original author submitted it to both places (see at bottom) https://medium.com/@larseidnes https://medium.com/@larseidnes Or am I missing something?
- albedoa 6y ago
  That is not what "originally published at" means. The author is providing the canonical home of his own article.
- KukiAirani 6y ago
  My mistake, thanks for pointing this out
- ffpip 6y ago
  itnext.io gets better SEO so the author posted to both places.
pjc50 6y ago
I knew about googleanalytics; some years ago, back when browsers still had a status bar at the bottom, I noticed many sites waiting on it. So I redirected that domain to 127.0.0.1 and went on my way noticeably faster. I'd not encountered Amazon Publisher Services but this article makes them look very bad.
- aferran8 6y ago
  A lot of these pages have very heavy analytics libraries. I've built a lightweight full-suite analytics platform to counter this problem. It's also privacy-focused: https://getinsights.io https://getinsights.io
inthewoods 6y ago
Seems like jQuery is a big cause of slowdowns - anybody have suggestions for how to provide similar functionality without it?
- mtmail 6y ago
  API compatible smaller libraries https://zeptojs.com/ https://zeptojs.com/ or no library http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/
- jameslk 6y ago
  jQuery is a large library, but it isn't exactly the source of web performance issues in my experience. It's the way it's used: many sites use it to render content, especially above-the-fold content (like image galleries, such as on ecommerce sites). Since much jQuery-based code waits for the DOM to finish loading first (e.g. with `$(function() { ... })`) [0], that means all the HTML has to finish being parsed and loaded first, jQuery has to be loaded, and then FINALLY you have scripts all firing at once in a frenzy rendering even more content. It's a big issue and the solution is to avoid rendering content with jQuery when pages load. Oh and a lot of sites load jQuery synchronously in the <head> tag, usually pointing to some external CDN. That means the browser stops parsing the HTML mid-way through the page load, resolves the CDN's domain to IP, does a TLS handshake and establishes a connection to the CDN, waits to download the script, parses, runs it, and then proceeds on to the rest of the HTML. All because the developer(s) didn't know about the script `defer` attribute[1]. 0. https://api.jquery.com/ready/ https://api.jquery.com/ready/ 1. https://javascript.info/script-async-defer#defer https://javascript.info/script-async-defer#defer
  - jlokier 6y ago
    > That means the browser stops parsing the HTML mid-way through the page load, resolves the CDN's domain to IP, does a TLS handshake and establishes a connection to the CDN, waits to download the script, parses, runs it, and then proceeds on to the rest of the HTML. This is not true since about 2008. All major browsers parse the HTML without waiting for synchronous <script> to load. https://developer.mozilla.org/en-US/docs/Glossary/speculative_parsing https://developer.mozilla.org/en-US/docs/Glossary/speculativ... If the <script> uses document.write() and what's written contains unbalanced tags, or if the document is modified in some other ways, then they re-parse but that combination is rare. This page explains what to avoid to ensure re-parsing doesn't happen (the rules may differ with other browsers): https://developer.mozilla.org/en-US/docs/Glossary/speculative_parsing https://developer.mozilla.org/en-US/docs/Glossary/speculativ...
deleted 6y ago
[deleted]
kaycebasques 6y ago
As jameslk also mentioned, this article mistakenly uses "dominteractive" interchangeably with "time-to-interactive". They are not the same metric. Lighthouse uses a different algorithm for computing TTI. https://web.dev/interactive/#what-tti-measures https://web.dev/interactive/#what-tti-measures https://developer.mozilla.org/en-US/docs/Web/API/PerformanceNavigationTiming/domInteractive https://developer.mozilla.org/en-US/docs/Web/API/Performance...
kaycebasques 6y ago
See also the Web Almanac for an in-depth look at the state of the web: https://almanac.httparchive.org/en/2020/ https://almanac.httparchive.org/en/2020/
jeffbee 6y ago
The HTTP protocol level has got to be highly confused by being served from a high-performing AS. Won't any technique appear to be correlated with faster load times if it happens to be served from e.g. the same EC2 region where they ran these browsers?
marosgrego 6y ago
Just don't use JavaScript lol
geggam 6y ago
Didnt read the article, my money is on javascript crap linked into the page from 200 different sites
k__ 6y ago
Pages with rocket-lazy-load are generally faster. AFAIK Rocket is a Rust framework and my guess is that the average Rust dev cares more about perf. Which would imply that perf could be more about mindset than technology. But that's just my humble interpretation...
- steveklabnik 6y ago
  It is the name of a Rust web framework, but this is referring to a Wordpress plugin. (Also, the Rust Rocket is not primarily focused on perf, but developer ergonomics.)
  - k__ 6y ago
    Ah, good to know, thanks!
sambeau 6y ago
I had to laugh—It took 5 seconds for that page to load for me.
difosfor 6y ago
If you try to derive which framework is used based on global variables then you'll miss the ones that don't pollute the global namespace like that but just use closures etc. E.g: most modern frameworks+toolkits like React+Webpack as far as I know.
jefftk 6y ago
>If we were to believe this, we would conclude that moving requested resources from HTTP 1.1 to 2 gives a 1.8x speed-up, while going from HTTP 2 to 3 causes 0.6x slow down. Is it really true that HTTP 3 is a slower protocol? No: A more likely explanation is that HTTP 3 is rare, and that the few resources that are being sent over HTTP 3 (e.g. Google Analytics) are things that have a larger than average effect on dominteractive. If you wanted to measure the effect of protocol, you could compare requesting with support HTTP/N to requesting with support for HTTP/N+1. Since this is all synthetic testing it shouldn't be too hard to run a controlled experiment instead of a correlational one.
deleted 6y ago
[deleted]
woeirua 6y ago
If 50% of the top million websites use JQuery, is it time to just admit that it should be bundled with JS by default in some way, shape or form?
- jeofken 6y ago
  Browsers could possibly bundle it, but let’s not bloat the language specification with jQuery
- Hexigonz 6y ago
  No, the spec has evolved past the need for it. The sites that still use it could easily be rewritten, usually with even less code. Plus, it's not like a large majority of sites using it are actually taking advantage of JQuery features, they're merely including it for Bootstrap.
lsllc 6y ago
I love this quote measuring the age of jQuery in different units: JQuery was first released in 2006, which is 14 years ago in human years, but much longer in JavaScript years. Measured in Angular versions, it is probably hundreds of versions ago.
these_are_not_t 6y ago
Tangential question: are there other giveaways than download time for a cached document which could be used by malicious scripts? I ask because I don't understand why a zero download time for a cached document couldn't be simply masked by some (random) wait by the browser instead of downloading the file again. From the chrome update page linked in the article, the explanation is: > However, the time a website takes to respond to HTTP requests can reveal that the browser has accessed the same resource in the past, which opens the browser to security and privacy attacks, [...] which seems to indicate that only time matters in the attacks. Yet, the third bullet point suggests: > Cross-site tracking: The cache can be used to store cookie-like identifiers as a cross-site tracking mechanism. as a possible attack based on the cache, which doesn't seem to involve document download time.
- bastawhiz 6y ago
  Browsers are mitigating what you described with cache partitioning. https://developers.google.com/web/updates/2020/10/http-cache-partitioning https://developers.google.com/web/updates/2020/10/http-cache...
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
  - these_are_not_t 6y ago
    thx
Uninen 6y ago
Sad to see Sentry on the bottom 5 JS heap size list. Love their service but the JS payload is pretty massive.

187 points by KukiAirani 6y ago

One more point I observed while UI performance debugging earlier: Even though JS are cached by browsers, still loading them from disk (cache) to memory during page load is actually slow. Of course it also depends on machine capacities.

NavinF 6y ago
Hmm I wonder if there's a way to debug that. On a fast 1G internet connection and fast NVMe disk, the only status message I see on slow web pages is "waiting for cache". Maybe this is a chrome bug
- jeffbee 6y ago
  That is a Chrome UI quirk. It's actually waiting on some subsequent action that doesn't bother clearing the status message.

chrismorgan 6y ago

I’m curious about the HTTP/0.9 stuff. Last time I checked (four or five years ago, by making a trivial HTTP/0.9 server, as the first step of a “writing HTTP servers” tutorial series that never materialised), Firefox either wouldn’t render the output at all, or would render it as though it had been a text/plain response (can’t remember which it was). In other words, it’s not a real web page. I would expect precisely zero occurrences among the top million pages, not the thirty that 0.003% indicates. I think it’s far more likely (p≅0.9999) that these indicate some sort of error. (For those unfamiliar with it, HTTP/0.9 is the label for a protocol where the client opens a TCP connection to the server and sends “GET /”, and the server responds with the body, verbatim, and closes the connection. No status codes, no headers, nothing.)

gnfargbl 6y ago
With any large-scale scan dataset like this, noise is inevitable. Legitimate use of HTTP/0.9 in consumer-facing web servers is exceptionally unlikely, but there are all sorts of scenarios which could have led HTTP/0.9 responses to bleed into the data. For instance, here is an untested hypothesis: ~30 of the hostnames on the list have abandoned DNS A records, pointing to EC2 servers. Those EC2 IPs have since been repurposed as honeypots of some kind. The honeypots present themselves as HTTP/0.9, in order to look more like low-grade IoT devices. That hypothesis is almost certainly wrong, but you could quickly invent another and at some point one of them will be correct. The internet is just a very messy place.

ffpip 6y ago

Use an adblocker. I save about 25 gigs and hours of my time every month. * https://www.ublockorigin.com https://www.ublockorigin.com * I block much more than ads.

iamlolz 6y ago
Out of curiosity, what else do you use it for?
- kubanczyk 6y ago
  Not a parent, but it's super-easy to block any element I find distracting with about two clicks. For example looking at en.wikipedia.org I can just remove that COVID box. Scalable? No. Smart? Eeeyuh... Satisfying? Hell yes.
  - rektide 6y ago
    power & freedom, the things native apps never ever permit us.
  - SV_BubbleTime 6y ago
    Right, I’ll often make design choices to remove a whole div I don’t need. Your most recent stories I might be interested in that takes up 20% of my screen? No thanks!
- goodcharles 6y ago
  Blocking Drift Chatbots (those annoying things that change Title in browser windows, make noise, obstruct page content)
- rasz 6y ago
  You can use ubo filters to overwrite styles, saves you one extension
- jpcooper 6y ago
  YouTube comments.

ArtWomb 6y ago

Not scope of this analysis, but my #1 regression is large PDF in tabs. It such a standard part of the web experience, especially in sharing academic research, that it feels like a legit pain point in dire need of an upgrade.

mhh__ 6y ago
I think the issue for me isn't so much the PDF itself but the way that the way it first never appears quite fit's my eyes, and scrolling around is unpleasant.
tylerrobinson 6y ago
Can you elaborate on the pain point here? I like how PDFs open in a new tab in Chrome but I’d like to understand what you have a problem with.

jokoon 6y ago

Burn the DOM with fire. I'm so allergic to it. I'd rather write my own 2D tile tree format, with a simple flex-like rendering layout, than to work with HTML and expect reliability. HTML was never designed for interactive applications. The historic reality is that HTML served as a "backdoor"/gateway to let the linux community compete with microsoft: linux devs could ship their code for windows clients. Now, HTML webapps cannot run properly on a mobile platform without depleting expensive batteries. So each mobile platform are making bucks on the back of developers who have to work twice as hard. I have very high hopes that webassembly could somehow solve all those problems, but there are several problems: * Not all browser vendors like WASM and I doubt that any WASM progress would be supported equally. * WASM toolchains are not really mature for most languages. Compiler makers don't have a lot of incentive working with WASM. * The DOM would still exist.

ajuc 6y ago
> I'd rather write my own 2D tile tree format, with a simple flex-like rendering layout, than to work with HTML and expect reliability. I suspect you'd quickly find there's a lot more complexity there than you predicted. Anyway - if that's what you want check out Qt + QML. You can do it badly, but when you use it well it's the best declarative UI framework I know.
rektide 6y ago
what would hacker news here be helped by by removing the dom? do you think this website would be better with your solution? why?
- rektide 6y ago
  fwiw there's almost nothing on the dom in this article. I'm quite tired of the hot air pointless uneducated uninformed web bashing. I don't know why the web attracts such angry angry people but for all the complaining the grandparent post is about as real of a counter-idea to the dom as I have ever seen. what we do with the web is often bad. fully agreed there are terrible experiences everywhere. but starting fresh, starting with different source materials, different rendering data structures: I don't think that targets at all what is wrong. so I just see such complaining as misdirected, complaints against a pop culture that instead focus on the tech that allows that pop culture. and I see it as sabotaging the best tech humanity has going, the freest most expressive most versatile data we've got that we often yes use quite poorly. but that we do get better at. that we continue to evolve our architectures of use around. and I see such grumbles as undermining this great thing, while supporting something limited & domineering & utterly in corporate control, something apart from the greater connected cyberspace: native (awful) apps.

ableal 6y ago

> tracking every conceivable performance metric Technically it's not a metric for one-of rendering, but memory leaks by an open browser tab have bugged me a bit lately. Safari does a per URL report in MacOS, and the ancient MacBook with "only" 8GB RAM gets a tad hot and bothered when a local PC store page runs up a 1.5 GB tab just sitting there, GMail snarfs 1 GB if not opened in a fresh tab once in a while, etc.

rasz 6y ago

I can guess without reading: 1 ads 2 client side rendering. Youtube nowadays is 400-1000 kilobytes of Json + ~!8! megabyte of javascript(1). Pre Polymer (YT client side rendering engine update) you would receive 50KB of pre rendered pure HTML that would display instantly. Nowadays scrolling comments results in seeing them appear one by one while browser struggles with constant DOM updates. 1) >7MB desktop_polymer_inlined_html_polymer_flags.js + 1.6MB base.js Edit: After reading the article >Top linked URLs That's amazing. I've got the same combination on my luggage ^^^^^ tracking blocker, every single one of those (even the yt iframe one). Nothing bout ads or tracking. >What marketing strategies does Itnext use? Get traffic statistics, SEO keyword opportunities, audience insights, and competitive analytics for Itnext. oh, Itnext is all about that user tracking

SV_BubbleTime 6y ago
> Judging by this top 10, our browsers are mostly running analytics, ads, and code to be compatible with old browsers. Exactly as anyone should have expected.
jakelazaroff 6y ago
And you'd be wrong. SPA frameworks are almost entirely absent from this list. HN discourse would have you think single-page apps are pervasive, but they're only on a tiny fraction of websites: https://css-tricks.com/how-the-web-is-really-built/ https://css-tricks.com/how-the-web-is-really-built/
- BrianOnHN 6y ago
  Given that most public-facing websites want to benefit from SEO, it doesn't make sense to build a SPA for those websites. I'd bet the majority of developers working on SPAs are doing so for internal dashboards/tools.
  - jameslk 6y ago
    You can render SPAs before the page loads, which eliminate any potential issues with SEO. This is how it should be done and the approach frameworks like Next.js take.

thefz 6y ago

Don't tell me: it's mostly ad media, and then a bunch of .js packages.

superkuh 6y ago

It's pretty obvious. Javascript. Web applications that display text and media are slow. Web documents that display text and media are fast.

jameslk 6y ago

It seems web performance is one of the least understood topics, even for engineers. Unfortunately even this author makes the mistake of confusing DOM Interactive[0] with Time to Interactive[1]. And yet this is a better analysis than what I often see repeated backed with no evidence. For example, the myths about page weight and big SPA JS websites being the source of web performance issues is one I see so frequently here. Even in this thread others have started to claim the problem is all JS (take a closer look at the article). And it's good to see some actual data to back what I actually have seen optimizing many websites myself (spoiler: a lot of badly performing sites use jQuery). For speed (which is also a complex subject that can't be captured in one metric[2]), the problem isn't page weight or JS frameworks, it's network latency[3]. Because you can't optimize the speed of light. This is especially true for websites that connect to many different origins (usually for different types of analytics services) and for many things related to the critical render path[4]. The issues I see most often are not the huge frameworks loading, but inefficient loading of all resources, especially those that will affect user-centric timing metrics. I frequently see many render-blocking CSS and JS files loaded which increases First Contentful Paint. I see images, script code, and other resources that affect below-the-fold content loaded before above-the-fold content and resources. And of course my favorite: above-the-fold content loaded with JS. These affect Largest Contentful Paint. Etc etc. Of course we can all claim the problem is something else and collectively decide to switch to server-side rendering as an industry but this won't fix issues with web performance. Understanding how browsers load pages and how your users perceive the load will. 0. https://developer.mozilla.org/en-US/docs/Web/API/PerformanceTiming/domInteractive https://developer.mozilla.org/en-US/docs/Web/API/Performance... 1. https://web.dev/interactive/ https://web.dev/interactive/ 2. https://developers.google.com/web/fundamentals/performance/speed-tools#common_myths_about_performance https://developers.google.com/web/fundamentals/performance/s... 3. https://www.speedshop.co/2015/11/05/page-weight-doesnt-matter.html https://www.speedshop.co/2015/11/05/page-weight-doesnt-matte... 4. https://developers.google.com/web/fundamentals/performance/critical-rendering-path https://developers.google.com/web/fundamentals/performance/c...

nicoburns 6y ago
Yep, we have an SPA at work. It's not even small - around 2MB - but it loads, parses, and renders almost instantly (say <300ms - not bad for a complex app). However, in practice users don't get into the app for a couple of seconds. This is due to it making several slow network requests to check auth and load data before letting you in. I have a WIP branch that caches things locally, but my boss tells me that the app is fast enough and I should be working on other things. And I'm loathe to sneak it in without proper testing as caching is something that has a tendency to break in horrible ways if you're not careful.

Log1x 6y ago

Original article: https://catchjs.com/Blog/PerformanceInTheWild https://catchjs.com/Blog/PerformanceInTheWild

bumblebritches5 6y ago

tldr: jQuery

ru552 6y ago

https://catchjs.com/Blog/PerformanceInTheWild https://catchjs.com/Blog/PerformanceInTheWild — actual link to the people that did the study. Itnext.io just ripped it off with a small credit at the bottom.

NicoJuicy 6y ago
Perhaps dang can change the link to https://catchjs.com/Blog/PerformanceInTheWild https://catchjs.com/Blog/PerformanceInTheWild
- a1369209993 6y ago
  From 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... , in case anyone later wants to know.
jefozabuss 6y ago
From what I see it wasn't "ripped off" if the original author submitted it to both places (see at bottom) https://medium.com/@larseidnes https://medium.com/@larseidnes Or am I missing something?
albedoa 6y ago
That is not what "originally published at" means. The author is providing the canonical home of his own article.
KukiAirani 6y ago
My mistake, thanks for pointing this out
ffpip 6y ago
itnext.io gets better SEO so the author posted to both places.

pjc50 6y ago

I knew about googleanalytics; some years ago, back when browsers still had a status bar at the bottom, I noticed many sites waiting on it. So I redirected that domain to 127.0.0.1 and went on my way noticeably faster. I'd not encountered Amazon Publisher Services but this article makes them look very bad.

aferran8 6y ago
A lot of these pages have very heavy analytics libraries. I've built a lightweight full-suite analytics platform to counter this problem. It's also privacy-focused: https://getinsights.io https://getinsights.io

inthewoods 6y ago

Seems like jQuery is a big cause of slowdowns - anybody have suggestions for how to provide similar functionality without it?

mtmail 6y ago
API compatible smaller libraries https://zeptojs.com/ https://zeptojs.com/ or no library http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/
jameslk 6y ago
jQuery is a large library, but it isn't exactly the source of web performance issues in my experience. It's the way it's used: many sites use it to render content, especially above-the-fold content (like image galleries, such as on ecommerce sites). Since much jQuery-based code waits for the DOM to finish loading first (e.g. with `$(function() { ... })`) [0], that means all the HTML has to finish being parsed and loaded first, jQuery has to be loaded, and then FINALLY you have scripts all firing at once in a frenzy rendering even more content. It's a big issue and the solution is to avoid rendering content with jQuery when pages load. Oh and a lot of sites load jQuery synchronously in the <head> tag, usually pointing to some external CDN. That means the browser stops parsing the HTML mid-way through the page load, resolves the CDN's domain to IP, does a TLS handshake and establishes a connection to the CDN, waits to download the script, parses, runs it, and then proceeds on to the rest of the HTML. All because the developer(s) didn't know about the script `defer` attribute[1]. 0. https://api.jquery.com/ready/ https://api.jquery.com/ready/ 1. https://javascript.info/script-async-defer#defer https://javascript.info/script-async-defer#defer
- jlokier 6y ago
  > That means the browser stops parsing the HTML mid-way through the page load, resolves the CDN's domain to IP, does a TLS handshake and establishes a connection to the CDN, waits to download the script, parses, runs it, and then proceeds on to the rest of the HTML. This is not true since about 2008. All major browsers parse the HTML without waiting for synchronous <script> to load. https://developer.mozilla.org/en-US/docs/Glossary/speculative_parsing https://developer.mozilla.org/en-US/docs/Glossary/speculativ... If the <script> uses document.write() and what's written contains unbalanced tags, or if the document is modified in some other ways, then they re-parse but that combination is rare. This page explains what to avoid to ensure re-parsing doesn't happen (the rules may differ with other browsers): https://developer.mozilla.org/en-US/docs/Glossary/speculative_parsing https://developer.mozilla.org/en-US/docs/Glossary/speculativ...

deleted 6y ago

[deleted]

kaycebasques 6y ago

As jameslk also mentioned, this article mistakenly uses "dominteractive" interchangeably with "time-to-interactive". They are not the same metric. Lighthouse uses a different algorithm for computing TTI. https://web.dev/interactive/#what-tti-measures https://web.dev/interactive/#what-tti-measures https://developer.mozilla.org/en-US/docs/Web/API/PerformanceNavigationTiming/domInteractive https://developer.mozilla.org/en-US/docs/Web/API/Performance...

kaycebasques 6y ago

See also the Web Almanac for an in-depth look at the state of the web: https://almanac.httparchive.org/en/2020/ https://almanac.httparchive.org/en/2020/

jeffbee 6y ago

The HTTP protocol level has got to be highly confused by being served from a high-performing AS. Won't any technique appear to be correlated with faster load times if it happens to be served from e.g. the same EC2 region where they ran these browsers?

marosgrego 6y ago

Just don't use JavaScript lol

geggam 6y ago

Didnt read the article, my money is on javascript crap linked into the page from 200 different sites

k__ 6y ago

Pages with rocket-lazy-load are generally faster. AFAIK Rocket is a Rust framework and my guess is that the average Rust dev cares more about perf. Which would imply that perf could be more about mindset than technology. But that's just my humble interpretation...

steveklabnik 6y ago
It is the name of a Rust web framework, but this is referring to a Wordpress plugin. (Also, the Rust Rocket is not primarily focused on perf, but developer ergonomics.)
- k__ 6y ago
  Ah, good to know, thanks!

sambeau 6y ago

I had to laugh—It took 5 seconds for that page to load for me.

difosfor 6y ago

If you try to derive which framework is used based on global variables then you'll miss the ones that don't pollute the global namespace like that but just use closures etc. E.g: most modern frameworks+toolkits like React+Webpack as far as I know.

jefftk 6y ago

>If we were to believe this, we would conclude that moving requested resources from HTTP 1.1 to 2 gives a 1.8x speed-up, while going from HTTP 2 to 3 causes 0.6x slow down. Is it really true that HTTP 3 is a slower protocol? No: A more likely explanation is that HTTP 3 is rare, and that the few resources that are being sent over HTTP 3 (e.g. Google Analytics) are things that have a larger than average effect on dominteractive. If you wanted to measure the effect of protocol, you could compare requesting with support HTTP/N to requesting with support for HTTP/N+1. Since this is all synthetic testing it shouldn't be too hard to run a controlled experiment instead of a correlational one.

deleted 6y ago

[deleted]

woeirua 6y ago

If 50% of the top million websites use JQuery, is it time to just admit that it should be bundled with JS by default in some way, shape or form?

jeofken 6y ago
Browsers could possibly bundle it, but let’s not bloat the language specification with jQuery
Hexigonz 6y ago
No, the spec has evolved past the need for it. The sites that still use it could easily be rewritten, usually with even less code. Plus, it's not like a large majority of sites using it are actually taking advantage of JQuery features, they're merely including it for Bootstrap.

lsllc 6y ago

I love this quote measuring the age of jQuery in different units: JQuery was first released in 2006, which is 14 years ago in human years, but much longer in JavaScript years. Measured in Angular versions, it is probably hundreds of versions ago.

these_are_not_t 6y ago

Tangential question: are there other giveaways than download time for a cached document which could be used by malicious scripts? I ask because I don't understand why a zero download time for a cached document couldn't be simply masked by some (random) wait by the browser instead of downloading the file again. From the chrome update page linked in the article, the explanation is: > However, the time a website takes to respond to HTTP requests can reveal that the browser has accessed the same resource in the past, which opens the browser to security and privacy attacks, [...] which seems to indicate that only time matters in the attacks. Yet, the third bullet point suggests: > Cross-site tracking: The cache can be used to store cookie-like identifiers as a cross-site tracking mechanism. as a possible attack based on the cache, which doesn't seem to involve document download time.

bastawhiz 6y ago
Browsers are mitigating what you described with cache partitioning. https://developers.google.com/web/updates/2020/10/http-cache-partitioning https://developers.google.com/web/updates/2020/10/http-cache...
- deleted 6y ago
  [deleted]
- deleted 6y ago
  [deleted]
- these_are_not_t 6y ago
  thx

Uninen 6y ago

Sad to see Sentry on the bottom 5 JS heap size list. Love their service but the JS payload is pretty massive.