Live data from Hacker News

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

itnext.io

21–30 of 124 posts

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

#21
post #19

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_inl…

> 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.

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

#23
post #6

Earlier 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.

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!

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

#25
post #6
post #4

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.

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.

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

#26
post #19

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_inl…

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/

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

#27
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...

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

#30
post #4

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.

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.

Post reply on HN