There are multiple types of response caching. SellCloud enables caching that is safe for all applications. Your application may use additional caching of its own if it was designed for it.
Static File Caching
SellCloud enables ETag-based caching of static resources.
When a browser makes a request for a static file, Nginx includes a unique version identifier (called an ETag) in the response headers. When the browser requests the file again, the browser sends the last ETag with the request. Nginx checks the provided ETag against the static file's current version. If the file has not changed, Nginx sends back a 304 Not Modified response indicating that the browser has the latest version of the file and doesn't need to download the file again.
SellCloud does not configure your server to send response headers instructing browsers and proxies to cache files for extended periods of time without requesting them again. Caching files in this way can cause websites to break if old versions of static files are cached for long periods of time by web browsers. As you generally get little benefit from this type of caching and the risk of seeing a broken website is high for your visitors, SellCloud does not enable additional caching for static files.
PHP Response Caching
SellCloud does not enable any caching of PHP-generated responses.
Caching PHP responses can be very risky. There are many application-specific issues to consider, such as whether private or user-specific content is cached by browsers and proxies. If you are interested in caching responses generated by PHP, see your application's caching documentation for how to safely enable response caching.
Alert: For Control Panel Help & Tutorials, click here: Panel Tutorials
