3 ms·

Google found a 0.5 second delay caused a 20% decrease in repeat traffic, that persisted after the delay went away (http://glinden.blogspot.com/2006/11/marissa-m

by arohner 11y ago

Google found a 0.5 second delay caused a 20% decrease in repeat traffic, that persisted after the delay went away (http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20....) Amazon found every 100ms slower the site loaded, they lost 1% in revenue: http://www.gduchamp.com/media/StanfordDataMining.2006-11-28.pdf http://www.gduchamp.com/media/StanfordDataMining.2006-11-28.... Walmart.com found a very large change in conversion rate based on page load times: ( http://www.slideshare.net/devonauerswald/walmart-pagespeedslide http://www.slideshare.net/devonauerswald/walmart-pagespeedsl... slide 37) My own customers have seen 4x different conversion rate, when grouped by page load time. (i.e. same slide as walmart page 37 above, where the peak is 4x higher than the lowest performing group). Your business probably won't fail because it's slow, but it will certainly make less money because it's slow.

robocat 11y ago
> My own customers have seen 4x different conversion rate, when grouped by page load time Was that a controlled test? If just a correlation, then other variables might confound i.e. users from overseas, users with a slow connection, users with a slow computer. Agree with you though!
- arohner 11y ago
  I agree there's certainly some correlation, but we can fix e.g. "slow connections" and "slow computers" by not serving 9MB auto-playing hero videos [edit:] when it's not appropriate for your user demographics. I'm not in the position to intentionally slow down my customers, so I haven't run a controlled test. Google's test was controlled though.
draw_down 11y ago
But in this context, the issue becomes how much JS bundle weight it takes to cause a 0.5 second delay. And there are many other things that can slow down page load time (and especially perceived page load time) that either don't involve JS at all, or are not directly caused by the amount of JS that gets loaded.
- arohner 11y ago
  Depends on your connection. I gave a talk about CLJS page speed, and server side rendering at the recent Clojure conj (https://www.youtube.com/watch?v=fICC26GGBpg https://www.youtube.com/watch?v=fICC26GGBpg). Trying to load my site on the conference wifi, 200kB took 3 seconds = 60kB/s, so 30kB would have been enough. "Ok, that's not real world". Today, the cable guy is here fixing my home internet, so I'm tethering my iPhone 5s. Loading the .js for my site took 40kB in 143ms = 300kB/s, so 150kB would have been enough. "Still not real world". Fine. Here's the waterfall graph of a visitor from Canada to rasterize.io today: (https://s3.amazonaws.com/static.rasterize.com/canada-waterfall.jpeg https://s3.amazonaws.com/static.rasterize.com/canada-waterfa...). Loading the .js took took 40kB in 60ms = 666kB/s, so 300kB. So certainly less than half a meg of JS, which is very common to see in SPAs. Certainly, there are tons of other things that can slow down a site. But the JS is one of the "easiest" to solve, because devs are responsible for it, and it has well known solutions, that people don't apply consistently. (reduce dependencies, only serve one file, Use webpack/closure, use CDN)

by arohner 11y ago

robocat 11y ago

> My own customers have seen 4x different conversion rate, when grouped by page load time Was that a controlled test? If just a correlation, then other variables might confound i.e. users from overseas, users with a slow connection, users with a slow computer. Agree with you though!

arohner 11y ago
I agree there's certainly some correlation, but we can fix e.g. "slow connections" and "slow computers" by not serving 9MB auto-playing hero videos [edit:] when it's not appropriate for your user demographics. I'm not in the position to intentionally slow down my customers, so I haven't run a controlled test. Google's test was controlled though.

draw_down 11y ago

But in this context, the issue becomes how much JS bundle weight it takes to cause a 0.5 second delay. And there are many other things that can slow down page load time (and especially perceived page load time) that either don't involve JS at all, or are not directly caused by the amount of JS that gets loaded.

arohner 11y ago
Depends on your connection. I gave a talk about CLJS page speed, and server side rendering at the recent Clojure conj (https://www.youtube.com/watch?v=fICC26GGBpg https://www.youtube.com/watch?v=fICC26GGBpg). Trying to load my site on the conference wifi, 200kB took 3 seconds = 60kB/s, so 30kB would have been enough. "Ok, that's not real world". Today, the cable guy is here fixing my home internet, so I'm tethering my iPhone 5s. Loading the .js for my site took 40kB in 143ms = 300kB/s, so 150kB would have been enough. "Still not real world". Fine. Here's the waterfall graph of a visitor from Canada to rasterize.io today: (https://s3.amazonaws.com/static.rasterize.com/canada-waterfall.jpeg https://s3.amazonaws.com/static.rasterize.com/canada-waterfa...). Loading the .js took took 40kB in 60ms = 666kB/s, so 300kB. So certainly less than half a meg of JS, which is very common to see in SPAs. Certainly, there are tons of other things that can slow down a site. But the JS is one of the "easiest" to solve, because devs are responsible for it, and it has well known solutions, that people don't apply consistently. (reduce dependencies, only serve one file, Use webpack/closure, use CDN)