We rendered a million web pages to find out what makes the web slow
catchjs.com
catchjs.com
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.
Is the outcome of the research by CATCHJS different from what you have learnt?
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.
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?
[1]: https://optidash.ai/blog/optimizing-images-on-the-worlds-top...
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%?
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
It's interesting to see that even these big websites potentialy still have a lot of room for improvement for their loading times.
It would be interesting to get a drill down on what is being served on those protocols.
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.
34 days ago:
https://news.ycombinator.com/item?id=25517628 (115 comments)
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
[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.
Security is part of the reason but the bigger problem I find is tying uptime to somebody else whom I have no control over.
Install this wonderful extension to save hours of your time and gigabytes of your bandwidth.
I knew I would get alternative browser recommendations because of my phrasing... but I was also looking forward to them!
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.)
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.
It was also easier to install it on my parents' computers than to convince them to change browsers.
Also has a neat broken site reporting system in it which automatically generates a GitHub issue to fix the filter lists from a simplified form. Automatically prioritises sites via an algorithm, probably their Alexa ranking or something similar.
https://github.com/AdguardTeam/AdguardFilters/issues
I've found the issues get fixed pretty quickly too.
They've got an iOS app as well which integrates with the Safari content blocking system.
For desktop & mobile: use something like nextdns/adguard or pihole & consider installing it on your home networks router.
(It’s been 2 years or so, for all I know, they have both advanced to the point of being sufficient alone - but I did not experiment, since everything just works so well)
From their website: "Better is hand-crafted by Small Technology Foundation, a tiny two-person-and-one-husky not-for-profit striving for social justice in the digital network age. We curate our own unique blocking rules for Better based on the principles of Ethical Design."
Nice app.
Be aware, Better actually allows most compact, low compute, non-tracking ads. Anyone who wants to serve me respectful ads that don't abuse my privacy or my compute resources are absolutely welcome on my system. Happy to help. Non-respectful ads are not welcome.
While I'm promoting small Indie browser extension makers, I also like the StopTheMadness extension. This kills lots of rude click/function hijacking that is done by many obnoxious web pages. It also stops a lot of tracking code. Again, I have no relationship with the developer.
https://underpassapp.com/StopTheMadness/
Between the two of these, browsing becomes much less user hostile.
Give it a try if you want. It's free. https://ads-free.app/Ads-Free!%20Desktop/
Use this for network wide blocking of all sorts of virtual garbage. Not only for safari, but all your locally connected devices.
'1block'[1] kills even the video-ads on yt for free. 'firefox focus' has built-in ad-blocking but does not get the yt-ads afaik.
i wonder if the the fact that the most popular ad-tech company also producing the most popular mobile os has something to do with it.
I have informed many of my technophile, uBO/ABP friends and colleagues that it’s possible, and not one of them was aware before I told them.
The reason I don't use uBlock is because I think that it's overkill for me to run thousands of filters for every website in the world. And also I like the fact that I'm in control of my user agent. For example recently I turned off feature on some website which paused video when I switched to another tab. I did not like that feature, so I disabled corresponding JS handler, simple as that.
In return you get thousands of lines of tracking and advertisement JavaScript running on your machine for almost every website in the world.
Is that better? ;)
The JS for actual essential site functionality often pales in comparison to the assets and scripts activated by ads, which simultaneously track you.
No no no.
Mostly text, MAYBE some images.
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.
Is something like already proposed anywhere, or not really a solution to the problem — thoughts?
Wordpress itself probably skewed the numbers significantly.
- latency is bad, do a single request at start
- don’t use jquery
- ui frameworks are not part of the issue(?)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.
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.
With React and the like they operate on a copy of the DOM and automatically batch updates to it. All of the changes are applied at once so there's fewer layout, render, and draw events.
Part of the problem with jQuery is there's a cohort of web "developers" that grew up with it. Instead of learning the actual web stack they learned jQuery. Everything is put together (slowly) with jQuery. Even if they've been promoted out of junior positions they're not PMs or marketing drones requiring slow scripts because they're written in a style they understand.
The latest jQuery is 85 KB (~30 KB gzipped), and doesn't do anything time consuming on load. My guess is the types of sites that don't use jQuery happen to be the types of sites that are faster.
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?
And some times you have to let things fail and then explain why it di and then do it right
No JS, no tracking, no nonsense. 100% content.
BTW I do this for a living for some big brands just dropped FCP from 2.6 to 2.4 and CLS .478 to 0.385 with some tweaks to the preload.
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.
You could automate it with Selenium (headless Chrome). I think Googlebot does something similar?
I think what the OP was asking was more along the lines of partial hydration (where only parts of the DOM are hydrated by React/other framework) or no hydration (no JavaScript is loaded at all).
11ty does the latter: https://www.11ty.dev
The React team are working on partial hydration and announced it in December. Vercel did a write up on it here: https://vercel.com/blog/everything-about-react-server-compon...
Slack, Asana, GitHub, Gravit Designer, Google Docs/Sheets/Mail...
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.
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-missi...
It's challenging to convince a PM that people who block stats don't show up in their stats, but do still have money to spend. Often, a simple try/catch in the onclick handler that fires analytics events, and a quick happy path test with ublock on, is all it would take to fix a site. Well worth the 1% of extra revenue for a few minutes effort.
Bad example, I give you that.
This is my choice, except that periodically I have to go back to the web interface because searching over IMAP barely works at all. Maybe it's not even implemented and I'm only really searching downloaded mail, I'm not sure.
Bad software development slows the web down. The web, for what it is and does, is an incredibly fast network. The problem is people no longer care about performance, nor do you have the engineering talent to write performant web applications. Yes some of this can be boiled down to companies not prioritizing performance, and product managers pushing for more features and tracking, but we've always had these constraints, and tight deadlines, and seemed to deliver just fine. It was part of the expectations.
Our craft is degrading, I hate to say. We've allowed the vocal minority who were shouting "gatekeepers!" to water down the discipline of software development to the point where yes, you install a single npm dependency so you can reverse your array.
This is an empty statement and another overly simplistic answer. Of course bad software development slows the web down, because you're defining slow web sites as being badly developed.
whats wrong with that?
living throu the computers/internet/web for 25 years i can attest that there is truth in wirth's law, if only that folks are lazy.
You could similarly write:
“Lazy software development is why websites are slow because slow websites are caused by lazy development.”
“Greedy business practices are why websites are slow because advertising slows down the web and advertising is the result of greedy business practices”.
These are feel good statements that don’t actually provide any insight on the market forces at play nor provide any path to improving things.
The engineering might be perfectly fine if you take into account the deadlines, budgets and requirements from the clients/managers.
If you pay someone to build a house on a short deadline with a small budget, then you'll obviously get a crappy house. But the skill that went into building that house in such a short time, and on such a low budget, might be extremely high.
Good engineering doesn't mean a perfect product. It just means you managed to deliver the best possible one out of the situation you were in. It's up to the owner of the product to decide if it's good enough.
> Argument from fallacy is the formal fallacy of analyzing an argument and inferring that, since it contains a fallacy, its conclusion must be false.
Nobody here is claiming that the parent's statement is false. We're saying it's true! However, we're also saying it's useless (i.e. "vacuously true" or "tautologically true"). The parent is saying that many Web sites contain JS; the slow ones are due to "bad JS" (and implicitly, that the non-slow ones have non-bad JS).
How can we tell whether some JS is "bad"? By checking if it's slow. Let's say we do that, and find that the site is slow, and hence our JS is "bad". How can we improve it, to get non-bad JS? No idea; maybe getting a bunch of developers to make random refactorings, measuring the speed of each, using that to tell whether the JS is still "bad", and stopping once it's no longer slow and hence no longer "bad"? In which case, the whole notion of "bad JS" is irrelevant; it's conceptually indistinguishable from "slow page", and hence adds nothing to the discussion (i.e. if we followed the above steps, we would get exactly the same result if we ignore all the stuff about "bad JS" and just use the timing measurements directly).
Note that the concepts of "slow page" and "page with JS" are not vacuous, since we can measure them (with a clock, and by parsing the page source, respectively) and hence make falsifiable predictions about correlations and causal relationships between them.
All this results in bloated, unoptimized javascript bundles. To top it off, we under cache, and aggressively cache bust, and ship unminified bundles with oodles of source maps because of "developer experience" I can't tell you how many times I see, to this day, a fortune 500 company bundling an entire unminified javascript framework. Wirth's law indeed.
Hope this was a little less empty. These are my observations having done this for a few decades now and managing developers these days.
Good software development can slow the web down. People are often optimizing for code reusability, code quality, ease of debugging and other advantages of some heavyweight frameworks rather than raw load time. Often this is the right call as engineering is a cost centre. Where it goes wrong is when things get too slow and too bloated to the point you're actually having people abandon the site before load but most of the major frameworks used properly don't offer that extreme a tradeoff. I also have no idea what % of these sites have reached that level.
I don't think that's the whole story. I don't have hard numbers but Electron-based applications seem to reliably be far more bloated than applications using ordinary GUI frameworks.
I agree that deprioritising performance is part of the problem, but as far as I can tell the web is a very poorly performing GUI framework, when it's used as such.
Which, for the most part, is celebrated. Nearly nobody actually understands what they're doing anymore - I challenge anybody to point to the Javascript in their web app and explain what the purpose of each file is. Just the purpose, just the top level files. I doubt the majority of web devs can (if they could, they'd realize they don't need at least half of them).
All of this for something that should be no more complicated than entering a zip code and getting back a small page with information about whether or not there is an outage.
A large part of the web are static documents and they should be developed as such.
But I 100% disagree that this is how every website should be. We're given these amazing technologies, the internet, computers, libraries, tools and creativity and now we should just stick with sending and looking at formatted text?
I don't think so!
> 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.
Bundling, code splitting, tree shaking and asynchronous loading, pre-optimizations help here too.
I miss the marquee era, truly.
Here's a stupid, simple Vimeo downloader instead of a using the massive, slow starting youtube-dl
#!/bin/sh
# usage: curl https://vimeo.com/123456789 | $0
x=$(curl -s `grep -m1 -o https://player.vimeo.com/video/[^\"?]*|sed 's>$>/config>'`|grep -o https://[^\"]*mp4|sed -n \$p)
y=${x%/*};y=${y##*/};exec curl -so $y.mp4 $x
https://www.usenix.org/legacy/events/webapps10/tech/full_pap...
https://www.usenix.org/system/files/1403_02-08_mickens.pdf
Unlike Mickens, I cannot save the world, and I am not telling anyone else what to do or not to do, but I made the web fast for myself. Hence I am very skeptical of claims that "the web is slow". Web servers, the network and computers are plenty fast and still getting faster. I do not define "the web" as certain popular browsers, CSS, Javascript, etc. or whatever web developer tell me it is. Those are someone else's follies. I define it as hyperlinks (thus, a "web") and backwards compatible HTML. Stuff that is reliable and always works. To "make the web fast", I follow some simple rules. I only load resources from one domain, I forgo graphics, and I do not use big, complex, graphical, "modern" web browsers to make HTTP requests.
I do not even use wget or curl (only in examples on HN). I generate the HTTP myself using software I wrote in C for that purpose and send using TCP clients others have written over the years. There are so many of them. With a "modern" SSL-enabled forward proxy or stunnel, they all work with today's websites. "Small programs that do one thing well", as the meme goes.
Obviously, I still need the ever-changing, privacy-leaking, security risk-creating, eye-straining, power-consuming, time-wasting, bloated, omnibus browsers for any sort of serious transaction done with web, e.g., commerce, financial, etc. However that is a small fraction of web use in my case.
For me, using the web primarily comprises searching, reading and downloading. I never need Javascript for those tasks. I can do those them faster without the popular broswers than I can with them. The less interaction the better. I use automation where I can because IMO that is what computers were made for. "The right tool for the job", as the meme goes.
To think how much time and energy (kwH) has been devoted to trying to make Javascript faster as a way to make websites faster is, well, I won't think about it. Those working in the "software industry" and now "tech" are highly adept at creating the problems they are trying solve. Unfortunately today as we try to rely on software and the web for important things, we all have to suffer through that process with them.
By not using the popular browsers for a majority of web use, I have minimised the suffering of one user: me. The web is fast.
This way, there is no DNS traffic leaving the network. The only lookups preceding a TCP connection to a website are to the loopback.
That is the number one way I "make the web fast". If retrieving a web page were a chemical reaction, DNS is the "slow step". In most cases, I eliminate it.
Blind people use smartphones this way, so it's not as though the device can't support it.
And it would encourage all websites to be accessible, content-only, no-image sites, and they'd be no-javascript as well. Problem solved.
I always ask myself if something can be static now, and if so, I make it static.
I recently worked on a side project to transition [0] to a fully static web. Needless to say, the speed went up.
That’s not why. It’s ad networks and tracking scripts. Notice that single page application frameworks show up exactly zero times on the list of worst offenders.
Running Google or FaceBook ads? You need analytics, pixels and event trackers to know if you're ads are working optimally.
ReCaptcha v3 is a good way to slow down your site as are hero banner sliders (5% of sites were running GreenSock + Waypoint), also some flavour of interactive chat. Some 3rd party plugins simply don't work with async/defer or still use DOM write().
I'm sceptical of this statement. I think catching application errors is a necessity to ensure your application runs smoothly and doesn't mess with customer/user experience. We're already tracking all the errors in the backend, and we should also be able to do the same with frontend. At the end of the day, we're all humans, we will introduce bugs. Even if you can guarantee 100% no one will deliberately introduce bugs, there's still the accidental introduction, or the third party library issues.
The issue comes with tracking users. The amount of code needed to track user interactions is insane, because of the number of possible interactions. Tracking application code generally does not need a lot of code.
Sadly, the user trackers have messed it up for application error trackers too. We're blocking everything regardless of context, and this doesn't allow websites to fix their application errors.
(We've been around since 2014, so we pre-date them by 4 years)
Edit: I will give you that their web page header and pricing looks very similar.
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.