{"id":18775,"date":"2020-02-26T12:10:15","date_gmt":"2020-02-26T17:10:15","guid":{"rendered":"https:\/\/www.boldgrid.com\/support\/?p=18775"},"modified":"2024-02-22T09:58:47","modified_gmt":"2024-02-22T14:58:47","slug":"configuring-browser-caching-in-w3-total-cache","status":"publish","type":"post","link":"https:\/\/www.boldgrid.com\/support\/w3-total-cache\/configuring-browser-caching-in-w3-total-cache\/","title":{"rendered":"Configuring WordPress Browser Caching using W3 Total Cache"},"content":{"rendered":"\n

Browser caching is extremely important for improving your WordPress performance<\/a> and speed, and it is recommended that you enable it in nearly all situations. The good news is that it is very easy to enable for WordPress with W3 Total Cache. Browsers are already parsing HTTP headers for your website, so we can add some information to these headers that declare how long the assets should be held on to locally, or if the browser should download a newer copy.<\/p>\n

When users visit your site, their browser will examine the HTTP headers being passed to determine if it should store a local copy of the assets. Not only will your site load faster for users since they are loading local copies of your stylesheets, javascript, images, fonts, and etc, but these assets will not have to be served from your hosting plan when a user navigates through your site.<\/p>\n

\n
\n
\n
<\/div>\n
\n

Speed up your WordPress website with Browser Caching and W3 Total Cache Pro<\/strong><\/p>\n<\/div>\n

\n

View Plans<\/a><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

Browser Cache Settings<\/h2>\n

Here we will review the Browser Cache > General Settings section in W3 Total Cache for WordPress<\/a> and examine what each of the available settings do.<\/p>\n

General<\/h3>\n

Set Last-Modified header<\/h4>\n

Default value<\/strong>: Enabled<\/p>\n

The “Set Last-Modified header” option in W3 Total Cache lets you decide whether or not your server includes a special “Last-Modified” timestamp when delivering web content. When you turn this option on, the server adds information about the last time the content was changed to its responses. This is handy for web browsers and proxies because they use this timestamp to figure out if they can keep using a stored (cached) version of the content or if they need to grab a fresh one. Essentially, it helps improve website speed and performance by managing how cached content is handled based on when it was last modified.<\/p>\n

For more information on the Last-Modified header, please see mozilla.org’s documentation<\/a>.<\/p>\n

\"\"<\/p>\n

\n

Set expires header<\/h4>\n<\/div>\n
\n

Default value:<\/strong> Disabled<\/p>\n<\/div>\n

\n

The “Set Expires Header” option in W3 Total Cache lets you explicitly tell browsers and proxies how long they can keep a cached version of your web content before they need to check with your server again. Instead of relying on the server’s “Last-Modified” timestamp, you set a specific expiration date, like a countdown timer, for each resource. Imagine this as a built-in freshness label, telling the browser how long it can serve a cached version before checking for updates.<\/p>\n

\"\"<\/p>\n

\n

Set cache control header<\/h4>\n<\/div>\n
\n

Default value:<\/strong> Disabled<\/p>\n<\/div>\n

\n

The “Set Cache-Control Header” option in W3 Total Cache empowers you to control the caching directives sent by your server along with web content responses. When enabled, this option allows your server to include a “Cache-Control” header in its responses, specifying directives that govern how the content should be cached, stored, and re-validated by browsers and proxies.<\/p>\n<\/div>\n

\n

How It Works:<\/strong><\/p>\n<\/div>\n

\n
    \n
  1. Server sends resources with Cache-Control headers, providing specific caching instructions.<\/li>\n
  2. Browsers follow these instructions, caching resources accordingly.<\/li>\n
  3. Browsers send conditional requests to the server only when necessary, based on the directives.<\/li>\n
  4. Server responds with updates or validation, ensuring content freshness and efficient caching.<\/li>\n<\/ol>\n

    \"\"<\/p>\n

    \n

    Set entity tag (ETag)<\/h4>\n<\/div>\n
    \n

    Default value:<\/strong> Enabled<\/p>\n<\/div>\n

    \n

    The “Set Entity Tag (ETag)” option in W3 Total Cache provides you with the ability to determine whether your server includes a unique “Entity Tag” in its responses when delivering web content. When this option is activated, the server appends an ETag to its responses, serving as a mechanism for identifying changes in content. Web browsers and proxies leverage this ETag information to determine whether their cached version of the content is still valid or if they need to retrieve a fresh copy. In essence, the Set Entity Tag option plays a crucial role in managing cached content by facilitating a more granular approach to determining when content has been modified. This ensures that users receive the most up-to-date content while minimizing unnecessary data transfers and enhancing overall website responsiveness.<\/p>\n

    It is suggested to enable ETags while Set expires header<\/strong> is active, along with Prevent caching of objects after settings change<\/strong> as these combined will force browsers to reload assets when they are updated. This prevents users from seeing old content after changes are made.<\/p>\n

    \n

    Set W3 Total Cache header<\/h4>\n<\/div>\n
    \n

    Default value:<\/strong> Disabled<\/p>\n<\/div>\n

    \n

    This setting can be used to set an optional HTTP “X-Powered-By” header that websites can include in responses to assist in identifying requests and files optimized by W3 Total Cache. This is useful for troubleshooting as this header can help you identify which files or requests are being cached.<\/p>\n

    Some caching systems and CDNs might use the X-Powered-By header as part of their cache validation process. They might check for changes in the header’s value to determine if a cached version of a resource is still valid or needs to be refreshed. If the header changes, it could signal a change in the underlying software, potentially affecting cached content.<\/p>\n

    \"\"<\/p>\n<\/div>\n

    \n

     <\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

    <\/h4>\n
    \n

    Enable HTTP (gzip) compression<\/h4>\n<\/div>\n
    \n

    Default value:<\/strong> Enabled<\/p>\n<\/div>\n

    \n

    Gzip compression plays a crucial role in enhancing both caching and website performance. When enabled, your server “zips up” HTML, CSS, and JavaScript files before sending them to the user’s browser. This reduces their size by up to 70%, resulting in significantly smaller data transfers. With this option enabled, less data needs to be transferred between the server and the user’s browser, which translates to less strain on your server and improved bandwidth efficiency. This benefit becomes increasingly impactful as your website traffic grows.<\/p>\n<\/div>\n

    \n

    Using a popular blog with frequent content updates as an example, enabling gzip compression could reduce the size of its homepage from 1MB to 300KB. With caching activated, this compressed version gets stored in the browser’s cache. During a return visit, the browser retrieves the cached version instantly, leading to a much faster loading experience compared to downloading the full 1MB version again.<\/p>\n

    \n

    Enable HTTP (brotli) compression<\/h4>\n<\/div>\n
    \n

    Default value:<\/strong> Disabled<\/p>\n<\/div>\n

    \n

    While gzip has long been a staple in performance optimization, Brotli compression is emerging as a cutting-edge partner in caching and speed. Developed by Google, it offers even more impressive compression capabilities, often achieving a 10-20% reduction in file size compared to gzip. This translates to smaller files, faster transfers, and enhanced caching benefits. While Brotli compression is more powerful than gzip, the Brotli compression process is slower making gzip preferable if you host a large amount of dynamic content that cannot be cached.<\/p>\n

    The brotli PHP extension must be installed on your server in order to use this option. If you would like to use this feature and are unable to enable it, reach out to your host for further assistance.<\/p>\n<\/div>\n<\/div>\n

    Prevent caching of objects after settings change<\/h4>\n

    Default value<\/strong>: Disabled<\/p>\n

    The “Prevent caching of objects after settings change” option in W3 Total Cache is designed to ensure that changes to your caching settings take effect immediately. When this option is enabled, any time you make adjustments to your caching configurations, a new query string is generated and added to the objects (like images or stylesheets) on your website. This new query string acts as a signal to servers and browsers that the content has been modified, prompting them to fetch the updated version rather than relying on cached copies.<\/p>\n

    When this feature is enabled, an “Update media query string” button becomes available on your Browser Cache settings page to reset the query string.<\/p>\n

    \"\"<\/p>\n

    Real World Example<\/strong><\/p>\n

    Let’s consider the example URL: https:\/\/example.org\/image.png<\/code><\/p>\n

    Suppose you have the “Prevent caching of objects after settings change” option enabled in W3 Total Cache. Now, if you make changes to your caching settings, such as adjusting compression or expiration times, the plugin will automatically generate a new query string and append it to the object’s URL.<\/p>\n

    Before settings change: https:\/\/example.org\/image.png<\/code><\/p>\n

    After settings change: https:\/\/example.org\/image.png?x25139<\/code><\/p>\n

    In this example, the ?x25139<\/code> is the new query string automatically added after the settings change. Browsers and servers recognize this change, ensuring that when users revisit the site, they fetch the updated image rather than using the previous cached version. This dynamic approach helps in quickly applying and reflecting changes across your website’s content in response to modifications in caching settings.<\/p>\n

    \n

    Remove query strings from static resources<\/h4>\n<\/div>\n
    \n

    Default value:<\/strong> Disabled<\/p>\n<\/div>\n

    \n

    This setting aims to improve website performance and caching efficiency by removing query strings (the extra bits of text added to the end of URLs after a question mark) from static resources like images, CSS, and JavaScript files. When enabled, the setting rewrites URLs of static resources to remove query strings. For example, example.com\/image.jpg?v=123<\/code> becomes example.com\/image.jpg<\/code>.<\/p>\n<\/div>\n

    \n

    Browsers and proxy servers often consider URLs with query strings as unique resources, even if the content is identical. This can lead to unnecessary re-downloads, slowing down page loads. Removing query strings allows these resources to be cached more effectively, reducing the number of requests to the server and improving website performance.<\/p>\n

    \n

    Prevent caching exception list<\/h4>\n<\/div>\n
    \n

    Default value:<\/strong> NULL<\/p>\n<\/div>\n

    \n

    This setting provides granular control over caching behavior by allowing you to specify URLs or URL patterns that should bypass caching. You can add multiple addresses\/patterns by separating each item with a new line. It acts as a safeguard to ensure certain sensitive or dynamic content is always served fresh from the server, even when caching is enabled. When a visitor requests a URL matching an entry on the exception list, the server will handle the request directly, generating a fresh response every time.<\/p>\n<\/div>\n

    \n

    Common Use Cases:<\/strong><\/p>\n<\/div>\n

    \n