work with us

Quick and easy tips for improving your site speed (part 1)

Written by Ian Leckey: Head of development.
· 4 minute read

Thanks to Google’s PageSpeed Insights tool, web page speed and performance is never far from the minds of website stakeholders. Whilst PageSpeed Insights as a tool does have glaring credibility issues (even Google-owned YouTube only scores 68), especially when viewed and interpreted by an untrained eye, the fundamental of what it’s trying to achieve is spot on. So here’s part 1 of a list of easily implementable changes to boost your site’s performance.

Gzip compression

Gzip will compress your web pages and assets, lowering the overall data that users need to download when they hit your site. It’s super easy to enable and can reduce file sizes by up to 70% in some cases.

Apache config:
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xml+rss
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE image/x-icon
AddOutputFilterByType DEFLATE image/bmp
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/png
AddOutputFilterByType DEFLATE image/jpeg
Header append Vary User-Agent

Nginx config:
gzip on;
gzip_proxied any;
gzip_types text/plain text/css application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript image/x-icon image/bmp image/svg+xml image/png image/jpeg;
gzip_vary on;

Naturally, add any extra MIME types you want to be included.

Optimise images

Unoptimised (or poorly optimised) JPG/PNG images are one of the biggest and most noticeable factors in page load time. A huge amount of improvement can be made, simply by making sure your images are properly compressed and in a format appropriate for the application. There are two ways an image can be compressed: Lossless, and lossy. A lossless compression will aim to reduce file size of an image without sacrificing quality, whereas a lossy compression will sacrifice data and quality for significantly larger decreases in file size.

You’ll have to make a judgement call on which type of compression is appropriate, but a great tool for this is:

Although what I consider to be an even better solution, is to use a next-gen image format such as WebP. WebP is an image format created by Google which is specifically designed for use on the web, and massive file size decreases are seen as a result (I’ve seen a 150kb image squashed down to 20kb). It’s not supported by every mainstream browser yet, so you’ll need to implement png/jpg fallbacks for these cases.

If you’re running WordPress, there’s a hugely helpful plugin available, WebP Express, which simplifies the entire process, and takes care of the fallbacks for you. Alternatively, a good solution would be to implement the cwebp binary in to your build scripts, to automate the conversion process.

Lazyload your images

What’s the sense in downloading a load of footer images on page load, that 90% of your users will never see? It wastes data, bandwidth, system resources and time for the user. This is where lazyloading comes in.

Lazyloading is a technique that defers the loading of assets that aren’t needed at page load time. In terms of images, think of this as any image which is offscreen initially (either below the fold, or the 2nd image in a slider for example).

A great tool for implementing this behaviour is lazysizes.

Lazysizes prioritises image loading by classifying them as “in view”, “very near view”, and “not so near view” to determine which images need to be downloaded and when. It also comes with a great JS API.

Minify assets

Another simple way of increasing performance, is to minify your CSS & JS assets. Minification is essentially a process of removing unnecessary characters from your files, with the prime intention of reducing file size and subsequently resulting in quicker downloads.

There are a plethora of tools available to accomplish this, and you can automate the process by adding them in to your build script, but for the sake of brevity, here are just a couple of examples:


Browser caching

Leveraging browser caching won’t do a jot for first-time visitors, but for returning users, the gains are huge. Browser caching helps by storing files/assets on the user’s machine after they’ve initially downloaded them – meaning the next time they visit, they won’t need to redownload the same files. Thus decreasing load on your web server, and removing network latency and downloads for the user.

We’re able to set expiry times for each type of asset that a user may encounter when visiting. So you may for example, wish to have a lower expiry time for assets which are more likely to be updated regularly, versus an image which is unlikely to ever change.

Apache config:

ExpiresActive On
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresByType video/mp4 "access plus 1 year"
ExpiresByType video/mpeg "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"

Nginx config:
location ~* \.(?:css|js)$ {
expires 30d;
add_header Pragma public;
add_header Cache-Control "public";
location ~* \.(?:ico|gif|jpe?g|png)$ {
expires 1y;
add_header Pragma public;
add_header Cache-Control "public";

This isn’t an extensive list of file types, so you’ll want to add your own application-specific ones which your users are likely to encounter.

Reverse Proxy

Using a reverse proxy to handle the serving of static assets is a neat way to gain some extra performance. Nginx for example, is documented as being capable of serving static assets quicker than Apache. Sometimes though it’s just not feasible to entirely replace Apache, as it’s much more flexible in shared hosting environments for example. The good news is, we can run Apache and Nginx side-by-side, allowing Nginx take care of our static content, and Apache to process our dynamic content.

This is trivial to set up if you’re running something like Plesk, but for those of you that aren’t, take a look at how to set it up here: