We rendered a million web pages to find out what makes the web slow(itnext.io)
itnext.io
We rendered a million web pages to find out what makes the web slow
https://itnext.io/we-rendered-a-million-web-pages-to-find-out-what-makes-the-web-slow-72bbba9ade96
123 comments
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.
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.
Use an adblocker. I save about 25 gigs and hours of my time every month. *
https://www.ublockorigin.com
* I block much more than ads.
https://www.ublockorigin.com
* I block much more than ads.
uBlock is what's keeping me from switching to Safari (which is so much nicer to use on a Mac)
It seems like most people who use Safari use full system-level ad blockers like Wipr. But I was also Googling around and found some complaints about Wipr, like it taking forever to be updated to block YouTube ads when they switch how they're displayed, or not being as good at getting around ad-block detection on certain sites.
It seems like most people who use Safari use full system-level ad blockers like Wipr. But I was also Googling around and found some complaints about Wipr, like it taking forever to be updated to block YouTube ads when they switch how they're displayed, or not being as good at getting around ad-block detection on certain sites.
I use AdGuard and it works pretty well. Well enough that Safari is still the superior experience on my Mac for general browsing, especially when it comes to performance and battery life.
I actually use Chrome, Firefox, and Safari on a daily basis, so I have some pretty solid annecdata that Safari is the best experience.
I actually use Chrome, Firefox, and Safari on a daily basis, so I have some pretty solid annecdata that Safari is the best experience.
I've recently switched to macOS and Safari with Wipr. I don't see much difference to my Firefox setup with AdNauseam (uBlock Origin) before. More on the contrary - my selected lists were very aggressive and I had various sites where I had to disable uBlock to see them properly. With Safari and Wipr, everything seems to just work.
> I don't see much difference to my Firefox setup with AdNauseam (uBlock Origin)
AdNauseam is not uBlock Origin, you can not use AdNauseam's results to judge uBlock Origin.
AdNauseam is not uBlock Origin, you can not use AdNauseam's results to judge uBlock Origin.
As a direct fork, it’s currently 2282 commits ahead, 586 commits behind your uBlock. That amounts to about the commits since uBlock 1.29.0 - which is exactly the version they’re claiming to use.
But yes, who knows what they’ve changed.
But yes, who knows what they’ve changed.
It's not just the code, it's also about what is not filtered in Adnauseum that would normally be filtered in uBO with default settings/lists.
Thank you so much for umatrix (I know, discontinued) and UBO, Raymond, and thanks to all the filter list maintainers.
Please allow me this minor hijacking to express my complete and absolute gratitude for your efforts in developing uBO.
Good to know, thanks. Maybe I'll have to give it a shot. I suppose $2 isn't that big of a risk given what some apps on the Mac App Store cost
I use AdGuard with Safari, works great.
You can install uBlock in Safari from the AppStore. Works great for me.
That is a clone, not the original uBlock Origin. I don't think uBlock Origin exists for safari 13+
If you can afford it, I'd suggest switching to AdNauseam (https://adnauseam.io). They're using the same uBlock Origin engine, but ads are downloaded and clicked on in the background. This way you still generate revenue for site owners.
But since this extension is banned from the Chrome Web Store, you'll have to install it manually there. On Firefox it's available from their add-on store.
But since this extension is banned from the Chrome Web Store, you'll have to install it manually there. On Firefox it's available from their add-on store.
I specifically choose not to use this. Do not use forks of uBlock Origin. They might sell anytime. It has happened before, it will happen again.
Plus I do not like ad fraud. I get lots of captchas. I also don't wanna give money to Google and Facebook.
If uBO sells out (I don't think gorhill will, but I don't know him) it'll be the top link on HN
https://www.lowyat.net/2020/224264/chromium-versions-nano-ad...
https://arstechnica.com/information-technology/2020/10/popul...
Plus I do not like ad fraud. I get lots of captchas. I also don't wanna give money to Google and Facebook.
If uBO sells out (I don't think gorhill will, but I don't know him) it'll be the top link on HN
https://www.lowyat.net/2020/224264/chromium-versions-nano-ad...
https://arstechnica.com/information-technology/2020/10/popul...
This is based on a misunderstanding of how ads work and does harm.
If this silently clicks ads in the background the click rate goes up but the goal action (buying, signing up) remains at 0 which smartprices the ads and tanks the value of the ads for the real clickthroughs.
If you must block ads just use uBlock Origin so you are treated like your visit doesn't exist.
A deeper question is it moral to consume content and block the ads. Wouldn't that be the same as pirating a movie? (not that there is anything wrong with pirating). Are there people who would block ads and complain about people pirating, or even stealing from a store if you can get away with it.
If this silently clicks ads in the background the click rate goes up but the goal action (buying, signing up) remains at 0 which smartprices the ads and tanks the value of the ads for the real clickthroughs.
If you must block ads just use uBlock Origin so you are treated like your visit doesn't exist.
A deeper question is it moral to consume content and block the ads. Wouldn't that be the same as pirating a movie? (not that there is anything wrong with pirating). Are there people who would block ads and complain about people pirating, or even stealing from a store if you can get away with it.
Is it moral to conflate "advertisement" with code running on my device without my express permission? Tracking my behavior across the web? Selling their profiles to entities with which I have no direct connection? Dog wagging by changing what I see across sites to get better conversion rates?
Doing what I can to prevent all that doesn't present me with any moral quandary. Advertisers certainly don't follow any sort of moral imperative.
Advertising is not inherently bad but modern web advertising is ridiculous.
Doing what I can to prevent all that doesn't present me with any moral quandary. Advertisers certainly don't follow any sort of moral imperative.
Advertising is not inherently bad but modern web advertising is ridiculous.
Morally, blocking ads is equivalent of having your butler cut the ads out of the newspaper before handing it to you.
Free newspaper I want to add. Nobody is forcing companies to publish their content freely accessible.
I don’t know how many of you people remember the Internet around 2000. People actually paid to be able to publish their stuff on the Internet. Because they wanted to. Without any intent on getting revenue. Unthinkable, I know!
I don’t know how many of you people remember the Internet around 2000. People actually paid to be able to publish their stuff on the Internet. Because they wanted to. Without any intent on getting revenue. Unthinkable, I know!
[deleted]
After stealing the newspaper?
Browsing the web is equivalent of your butler shouting to another butler to please GET /some/page, and the other butler then kindly replying with a document.
Theft requires the action to not be voluntary, but a web server replying with a page is free to reject my request. It is entirely moral.
Theft requires the action to not be voluntary, but a web server replying with a page is free to reject my request. It is entirely moral.
The torrent accepts my clients request.
My mp3 player will play that song you downloaded as well.
It's like your butler downloading a torrent with a song played to you.
I won't argue pirating is not moral. But it has the same morality as blocking ads.
My mp3 player will play that song you downloaded as well.
It's like your butler downloading a torrent with a song played to you.
I won't argue pirating is not moral. But it has the same morality as blocking ads.
I agree that copyright law does not make sense
Ads are inherently immoral and it's ok to watch a movie for free as nothing is stolen in that case. Ads are immoral because the website gets access to the biggest distribution channel in history - the internet, access to the financial system, a huge educated society and all this for free, and for this opportunity it sneakily builds a profile of visitors and sells that info to whoever pays. On top of that it dares to annoy visitors with tasteless visuals. Imagine someone wants to start a business and is given an opportunity be seen by hundreds of potentials clients: they come to his party curious to see what's there, but he secretly takes pictures of all visitors, records who talks to whom, takes photos of contact lists in their phones, and then sells all that to the highest bidder. On top of that he suddenly starts loud tv ads on a huge bright lcd screen to feature some junk paid by nobody knows who. Only then, after wasting everyone's time and profiting off their personal data, the host dares to pitch his business idea. So yeah, if a website treats me like trash, I'll do the same in return.
Was it moral from advertisers to pervert the web protocols so that advertisements can be forced upon us? HTTP still allow us to choose not to fetch content based on the URL. If advertisers do not like it they are free to invent their own web.
Advertisements cannot be the price to pay for the modern internet because the old internet had more value.
So, an adblock should blank the entire page, no, scratch that, back() me immediately? That actually sorta makes sense. Not talking about morals, just practically.
That would create a subset of "no attention stealing" web.
But actually ads placed in separate elements are convenient in a way . It would be much much worse if the ad industry switched to a sponsored content to invade that area.
That would create a subset of "no attention stealing" web.
But actually ads placed in separate elements are convenient in a way . It would be much much worse if the ad industry switched to a sponsored content to invade that area.
This seemed really interesting, so I clicked through to their FAQ.
> Does AdNauseam's automatic Ad-clicking create billable events for advertisers?
> It depends on the advertising business model and the degree of effort they are willing to put into filtering. Some might, others would not.
So it seems like the extension only "generates revenue for site owners" if it's either
- small enough for ad selling companies to not know it exists (and sophisticated enough to defeat their baseline filtering measures) or - large enough for ad selling companies to notice it exists and sophisticated enough to defeat active attempts to filter clicks from AdNauseam specifically
I don't know how this arms race usually turns out, but it seems like there could be a chance that this is just a uBlock Origin that consumes more bandwidth.
> Does AdNauseam's automatic Ad-clicking create billable events for advertisers?
> It depends on the advertising business model and the degree of effort they are willing to put into filtering. Some might, others would not.
So it seems like the extension only "generates revenue for site owners" if it's either
- small enough for ad selling companies to not know it exists (and sophisticated enough to defeat their baseline filtering measures) or - large enough for ad selling companies to notice it exists and sophisticated enough to defeat active attempts to filter clicks from AdNauseam specifically
I don't know how this arms race usually turns out, but it seems like there could be a chance that this is just a uBlock Origin that consumes more bandwidth.
This seems very hostile to small businesses who pay for those ads.
Yeah they didn't mention the stated purpose of AdNauseam, which is explicitly hostile to ad networks and advertisers.
EDIT: From their paper:
"The second goal is to provide a means of proactive engagement, allowing users an avenue for expression of their dissatisfaction with current advertising mechanisms to those in control of such systems. In the case of AdNauseam, this expression has an interventional aspect, as the software actively attempts to disrupt the economic model that drives advertising surveillance"
http://ceur-ws.org/Vol-1873/IWPE17_paper_23.pdf
EDIT: From their paper:
"The second goal is to provide a means of proactive engagement, allowing users an avenue for expression of their dissatisfaction with current advertising mechanisms to those in control of such systems. In the case of AdNauseam, this expression has an interventional aspect, as the software actively attempts to disrupt the economic model that drives advertising surveillance"
http://ceur-ws.org/Vol-1873/IWPE17_paper_23.pdf
What percentage of google ads are from small businesses?
What percentage of google ads targeted to me are from small businesses?
(I've no way of guessing as I just block all of them)
What percentage of google ads targeted to me are from small businesses?
(I've no way of guessing as I just block all of them)
Well, you can decide. Do you care more about the sites you visit frequently or the businesses that use Google Ads?
Nearly all Ad Networks do not use Click-Through as their payment metric anymore
It's still mentioned in e.g. Google's AdSense Help: https://support.google.com/adsense/answer/32725?hl=en
Out of curiosity, what else do you use it for?
I spend a lot of time on Youtube, and their recommendations are addictive, so I blocked the sidebar that recommends next videos.
I block scripts on news sites since they serve no purpose.It removes things like popups, autoplaying videos and comments.
And I have so many custom filters set up to block cookie prompts, annoyances and other stuff.
I block scripts on news sites since they serve no purpose.It removes things like popups, autoplaying videos and comments.
And I have so many custom filters set up to block cookie prompts, annoyances and other stuff.
> I block scripts on news sites since they serve no purpose
https://outline.com/ is also fantastic for this purpose.
https://outline.com/ is also fantastic for this purpose.
Never works for me. Tried with dozens of links and multiple browsers.
Plus paywalls aren't really a problem. 2/3 clicks and they're gone
Plus paywalls aren't really a problem. 2/3 clicks and they're gone
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.
For example looking at en.wikipedia.org I can just remove that COVID box. Scalable? No. Smart? Eeeyuh... Satisfying? Hell yes.
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!
power & freedom, the things native apps never ever permit us.
On news websites, beyond the typical heavy JS ads, uBlock is super useful for removing 1P static ads (e.g. New Yorker "subscribe and get a free tote" linked to as a newyorker.com image from next to an article) as well as things like sticky title bars and "top articles" widgets to declutter the reading experience.
You can use ubo filters to overwrite styles, saves you one extension
I don't use Facebook much any more but a lot of the noise on there can be blocked (the ads which are conveniently labelled as sponsored, and "suggested for you").
They've seemingly gone out of their way to make this difficult by putting each letter of "Sponsored" in its own div, but you can make a filter based on the aria-label instead.
They've seemingly gone out of their way to make this difficult by putting each letter of "Sponsored" in its own div, but you can make a filter based on the aria-label instead.
Blocking Drift Chatbots (those annoying things that change Title in browser windows, make noise, obstruct page content)
YouTube comments.
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.
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
Or am I missing something?
Or am I missing something?
That is not what "originally published at" means. The author is providing the canonical home of his own article.
Perhaps dang can change the link to https://catchjs.com/Blog/PerformanceInTheWild
From https://itnext.io/we-rendered-a-million-web-pages-to-find-ou... , in case anyone later wants to know.
itnext.io gets better SEO so the author posted to both places.
My mistake, thanks for pointing this out
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://developer.mozilla.org/en-US/docs/Web/API/Performance...
https://web.dev/interactive/#what-tti-measures
https://developer.mozilla.org/en-US/docs/Web/API/Performance...
>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.
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.
Original article: https://catchjs.com/Blog/PerformanceInTheWild
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.
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.
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.
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.
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
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
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/
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/
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.
I'd bet the majority of developers working on SPAs are doing so for internal dashboards/tools.
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.
> 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.
Exactly as anyone should have expected.
> I can guess without reading:
Can you not.
Can you not.
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.
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.
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.
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
That is a Chrome UI quirk. It's actually waiting on some subsequent action that doesn't bother clearing the status message.
I had to laugh—It took 5 seconds for that page to load for me.
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/Performance...
1. https://web.dev/interactive/
2. https://developers.google.com/web/fundamentals/performance/s...
3. https://www.speedshop.co/2015/11/05/page-weight-doesnt-matte...
4. https://developers.google.com/web/fundamentals/performance/c...
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/Performance...
1. https://web.dev/interactive/
2. https://developers.google.com/web/fundamentals/performance/s...
3. https://www.speedshop.co/2015/11/05/page-weight-doesnt-matte...
4. https://developers.google.com/web/fundamentals/performance/c...
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.
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.
[deleted]
> the problem isn't page weight or JS frameworks, it's network latency[3].
if that was the case electron apps with content available locally would not be so slow
if that was the case electron apps with content available locally would not be so slow
> 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.
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.
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.
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.
Browsers are mitigating what you described with cache partitioning.
https://developers.google.com/web/updates/2020/10/http-cache...
https://developers.google.com/web/updates/2020/10/http-cache...
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.
I'd not encountered Amazon Publisher Services but this article makes them look very bad.
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
[deleted]
It's pretty obvious. Javascript. Web applications that display text and media are slow. Web documents that display text and media are fast.
Seems like jQuery is a big cause of slowdowns - anybody have suggestions for how to provide similar functionality without it?
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/
1. https://javascript.info/script-async-defer#defer
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/
1. https://javascript.info/script-async-defer#defer
> 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/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/speculativ...
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/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/speculativ...
You're right, I stand corrected on the parsing bit I mentioned, which to be honest is a nuance I had not heard of. But it doesn't change my point much. Using script tags without `defer` will still delay the page load. They might not block parsing, but they will still block rendering. Both matter when it comes to seeing anything on your screen at all.
There's an entire site dedicated to this:
http://youmightnotneedjquery.com/
http://youmightnotneedjquery.com/
Have a local instance of it [1] to keep the functionality.
[1] - https://addons.mozilla.org/en-US/firefox/addon/localcdn-fork...
[1] - https://addons.mozilla.org/en-US/firefox/addon/localcdn-fork...
API compatible smaller libraries https://zeptojs.com/ or no library http://youmightnotneedjquery.com/
There's https://umbrellajs.com/. It's 2.5kb gzipped.
It's not feature complete with jquery as a drop in replacement but the API is about the same and it covers the 90%.
It's not feature complete with jquery as a drop in replacement but the API is about the same and it covers the 90%.
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?
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...
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...
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.)
(Also, the Rust Rocket is not primarily focused on perf, but developer ergonomics.)
Ah, good to know, thanks!
See also the Web Almanac for an in-depth look at the state of the web: https://almanac.httparchive.org/en/2020/
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?
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.
Browsers could possibly bundle it, but let’s not bloat the language specification with jQuery
Sad to see Sentry on the bottom 5 JS heap size list. Love their service but the JS payload is pretty massive.
[deleted]
Just don't use JavaScript lol
Don't tell me: it's mostly ad media, and then a bunch of .js packages.
Didnt read the article, my money is on javascript crap linked into the page from 200 different sites
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.
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.
No one has made anything as capable as the DOM.
It’s excellent for documents, and very capable for apps. Games and other intensely custom-graphical interfaces are really the only situation where it’s not great, and in that case you can drop into a canvas and/or SVG (SVG admittedly still being DOM, but not HTML DOM) with no difficulty.
HTML was not initially designed for interactive applications, but for many years has progressively been.
The DOM gets you things like support for accessibility tech in a way that few other technologies can rival; the only real defect it has is that it strictly uses a push model and you can’t query the screen reader—so you can’t do things like tweak things for particular screen readers (for good or ill), or skip parts of the accessibility tree for efficiency based on where the tool is looking at present, but must present the entire accessibility tree up front. But although this is limiting, there are also reasons why it is so, around privacy and robustness.
WebAssembly never had anything at all to do with the DOM, let alone replacing it.
It’s excellent for documents, and very capable for apps. Games and other intensely custom-graphical interfaces are really the only situation where it’s not great, and in that case you can drop into a canvas and/or SVG (SVG admittedly still being DOM, but not HTML DOM) with no difficulty.
HTML was not initially designed for interactive applications, but for many years has progressively been.
The DOM gets you things like support for accessibility tech in a way that few other technologies can rival; the only real defect it has is that it strictly uses a push model and you can’t query the screen reader—so you can’t do things like tweak things for particular screen readers (for good or ill), or skip parts of the accessibility tree for efficiency based on where the tool is looking at present, but must present the entire accessibility tree up front. But although this is limiting, there are also reasons why it is so, around privacy and robustness.
WebAssembly never had anything at all to do with the DOM, let alone replacing 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.
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.
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.
what would hacker news here be helped by by removing the dom? do you think this website would be better with your solution? why?
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.
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.
I'd be interested in some people expanding on what they think is so "wrong" with the DOM, especially from the point of view of performance, and (emphasis on this!) what would be so much better. It's not that different than any other widget toolkit anymore, which have all largely converged on the same sort of model for the same reasons.
I can't think of very many things that affect performance in big ways. An explicit "I'm going to do a lot of things to the DOM here, please hold the reflows until I'm done, I understand that some of the properties may go out of date in the meantime" might be nice. (Perhaps it's a death-of-a-thousand-cuts.)
The API itself is a bit klunky, but the rough edges are easy to paper over with any number of libraries, and is hardly the world's first klunky-but-functional API to be so papered over by libraries that add no significant slowdown. (Note I'm not talking about "react" here, but just things that make the DOM API a bit less klunky. Thin little wrappers that mostly get JIT'd out.) Native XPath-like integration into JS would be nice, but honestly, that's going to be a net slowdown because people will do lots of slow, easy things rather than write the more tedious, but faster, DOM manipulation.
But just being klunky doesn't actually make it slow.
I can't think of very many things that affect performance in big ways. An explicit "I'm going to do a lot of things to the DOM here, please hold the reflows until I'm done, I understand that some of the properties may go out of date in the meantime" might be nice. (Perhaps it's a death-of-a-thousand-cuts.)
The API itself is a bit klunky, but the rough edges are easy to paper over with any number of libraries, and is hardly the world's first klunky-but-functional API to be so papered over by libraries that add no significant slowdown. (Note I'm not talking about "react" here, but just things that make the DOM API a bit less klunky. Thin little wrappers that mostly get JIT'd out.) Native XPath-like integration into JS would be nice, but honestly, that's going to be a net slowdown because people will do lots of slow, easy things rather than write the more tedious, but faster, DOM manipulation.
But just being klunky doesn't actually make it slow.
It's not so much there being something "wrong" with it, it's more that there are trade-offs. Look, for example, at https://tc39.es/ecma262 (the JS spec) and try to jump around the page: you'll notice that it takes quite a bit of time for some things to render simply because the document is absolutely humongous. BUT, once it does load completely, you can insta-search it with ctrl+f, it reflows/wraps correctly in a mobile browser and and if you throw your iphone's accessibility feature at it, it'll read the document for you. Being able to google the thing in the first place is also due to ability to programmatically crawl the document and analyze its contents. These are important features that are usually forgotten by the people proposing that everything should be a thin bitmap buffer on top of raw hardware.
> 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.
lmao. sources?
lmao. sources?
(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.)