Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Despite faster broadband every year, web pages don't load any faster

datafantic.com

Post reply on HN
Print view View original

51–60 of 178 posts

Re: Despite faster broadband every year, web pages don't load any faster

#51

Post by illuminati1911 »

wodenokoto wrote: post #30

Not just load time, but "time to read content" has exploded. Once the webapp has downloaded and it can start doing REST like requests for the actual content, it also needs to start loading pop-ups and the "continue reading"-button, that can hide the content after it is loaded. So once all that is done, the user needs to click away cookie consent banner, newsletter sign-up and the continue reading button. And only now…

”So once all that is done, the user needs to click away cookie consent banner, newsletter sign-up and the continue reading button. And only now can we stop the clock on "time to read content".”

You forgot the paywall that you will see at this point.

Maybe there is also a customer service bot saying: ”Hey! Ask me about our special offer on 12 month subscription!”

Re: Despite faster broadband every year, web pages don't load any faster

#52

Post by alkonaut »

dylan604 wrote: post #39
alkonaut wrote: post #36

Good enough is good enough. Just like faster computers don’t make new apps any faster (even at the peak of scaling decades ago), they make sure we can write more complex apps without making them too slow, or equivalently, add more things to apps and sites if there is any performance headroom left.

>Good enough is good enough. Oh to be a mere average computer user. I work with files that can still take some non-instant time after hitting save to complete. Conversely, it still takes some non-instant time to open said file. As long as there's such a thing as progress bars, count downs, spinning wheels, beach balls, etc, there is always room to make things faster.

I develop very complicated software for a living and as always, there are some features that will take an unreasonable amount of time. On large documents, you have customers wait 5 seconds for a regular operation (that you may need to complete dozens of times in a row).

And yet when you ask customers whether they want more features, or a faster program it's invariably features. Fix a bug or add a feature? Add a feature. Improve perf or add a feature? Add a feature.

My own tolerance for delays is tiny, but my "average users" seem to not suffer from it at all. I guess the reason is this: they know how much time something took before. They know that if this takes 10 seconds and it took them an hour to do on paper, that's quick. Meanwhile for me I'm in the IDE having a 200ms keystroke delay and I'm almost having a heart attack.

Re: Despite faster broadband every year, web pages don't load any faster

#53

Post by fmajid »

Throughput of networks is increasing but latency doesn’t improve as much (although 5G wireless is a big improvement over 4G LTE). Also TCP slow-start limits how fast an HTTP connection can go, and most are short-lived so the connection is still ramping up when it is closed. That’s one of the supposed benefits of QUIC a.k.a. HTTP/3.

And then there is bloat, the scourge of JavaScript frameworks and what passes for front-end development nowadays.

Re: Despite faster broadband every year, web pages don't load any faster

#54

Post by manuelmoreale »

Dma54rhs wrote: post #46
manuelmoreale wrote: post #41

The irony of this post is that the single heaviest resource loaded by this page is a 750kb image used only for the meta tags as a sharing image which most people consuming and downloading the page will never see. What's baffling to me is how people love to spend seemingly infinite time playing with tech stacks and what not but then pay very little attention to basic details like what to load and how many resources do…

These images don't get loaded by a browser, probably it's being used somewhere else. 750kb is way too big for that kind of image anyway.

Ah you're right. It's even dumber. It's used as a header image but it's then hidden with a display: None !important;

But I see the image inside the network tab so bandwidth is getting wasted for no reason.

Re: Despite faster broadband every year, web pages don't load any faster

#55

Post by fmajid »

sp332 wrote: post #17

https://web.archive.org/web/20220923024040/https://www.dataf... Do you think this is including ad loads? Ad networks run a real-time auction. It takes some time to collect bids so the highest can be chosen.

OpenRTB is capped at 100ms for the auction and in practice much less than that. One of the few areas of web development or assimilated where serious attention is paid to performance.

Re: Despite faster broadband every year, web pages don't load any faster

#56

Post by RF_Savage »

fmajid wrote: post #53

Throughput of networks is increasing but latency doesn’t improve as much (although 5G wireless is a big improvement over 4G LTE). Also TCP slow-start limits how fast an HTTP connection can go, and most are short-lived so the connection is still ramping up when it is closed. That’s one of the supposed benefits of QUIC a.k.a. HTTP/3. And then there is bloat, the scourge of JavaScript frameworks and what passes for fron…

On mobile latency has constantly improved. GPRS/EDGE was often +100ms ping --> 3G 400-50ms depending on the day --> 4G/LTE 50-30ms and now I'm often getting sub-20ms ping on 5G connections.

Re: Despite faster broadband every year, web pages don't load any faster

#57

Post by lrem »

Kiro wrote: post #45
wodenokoto wrote: post #30

Not just load time, but "time to read content" has exploded. Once the webapp has downloaded and it can start doing REST like requests for the actual content, it also needs to start loading pop-ups and the "continue reading"-button, that can hide the content after it is loaded. So once all that is done, the user needs to click away cookie consent banner, newsletter sign-up and the continue reading button. And only now…

What's the point of "continue reading"? Why not just show the full thing immediately?

A measuring point.

Re: Despite faster broadband every year, web pages don't load any faster

#58

Post by tannhaeuser »

Well we could start here and now by reporting load sizes/site footprint in bytes which wouldn't look out of place on hn, along with badges for cookie consent dialogs, ga usage, non-responsive design, high energy consumption flags for sites that suck the last power out of your mobile, and other non-desiderata. Or just mark a site as requiring JavaScript so we can avoid it. DDG should be doing the same.

Re: Despite faster broadband every year, web pages don't load any faster

#59

Post by mostlystatic »

Desktop bandwidth is improving over time, but as I understand HTTP Archive is still using a 5 Mbps cable connection.

From their FAQ/changelog [1]:

> 19 Mar 2013: The default connection speed was increased from DSL (1.5 mbps) to Cable (5.0 mbps). This only affects IE (not iPhone).

There was another popular article on HN a while ago [2], claiming mobile websites had gotten slower since 2011. But actually HTTP Archive just started using a slower mobile connection in 2013. I wrote more about that issue with the HTTP Archive data at the time [3].

[1] https://httparchive.org/faq [2] https://www.nngroup.com/articles/the-need-for-speed/ [3] https://www.debugbear.com/blog/is-the-web-getting-slower

Re: Despite faster broadband every year, web pages don't load any faster

#60

Post by mostlystatic »

mostlystatic wrote: post #59

Desktop bandwidth is improving over time, but as I understand HTTP Archive is still using a 5 Mbps cable connection. From their FAQ/changelog [1]: > 19 Mar 2013: The default connection speed was increased from DSL (1.5 mbps) to Cable (5.0 mbps). This only affects IE (not iPhone). There was another popular article on HN a while ago [2], claiming mobile websites had gotten slower since 2011. But actually HTTP Archive j…

Regarding "4 seconds wasted" per visit: HTTP Archive also publishes real-user performance data from Google, and only 10% of desktop websites take 4 seconds or more to load. (And I think that's not the average experience but the 75th percentile.) https://httparchive.org/reports/chrome-ux-report#cruxSlowLcp

The Google data uses Largest Contentful Paint instead of Speed Index, but the two metrics ultimately try to measure the same thing. Both have pros and cons. Speed Index goes up if there are ongoing animations (e.g sliders). LCP only looks at the single largest content element.

When looking at the real-user LCP data over time, keep in mind that changes are often due to changes in the LCP definition (e.g opacity 0 elements used to count but don't any more). https://chromium.googlesource.com/chromium/src/+/master/docs...

Post reply on HN