5 quick wins to increase your PageSpeed Insights score

Posted 13/06/2017 under General.

Read our quick tips on how to tweak your server or website for improve speed, user experience and SEO ranking…

Increasing your PageSpeed Insights score isn’t just for bragging rights, a faster loading website will retain visitors for longer, encourage repeat visits, and will help increase your search rankings.

Using a tool like PageSpeed Insights or GTmetrix will help you see where you can make improvements to your website’s speed and usability, as well as you give you some pointers towards implementation of these improvements. We have put together a short list of the best bang-for-your-buck changes you can make to increase your score without spending hours re-configuring servers and updating code.

1. Enable gzip compression

This is one of the biggest differences to score that also has a real world difference, it is not unusual to compress CSS and JS files to 30% of their original size before you even start playing with higher compression rates.

To enable gzip in NGINX simply add the following to your site’s config somewhere inside the relevant “server” block. This is a basic example that should work in most instances.

gzip on;
gzip_proxied any;
gzip_types text/plain text/xml text/css application/x-javascript application/javascript image/svg+xml;
gzip_vary on;
gzip_comp_level 6;
gzip_disable "MSIE [1-6]\.(?!.*SV1)";

To enable gzip in Apache add the following to your .htaccess file

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE application/javascript
  AddOutputFilterByType DEFLATE application/rss+xml
  AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
  AddOutputFilterByType DEFLATE application/x-font
  AddOutputFilterByType DEFLATE application/x-font-opentype
  AddOutputFilterByType DEFLATE application/x-font-otf
  AddOutputFilterByType DEFLATE application/x-font-truetype
  AddOutputFilterByType DEFLATE application/x-font-ttf
  AddOutputFilterByType DEFLATE application/x-javascript
  AddOutputFilterByType DEFLATE application/xhtml+xml
  AddOutputFilterByType DEFLATE application/xml
  AddOutputFilterByType DEFLATE font/opentype
  AddOutputFilterByType DEFLATE font/otf
  AddOutputFilterByType DEFLATE font/ttf
  AddOutputFilterByType DEFLATE image/svg+xml
  AddOutputFilterByType DEFLATE image/x-icon
  AddOutputFilterByType DEFLATE text/css
  AddOutputFilterByType DEFLATE text/html
  AddOutputFilterByType DEFLATE text/javascript
  AddOutputFilterByType DEFLATE text/plain
  AddOutputFilterByType DEFLATE text/xml

  BrowserMatch ^Mozilla/4 gzip-only-text/html
  BrowserMatch ^Mozilla/4\.0[678] no-gzip
  BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
  Header append Vary User-Agent
</IfModule>

2. Set Expires Headers

Another improvement that is super easy to implement and increases your score dramatically.

To set expiry on assets in NGINX add the following your site’s config inside the relevant “server” block.

location ~* \.(svg|woff|woff2)$ {
    expires 31d;
}
location ~* \.(png|jpg|gif|ico)$ {
    expires 14d;
}
location ~* \.(css|js)$ {
    expires 7d;
}

And for Apache add the following to your .htaccess file

<IfModule mod_expires.c>
ExpiresActive On 
ExpiresDefault "access plus 31 days"
ExpiresByType image/x-icon "access plus 14 days"
ExpiresByType image/gif "access plus 14 days"
ExpiresByType image/png "access plus 14 days"
ExpiresByType image/jpg "access plus 14 days"
ExpiresByType image/jpeg "access plus 14 days"

ExpiresByType application/javascript "access plus 7 days"
ExpiresByType text/css "access plus 7 days"
</IfModule>

As you can see we have different lengths of expiration for different types of files, font files aren’t likely to change so can have a long expiration, CSS and JS files will change relatively frequently so should have a shorter duration to ensure users are getting the latest versions. Google suggests a minimum of 1 week, all the way up to 1 year for assets that won’t change. If you aren’t using any sort of versioning or cache busting e.g. ?v=4.5.6 on your URLs for your CSS or JS assets you might have to adjust the expires headers to suit your update/deployment schedule, or better still use cache busting!

These are just examples of what we might use but are a pretty good starting point for most sites.

3. Minify your CSS and JS

There is no reason not to minify your CSS and JS in a production environment, this should be part of your workflow or at the very least part of your deploy process. We won’t go into details here as it could fill several very long articles on it’s own but look into using a frontend build pipeline (webpack/browserify+gulp) to combine and minify your CSS and JS files at the very least. You should be using SCSS/LESS/Stylus for your CSS preprocessing anyway so minifying your assets should be fairly trivial from that point.

If not – try a tool like minifier.org to manually minify your assets.

4. Serve your images at an appropriate size

If you are using WordPress, Magento or any other CMS which allows you to specify an image size to show, use it! Google doesn’t mind if your page is image heavy, it is (hopefully) relevant content, but if they are all 50% larger (pixel size) than the size they are getting displayed at you will be penalised in your score and possibly even your search rankings.

If your image sizes vary significantly between device sizes then consider using srcset, this is supported in all major modern browsers (Edge currently has some issues with pixel widths) and allows you to specify what image to load at what display size. srcset is not supported in Internet Explorer but luckily it will ignore the attribute and just use the normal src value instead meaning your image will still be displayed albeit at full size.

<img src="my-large-submarine-image.png" alt="Submarine" 
 srcset="my-small-submarine-image.png 400w, my-large-submarine-image.png 1000w" 
sizes="(max-width: 1200px) 400px, 1000px" />

The above example tells the browser we have 2 images 400px and 1000px, at a window width of up to 1200px we would like the 400px one loaded, otherwise the default is the 1000px version. The standard src attribute also contains the one which is 1000w for fallback without browser support. You can extend this with more images and media queries as well as using viewport width percentages to request relevant sizes.

Alternatively if you, like us, use the fantastic Foundation framework, you could take a look into Interchange.

5. Compress your images

Most images coming straight off a camera or out of Photoshop even when saved for web are not very efficiently stored and have file sizes much larger than necessary. Using a tool such as Trimage (Linux) or ImageOptim (Mac) allows you to perform lossless compression which removes metadata reducing the file size. You can go a step further a perform lossy compression which will remove some quality but reduce the file size even further – generally you can save quite a bit of size before you start to notice any visible difference.


There are many other ways to improve your site speed or the user experience of how fast it “feels” but without going into details of specific backends and frontends, it is hard to recommend something that will work for everyone. The points above should be applicable to any site and will improve the fully loaded time and should bump up your PageSpeed insights score dramatically!

Need more help?

If your site is slow or needs optimisation, we can provide you with a free consultation and advice, or a quote for us to fix your website or server issues. Get in touch with us today for more information!