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?
We rendered a million web pages to find out what makes the web slow
51–60 of 124 posts
Re: We rendered a million web pages to find out what makes the web slow
#52Use an adblocker. I save about 25 gigs and hours of my time every month. * https://www.ublockorigin.com * I block much more than ads.
Out of curiosity, what else do you use it for?
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.
Re: We rendered a million web pages to find out what makes the web slow
#53Earlier quoted context omitted.
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,…
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.
Re: We rendered a million web pages to find out what makes the web slow
#54One 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.
Re: We rendered a million web pages to find out what makes the web slow
#55Earlier quoted context omitted.
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.
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
Re: We rendered a million web pages to find out what makes the web slow
#56Seems like jQuery is a big cause of slowdowns - anybody have suggestions for how to provide similar functionality without it?
API compatible smaller libraries https://zeptojs.com/ or no library http://youmightnotneedjquery.com/
Re: We rendered a million web pages to find out what makes the web slow
#57Earlier quoted context omitted.
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
https://outline.com/ is also fantastic for this purpose.
Re: We rendered a million web pages to find out what makes the web slow
#58Use an adblocker. I save about 25 gigs and hours of my time every month. * 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 site…
I use AdGuard with Safari, works great.
Re: We rendered a million web pages to find out what makes the web slow
#59Just don't use JavaScript lol
Re: We rendered a million web pages to find out what makes the web slow
#60Seems 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 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].