4 ms·

I don't know if this talk was ever made public but I heard at Google that under some circumstances cutting a few hundred milliseconds of latency can double clic

I don't know if this talk was ever made public but I heard at Google that under some circumstances cutting a few hundred milliseconds of latency can double click-through, conversions, etc., or even more. I do occasionally see Google people encouraging web developers to make their pages faster at conferences and such. Personally I would be very concerned about the money I was losing if I had a web site where the 95th worst percentile of my paying customers had to wait more than two seconds (from the client's perspective) for a pageload. I'd buy a bigger database machine, spread my servers to more geographical regions, whatever it took to try to bring that latency down.

patio11 17y ago
Google's Marissa Mayer has presented their page loading results a few times publicly: in one unplanned experiment, about .5 seconds in marginal load time caused number of user searches (and, by extension, clicks on ads and Google revenue) to decline by 20%. That was the Web 2.0 Conference in 2006. I'd buy a bigger database machine, spread my servers to more geographical regions, whatever it took to try to bring that latency down. Why make life hard. Buying a bigger database server costs actual money and time. Getting out the YSlow checklist and knocking two to three things off of it costs nothing and no significant amount of engineer time. Gzip CSS/JS files: four lines in your Apache config, warm restart, done. Collapsing CSS/JS together: 16 characters (:cache => true) in Rails, warm restart, done. Spriting CSS images: open a web page, type a bit, copy/paste what it tells you to to development, push to staging, verify it works, done. Moreover, as compared to buying a DB or spreading your servers, these are virtually guaranteed to actually work. Many, many of the suggestions that come under the heading "performance improvements" do not actually work because they address things that are not problems. (For example, unless you have data which convincingly demonstrates differently, the vast majority of websites can assume that the web stack is not a problem. Optimizing your code within the web stack is generally a hideously expensive waste of time.)
- houseabsolute 17y ago
  Sure, fixing the webpage would come first. I only mean to demonstrate that I would spare no metaphorical expense in fixing the problem.

patio11 17y ago

Google's Marissa Mayer has presented their page loading results a few times publicly: in one unplanned experiment, about .5 seconds in marginal load time caused number of user searches (and, by extension, clicks on ads and Google revenue) to decline by 20%. That was the Web 2.0 Conference in 2006. I'd buy a bigger database machine, spread my servers to more geographical regions, whatever it took to try to bring that latency down. Why make life hard. Buying a bigger database server costs actual money and time. Getting out the YSlow checklist and knocking two to three things off of it costs nothing and no significant amount of engineer time. Gzip CSS/JS files: four lines in your Apache config, warm restart, done. Collapsing CSS/JS together: 16 characters (:cache => true) in Rails, warm restart, done. Spriting CSS images: open a web page, type a bit, copy/paste what it tells you to to development, push to staging, verify it works, done. Moreover, as compared to buying a DB or spreading your servers, these are virtually guaranteed to actually work. Many, many of the suggestions that come under the heading "performance improvements" do not actually work because they address things that are not problems. (For example, unless you have data which convincingly demonstrates differently, the vast majority of websites can assume that the web stack is not a problem. Optimizing your code within the web stack is generally a hideously expensive waste of time.)

houseabsolute 17y ago
Sure, fixing the webpage would come first. I only mean to demonstrate that I would spare no metaphorical expense in fixing the problem.