There are several tools that analyze page speed and show how quickly users can see and interact with content. The tools will identify areas that need improvement and most of them will analyze the same areas. There is a great article by Gtmetrix.com that explains why different tools might show different results when analyzing page speed on sites.
On this blog post, I’ll review the items that are analyzed at server level and provide examples of how you can fix or improve you site speed at server level.
Items Fixed on Server
- Leverage browser caching or Add Expires headers – HIGH Priority
- Specify a cache validator – Etags & Cache-control tags – HIGH Priority
- Enable gzip compression or Compress components with gzip – HIGH Priority
- Avoid landing page redirects – HIGH Priority
- Enable Keep-Alive – HIGH Priority
- Use a Content Delivery Network (CDN) – HIGH Priority
- Specify a Vary: Accept-Encoding header – HIGH Priority
Leverage browser caching:
Browsers can store webpage resources on computers so that they don’t have to download these resources every time they visit a site. By leveraging browser caching, you can instruct browsers how often resources are updated on your website so that they know when these resources should be downloaded again.
Leveraging browser caching is different depending on the type of server your site is using. We will discuss how to fix these items on Apache but will provide resources for other servers:
Note: Editing your .htaccess file could break your site if not done correctly. If you are not comfortable doing this, please check with your web host first.
To enable browser caching on Apache servers you need to edit your .htaccess file by using notepad or any form of basic text editor.
In this file you can set your caching parameters to tell the browser what types of files to cache or store. Below is an example of the code:
You can see on the code above that images are updated once a year, css is updated once a month and so on.
Depending on your website’s files you can set different expiry times. If certain types of files are updated more frequently, you would set an earlier expiry time on them (ie. css files)
Before adding expire dates, make sure that you are not setting this up for every resource on the site, for ecommerce sites it is important not to cache resources on the shopping cart because it can lead to serious issues. There is a great article on this topic.
When you are done save the file as is and not as a .txt file.
Specify a cache validator:
When you see a “Specify a cache validator” warning in when analyzing your site’s speed on one of the tools is because you are missing HTTP caching headers like: Last-Modified, Cache-Control and Etag headers.
These headers should be included on every page server response, as they both validate and set the length of the cache. If the headers aren’t found, it will generate a new request for the resource every time, which increases the load on your server. Utilizing caching headers ensures that subsequent requests don’t have to be loaded from the server, thus saving bandwidth and improving performance for the user.
The Last-Modified headers are weak cache headers. The current preference is to use Cache-Control headers. Below we’ve included how Google defines these headers:
- Cache-Control defines how, and for how long the individual response can be cached by the browser and other intermediate caches.
- ETag provides a revalidation token that is automatically sent by the browser to check if the resource has changed since the last time it was requested. To learn more, see HTTP caching.
Below you can see an example of how to set up an Etag on your .htaccess file.
<IfModule mod_headers.c> Header unset ETag </IfModule> FileETag None
Enable gzip compression / Compress components with gzip
As discussed above, there are different methods of configuring servers depending on their type and gzip is no different. Below are examples of how you can enable gzip on different servers:
You will need to add the following lines to your .htaccess file:
After you’ve saved your .htaccess file, test your site again on one of the speed tools to make sure it has been properly compressed.
If you are running on IIS, there are two different types of compression, static and dynamic. We recommend checking out Microsoft’s guide on how to set up gzip.
If you are running on NGINX, simply add the following to your nginx.conf file.
Avoid landing page redirects
If you see a warning on avoiding landing page redirects, this means that you have more than one redirect from the given URL to the final landing page. Reducing the number of redirects from one URL to another cuts out additional round trip times to the server and wait time for users.
Google provides some examples on redirect patterns that can harm your site:
- example.com uses responsive web design, no redirects are needed – fast and optimal!
- example.com → m.example.com/home – multi-roundtrip penalty for mobile users.
- example.com → www.example.com → m.example.com – very slow mobile experience.
- http://mydomaine.com/ → https://mydomaine.com → https://www.mydomaine.com – very slow experience.
So, make sure that your domain redirects only once when needed in order to avoid the multiple RTTs to the server by:
- Using responsive layouts to avoid sending users to a mobile version of the site on a subdomain like shown above.
- Identify redirects to non-html resources such as images and CSS.
- Perform the redirection server-side rather than client side.
Depending on the landing page redirects, you’ll need to add different codes on your .htacces in the case of an Apache server.
Enable keep-alive will allow the same TCP connection to handle several requests between the web server and the browser.
Apache enables Keep-Alive connections by default, however you can explicitly turn them on by adding the following line to your httpd.conf file.
It is important to know that you should not set up keep-alive headers through .htaccess since it can send misleading information about the server’s capabilities.
Use a Content Delivery Network (CDN)
To summarize, a CDN is a network of servers on different locations. Each of these servers will save static content of sites like images and CSS/JS files. It’s common that most of the page load time is spent on retrieving this type of content, which is why making them available in servers in different geographical regions will allow browsers to pull data from servers’ closer to them. The short distance for the data to travel will provide a fast site experience.
There are several companies that offer CDN, below we’re are listing three of the more popular options:
Specify a Vary: Accept-Encoding header
Issues on some public proxies may lead to compressed versions of your resources being served to users that don’t support compression. Specifying the Vary: Accept-Encoding header instructs the proxy to store both a compressed and uncompressed version of the resource.
To fix this issue on Apache, add the following code on your .htaccess:
<IfModule mod_headers.c> <FilesMatch ".(js|css|xml|gz|html)$"> Header append Vary: Accept-Encoding </FilesMatch> </IfModule>
If you have any other resources and suggestions for improving server speed, please feel free to add them on the comments below.