Google’s PageSpeed Insights is an easy-to-use tool that tests whether a web page might be slower than it needs to be. It gives a score to quantify page performance. Because this score is concrete, the PageSpeed Insights score is often used as a measure of site performance. Similarly to PageRank years back, folks want to optimize this number just because it exists. In fact, Moz has a popular article on this subject: How to Achieve 100/100 with the Google Page Speed Test Tool.
For small sites on common CMSes (think Wordpress), this can be accomplished. If that’s you, PageSpeed Insights is a great place to start. For most sites, a perfect score isn’t realistic. So where do we start?
That’s what this post is about. I want to make three points:
- Latency can hurt load times more than bandwidth
- PageSpeed Insights scores shouldn’t be taken at face value
- Improvement starts with measurement, goal setting, and prioritization
I’m writing with SEO practitioners in mind. I’ll skip over some of the more technical bits. You should walk away with enough perspective to start asking the right questions. And you may make better recommendations as a result.
|
Disclaimer: HTTP2 improves some of the issues discussed in this post. Specifically, multiple requests to the same server are less problematic. It is not a panacea. |
Latency can hurt load times more than bandwidth
A first look at PageSpeed Insights’ rules could make you think it’s all about serving fewer bytes to the user. Minify, optimize, compress. Size is only half the story. It also takes take time for your request simply to reach a server. And then it takes time for the server to respond to you!
What happens when you make a request?
If a user types a URL into a browser address bar and hits enter, a request is made. Lots of things happen when that request is made. The very last part of that is transferring the requested content. It’s only this last bit that is affected by bandwidth and the size of the content.
Fulfilling a request requires (more or less) these steps:
- Find the server
- Connect to the server
- Wait for a response
- Receive response
Each of these steps takes time, not just the last. The first three are independent of file size; they are effectively constant costs. These costs are incurred with each request regardless of whether the payload is a tiny, minified CSS file or a huge uncompressed image.
Why does it take time to get a response?
The factor we can’t avoid is that network signals can’t travel faster than the speed of light. That’s a theoretical maximum; in reality, it will take longer than that for data to transfer. For instance, it takes light about 40ms for a round trip between Paris and New York. If it takes twice that time for data to actually cross the Atlantic, then the minimum time it will take to get a response from a server is 80ms.
This is why CDNs are commonly used. CDNs put servers physically closer to users, which is the only way to reduce the time it takes to reach the server.
How much does this matter?
Check out this chart (from Chrome’s DevTools):
The life of a request, measured by Chrome Dev Tools.
All of the values in the red box are what I’m considering “latency.” They total about 220ms. The actual transfer of content took 0.7ms. No compression or reduction of filesize could help this; the only way to reduce the time taken by the request is to reduce latency.
Don’t we need to make a lot of requests to load a page?
It’ll take more than one request to load all of the content necessary to render a page. If that URL corresponded to a webpage, the browser will usually discover that it needs to load more resources to render the page. These could be CSS, JavaScript, or font files. It must recursively go through the same steps listed above to load each of these files.
Fortunately, once a server has been found (“DNS Lookup” in the image above), the browser won’t need to look it up again. It will still have to connect, and we’ll have to wait for a response.
A skeptical read of PageSpeed Insights tests
All of the PageSpeed Insights evaluations cover things that can impact site speed. For large sites, some of them aren’t so easy to implement. And depending on how your site is designed, some may be more impactful than others. That’s not to say you have an excuse not to do these things — they’re all best-practice, and they all help. But they don’t represent the whole site speed picture.
With that in mind, here’s a “skeptical reading” of each of the PageSpeed Insights rules.
Tests focusing on reducing bandwidth use
|
Rule |
Skeptical reading |
|---|---|
|
Optimize images |
Unless you have huge images, this might not be a big deal. This is only measuring whether images could be further compressed — not whether you’re loading too many. |
|
Enable compression |
Compression is easy. You should use it. It also may not make much of a difference unless you have (for instance) huge JavaScript files loading. |
|
Minify HTML |
Will likely reduce overhead only by tens of KB. Latency will have a bigger impact than response size. |
|
Minify CSS |
Will likely reduce overhead only by tens of KB. Latency will have a bigger impact than response size. |
|
Minify JS |
Probably not as important as consolidating JS into a single file to reduce the number of requests that have to be made. |
Tests focusing on reducing latency
Rule | Skeptical reading |
|---|---|
Leverage browser caching | Definitely let’s cache our own files. Lots of the files that could benefit from caching are probably hosted on 3rd-party servers. You’d have to host them yourself to change cache times. |
Reduce server response time | Threshold on PSI is too high. It also tries to exclude the physical latency of the server—instead looking only at how long it takes the server to respond once it receives a request. |
Avoid landing page redirects | Yes. |
Eliminate render-blocking JavaScript and CSS in above-the-fold content | A valid concern, but can be frustratingly difficult. Having zero requests on top of the initial page load to render above-the-fold content isn’t necessary to meet most performance goals. |
Prioritize visible content | Actually kind of important. |
Don’t treat these as the final word on site performance! Independent of these tests, here are some things to think about. Some aren’t covered at all by PageSpeed Insights, and some are only covered halfway:
- Caching content you control.
- Reducing the amount of content you’re loading from 3rd-party domains.
- Reducing server response time beyond the minimum required to pass PageSpeed Insights’ test.
- Moving the server closer to the end user. Basically, use a CDN.
- Reducing blocking requests. Ensuring you’re using HTTP2 will help here.
How to start improving
Measurement
The screenshots in this post are created with Chrome DevTools. It’s built into the browser and allows you to inspect exactly what happens when a page loads.
Instead of trusting the Pagespeed Insights tool, go ahead and load your page in Chrome. Check out how it performs. Look at what requests actually seem to take more time. Often the answer will be obvious: too much time will be spent loading ads, for instance.
Goal setting
If a perfect PageSpeed Insights score isn’t your goal, you need to know what your goal will be. This is important, because it allows you to compare current performance to that goal. You can see whether reducing bandwidth requirements will actually meet your goal, or whether you also need to do something to reduce latency (use a CDN, handle fewer requests, load high-priority content first).
Prioritizing
Prioritizing page speed “fixes” is important — that’s not the only type of prioritization. There’s also the question of what actually needs to be loaded. PageSpeed Insights does try to figure out whether you’re prioritizing above-the-fold content. This is a great target. It’s also not a perfect assessment; it might be easier to split content into “critical” and “non-critical” paths, regardless of what is ostensibly above the fold.
For instance: If your site relies on ad revenue, you might load all content on the page and only then begin to load ads. Figuring out how to serve less is a challenge best tackled by you and your team. After all, PageSpeed Insights is a one-size-fits-all solution.
Conclusion
The story so far has been that PageSpeed Insights can be useful, but there are smarter ways to assess and improve site speed. A perfect score doesn’t guarantee a fast site.
If you’re interested in learning more, I highly recommend checking out Ilya Grigorik’s site and specifically this old-but-good introduction deck. Grigorik is a web performance engineer at Google and a very good communicator about site speed issues.
Great insight here Benjamin, we usually ned up cross-referencing Google PageSpeed Insights with a free Website Speed Test from Pingdom, which gives you the exact seconds it took to load your page from a chosen location. To emphasize Cory's question, do you have any recommendations with setting up and/or properly using a CDN?
It may seem like ages ago and while some things are easier than before, my Moz article from 2011 gives you a taste of CDN setup and usage.
This is brilliant loved the blog post. There was one minor spelling mistake "It also takes take time for your request simply to reach a server" but apart from that i loved it. Very informative and i have learnt off it.
How do you go about moving the server closer to the user with a CDN? Also using HTTP2 why would this be better? What makes it better than the current one we normally use? Could you please answer these for me?
I use that Google Chrome tool as well and it is really good, thank you again for this blog post.
Cory,
HTTP2 speeds up the overall website loading time. What it does? It allows to download all requests (images, css, js and other static files) almost everything at the same moment. HTTP v.1 allows to serve 1 request at the same time. HTTP2 technology allows the browser to connect with a web server and serve all requests in paralel
This is a great post and something that has been needed in terms of basic information. For me consolidating the JS files, HTTPS, and enabling compression has really helped out. I did notice that there are many tools out there to help as well such as CDN's, but also plugin's if you are using wordpress to compress both images and minifying CSS and JS.
Thanks for this needed contribution.
I'm not sure if HTTP2 will actually help with render blocking requests, you should see improvements across the board because of multiplexing but the render blocking JS still needs to download - right? (not entirely sure). Methods that have worked for me: add the JS inline (if it's small enough) or make it async. Some scripts just don't play nice when they're async though, like Optimizely - I've tested it a bunch of times and it's not fast enough to avoid to an initial screen flick.
It makes the downloading of render blocking JS faster but it doesn't solve the issue itself.
It's a very nice post.
I still wonder why GG Pagespeed doesn't recognize my CDN (from OVH host) and keeps saying things like "enable cache for" ........ external resources provided by Google himself (fonts, ads,...) !
Thank you for this information. For non technical seos or marketers, would you recommend to get a technical person to check some of these points or is it worth it learn about it?
I regularly use PageSpeed Insights for SEO audits. The similar data is also available i.e. in Screaming Frog (image optimization, redirects), GA (speed) and others. But PSI is useful in having everything at one place.
I don’t know why Google don’t give more value for those who have done speed optimization and technical optimization and have to give extra +points for those who do w3validation.
I optimized my site, achieving 90 in Page Insights, however, I declined in Google positions since I made the changes. What could have happened?
It could be any number of thing Zid, is the optimisation the only change you did? It could be organic competition, or something that you did in your optimisation that blocked some crucial javascript or css that is required to make your site render for spiders.
Really interesting. Sometimes we get stuck in trying to speed-up a website. The problem is that sometimes that kind of insights shows errors that can be misleading but it's a good way to improve a site.
i think score over 90 is enought
Great insights, truly a worth reading post. Thanks for sharing Benjamin keep posting some interesting stuff like this cheers..
Thanks for a detailed explanation! I'm quite ignorant in blogging. Actually, started a blog, but everything connected with its optimization is still a mystery to me. Hope I'll learn something here.
Best,
Samantha
Very good explanation Benjamin! You've clarified a few things about pagespeed, I'm a bit stuck on how to improve some things. Can anyone help me with pagespeed? For more than I try not give with the key to improve the speed of my website.
I think Google's PageSpeed insight is misleading. My Site is showing the following scores on Page Speed Insights:
While I test my site on GTmetrix , I get the following scores:
And, finally when I test my site on Alexa it says the following:
Well, the above mentioned results are not the only reason why am I saying the Google Page Speed Insights are misleading. I have another observation.
Some of the top sites have very poor scores on PageSpeed Insights. However, that doesn't adversely affect their ranking or user experience.
My suggestion is that one shouldn't take Google's PageSpeed Insights too seriously. Instead, one should concentrate on user experience. After all that's the main motive.
I think you're probable right, with my web site I have similar results.
Interesting post!
I'm looking for a template for pagespeed audits, do you guys have any suggestions?
Its good to know that google also calculates load time on a global average you need to set up cloud server architecture to handel this - At mindmyhost we normally use 2 or 3 servers architecture that costs less than 100 dollars a month for clients serious about SEO. we place these on different ends of the world to get a very good competitive advantage for global averages which will boost SEO massively.
[link removed]
Nice post. Having a good CDN provider is essential for latency and we have seen significant improvements when implementing such a solution.
What would be important as well for latency is making sure you are not hosting your site on a shared scheme. Basically, your website is served alongside many, many, many others. If latency is important for you, don't do shared hosting. Even a VPS is slow. If your project really needs speed (all do, but who has the budget?), go for a dedicated server located near your main client zone + CDN.
It’s truly a good read.
Speed test can make or break your website. They are a necessity to improve. I think the maximum time for a website to upload should be less than 1.8 seconds. Anything above this mark and the users might throw a brick at their screen. Bandwidth is not something you can control or change. Latency, however, comes under your umbrella. You are right about prioritizing though. The goal settings change frivolously according to the website’s content and size.
Thanks for sharing.
It is not our experience that page speed has anything to do with Google optimisation. We tested 200 code and video heavy sites, unoptimised for compression and 200 light compressed sites and there was little difference.
Might I suggest more research?
[link removed by editor]
Hi Benjamin, this is invaluable thank you.
Until recently we have built all our sites in a proprietary CMS but are considering only building sites in Wordpress going forward to help with speed issues.
Does that sound like a good move ?
thanks for the post. I got an Answer here. Since i am not posting any thing on my blog for months but when ever i test the page speed, it shows different results each time. I was always wondering why i am having different results although there is no change in my jss, css files. Many thanks again for the lighting up the speed issues.
Great read on the article.
The one takeaway I got (which I have been feeling since the start) is that pagespeed insights is far from your one stop shop for getting your website's speed to where it needs to be. Too many times I have run across a great pagespeed score, but the website load time is still slow when I go to the website.
My problem with it is that I want to be able to recommend the best route for clients to increase their website speed. We all know that this issue is very important for rankings. When I look at pagespeed insights I see a tool that is (most of the time) looking at small issues within a website when if they changed their hosting server they would make a huge impact.
This leads me to my question, what would be your top 3 major changes you would make (outside of pagespeed insights recommendations) to speed up a website (i.e CDN provider, change hosts, reduce page bloat).
This article is simple to see without departing out any specifics and enjoy. Excellent work! You finished particular factors that were trusted there try this web-site . I discovered almost all individuals may accept your site and did a research about them.