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.
We rendered a million web pages to find out what makes the web slow
11–20 of 124 posts
Re: We rendered a million web pages to find out what makes the web slow
#12Burn 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 webap…
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.
Re: We rendered a million web pages to find out what makes the web slow
#13Not 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.
Re: We rendered a million web pages to find out what makes the web slow
#14Use 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?
Re: We rendered a million web pages to find out what makes the web slow
#15Re: We rendered a million web pages to find out what makes the web slow
#16Technically 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.
Re: We rendered a million web pages to find out what makes the web slow
#17Burn 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 webap…
what would hacker news here be helped by by removing the dom? do you think this website would be better with your solution? why?
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.
Re: We rendered a million web pages to find out what makes the web slow
#18Earlier quoted context omitted.
Out of curiosity, what else do you use it for?
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.
Re: We rendered a million web pages to find out what makes the web slow
#191 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