SiteGround CDN - Configuration, Headers, and Purging

Our own Content Delivery Network – SiteGround CDN – is developed specifically for our clients and makes it possible for their content to be cached and replicated across multiple locations. It directs site requests to the closest to the visitor SiteGround CDN location which in turn will serve the cached content (if the specific content has been cached previously) or forward it to the origin hosting server. Here, we will take a closer look at how the service operates and handles caching.

Operation

The SiteGround CDN service can be activated only if your domain name is using SiteGround’s centralized DNS. This means that your domain name must be using these nameservers:

ns1.siteground.net
ns2.siteground.net

This is how a web request is handled with the SiteGround CDN enabled:

• Visitor requests to visit a particular web page;
• The visitor’s request is routed to the closest SiteGround CDN location;
• If the web page has been visited recently, it should be stored in cache and therefore the visitor will get a response with the cached version of the page (Caching of dynamically generated pages is available only for Premium SiteGround CDN plan. The free SiteGround CDN plan caches only static files such as CSS files, JS files, images, static HTML files, etc.);
• If the page is not cached, SiteGround CDN will proxy the request to the domain’s origin server (i.e. host server), which will serve the request back to the CDN, where the page will be stored in cache and then sent to the visitor (if it is cacheable).

Default Expiration Time

The default time website resources are kept in the SiteGround CDN cache is 12 hours. This time can be overwritten by Cache-Control:max-age header sent by the application, thus the clients can manage the cache time on their end too.

SiteGround CDN Locations

The SiteGround CDN locations can be found on our website:

https://www.siteground.com/datacenters

Make sure that you get familiar with the exact locations of SiteGround CDN.

Data Protection

You may be legally required, under privacy or data protection legislation to protect your website user’s personal data. This creates certain cases in which caching should not be used. For instance, in most situations when a user is logged into a website they should see personalized information, which is something caching interferes with. Prominent examples of this are checkout pages, or shopping cart pages, both of which should not be cached. That’s why we have excluded a number of addresses from SiteGround CDN cache by default. The excluded URLs are:

wp-login, preview=true, wp-cron.php, xmlrpc.php, status.php, update.php, install.php, admin, user, info, flag, ajax, aha, cart, contact, domainmap_action, task=registration, register, view=registration|administrator|remind|login, /admin/content/backup_migrate/export

The list can be updated with other URLs that meet the same criteria.

We recommend that you check that pages containing personal data will be excluded by default, by referring to the above URL matches.

Cookies

We monitor whether your browser has  the following cookies and bypass the cache if they are present: wordpress_logged_in_, yith_wcwl_products, wp-postpass_, edd_items_in_cart=1, it_exchange_session_, wp_woocommerce_session, woocommerce_cart_hash, woocommerce_items_in_cart=1, wpSGCacheBypass=1

For some, we monitor the value of the cookie while for others, just the cookie itself is enough.

Supported Caching Headers

SiteGround CDN cache relies largely on headers. While it has custom headers of its own, we also follow best practices and support the standard headers which most CMS apps use. These include:

• Cache-Control: no-cache – passing this header tells our system not to cache this request;
• Cache-Control: max-age – we will cache the page for the specified time in seconds defined via max-age. If it is set to 0 we do not cache the page;
• Expires – The same as max-age. It is advised to use max-age instead of Expires;
• Set-Cookie – the page will not be cached if the response includes this HTTP header;
• X-Accel-Expires – we cache the page for the specified time in seconds. If it is set to 0 we do not cache the page.

If you’re developing your own script or using a custom web application, you can exclude URLs simply by passing the appropriate header:

<php header(“Cache-Control: no-cache”); ?>

Or, you can set how long your pages should be cached for:

<php header(“Cache-Control: max-age=6000”); ?>

Purging the SiteGround CDN cache

You can initiate a purge of all cached resources manually from Site Tools > Speed > SiteGround CDN. Note that deleting all caches around the world could take up to 180 seconds.

Purging the Dynamic Cache

If you’re a WordPress user, the best way is to have the Speed Optimizer plugin installed and activated. In its Cache tab, you will find a button to manually purge. In most cases, leaving the Auto Purge option should be enough. In addition to that, you can use our WP-CLI command (that comes with the plugin) to purge the Dynamic Cache:

wp sg purge

Aside from our WordPress plugin, you can manually purge the cache from the Site Tools -> Caching tab.

Testing the SiteGround CDN cache

As SiteGround CDN works based on headers, the recommended approach to test if it’s working or not is to make a request to your site and then inspect the returned headers. For that purpose, you can use the Network tab of your browser’s inspector tool, curl or an easy online tool like Reqbin curl (https://reqbin.com/curl) with the option to get the site’s headers. Then, check the value of the following headers:

• x-sg-cdn: 1 – if this header’s value is “1” then  SiteGround CDN is enabled
• x-proxy-cache: HIT – this header confirms that your page is successfully delivered from the cache
• x-proxy-cache: MISS – the request is served dynamically. Refresh your page and check the header again. Either your cache is not turned on or that’s the first time this page has been requested
• x-proxy-cache: BYPASS – the request is served dynamically because the cache is instructed to skip it. The presence of this header means that either you’re logged in to your website, you’re testing a URL from our default exclude list or you have a cookie in your browser that tells our system to serve this page dynamically