A recent article on the Econsultancy blog discussed the issue of page load times getting slower with some helpful tips on what can be done to help speed things up.  

The article stimulates other questions that I thought it would be interesting to tackle in more depth. 

These include issues such as: 

  • What should be specifically measured to determine a true sense of page load time? 
  • What tools can be used to measure your pages? 
  • What are slow page load times doing to your ecommerce channel?

What should be specifically measured to determine a true sense of page load time?

To understand what both new and existing consumers are facing when they are loading your pages, a few different scenarios should be undertaken when measuring page load speed times:  

  • First view – how long do pages load the first time someone comes to your site. 
  • Repeat view -  how long do pages load when someone comes back to your site.

Both are important, and both first and repeat view traffic types have high expectations.

For both first and repeat views, there are three specific metrics to measure: time to first byte, render start, and load time.

Time to first byte. The time to first byte measures the amount of time it takes for the servers (where your site is hosted) to react to the request of sending data (your content) to a browser (the browser of the individual who wishes to view your website).  

This determines if your server environment/infrastructure is truly responsive to the needs of your website.

Render start. The render start is a measure of time required for the first page element to appear on the browser. In other words, how long does it take for the individual to see something on their screen?  

Load time.  Load time is measured as the total time taken to load all elements of the page requested.

Once you have the above data for both first and repeat views there is one more scenario that needs testing - the above metrics under normal conditions, and conditions of stress (i.e. how does the website load content during campaign activity).

What tools can be used to measure your page load speeds? 

There are a quite a few options, but Webpagetest.org appears to be the most consistent in its data, and produces all the above metrics.   

What to do with this data?

Once you regain consciousness from the poor results, the reporting will indicate precisely what is slowing the pages down.  There is another very good article taking a technical view on what to do to increase the speed of loading pages.  

The most common reasons for slow loading pages is a mix of heavy images, heavy interactive page features (i.e. carousels on the home page) site build shortcuts from the dev team, and/or hosting environment not equipped to handle the traffic.  

For the purpose of context, have a look at Amazon’s results:

First View:

  • First Byte: 0.285 sec
  • Render Start: 0.944 sec
  • Load Time: 2.071 sec

Repeat View:  

  • First Byte: 0.285 sec
  • Render Start: 0.833 sec
  • Load Time: 1.346 sec

What are slow page load times doing to your ecommerce channel?

Mobile users are impatient.  The issue of load time is no longer confined to your website displaying on a PC or laptop.  If it takes seven seconds to display your content on a PC what happens with your mobile site on a 3G network?  

A study was done by Keynote who surveyed over 5,000 people in the first half of 2012 to find 66% of respondents expected mobile sites to load in under four seconds. It can be assumed this expectation has risen since then.  

Google’s support of page load times. While the purpose of this discussion is to recognise methods to solve slow page load times to improve the experience for consumers, it is worth noting a recent study showing a correlation between Google rankings and time to first byte.  

Over 2,000 websites had taken the above measures only to find those with a more robust back-end infrastructure achieved higher search rankings.  

The creators of the study had this to say about why they felt Google would use this metric: 

TTFB (time to first byte) is likely the quickest and easiest metric for Google to capture. Accurately measuring the various load times is also browser dependent and relies on its ability to load images and content. 

Using TTFB to determine the "performance" or "speed" could perhaps be explainable by the increased time and effort required to capture such data from the Google crawler. Not only is TTFB easy to calculate, but it is also a reasonable metric to gauge the performance of an entire site. 

Ever wonder why you are experiencing high bounce rates for highly targeted campaigns?  Many times marketers attribute high bounce rates to a high influx of traffic. That may be true, however, consideration of page load times under high stress is recommended.  

How does Google Analytics (GA) record a “bounce”?  If you have a situation where a page is taking seven seconds to load, but after the third second, the individual gives up and leaves, a "bounce" is ackowledged in GA.  If the tracking code is installed correctly (in your header), GA recognises the visit as a pageview and therefore a bounce.

You can have the most effective campaign running, however, slow page load times will stifle your ability acquire new business and stimulate repeat sales.

Get measuring... good luck.

Greg Randall

Published 7 August, 2013 by Greg Randall

Greg Randall is a senior digital consultant with Comma Consulting and a contributor to Econsultancy. You can connect with Greg on LinkedIn or Twitter

26 more posts from this author

You might be interested in

Comments (17)

Save or Cancel
James Gurd

James Gurd, Owner at Digital JugglerSmall Business Multi-user

Hi Greg,

Thanks for the reference to my blog and the helpful advice on measuring page speed.

I think first byte is really important. The longer that delay, the worse the user experience because nothing is coming back to the browser and it indicates a back-end issue that needs addressing.

It's useful to split out the measures of speed as you've done to help people prioritise. Get the technical performance sorted so browsers can start rendering your content quickly, then move on to fine tuning page content to reduce the full doc load time, then look at solutions like CDNs to help you manage multiple resources and go even further.

Are there any paid tools out there that you have used and rate highly to support ecommerce teams with this challenge?


almost 5 years ago



The performance of Amazon of course is improved via the use of a CDN that enables content to appear to be delivered in a more timely fashion to users in dispersed geographic locations.

For some (particularly smaller) companies, outside of making all the obvious on-site changes, the use of a CDN might be prohibitive cost-wise.

Good read Greg, thanks.

almost 5 years ago


Tim Leighton-Boyce, Analyst at CxFocus

Greg, this is really useful, thank you.

I wonder if you know how the metrics which you suggest above correlate with those in the 'technical' and 'DOM' tabs of the Google Analytics page speed reports.

I'm guessing that 'first byte' would be close to GA's 'server response time' and 'load time' would be... 'load time'.

But I wonder about 'render start.' What do you reckon? GA has 'document interactive' (which is my experience is closer to the figure reported as 'load time' by GtMetrix -- another handy monitoring tool which even records videos of slow loads to scare you) but that suggests something further down the process than the start of the render.

The reason for my question is that your post is wisely encouraging people to use the performance of the ecommerce stars as targets, but GA is no good for that, since you only have your own data, albeit lots of it and from real visitors not test systems. It would be nice to be able to compare the big/real data sample from GA with benchmarks established using tools like webpagetest.

almost 5 years ago


Jo Harrison, PR & Marketing Manager at 1st Central

I agree with Gav on this one.

It would be good to have suggestions on how to get a 'CDN like performance', for smaller companies which cannot afford the outlay.

James Gurd is also very much on the right point with first byte. For most users, Render Start is the perceived performance of a page - even if the total download time is far longer.

almost 5 years ago


Greg Randall


You definitely have a greater appreciation for the technical than I do, and is why I referenced your article. You make great points, and provide a clear view on all the requirements of the web dev team in getting the build right. Unfortunately, the "shortcuts" of web dev teams continue to occur and become a common factor in slowing down page load speeds. I work very hard to surround myself with people like you when I am in the midst of large eCommerce build projects.

The only other tool I have used in the past is found at: http://tools.pingdom.com/fpt/. The reason I like Webpagetest.org is for its breadth and depth of reporting for all the elements I refer to in this article. It is more thorough.


Great question, I get this one often. I have the good fortune to work with a highly regarded GA specialist (Ken, thanks for all your help) who confirms the speed reporting in GA is a great indicator, but don't rely on the numbers to be exact. Having said that, when I have compared reporting from Webpagetest.org to GA the high level numbers are very close.

GA does a great job in highlighting issues and allows you to report on page load times during times the site is under stress, however, to solve the problem you need to go elsewhere to get the data required to fix the problem.

Yes, first byte and server response is the same.

The assumption is the document interactive time and render start is also the same, however, GA defines document interactive time as "the average time (in seconds) the browser takes to parse the document". Where it becomes not clear for me is the use of the term "parse" which refers to the ability for the browser to "interpret" the data to display the content. This is why I don't rely on this data and revert to render start reporting.


I agree the CDN option is difficult for smaller businesses however, I am confident business cases can be made for those who wish to reach international markets. The only other thing to look at is dedicated server options. Many times slow performance is attributed to the sharing of a server environment. The traffic spikes of other businesses can/will slow your site down. Unfortunately, I have seen this many times. The ability to optimize server configuration is now a science and is very suitable for those who find the CDN option cost prohibitive.

almost 5 years ago

Osvaldo Spadano

Osvaldo Spadano, Founder and CEO at Akoova

CDN is very easy and affordable nowadays. Obviously if you ask Akamai you ask for trouble!

CloudFlare - Free Plan available: www.cloudflare.com

Amazon AWS CloudFront - Pay as you Go: http://aws.amazon.com/cloudfront/

GoGrid CDN (powered by EdgeCast, Fast!) - Pay as you Go: www.gogrid.com/products/infrastructure-cdn

Yotta - Affordable CDN, Optimizer & Firewall: www.yottaa.com/pricing/

Really there is no excuse. CloudFlare is free. With a Pay as you Go plan a small site will pay well below £50/mo. The only reason why many online retailers and even e-commerce agencies don't you CDN is because they do not know where to start from.

almost 5 years ago



Cloudflare's is lacking when it comes to TTFB.

At one time they even posted a blog which claimed that TTFB "meangless" and were reprimanded by Google's Ilya Grigorick who had some really strong notions about their approach to acceleration and TTFB metric.

Free <> Best

almost 5 years ago

Osvaldo Spadano

Osvaldo Spadano, Founder and CEO at Akoova

Absolutely, TTFB is very important, so much so I am on a mission to get online retailers on a TTFB sub 20ms rather than 1s. However, TTFB is not strictly related to CDN; it is down to platform & infrastructure. There is obviously a TTFB for each static/image component as well, which depends on the CDN provider. I did some thorough performance testing a while ago and EdgeCast was top performer for small objects, well above the like of Akamai. The good news is that GoGrid (no affiliation) provides EdgeCast service on a Pay as you Go model and it is very cheap! Going back to the main point, it is possible to get the best CDN for a small amount of money, no upfront cost, no minimum commitment of contract length!

almost 5 years ago



Sounds interesting.

After reading the Moz post, I`m just now starting to dig into this.
From Ilya's post it seems that, from SEO point of view, the actual TTFB time is not as important as the type of response.

Anyway, I`m now looking into Incapsula.
It looks like a solid alternative to Cloudflare. They have a very similar free option and an impressive performance ->

How much Is Akmai and EdgeCast?

almost 5 years ago

Osvaldo Spadano

Osvaldo Spadano, Founder and CEO at Akoova

First time I heard of Incapsula, thanks!

With Akamai you will end-up spending £2K per month and with a minimum contract of 1y to 2y. Way too expensive!

EdgeCast is also fairly expensive if you go directly to them. However, if you go through www.gogrid.com/products/infrastructure-cdn you have no minimum commitment and it is cheap. For instance a site with 10K unique visitors a day will cost less than £100 per month, possibly £50.

almost 5 years ago


William V

Great overview on the different metric!

Working for a CDN (CDNetworks), I can say that load time is extremely important for both the business and end user. Slow load times not only affect SEO rankings and time spent on the site, but negatively impacts conversions and transactions success. This is especially true for ecommerce sites... lagging transactions is equal to long and slow moving checkout lines at a physical store. The truth is no one likes to wait, especially on the internet... it is so easy just to close the window and do go to a different site.

CDNs can be a bit pricey, but if you business is losing 2-8% revenue for every second your site lags, it may be something to consider.


almost 5 years ago

Osvaldo Spadano

Osvaldo Spadano, Founder and CEO at Akoova

CDN can be pricey if clients talk to the wrong suppliers. As explained, a few millions revenue online retailer (e.g. 10K unique visitors per day), can have a top-notch CDN provider, no compromise, for less than $100/mo. Is that pricey? Not from my point of view! Obviously I am referring to basic services such as serving static images/JS/CSS files (aka small objects). Streaming etc.. is a different story.

almost 5 years ago


Ben Daniel

I was under the impression that Google used the OnLoad metric as their measurement of a pages performance - Tammy Everts has written a piece referencing how the Google toolbar uses this to crowd source and record 'the internets' performance (http://blog.radware.com/applicationdelivery/applicationaccelerationoptimization/2013/07/18-questions-google-site-speed-seo/), but Both Steve Souders (http://www.stevesouders.com/blog/2013/05/13/moving-beyond-window-onload/) and Pat Meenan (http://blog.patrickmeenan.com/2013/07/measuring-performance-of-user-experience.html) have both put forward good cases as to why this probably isn't relevant from here onwards.

I would also query your statement of "first byte and server response are the same". In my experience, they're not. First byte is typically used to encapsulate everything from DNS resolution time, TCP handshake time, SSL negotiation time (where necessary), AND server response time, so be aware that a high TTFB measurement might actually be because of a slow network, poor SSL negotiation etc.

almost 5 years ago



Here's a good list of speed tools

almost 5 years ago

Greg Randall

Greg Randall, Director at Econsultancy Guest Access TRAININGSmall Business Multi-user

Max, thanks, this is a brilliant list! I particularly like the Media 4x message on their home page....classic.

almost 5 years ago


Simonne Vickers, Online PR Executive at Summit

Site speed can be affected by the following factors:

Front-end design/build

-Multimedia such as Flash or video
-Images that are not optimised i.e. reduced in size for the web
-Dynamic scripts that are server-intensive
-Web pages that aren’t -compressed so the file size is big and cumbersome to download
-Bulky code – this can occur when diferent developers have worked on a site or various new features have been added over time
-3rd party scripts and APIs

-A shopper’s proximity to your hosting infrastructure can impact on response times.
-Shared web servers where another eCommerce website’s traffic can impact server capacity

The online marketing company Summit highlight the real cost of a slow eCommerce site. Se below in the report:


over 4 years ago

George Klarkson

George Klarkson, Sys admin at It

Agree with guys about CDN. I've also speed up my website working http://cdnsun.com/
today it perhaps the easiest and most effective way to speed up web sites and a lot of administrators use it.

about 3 years ago

Save or Cancel

Enjoying this article?

Get more just like this, delivered to your inbox.

Keep up to date with the latest analysis, inspiration and learning from the Econsultancy blog with our free Digital Pulse newsletter. You will receive a hand-picked digest of the latest and greatest articles, as well as snippets of new market data, best practice guides and trends research.