Hacker News Reader

Comment by iainmerrick | Hacker News Reader

I don’t have a citation handy, but this is something that Google has famously studied. They claimed years ago that a tiny increase in the loading time of the Google home page led to a measurable decrease in the number of searches (like, a few percent).

Not everyone is operating “at Google scale”, of course, but in aggregate the effect is real and faster-loading pages have better metrics.

So, most satellite internet users won’t give up just because your page is slow, but some of them will, and even the ones that persevere will likely appreciate a faster page.

View on HN

most satellite internet users won’t give up just because your page is slow

My point is that 'slow' is a relative measure against other websites, not an objective value. So long as your website is faster than a typical website then users won't give up. Trying to be faster than average is worthwhile, but trying to be as fast as possible might not bring any additional value.

It's also possible (likely, in my opinion) that the website itself is important too. People expect Google to be fast because it's made by the biggest internet company there is, and perhaps because the page itself is very simple. It's just a textbox on a page. Surely it should be fast. That doesn't mean people have the same expectations for grannys-discount-wool.com.

This is a complex problem that probably doesn't have a straightforward answer. Using the mantra 'make your website as fast as possible' means you won't get it wrong, so it's worth doing, but you almost certainly get diminishing returns for that effort as you optimize for things like shaving off milliseconds and bytes.

Unless you're Google.

Although... that said... if Google really thought sites should be as fast as possible, wouldn't they make a smaller GoogleTagManager.js script?

Yeah, that's fair. My point (really just repeating hearsay -- I should check that Google research still stands up!) is just that load time optimization apparently has a bigger benefit than you might expect, and the diminishing returns don't kick in until much later than you'd expect. Edit to add: and the post being discussed has a good point that there's a performance shelf at ~14KB, so a small improvement can have a big impact.

Although... that said... if Google really thought sites should be as fast as possible, wouldn't they make a smaller GoogleTagManager.js script?

A good question! They're definitely not the most consistent. The left hand says one thing, some of their thousand right hands do the exact opposite...

Might be a competition thing. It would take a big delta in time-to-load for me to switch from Google to Bing. But if wsj.com takes 1s more than cnn.com maybe next time I pull out my phone on the train I'll switch publications.

>My point is that 'slow' is a relative measure against other websites, not an objective value.

No, it is an objective measure that is rooted in human biology and psychology. Our perception of HCI is based on various response time limits, that define whether we consider interactions seamless or retaining our attention. For the websites those response time limits are often hit in various circumstances, even in urban areas of developed countries (e.g. poor cellular network coverage in a building results in reduced speeds and higher bounce rates).

https://danluu.com/ loads super-fast for some reason. I definitely noticed it. I bookmarked this blog partly because it loads so quickly.

Actually, I was thinking of prog21.dadgum.com

>My point is that 'slow' is a relative measure against other websites, not an objective value. So long as your website is faster than a typical website then users won't give up.

You're competing against more than other web sites, and data shows this isn't true at all in any case. There are certain "thresholds" beyond which users will stop visiting much more frequently, but yeah.

We ran some A/B tests where we intentionally slowed our site down (at the webserver page generation level) by set percentages (0%, 10%, 25%, and 33% IIRC). Those would be against a baseline page generation time of around 2000ms, so the slowdowns were not small.

All tests showed a drop in traffic, conversion, and average session value indistinguishable from zero. Our hypothesis is that our site (where a converting visitor is on average designing and ordering a custom product) is one where the difference between 30 minutes and 31 minutes is not meaningful and a lot of the time is spent in the web-based document editor. It would not generalize to a "give me a quick search result", "sell me an item from a warehouse shelf", or "let me argue with someone on a forum".

This was of course disappointing, because we ran this test as a sanity check after having done an extensive project to improve the page speed across the main conversion funnel. The project was technically successful, but a business zero (probably for the same hypothesis as above), so we decided to test in the other direction, because that's easier to implement than to force faster pages.

Amazon has publicly stated that every 100ms in additional loading time leads to 1% loss in revenue. For the scale of Amazon, that is massive

That's a claim that they made in 2006. Could there be a reason why Amazon said that a slow website would have a massive impact on ecommerce sales back then? Was there some other Amazon product that would greatly benefit from people believing they had to use the fastest hosting service possible for their online store?

Coincidently, AWS also launched in 2006.

AWS was nothing like it is today back in 2006. It’s not as easy as your post implies, and if you know the full story, it’s super far fetched.

Was it linear though? I understand how you can lose 50% revenue by 5 seconds delay per click. But thinking that this has no “breakpoints” is naive.

Also, personally when shopping for e.g. jeans and tshirts I’d rather just wait for all items (json) and thumbnails to load (they can do that in bg except for the first page) and then filter/search/pagination would work instantly. You can lose half a hour in total by dealing with these shitty filtering sidebars which reload everything every time. Why aren’t e-shops then just semi-local apps over an on-demand synchronizable full-blown localstorage db? Nobody does this sort of precaching. Do they know how much revenue they are losing? It doesn’t add up.

It was a very limited study and Amazon have sent C&Ds to other large companies to tell them to stop using that quote

Well then, since Google these days is slow as hell on slow internet, I guess users with slow internet are no longer important.

When trying to find something on Google while visiting smaller towns in Germany, it's often down right unusable. Then again, I've been used to broadband and 4G for many years now.

Page / ad impressions is another metric for google; that's one reason why they have made such big improvements in the speed of internet and browsing with Chrome, their own DNS, HTTP/2 and 3, etc; the reasoning being that the faster people can browse, the more ads they will see, the more revenue Google gets. And it bought them a lot of goodwill.

But this may apply on a smaller scale too. For Amazon, it's giving people less time to rethink their impulsive decision.

Reply on news.ycombinator.com