The Biggest Misconception about Google Page Speed

in my conversations with customers and prospects we often talk about one of the biggest it problems: “how can we make the website faster for end users”.

obviously web performance optimization (wpo) techniques are key to faster webpage and google page speed score is a key tool on measuring how well they are applied. however, quite often i hear comments about the score that make no sense like “we have spent a lot of $, time and efforts to get amazing google page speed scores but our site is still slow. what did we miss?” or “competitor x has a score 50, we have 85, yet they load twice as fast!”

these concepts clearly show a misconception of what google page speed score does. certain people fall prey to the idea that pages with high page speed scores should be faster than pages with low scores. there are probably various causes to this misconception, from the name – to how certain individuals or companies sell products or services. our goal with this post is to clarify why this belief is false, and why you should not rely on it.

google page speed is a score calculated based on web optimization rules that would improve the rendering and execution of the front end code (html, css, etc) on browsers.  per google’s definition: “these rules are general front-end best practices you can apply at any stage of web development”. in other words, the score does not look at your infrastructure, application performance, db queries, datacenter distribution, load handling, content loaded on the browser, etc. most importantly it does not include the actual speed of the page and therefore cannot be used a yard stick about who is faster – page a or page b.

to illustrate the point that there is no correlation between page speed score and how fast a page loads let’s take a look at the performance data we collected over black friday and cyber monday 2011 for the top internet retailers . we measured several speed metrics and the google page speed score utilizing catchpoint synthetic agents in major us cities . we will focus on two key metrics – which are most commonly used and that are the best gauges of webpage speed.

document complete time & google page speed score

as you can clearly see from the chart there is no relationship on the document complete and google page speed score. the fastest site, j.c. penny and the slowest site, target, had an identical score of 84.

web page response time (fully loaded) & google page speed score

even when looking at the fully loaded page, we still see that there is no correlation with google page speed.

google page speed score should be treated as a grade of how good of a job your front end developers (or optimization solution) has done in making a page that renders as quickly as it can given the content it needs to display. when you compare it with your competing sites, use it to compare how good of a job they have done -do not use it as measuring stick for speed. to measure speed use metrics like response, document complete, fully loaded, etc. the same reasoning holds true for the yslow score from yahoo .

so great we clarified the page speed misconception, your front end team does an awesome job and gets the score in the 90s for the entire site – but somehow the site is still under-performing competition in speed. well take a look at the rest of your system, analyze the data, review it carefully and i am sure there is plenty you can do to make it faster:

• trim down bytes. you could have a well optimized page, but if you are loading 2mb+ of data – it will be slow for the average joe. do you really need that rather large swf file? should every visual effect be an image?
• analyze application performance. take a look at every page and process. are there particular queries taking too long? is the mid-tier/backend code that needs optimization? can you achieve better caching rather than reading from disk for every pageview? are certain processes impacting performance?
• analyze how application does under user load. on a developers machine might be fast, but get 100 users on it – and maybe there are problems related to code, hardware, etc.
• analyze your infrastructure. take a look at routers, switches, load balancers, various machines, are they over utilized? are they misconfigured?
• evaluate your datacenter location and isps. are your users mainly on west coast, but serving all content from east coast? maybe you need a new datacenter, or move it to midwest so it has better coverage of us.
• evaluate your third party vendors. if you are relying on cdns, adserving, etc – ensure they are not impacting your speed.

in conclusion, the speed of your page is not dependent only on front end code or page speed score – it is dependent on your entire system and infrastructure. the engineering and operations team must talk and work with each other and get a better understanding of what is impacting speed.

everyone in an organization is responsible for a fast web site / application.

mehdi – catchpoint