Website Help
Speed And Uptime
How to improve the Cache Ratio of your website?

How to improve the Cache Ratio of your website?

When it comes to the loading speed of your website, one of the most critical factors to consider is how many of your requests are served from the cache. Cached requests are much faster than those that rely on server computing power to be processed, which means that the more requests are served from the cache, the faster your website loads.

SiteGround web servers have an integrated caching system (NGINX Direct Delivery, Dynamic Cache service) and they always check if the requested content is present in the cache pools prior to proxying it down the line. If the content is found in the cache, then it is being served immediately to the client (avoiding PHP processing, MySQL queries, etc.). This is called a cache HIT. On the other hand, if the content is not found in the cache, the web server has to fetch it from the origin server and cache it for future requests. This is called a cache MISS.

The cache ratio represents the percentage of requests that are served from the cache without needing to access the origin server. A higher cache ratio indicates that more requests are being served from the cache, reducing the load on the origin server and improving the overall performance of the website.

For example, if there are 100 lines in the access log file of your website and 80 of them contain “HIT” and 20 of them contain “MISS”, the cache ratio would be 80%.

There are pages that store sensitive data or POST requests most of the time, so they’re excluded from caching by default – in other words login to your WordPress Admin dashboard, order process and actual payment requests are all not supposed to be cached and they are not counted when calculating the cache ratio.

By measuring the “HIT” ratio, you can determine how effective your caching strategy is and whether you need to adjust any settings on your website in order to improve its performance. A high cache ratio indicates that your caching strategy is working well and that you are effectively taking advantage of the site speed features provided by SiteGround. A low cache ratio, on the other hand, suggests that your caching strategy may not be effective, and you may need to consider implementing other optimization techniques.

For sites subscribed to our Monthly Performance Reports we measure the cache ratio and report it to our client. Our recommendation is to strive for a result higher than 60%.

How to increase the cache ratio of your website?

1. Keep an eye on the custom Cache-Control headers set in your .htaccess files

Having .htaccess rules for adjusting the response headers is one of the most common ways to control the caching efficiency. Sadly, we noticed a lot of generic Cache-Control headers embedded in the .htaccess files that aren’t location specific and as a result affects the cache HIT ratio and performance negatively.


Header set Cache-Control "no-cache,no-store"

SiteGround web servers respect directives in the Cache-Control header and do not cache responses when the header includes “Private”, “No-Cache”, or “No-Store” directive.

Rule of thumb #1: Make sure that “Header set Cache-Control” in .htaccess is used only for pages, locations or files on your website that contain sensitive client data and shouldn’t be cached – not for the entire site. Example:

# add Cache-Control header to single contact.php file
<Files contact.php>
Header set Cache-Control "no-cache,no-store"

2. Inspect precisely Expires and max-age directives

Another well-known approach for controlling the caching servers efficiency is either by including Expires headers with a date and time not in the future, or a Cache-Control header with the max-age directive set to zero or negative number value.

Example #1:

# Expires headers (for better cache control)
<IfModule mod_expires.c>
# Your document html
ExpiresByType text/html                     "access plus 0 seconds"

This definition in .htaccess files means that the cache should expire immediately for content type text/html (most web pages are delivered in this type) and the request should be served by the backend not by the cache.

Example #2:

Header set Cache-Control "max-age=0"

Having a Cache-Control header with max-age=0 or -1 (or other negative number) means again that the request should be processed by the backend and not by the cache.

Rule of thumb #2: Make sure that Expires headers and max-age cache-control headers are used only for content types and locations of your website that should not be stored in the cache.

3. Avoid usage of Set-Cookie header

Another approach for bypassing the caching is to have a Set-Cookie header. Commonly the Set-Cookie header is used with “PHPSESID” variable – a session cookie that is used to identify a user’s session on a website. However, generating and using a session cookie on pages that don’t contain sensitive information could be an indication for a not very well designed plugin or theme. As a result, the existence of a Set-Cookie header avoids responses to be cached and instead each time a PHP execution is performed.


When this is the case you will notice the following line in HTTP response headers of your website:

set-cookie: PHPSESSID=5eff6b1bc4f7ab78758e112be82f7b9e

Rule of thumb #3: In case your website uses Set-Cookie header and the most commonly used “PHPSESID”, make sure that it is being generated only to identify a user’s session on a website and not on all pages and posts.

4. Avoid using Vary: User-Agent header

This configuration doesn’t disable caching completely as described in the previous examples but lowers the cache ratio a lot. In fact, the problem is that commonly visitors of your website will be using different User-Agent (different browsers , with different versions), which will practically make each first visit not cached. It’s also a common case when a WP plugin is adding such a header. In these cases, the responses are cached but there are different cache entries for the different User-Agents, making the cache drastically less effective.

Here is an example of .htaccess vary header:

Header set Vary User-Agent

HTTP headers can be also managed through the applications of the hosting account. Vary header, for example, might be configured through PHP in the following way:

header("Vary: User-Agent");

or on a WordPress website (from the functions.php file)

function add_vary_header ($headers)
$headers['Vary'] = 'User-Agent';
Return $headers;
add_filter('wp_headers', 'add_vary_header');

Rule of thumb #4: Try to avoid usage of User-Agent Vary header if it is not absolutely necessary or required by the theme developers. This will help you to improve the caching rate and performance of your site a lot.

If using a User-Agent Vary header is a must, then it is still better to have a per-user-agent cache instead of no cache.

If you would like our support engineers to investigate if your current site cache ratio can be improved, you can post us a ticket through Help Desk > Other > Cache Ratio Optimization.

Share This Article