1. You need to enable gzip compression.

Gzip compression should be applied to assets that are not already compressed. Good candidates for gzip compression include:

• HTML and XML files
• CSS files
• JavaScript and JSON files (even minified JavaScript will benefit from this treatment).
• Font files (except WOFF2 files which are already compressed).
• Text files
• MS Office type documents (Word, Excel, Powerpoint, etc)

Files that should NOT be gzip compressed include:

• Images e.g. JPEG, PNG and GIF (note that if they compress significantly then it suggests they contain text metadata which should be removed)
• Video files (FLV, MOV, MP4, etc)
• ICO images
• PDF documents
• WOFF2 web fonts
• SWF (Flash movies)

If you’d like to enable gzip compression on your server, follow this set of best practices for Gzip compression .

2. You need to configure browser caching properly.

As you move around a website, there are files that are requested by a common group of pages. These files include the page logo, common stylesheets (CSS) and JavaScript libraries that are used, font files as well as other pieces of content. By enabling caching of these files, as the user moves around the site they will not have to download fresh copies of these files, greatly speeding up their experience. Browser caching can be set for specific intervals – you can signal to the browser how long you recommend it keeps certain files in its local cache.

Google provides some interesting materials on browser caching .

3. You need to enable HTTP KeepAlive (persistent connections).

Back when the web first started getting off the ground, every time you requested an object from the server the browser had to make a physical connection with the server. This would involve doing the lookup and opening a connection. Enabling HTTP KeepAlive make the setup run much more efficiently. Instead of opening multiple connections, the web browser will instead streamline on somewhere between 6 and 12 connections that are shared in a pool. This is a simple server configuration technique that will speed up your website for not a lot of work.

4. Your content is not properly optimized.

There are several main areas of content optimization to focus on:

• Images – often contain metadata or are not sized properly. In many cases they are not the right format. There are a range of tools you can use to determine this and fix these issues and best practices in this area which we will highlight in a future article.
• Movie files – often not compressed properly and need further optimization work. Once again, there are a range of tools out there to help you with this.
• CSS and JS files – often not minified (compressed). Sometimes the CSS and JS are just too heavy. This may involve some refactoring of code (in the case of CSS, removing redundant styles and architecting the CSS using best practice). In the case of JS, code profilers can be used to determine which pieces of code are being used and which are not. A common example seen on enterprise level sites is the loading of multiple copies of the JQuery library (when one will suffice).
• Heavy, complex pages where content hasn’t been deferred. There are ways to defer the loading of content until later so that the initial page load is snappy – techniques typically focus on lazy loading and event based loading (loading additional content after a browser event).

5. Your server side calls (to fetch the base HTML document) are slow.

This can be caused by a multitude of problems:

• Your web server is being overwhelmed by requests.
• Your database calls are inefficient.
• Your middleware logic is not optimized.
• You have no server side caching enabled and your HTML pages are complex to construct.
• The site uses SSL and this is the first time you are connecting (especially on poorly configured SSL).

6. You have too much CSS or JavaScript loading at the top of the page, delaying the initial page render.

Perception is everything when it comes to web pages. Pages that have slow loading JavaScript or CSS can appear to run slowly because the browser will often wait to make an initial paint to the screen until the initial CSS and JS loaded at the top of the page have fully downloaded and been processed. To get a snappier page, we recommend evaluating the load order of certain assets and determining what is crucial for the initial render and what can be deferred until later. Whilst this doesn’t necessarily impact the total page load time, this does help to get something onto the screen faster, and can alter the perception that your page is slow.

7. You are not making use of a content delivery network (CDN).

When you have a global audience, it’s important to serve up the content from a location that is close to the user. The reason for this is that it can take time to get content to an end user when your web server is located 6000 miles away. A CDN reduces the latency for the end user, resulting in a much faster experience.

8. Your pages are making too many back and forth requests.

This is common particularly on complex pages, or pages that load up multiple assets. Ways to streamline these include spriting (for images) and combining (for CSS and JavaScript). Other ways to streamline this are caching (which means you won’t be making the request in the first place) and lazy loading or deferring.

9. You have unnecessary redirects in place.

Redirects can be established either at the server level or in the browser (using meta tags). Where possible you want to avoid redirects. In many cases they can add overhead to the page in the order of 0.2 – 2 seconds. What you sometimes see is what are known as redirect chains – this is where page 1 redirects to page 2 which in turn redirects to page 3. In extreme cases, page 3 redirects to page 4, 5 and 6! As you can imagine, this leaves the browser having to make multiple requests back and forth until it finally can render the page. This is in no way ideal and so spending some time rationalizing complex redirects can be very worthwhile.

10. You are being slowed down by a 3rd party.

Increasingly sites are making use of 3rd parties for a multitude of reasons. In many cases, they provide extra functionality for your site – digital analytics, remarketing, A/B testing or may even provide a key piece of functionality. The challenge is that often these files are served from an external location that is not in your control. In addition, these files are sometimes configured to be crucial for your page load. If for any reason the end user is not able to make contact with the 3rd party it can cause a major problem with your website. We recommend you keep an eye on 3rd parties and monitor their performance before they end up causing you problems.