Peakhour caches and distributes your website's static assets amongst its global network. Unlike traditional CDNs that require that you upload your content separately to their servers and serve off a different domain (or subdomain), Peakhour does this transparently with no changes needed by the origin website.
Clicking on the CDN link in your domain Dashboard and then on the Files tab will show you what's currently being cached by Peakhour.
Clicking on the link under the Actions column shows the current headers associated with the file. If the headers are empty it means that the file must be fetched again from the origin or that it will no longer be cached. If a file is no longer cached it will automatically be removed from the file list.
The Files view also gives you the option of flushing/purging the resource from the Peakhour cache. This will notify Peakhour to refetch the resource from the origin server. You can purge individually, or if necessary flush the entire site. This will have a significant performance hit to your site as Peakhour will have to re fetch everything from the origin.
You have three options for handling assets that have a query string, the optional part of a url after a question mark. eg /foo/?bar=true, in this case the query string is bar=true
The first option is not to cache resources that have a query string as that usually implies that the asset is dynamically generated, depending on parameters specified in the query string. This is the default option
The second is to cache the asset along with its full query string. If this mode is selected each permutation of the query string will result in a different cache entry.
Finally you can cache and ignore the query string, this option will cache the asset without the query string and serve the stored file regardless of whether a request is made with different query strings.
If an asset has been requested and cached without a query string,
and then is requested with a query string:
then the default behaviour is to invalidate the cache entry for /styles.css as it implies that different versions are possible, tick this box if you want to not invalidate the cache. Alternatively you can change the query handling mode to cache with the query string.
The "Vary" header in a response describes what parts of a request, aside from the request method (eg GET, POST), Host header field, and request target, might influence the origin server's process for generating the response. The Vary value consists of either a single asterisk ("*") or a list of header field names (case-insensitive). eg:
Vary: accept-encoding, accept-language
This informs a cache or client that the content might be different depending on the values in the accept-encoding and accept-language headers. Unfortunately while this is a very powerful header it is usually misconfigured on a server sending Vary headers when the content is not actually varied.
Currently the Peakhour CDN can only cache 1 asset per URL, since a Vary header implies there are multiple versions per URL, the default (and safe) behaviour is to not cache the asset. If your origin server is misconfigured and is sending Vary headers you can tick this option to enable Peakhour to cache the content.
By default the CDN runs a set of rules over a requested file to determine whether it is cacheable or not. This will depend on the query string, the file top, and the headers coming back from the origin header. By ticking the skip logig option you are telling Peakhour to just cache an asset.
This option allows you to specify a series of cookies that your application might set on a client, informing Peakhour to always serve 'fresh' content if they are set. This will bypass our cached asset and fetch it from the origin for the request. This is very useful when you might serve dynamic content to logged in users but not to anonymous users.
If you have pagespeed optimisations running then assets might be cached by pagespeed first rather than the automatic CDN, we will cover that separately.
A large percentage of the web is authored using CMS systems such as Wordpress, Magento, Drupal etc. Once authored this content does not usually change, for example if the site is a blog. In this case it is possible to cache the generated page rather than asking the CMS to regenerate for every request. This can result in massive performance increases, we have a separate guide on anonymous page caching here!