How to Score 100/100 in Google PageSpeed Insights with WordPress
Updated on May 28, 2018
Here at Kinsta we work with a lot of agencies and freelancers that deal with clients on a daily basis. It is not uncommon for clients or even a CEO of a company to ask their agency or WordPress developer to increase their Google PageSpeed Insights score. Google does a good job at marketing this tool to consumers, and many times, they don’t always understand that a perfect score isn’t the end of the world. This can definitely be frustrating at times. However, today we want to share with you some tips and strategies that can help you score a 100/100 in Google PageSpeed Insights with your WordPress site.
How Important is Google PageSpeed Insights?
Google PageSpeed Insights is a web performance tool created by Google to help you easily identify ways to make your site faster and more mobile-friendly, by following recommendations on best web practices. A very important thing to remember though is that you shouldn’t always obsess over scoring 100/100. This might not even be possible in all scenarios, depending upon how your WordPress site is setup. With a lot of multipurpose themes and sites with dozens of external scripts, you simply will have an almost impossible time trying to achieve a perfect score. Which is perfectly OK.
We recommend looking at the speed of your site, more than the scores. Scores with tools like Pingdom, GTMetrix, and Google PageSpeed Insights can sometimes lead you astray. Especially since some of them don’t even support HTTP/2 yet. What really matters is ensuring your site loads fast and that the perceived performance is also up to par. Perceived performance is how fast your website feels like it loads to users.
Does Google use PageSpeed Insights when it comes to SEO and the page speed ranking factor or pure response speed? This was an interesting question brought up by an SEO over at FDP Group Leeds and discussed on Search Engine Roundtable. Gary Illyes, Webmaster Trends Analyst for Google, responded with saying “I’ll go with both.”
This is partially due to the fact that in most cases when you have a slow website, you are most likely going to have a lot of warnings in Google PageSpeed Insights. A lot of the recommendations go hand in hand with how they relate to your pure response times. They don’t always correlate 100%, but what Gary is most likely saying is that if you have a slow website, yes, it probably will affect your rankings.
Scoring 100/100 on Both Shared Hosting and Kinsta
We thought it would be fun to explore the new Twenty Seventeen theme in WordPress 4.7. This is the first default WordPress theme that is aimed at businesses instead a typical blog, which is exciting! So today we are going to show you how to score that perfect 100/100 on both Desktop and Mobile. We have installed common tools and services that many WordPress sites use, such as Google Analytics, Akismet, Yoast SEO, etc. We ran tests on both a low-budget shared host and on Kinsta to show you just how much difference there can be when it comes to fine-tuned Google Cloud hosting vs a shared hosting environment.
While this is a small site, it is a good foundation to at least understand a little bit about how Google PageSpeed Insights works. If you are interested in seeing some optimizations on a larger multipurpose theme, check out our post on optimizing the Total WordPress theme.
100/100 in Google PageSpeed Insights with Shared Host
Our first test site, we have WordPress 4.7 with the Twenty Seventeen Theme running on a popular low-budget shared host (Apache). SSL is configured and the following plugins are installed.
We also have Google Analytics running within the <body> of our header.php file. The only modification we have made is we added a featured image to the default dummy “Hello world!” blog post. We run our test site through Google PageSpeed Insights and out of the box, we get a 69/100 desktop score and a 58/100 mobile score. So we definitely have some improvements that should be made here. Let’s dig through each one of these to see how we can fix them.
Shared hosting score on Google PageSpeed Insights
We will start with desktop first as many of the fixes will also apply for mobile. The very first Google PageSpeed Insights recommendation that we need to fix is the Enable Compression warning.
Enable compression warning
According to Google, to fix this we need to enable Gzip compression. Unfortunately, the shared host doesn’t have this automatically enabled already on their servers, so we have to do it manually.
All modern browsers support and automatically negotiate Gzip compression for all HTTP requests. Enabling Gzipcompression can reduce the size of the transferred response by up to 90%, which can significantly reduce the amount of time to download the resource, reduce data usage for the client, and improve the time to first render of your pages.
There are a couple ways you can go about doing this. The first and one of the easiest is by using a caching plugin that supports enabling Gzip. WP Rocket for example adds Gzip compression rules in your .htaccess file automatically using the mod_deflate module. W3 Total Cache also has a way to enable this for you under it’s performance section.
The second way to enable Gzip compression is by editing your .htaccess file. Most shared hosts use Apache, in which you can simply add the code below to your .htaccess file. You can find your .htaccess file at the root of your WordPress site via FTP.
A tool like Check Gzip Compression can actually show you how my bytes were saved by enabling Gzip compression. Here is an example below of what we saved on our test site.
GZIP compression savings
If we run our site through Google PageSpeed Insights again we can see that the Gzip compression warning is now gone and it has raised our desktop score from 69/100 to 80/100 and our mobile score from 58/100 to 67/100.
PageSpeed Insights after GZIP compression
The next Google PageSpeed Insights recommendation that we need to fix is the Optimize images warning. Our default “Hello world!” blog post has a featured image which is throwing up this error.
Optimize images warning
This is a very important and useful warning. According to HTTP Archive, as of November 2016, images made up for on average 65% of a webpages total weight. Optimizing your images can be one of the easiest ways to see performance improvements with your WordPress website.
There are a couple ways you can fix this. The first is to use an image optimization plugin. A plugin can actually go through and bulk optimize your entire WordPress media library and also automatically optimize them when you upload them. We actually have an entire guide on how to optimize your WordPress images. Below are a few popular image optimization plugins:
Those plugins will fix the issue, or you can also compress them before you upload them in a tool like Adobe Photoshop, Gimp, or Affinity Photo. Below is the featured image that is throwing up that warning. We can compress it before-hand by both scaling it down and lowering the quality. It is best to keep your images as small as possible. This image was originally 2.32 MB, after down-scaling and compression, it is now 99.38 kB. Remember, it is best to upload images at scale and not rely on CSS to resize them. This slows down your site.
Compress images with Affinity Photo
If we run our site through Google PageSpeed Insights again we can see that the Optimize images warning is now gone and it has raised our desktop score from 80/100 to 88/100 and our mobile score from 67/100 to 73/100. We are making progress!
PageSpeed Insights after image compression
<script src="file1.js" async></script>
<script src="file1.js" defer></script>
If you don’t want to use a plugin for this there are a few other alternatives. Such as adding the following code to your functions.php file.
/*function to add async to all scripts*/
# Add async to all remaining scripts
return str_replace( ' src', ' async="async" src', $tag );
add_filter( 'script_loader_tag', 'js_async_attr', 10 );
Here are two additional posts that discussing adding async or defer without a plugin:
Optimize CSS delivery warning
You can see that the first CSS we need to optimize is our Google fonts (fonts.googleapis.com). CSS is by default render-blocking, which includes CSS coming from web fonts. To fix this we are going to install the free Disable Google Fonts plugin. The plugin author, Milan Dinić, just recently updated this to include the new Twenty Seventeen Libre Franklin font. After installing the plugin, your Google Fonts will obviously break. So you will want to head over to Google Fonts and grab the embed code manually. We select the same font weights that are by default included in the Twenty Seventeen theme.
Then you will need to add that to your footer.php file, right before the </body> tag. Note: Doing it this way will result in FOUT, which is what they refer to as flash of un-styled text. But it will also get rid of the render-blocking issue. You should decide on your own site if FOUT is an acceptable user experience for your visitors. You can also use Google’s Web Font Loader.
Google font in WordPress footer
We run our test site through Google PageSpeed Insights again and now under the Optimize CSS Delivery warning we are only left with one thing, and that is the style.css file.
After installing the plugin, click into the settings and select “Optimize CSS Code.” Then click the advanced tab and also enable “Aggregate inline CSS” and “Inline All CSS.” Note, depending on what theme you are doing this on, it might not be recommended to use this method. For large sites, inlining can be bad, in which case it would be actually better to simply ignore that particular Google PageSpeed Insights warning. And remember that with HTTP/2, concatenation can sometimes actually slow your site down.
Optimize CSS code
We also recommend enabling the optimize HTML code option.
Optimize HTML code
PageSpeed Insights after JS and CSS optimization
Leverage Browser Caching
The next Google PageSpeed Insights recommendation that we need to fix is the Leverage browser caching warning. We actually have an entire in-depth post on the leverage browser caching issue, as it pertains to WordPress.
Leverage browser caching warning
The most common reason the leverage browser caching warning is triggered is that your web server doesn’t have the appropriate headers in place. In the screenshot above you can see that all of our internal scripts have an expiration is not specified warning. When it comes to caching there are two primary methods which are used, Cache-Control headers and Expires headers. While the Cache-Control header turns on client-side caching and sets the max-age of a resource, the Expires header is used to specify a specific point in time the resource is no longer valid.
You don’t necessarily need to add both of the headers, as this is a little redundant. Cache-Control is newer and usually the recommended method, however, some web performance tools like GTmetrix still check for Expires headers. These are all examples, you can change file types, expire times, etc. based on your needs. Here are some options below. We are going to simply add expire headers in Apache on our shared host for this tutorial.
Adding Cache-Control Header in Nginx
You can add Cache-Control headers in Nginx by adding the following to your server config’s server location or block.
Remember we enabled Gzip compression earlier? Below is what our .htaccess file below now looks like after also adding the expires headers. We simply place it below the compression block.
Expire headers code
We run our test site through Google PageSpeed Insights again and now under the Leverage browser caching warning we are only left with one thing, and that is our Google Analytic’s script. This is kind of ironic seeing as this is Google’s own script. The issue is that they set a low 2 hour cache time on their asset, as seen in the screenshot below. They most likely do this because if for some reason they were to modify something on there end they want all users to get the changes as fast as possible. However there is a way to get around this, and that is by hosting Google Analytics script locally. Please be aware though that this is not supported by Google.
Leverage browser caching with Google Analytics
There is a great free little plugin called Complete Analytics Optimization Suite, created and developed by Daan van den Bergh, which allows you to host Google Analytics locally on your WordPress website.
CAOS WordPress plugin
Just install the plugin, enter your Google Analytics Tracking ID, and the plugin adds the necessary tracking code for Google Analytics to your WordPress website, downloads and saves the analytics.js file to your server and keeps it updated using a scheduled script in wp_cron(). We recommend also setting it to load in the footer. Note: This plugin won’t work with other Google Analytics WordPress plugins.
Local Google Analytics
If we run our site through Google PageSpeed Insights again we can see that the Leverage browser caching warning is now completely gone! And we have raised our desktop score from 92/100 to 97/100 and our mobile score from 89/100 to 96/100. So close we can almost taste it.
PageSpeed Insights after fixing leverage browser caching
Reduce server response time
The next Google PageSpeed Insights recommendation that we need to fix is the Reduce server response time warning. A lot of times this happens when someone is on a slow budget shared hosting plan. The server is not fast and Google knows it. So to fix this we need to implement some type of caching to speed things up. There are a lot of great caching plugins out there. In our example, we are going to be using the free Cache Enabler plugin from the team over at KeyCDN.
Cache Enabler WordPress plugin
If we run our site through Google PageSpeed Insights again we can see that the Reduce server response time is now completely gone! And we have raised our desktop score from 97/100 to 99/100 and our mobile score from 96/100 to 99/100. We are about to cross the finish line.
PageSpeed Insights after response time fix
Typically you won’t see the “reduce server response time” recommendation here at Kinsta. But it’s important to note though that there are dozens of potential factors which may slow down the response of your server: including slow database queries from plugins, frameworks, libraries, resource CPU starvation, or memory starvation. We utilize New Relic to help clients better determine where this might be originating from.
And that’s it! We have now successfully taken the WordPress Twenty Seventeen theme from 69/100 to 100/100 on both mobile and desktop on a low-budget shared host.
100/100 Google PageSpeed Insights score
Here are the mobile scores. We didn’t have to do anything additional for mobile. Getting the desktop version to 100/100 automatically raised our mobile version and user experience scores to 100/100 as well.
100/100 Google PageSpeed Insights mobile score
We also have a before and after with speed tests from Pingdom.
Before PageSpeed Insights Optimizations Speed Test
Here is a speed test from Pingdom before any optimizations were done on the shared host.
Speed test before PageSpeed optimizations
After PageSpeed Insights Optimizations Speed Test
Here is a speed test from Pingdom after optimizations were done on the shared host.
Speed test after PageSpeed optimizations
100/100 in Google PageSpeed Insights with Kinsta
Our second test site is configured the exact same way as the 1st. It is simply on a different domain. We have WordPress 4.7 with the Twenty Seventeen Theme running on our Kinsta servers (NGINX). SSL is configured and the following plugins are installed.
We have Google Analytics running within the <body> of our header.php file. The only modification we have made is we added a featured image to the default dummy “Hello world!” blog post. We run our test site through Google PageSpeed Insights and out of the box, we get a 73/100 desktop score and a 63/100 mobile score. It is important to note that compared to the shared host test site above, there are already a lot of warnings that are fixed out of the box, such as:
Enable Compression (Kinsta already has Gzip enabled on all servers, no need to enable)
Reduce server response time (Kinsta is already blazing fast, already well within Google’s acceptable parameters without any optimizations)
Expires Headers (No need to enable because Kinsta has caching headers enabled at the server-level)
PageSpeed Insights with managed WordPress host
On Kinsta you will want to follow just a few of the same recommendations as before:
The point of this tutorial was to better explain and understand what the Google PageSpeed Insights warnings mean and what you can do to fix them. Once you understand these better, you can go about applying some of these strategies to your larger sites. Of course, with big sites you probably won’t ever score that perfect 100/100, which is perfectly OK! Or if you do, it will take some work. We simply recommend implementing what you can and you will most likely see speed improvements. Remember that the speed of your site, along with perceived performance is what really matters. Don’t obsess too much over scores.
It is also important to note the differences above when it comes to shared hosting and Kinsta’s fine-tuned WordPress environment. We are faster out of the box than most shared hosts after optimization. You should ask yourself, how much is your time really worth? If you simply want fast out of the box, Kinsta’s managed hosting environment can do that for you.
The next time a client asks you to improve their scores, you now have some up to date tips on how to do that. And if we missed anything important, just let us know below in the comments. Stay tuned for larger-scale case studies with Google PageSpeed Insights that we will be doing in the future.
Brian is the Chief Marketing Officer at Kinsta. He focuses on everything from developing new online growth strategies, content creation, technical SEO, and outreach within the community. He has a huge passion for WordPress, has been using it for 8+ years, and even develops a couple premium plugins. Brian enjoys blogging, movies, and hiking. Connect with Brian on Twitter.
Kinsta is a premium hosting platform optimized specifically for WordPress, created by WordPress professionals.
A cookie is a piece of information that a website stores on a visitor’s computer. We use this for some functionality on our website to work properly, and also to collect analytics to better understand our visitors and offer them a better experience. You can accept all cookies at once or fine-tune your preferences in the cookie settings.
Thanks, we've saved your settings, you can modify them any time on the cookie settings page
These cookies are needed for our website to function providing payment gateway security and ther essentials. Therefore they are always on but they do not contain personally identifiable information (PII).
If you've set preferences (which cookies you accept and which you don't) we store your preferences here to make sure we don't load anything that you didn't agree to.
WordPress sets a couple of cookies that track logged in users and store user preferences set in their WordPress user profile. These are set for members of the Kinsta website only - members of our staff.
Stripe is our payment provider and they may set some cookies to help them with fraud prevention and other issues. This is required for our payments to work.
This cookie contains information about the affiliate who refered a visitor. The cookie contains no information about the visitor whatsoever.
Analytics help us deliver better content to our audience. We have made sure no personally identifiable information (PII) is sent by anonymizing IPs.
Analytics cookies allow us to gather data to help us better understand our visitors and offer them a better experience.
Set and used by Hotjar. We use Hotjar to analyze user behavior without identifying the user.
Marketing cookies help us target our ads better. We mainly use them to target ads to users who have visited Kinsta.
Set and used by Twitter, used for targeting advertisements and promoting content to users who have visited kinsta.com.
Set and used by AdRoll for remarketing and targeting advertisements to users who have visited kinsta.com.
Set and used by Facebook, used for targeting advertisements and promoting content to users who have visited kinsta.com.
Set and used by Quora, used for targeting advertisements to users who have visited kinsta.com.