Web Development

Attempt At Scoring 100 On Google PageSpeed

With PageSpeed being so important to Google and other search engines they have created a nice tool to judge the speed and optimization of your website by using Google PageSpeed tool.


Google PageSpeed

Before PageSpeed

First I'm going to start off by running PageSpeed on paulund.co.uk. This site isn't exactly resource heavy so I'm expecting quite a high score to start with but there will be things we can do to improve the speed of paulund.co.uk.

The first test running through PageSpeed paulund.co.uk is getting a score of 89/100 on desktop computers, this is a good enough score and I probably wouldn't have to do much work to get this to 100. But when you check the mobile score it's set to 73/100.

On the PageSpeed results page it tells you areas that your site needs to improve on. We can now run a speed test from WebPagetest and see what speeds the pages are loading on so we can try to beat this after making all the improves we need.


Paulund Page Test

As you can see from this image it's currently loading in 1.52 seconds with a repeat view of 1.37 seconds, now that's pretty quick for a website but it could be better.

PageSpeed Best Practices

First we're going to look at some of the best practices Google recommends to speed up your website.

  • Avoid landing page redirects
  • Enable compression
  • Improve server response time
  • Leverage browser caching
  • Minify resources
  • Optimize images
  • Optimize CSS Delivery
  • Prioritize visible content
  • Remove render-blocking JavaScript
  • Use asynchronous scripts

Avoid landing page redirects

You should avoid any unnecessary HTTP redirects when a visitor lands on your page. For example if you navigate to a site on your mobile some websites pick this up and will redirect you to a mobile version of the site http://example.com -> http://m.example.com. Instead of doing this you should make your website responsive so there is no need to redirect the visitor to a new website.

Paulund.co.uk does not do any redirects on HTTP redirects and has a responsive design for when viewing on mobile devices so there is no need to do any further work on this.

Enable compression

All modern browsers support gzip compression on all HTTP requests, when gzip is enabled it can reduce the size of files by 90%. Gzip compression alone should drastically improve the page speeds of your website.

To enable GZIP compression on NGINX all you have to do is open the file /etc/nginx/nginx.conf find the section for HTTP and use the following settings.

# enable gzip compression
gzip on;
gzip_min_length 256;
gzip_buffers 4 32k;
gzip_proxied any;
gzip_vary on;
# end gzip configuration

Improve server response time

It is recommended that server response time is reduced to under 200ms. Server response is the time it takes for your server to render the HTML on the page. There are many factors that can contribute to slow response time such as slow framework logic, database queries, slow routing, CPU usage and memory usage.

The hardest step to improve you server response time is to work out where the bottleneck is, use the data provided by your server hosts to analysis the resources to work out where the problem could lie. When using a framework or CMS always refer to the documentation for the best performance practices.

Leverage browser caching

When the browser loads a page it will have to gather multiple resources over the network to render the page correctly. This will include HTML, CSS, JS, image etc, having to do this on every page load can cause a large amount of transfer data, slowing down not only the client loading time but server response time. Having the ability to locally cache files means the browser is able to reuse previously fetched resources.

Each type of resource should have a defined caching policy for example if the resource can be cached and for how long.

To leverage browser caching in NGINX you need to setup the caching policies like the code below.

# Expire rules for static content

# cache.appcache, your document html and data
location ~* \.(?:manifest|appcache|html?|xml|json)$ {
expires -1;
# access_log logs/static.log; # I don't usually include a static log

# Feed
location ~* \.(?:rss|atom)$ {
expires 1h;
add_header Cache-Control "public";

# Media: images, icons, video, audio, HTC
location ~* \.(?:jpg|jpeg|gif|png|ico|cur|gz|svg|svgz|mp4|ogg|ogv|webm|htc)$ {
expires 1M;
access_log off;
add_header Cache-Control "public";

# CSS and Javascript
location ~* \.(?:css|js)$ {
expires 1y;
access_log off;
add_header Cache-Control "public";

This is a modified version of the expires.conf file as part of the h5bp project on github.

Minify resources

Minifying resources such as HTML, CSS and JS will reduce the size of files that need to be transferred and therefore speeding up the download of these resources from your server.

Minifying will remove things that aren't needed for your page to render correctly such as comments, whitespace, long variables and long function names etc.

Optimize images

Images will most likely be the biggest resource used on the web page, this is why it's very important to make sure they are optimised for the web page. Make sure you have selected the right format to get the smallest size while still keeping the quality of the images. Carefully choose the dimensions used for the image you are wasting resources if the image is too large and the browser has to automatically resize it. You may need to investigate on whether you need images at all and if they can be replaced by CSS.

Optimize CSS Delivery

Before a browser will render the page it must download and process all styles on the page. As a result the browser will not render the page until all external stylesheets are downloaded and processed which may result in a slower first render of the page.

To learn more about render blocking CSS view the Google guidelines.

Render Blocking CSS

The normal way you would include CSS on the page is by using external CSS stylesheets and using the link tag you will include these in the head tag.

        <link rel="stylesheet" href="styling.css">
        <h1 class="page-title">Welcome</div>

Inside styling.css file you can have critical styling for the page such as:

    font-size: 3.6rem;

Google's recommendation is to move all critical CSS to be inline styling on the HTML document, changing the HTML to look like this

            .page-title{ font-size: 3.6rem; }
        <h1 class="page-title">Welcome</div>

Remove render-blocking JavaScript

Similar to how you can speed up the rendering of CSS you can do the same for JavaScript any external files that need to be rendered can be placed directly inside the HTML to reduce the amount of HTTP requests the browser needs to make.

        <script type="text/javascript" src="page-javascript.js"></script>
        <h1 class="page-title">Welcome</div>

This can be replaced with

        <script type="text/javascript">
            /* contents of JavaScript file */
        <h1 class="page-title">Welcome</div>

Any external JavaScript files that aren't critical for the page to be rendered can be called by adding the async flag to the script tag.

<script async src="page-javascript.js">

Load Google Fonts Async

Most websites these days are using the useful Google web font library allowing you to import a huge library of fonts straight to your webpage. When you run your website through Google PageSpeed it will highlight the Google web font script as a render blocking file. Using the WebFontLoader to load the web fonts on the page with async and therefore removing the render-blocking on this file.

<script type="text/javascript">
    WebFontConfig = {
        google: { families: [ 'Roboto' ] }
    (function() {
        var wf = document.createElement('script');
        wf.src = ('https:' == document.location.protocol ? 'https' : 'http') +
        wf.type = 'text/javascript';
        wf.async = 'true';
        var s = document.getElementsByTagName('script')[0];
        s.parentNode.insertBefore(wf, s);
// ]]></script>

Leverage Browser Caching - Google Analytics

The only thing I can't fix on Google PageSpeed is the error for browser caching on Google analytics script.

https://ssl.google-analytics.com/ga.js (2 hours)

Because I download this script from Google itself there isn't much I can change about it. The only possible solution I have is to download the script, store it locally and apply browser caching to it. But then there's the problem of when Google makes a change to analytics my site will not receive the change and I will have to re-download the file. For this reason I've chosen not to do this and keep it as an external JavaScript file.

Results From PageSpeed

After making the above changes to the site what are the scores with Google PageSpeed now.


It's now getting a score of 97/100 with the two main problems being the server response time being at 0.38 and the Google analytics problems described above. With the server response time I need to monitor the resources of the server a bit more to find the bottleneck or I might need to upgrade the server to be able to handle all the requests.

WebPageTest is now saying that paulund.co.uk takes 1.07 seconds to load on first visit and 1.002 seconds on second visit, that's an improvement of 0.45 seconds. The website already loaded quite quickly so I didn't expect the changes made above to make a huge difference but they managed to reduce loading by half a second and almost breaking the 1 second load time barrier.

Seeing these results mean once the problems with the server response times are fixed it will most certainly break the 1 second barrier.


Here's a list of resources you can use to test the speed of your site, these will also give you recommendations on what you can do to improve the speed of your site.



Pingdom Tools


Back to top

Learn how to code with Treehouse

  • Learn projects with access to 1000+ videos
  • Practice live with our Code Challenge Engine
  • Get help in our members-only forums

Start with a 7 day free trial


  1. Adam says:

    Nice attempt, I can't believe Google still haven't sorted out the Analytics script. Its a pain to everyone trying to get that 100.

  2. David says:

    I've been working also on the optimization to achieve the nearest 100, it's true that Google Analytics is now my biggest barrier.

    I've got 98/100 for mobile and Desktop:

    1. Paul says:

      Looks like we're stuck on the same problem, let me know if you find a good solution.

      1. Brian J King says:

        https://wordpress.org/plugins/host-analyticsjs-local/ will help you with the google analytics issues. It downloads a copy of the Google Analytics file locally and serves it from your server, keeping it updated via WP-Cron.

  3. Hi. Maybe someone can mention, because maybe it was just overlooked? Lol. I don't know. But why can't they make a version that just calls to their server like Google Fonts? Then we could get rid of this issue and not have to worry about updates. Our platform could have a unique id in which we call or pass to our Analytics url.

    I'm not familiar with the how's to do this, so maybe I'm saying something that can't or hasn't been able to be done yet?

  4. Ethan says:

    I'm a few days away from putting up my portfolio / blog. I've been testing a few ideas and got 99/100 on desktop. The only issue I have is the same google analytics issue.

    The one thing that really pushed my score up was removing render blocking scripts by writing my own CSS / JS minify script that output the code on the page.

    Using curl to get the file contents of multiple files, combine & minify them and store the result in a 24 hour transient. After that I just echo out the transient CSS into wp_head and JS in wp_footer.

    That took out almost all my HTTP requests. I'll be writing more about once I'm done testing a few more things.

  5. André says:

    just load the analytics.js from your own server

    btw. our cms BLUE CREATOR from Germany gets the 100/100 automaticly.


  6. vijay says:

    I've looked at LoadCSS and LoadJS to prevent render block...
    Quick question - would a link file (CSS) in footer (before closing body tag) work to improve perceived page load? If so, would it also be cached?

    1. Paul says:

      Yes it does aid in loading the page quicker. Anything that isn't "above the fold critical" can be placed before the end of the closing body and as it's an external resource it will be cached 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *