Sometimes when you update your site, e.g. with a new design or new products, your changes don’t appear online after a Publish or Refresh.
Normally when this happens it is due to over-zealous caching either in the end user’s browser or at server level to make content delivery faster.
Taking care of your cache is really important for websites. If you don’t, customers could see out-of-date information, for example, last month’s prices or even products, and if you’re making fixes and changes to the design, they won’t see those either.
You may know about using a ‘Hard Reload’ in a browser (or even clear the cache and reload) to see your changes after publishing a change, but your customers won’t. It is however, possible to set up your web site so they won’t need to, while retaining the benefits of caching.
Some sites also use a ‘Content Delivery Network’ (CDN) to try and make the site faster, but if they’re not configured correctly, it can actually make performance worse as they can totally bypass any caching.
Firstly, a little information on what caching is and its primary purpose.
Browser Cache
A browser cache is a temporary storage location on a user’s device that stores frequently accessed web content. When a user visits a website, the browser stores a copy of the website’s files, such as HTML pages, images, videos, CSS files, and JavaScript files, in the cache. The next time the user visits the same website, the browser can retrieve the files from the cache instead of downloading them again from the server. This process speeds up page load times and reduces the amount of data transferred between the user’s device and the server. However, if the website’s content changes, the browser cache may not reflect the updated content, leading to inconsistencies.
CDN Cache
A 'Content Delivery Network' (CDN) is a distributed network of servers that stores cached copies of web content closer to the end-user. When a user requests a file from a website that uses a CDN, the request is sent to the CDN instead of the server that the site is hosted on. If the CDN has a cached copy of the file, it serves it directly to the user. This process reduces the load on the web server and speeds up page load times. CDNs also use a technique called edge caching, which stores cached copies of web content on servers located closer to end-users. This technique further reduces the time it takes to retrieve web content by minimizing the distance between the user’s device and the server.
In summary, both browser caches and CDN caches store web content to improve performance, but they have some key differences.
A browser cache is used only for a single user and can be deleted or modified by the user. A CDN cache is a shared cache that can serve multiple users and reduce the load on the server that the site is hosted on.
A browser cache is useful for repeated visits to the same site, while a CDN cache is useful for the first visit to a site.
Cache Settings
You have full control over the cache settings used by the browser or CDN. Normally this is done through the .htaccess file on your server. A simple command tells the browser how long it can keep a file before checking if it’s been updated.
If you don’t have any cache settings then the browser can choose to keep files for as long as it wants before asking for a new copy. This can be a big problem as images, scripts and pages can be very out of date. Additionally having a very long cache timeout can also be a problem.
For example, if you were to make price changes and one of your customers had the page in their cache, they will not then see the changed prices. Additionally, any changes made to the text on the page will not be shown in a browser until the cache has been reloaded.
A CDN merely copies the cache settings you put on your site, so if your settings are correct then you won’t have problems due to the CDN. However, Sellerdeck Desktop has some special requirements for CDNs – see below.
Recommended Settings
Add the following rules to your .htaccess file for your web site: -
Looking at the setting ‘max-age=’, for images it is set to ‘86400’, these are in seconds, and the value equates to one day. For HTML pages, stylesheets and Javascript, it is set to ‘3600’ or approximately one hour.
This will instruct the browser and CDN to only cache images for one day, before checking for newer versions of the image, and for one hour for HTML pages, stylesheets or Javascript.
After this is applied it can take a while to propagate to all browsers, but once this is in place it should only be a maximum of one hour before the amended pages are displayed.
We recommend relatively low values, as most customers will cache all the information during one visit to the site but get refreshed data the next time they visit.
Also, if a page is requested again which is in the cache but the time period has expired, then the browser makes a special request to the server. It effectively asks ‘Has this been modified since I last got a copy of the file?’ and if it hasn’t been modified, the server can respond very quickly with ‘No, you’re good, use your local copy’. So the additional overhead for a short one hour timeout period is very small, and will ensure that your customers get the latest information.
NOTE: If you aren’t familiar with working in the .htaccess file, and you are hosted by Sellerdeck then ask us and we will add our default .htaccess file which contains the cache code above or we can ask one of our partners to assist. Altenatively either your web designer or hosting company can help.
CDN Problems
CDNs will honour the instruction but may override the values. It’s worth checking what the settings are as a short cache period should be set.
All CDNs have facilities to clear the cache, which should be used if a lot of things have changed on the web site, and you want to force the changes through to customers more quickly.
Additionally regarding CDNs and their default settings, using ‘CloudFlare’ specifically as an example it is possible that the HTML cache status can be set to ‘DYNAMIC’ instead of ‘STATIC’. This means that the pages are not cached at all in the CDN, and every request is sent back to the website. This slows down your site as the CDN has to make a request to your site for every page; it completely bypasses the local browser cache so customers don’t get any benefit from caching; and therefore it increases server load and bandwidth.
DYNAMIC is relevant for ecommerce sites implemented with a database driven system like WooCommerce or as the content is generated from a database on each page request. However, it is not suitable for sites created by Sellerdeck Desktop as the content in the “acatalog” folder is fully static.
To override the default DYNAMIC setting you may have to configure a ‘Cache Rule’ whereby all files in a certain directory i.e. the “acatalog” folder can be made to be static.
It is also possible for certain file types such as .html to be forced to be ‘STATIC’ as shown here:
https://developers.cloudflare.com/ca...stomize-cache/
In the given examples, for a directory to have the status ‘STATIC’ you would create a ‘Cache Everything’ Page Rule matching the *genericwebsite.com/acatalog/* URL pattern, and for forcing a page type to have the status ‘STATIC’, you would create a ‘Cache Everything’ Page Rule matching the *genericwebsite.com/acatalog/* .html URL pattern.
NOTE: if you’ve used a different folder than ‘acatalog’ for the site content then use that instead. Do not cache the entire website i.e. 'www.genericwebsite.com/*' as this will then try to cache all of the script responses, meaning that you will not be able to place an order.
This will significantly reduce the load on the server as the CDN will only be polling the web server at certain times, and browsers will be able to cache the files locally.
Normally when this happens it is due to over-zealous caching either in the end user’s browser or at server level to make content delivery faster.
Taking care of your cache is really important for websites. If you don’t, customers could see out-of-date information, for example, last month’s prices or even products, and if you’re making fixes and changes to the design, they won’t see those either.
You may know about using a ‘Hard Reload’ in a browser (or even clear the cache and reload) to see your changes after publishing a change, but your customers won’t. It is however, possible to set up your web site so they won’t need to, while retaining the benefits of caching.
Some sites also use a ‘Content Delivery Network’ (CDN) to try and make the site faster, but if they’re not configured correctly, it can actually make performance worse as they can totally bypass any caching.
Firstly, a little information on what caching is and its primary purpose.
Browser Cache
A browser cache is a temporary storage location on a user’s device that stores frequently accessed web content. When a user visits a website, the browser stores a copy of the website’s files, such as HTML pages, images, videos, CSS files, and JavaScript files, in the cache. The next time the user visits the same website, the browser can retrieve the files from the cache instead of downloading them again from the server. This process speeds up page load times and reduces the amount of data transferred between the user’s device and the server. However, if the website’s content changes, the browser cache may not reflect the updated content, leading to inconsistencies.
CDN Cache
A 'Content Delivery Network' (CDN) is a distributed network of servers that stores cached copies of web content closer to the end-user. When a user requests a file from a website that uses a CDN, the request is sent to the CDN instead of the server that the site is hosted on. If the CDN has a cached copy of the file, it serves it directly to the user. This process reduces the load on the web server and speeds up page load times. CDNs also use a technique called edge caching, which stores cached copies of web content on servers located closer to end-users. This technique further reduces the time it takes to retrieve web content by minimizing the distance between the user’s device and the server.
In summary, both browser caches and CDN caches store web content to improve performance, but they have some key differences.
A browser cache is used only for a single user and can be deleted or modified by the user. A CDN cache is a shared cache that can serve multiple users and reduce the load on the server that the site is hosted on.
A browser cache is useful for repeated visits to the same site, while a CDN cache is useful for the first visit to a site.
Cache Settings
You have full control over the cache settings used by the browser or CDN. Normally this is done through the .htaccess file on your server. A simple command tells the browser how long it can keep a file before checking if it’s been updated.
If you don’t have any cache settings then the browser can choose to keep files for as long as it wants before asking for a new copy. This can be a big problem as images, scripts and pages can be very out of date. Additionally having a very long cache timeout can also be a problem.
For example, if you were to make price changes and one of your customers had the page in their cache, they will not then see the changed prices. Additionally, any changes made to the text on the page will not be shown in a browser until the cache has been reloaded.
A CDN merely copies the cache settings you put on your site, so if your settings are correct then you won’t have problems due to the CDN. However, Sellerdeck Desktop has some special requirements for CDNs – see below.
Recommended Settings
Add the following rules to your .htaccess file for your web site: -
Code:
##### Cache control # 1 DAY for images <filesMatch ".(ico|jpg|jpeg|png|gif|webp|avif)$"> Header set Cache-Control "max-age=86400, public, must-revalidate" </filesMatch> # 1 HOUR for html htm css js svg <filesMatch ".(html|htm|css|js|svg)$"> Header set Cache-Control "max-age=3600, must-revalidate" </filesMatch>
This will instruct the browser and CDN to only cache images for one day, before checking for newer versions of the image, and for one hour for HTML pages, stylesheets or Javascript.
After this is applied it can take a while to propagate to all browsers, but once this is in place it should only be a maximum of one hour before the amended pages are displayed.
We recommend relatively low values, as most customers will cache all the information during one visit to the site but get refreshed data the next time they visit.
Also, if a page is requested again which is in the cache but the time period has expired, then the browser makes a special request to the server. It effectively asks ‘Has this been modified since I last got a copy of the file?’ and if it hasn’t been modified, the server can respond very quickly with ‘No, you’re good, use your local copy’. So the additional overhead for a short one hour timeout period is very small, and will ensure that your customers get the latest information.
NOTE: If you aren’t familiar with working in the .htaccess file, and you are hosted by Sellerdeck then ask us and we will add our default .htaccess file which contains the cache code above or we can ask one of our partners to assist. Altenatively either your web designer or hosting company can help.
CDN Problems
CDNs will honour the instruction but may override the values. It’s worth checking what the settings are as a short cache period should be set.
All CDNs have facilities to clear the cache, which should be used if a lot of things have changed on the web site, and you want to force the changes through to customers more quickly.
Additionally regarding CDNs and their default settings, using ‘CloudFlare’ specifically as an example it is possible that the HTML cache status can be set to ‘DYNAMIC’ instead of ‘STATIC’. This means that the pages are not cached at all in the CDN, and every request is sent back to the website. This slows down your site as the CDN has to make a request to your site for every page; it completely bypasses the local browser cache so customers don’t get any benefit from caching; and therefore it increases server load and bandwidth.
DYNAMIC is relevant for ecommerce sites implemented with a database driven system like WooCommerce or as the content is generated from a database on each page request. However, it is not suitable for sites created by Sellerdeck Desktop as the content in the “acatalog” folder is fully static.
To override the default DYNAMIC setting you may have to configure a ‘Cache Rule’ whereby all files in a certain directory i.e. the “acatalog” folder can be made to be static.
It is also possible for certain file types such as .html to be forced to be ‘STATIC’ as shown here:
https://developers.cloudflare.com/ca...stomize-cache/
In the given examples, for a directory to have the status ‘STATIC’ you would create a ‘Cache Everything’ Page Rule matching the *genericwebsite.com/acatalog/* URL pattern, and for forcing a page type to have the status ‘STATIC’, you would create a ‘Cache Everything’ Page Rule matching the *genericwebsite.com/acatalog/* .html URL pattern.
NOTE: if you’ve used a different folder than ‘acatalog’ for the site content then use that instead. Do not cache the entire website i.e. 'www.genericwebsite.com/*' as this will then try to cache all of the script responses, meaning that you will not be able to place an order.
This will significantly reduce the load on the server as the CDN will only be polling the web server at certain times, and browsers will be able to cache the files locally.