How to manage your site's dynamic cache

Webhosting > Linux

How to manage your site's dynamic cache

With HiSpeed Cache you can manage your site's cache, significantly increasing page loading speed. This function is very useful for a better user browsing experience. The cache significantly reduces the time the browser has to wait before receiving data (TTFB).
The Dynamic cache allows you to keep the dynamic contents of the site in the server memory after their first loading in order to return them to the user browsing the site in the shortest possible time.
It is especially recommended for use with WordPress with the plugin Aruba HiSpeed Cache.

Standard Linux Hosting and WP Ready pages are cached for 12 hours. In case of a website update, if you want to make the change visible immediately, you can clear the cache at any time, as described below.
 


For Linux Hosting packages purchased after 15/02/2023  HiSpeed Cache can be activated.

If you want to enable the cache, you need to access the customer administration and click on enable. By clicking on disable it is possible to disable the function.

The purge cache button allows you to clear the active Dynamic cache. Clearing the cache allows you to show recent changes on your page without waiting for the 12 hours required for automatic emptying.
 
Enabling the cache on sites created with some CMSs, other than WordPress, could cause some pages to display incorrectly.
For WP Ready purchased after 15/02/2023 the Dynamic cache is pre-activated.

The WP Ready platform is optimized for using this feature and for this reason the cache is turned on by default.
If you want to disable the cache, you need to access the customer administration and click on disable. 

For WP Ready purchased before 15/02/2023, clicking the enable button activates the function;

By clicking the disable button it is possible to disable the function.

The purge cache button allows you to clear the active Dynamic cache. Clearing the cache allows you to show recent changes on your page without waiting for the 12 hours required for automatic emptying.
 
For WordPress-based sites, it's a good idea to check that themes or plugins don't block the use of the cache.
Furthermore, to verify the improvement in site performance with cache management, it is necessary to log out of the WordPress dashboard or, alternatively, open a window in confidential (or anonymous) mode or use another browser; this is because, when you are authenticated in the WordPress dashboard, there is a cookie in the browser that instructs the server not to use the cache.
For expert users it is possible to learn more about the operation and management of HiSpeed Cache by reading the following:
How cache management works 
HiSpeed Cache works based on headers. The standard Cache-control headers supported by CMS are supported:
  • cache-control: no-cache. In the presence of this header, the system does not cache this request;
  • cache-against: max-age. In the presence of this header, the system caches this request for a certain number of seconds
In the case of a custom script it is possible to exclude the URL simply by using the header:
 
<php header("Cache-Control: no-cache"); ?>
 
It is also possible to set a permanence time (in seconds) of the page in the cache:
 
<php header("Cache-Control: max-age=6000"); ?>
 
From the caching system are excluded:
  • addresses containing one of the following strings:
    wp-login, preview=true, cart, my-account, checkout, addons, add-to-cart, wp-cron.php, xmlrpc.php, contact, task=registration, registerview =registration|administrator|remind|login, admin/content/backup_migrate/export, status.php, update.php, install.php, user, info, flag, ajax, aha , / account;
  • requests with cookies that contain one of the following strings:
    wordpress_no_cache, comment_author, wordpress_logged_in_, yith_wcwl_products, wp-postpass_, it_exchange_session_, wp_woocommerce_session, woocommerce_cart_hash, Drupal.visitor.name, edd_items_in_cart=1, drupalSGCacheBypass=1, jSGCacheBypassache=1, wpBpassache=1 woocommerce_items_in_cart=1
Below are some examples of code to insert in the .htaccess file to exclude one or more pages from the cache:

Single page exclusion

<IfModule mod_headers.c>

Header always set Cache-Control "private" "expr=% {ENV:REQUEST_URI} =~ m#^/page/$#"

</IfModule>

Exclude multiple pages:

<IfModule mod_headers.c>

Header always set Cache-Control "private" "expr=%{ENV:REQUEST_URI} =~ m#^(?:/page1/|/page2/)$#"

</IfModule>

How to test the behavior of pages
The easiest way to check if pages are cached is to make a request to the site and check the return headers. You can use a built-in function in the Chrome browser for this purpose.
To check the  Response Header follow this procedure:
  1. click with the right mouse button anywhere on the page of your site to be tested and select  Inspect, or press the F12 key on the keyboard;
  2. in the console that opens, click the  Network tab at the top;
  3. if the tool indicates that network activity is being recorded, press Ctrl + R as suggested;
  4. select an item from the list;
  5. click the Headers tab.
  6. These are the possible values of   x-aruba-cache :
    • HIT. This result means that the page is correctly cached.
    • MISS. You need to reload the page and check it again - this is the first time this page has been visited in 12 hours.
    • BYPASS. This result indicates one of the following conditions: you have logged in to your site, you are testing a page excluded from the cache, or there are cookies in your browser that trigger the dynamic cache management request
Below is an example of a Response Header shown by Chrome:


If the header is not present it means the cache has been disabled by the exclusion rules or by the Cache-Control header sent by the CMS.
Article ID: 4338, , Modified: 2/15/2023 at 2:30 PM

Share this article

Translations

Czech (čeština)