Top tips to ensure fast website download speed

Posted by Jason Howard on 11 January 2017

 

47% of consumers expect a web page to load in 2 seconds or less*

Your website download speed impacts on not only the user experience but also search rankings - here's a few top tips to help you improve the speed of your website.

(The majority of these are implementation specific but a couple, specifically images and broken links, can be followed by all.)

Use GZIP compression

This feature is configured on the web server and will compress the files such as HTML, CSS and JavaScript before sending them to the user where the files are uncompressed resulting in smaller files and therefore faster transfer and less bandwidth. Most modern browser will support GZIP compression and if it doesn’t it will just get the uncompressed file.

Cache (Browser)

This feature is also configured on the web server and marks static files or files that change infrequently such as CSS, JavaScript and core images as being cacheable for a period of time on the recipient’s browser. The server marks these files with an expiration date of say one week in the future. The first time a browser requests a cacheable file the full file is downloaded and then cached locally. Any subsequent request for that file will not be loaded from the server and the browser will use the local cached copy until the expiration date is reached when the browser will reload the latest file from the server and cache it again. Really useful for CSS, JavaScript and images such as logos.

Google recommend an expiry date of at least 7 days and maybe even one year for content that changes very infrequently. One drawback of this is when a JavaScript or CSS file is updated to fix an issue or implement a new feature. The browser does not know the file has changed so it just uses the cached version unless the user performs a hard refresh which will reload all content from the server. One way round this is to append a query string parameter when requesting the resource. The browser will see a different URL from its cached version and will load the modified file.

Cache (Server)

Although it has to be configured the majority of CMS application do already perform caching of the managed content for you but most implementations will have some custom functionality that may use content from other sources.

Caching this data on the server will help reduce the time it takes the server to start sending content back to the browser. A simple example when this can be useful would be a list of countries that are used throughout the site or on particularly popular pages. The list of countries may be held in an external database so every time that list is to be displayed on a page the server has to get the items, format them in a particular way and create the HTML before returning that to the browser. Caching the countries or even the resultant HTML would reduce the overhead of getting the items and building the HTML. Just caching the countries in this example would probably not be very beneficial but when that is multiplied with other content that can be cached you could see a big benefit. Again caching of this sort has the drawback that if the data changes it will not be sent to the browser until such time as the item is rebuilt, when that item is expired from the cache or the whole server cache is cleared. You can also create cache dependencies so if an item does change the relevant cache item is destroyed or rebuilt automatically.

Content Delivery Network

For some resources using a Content Delivery Network (CDN) may result in a good boost in site performance. The CDN will cache your images and other content and as the network is location aware the browser will get the file from a location nearest to it. It will also mean that requests are on a different domain from the site so should reduce the load on the primary web server. When working with a CMS you would have to configure that to use the CDN so that it can upload the images as and when they are added or updated by content editors.
Fix broken links

It is always useful to keep on top of broken links not only so your users do not experience 404 – not found errors but any link that is redundant will still be an unnecessary request to the web site which it has to handle and respond back to the browser. This isn’t just pages but also images and other resources that may have been removed from your media library but are still referenced by other pages in the site.

Images

“A picture is worth a thousand words” and sometimes thousands of kilobytes especially on home pages and landing pages. Most images will be cached either by the browser and or by the server but they may well make up the most requests and the most bandwidth of a page on your website so making sure these are as small as possible is a good thing.  A lot of the static content such as footer logos and icons will normally be quite small in size but the images used in call to actions and banners may be quite large. In some cases the image is actually too detailed and tools such as Photoshop or online tools have a save as web version feature and whilst this reduces the image quality slightly, probably not noticeable enough for most of us, it will also reduce the file size and normally quite dramatically.

Another issue can be images that unnecessarily have dimensions too large for the space that they are being shown in. An example would be a header logo where the page will always show the image at a fixed size of say 350x200 but when this was uploaded to the CMS it was uploaded with dimensions of 3500x2000 (an extreme example, I know, but I have seen it). The browser will still retrieve the large image when a smaller image will do just as well and also load a lot quicker.


Images can also be an issue when used on a responsive site because regardless of the device requesting the page and the image dimensions shown on the device the full size image is always loaded. There are ways to address this but that’s for another article!

(*Source: kissmetrics.com)

Jason Howard

Find more posts by Jason Howard