Refund Policy

If you cache your WordPress install, you can effectively speed up your site. But, without the proper setup, the cache won’t work optimally, and it could lead to miss penalties.

These are delays in serving up your website’s content, slowing down your page load times.

This is where knowing the difference between a cache miss and a cache hit can help you understand how your caching system should be organized for maximum performance.

Today, I’ll share more detail on cache misses, cache hits, the difference between them as well as miss penalties, and how to reduce them to speed up your WordPress website’s page load times with caching.

What is Caching?

Before diving into the details of what a cache hit and a cache miss are, it’s imperative to know a bit about caching and how it works.

In terms of your WordPress website, caching refers to saving your site’s content to what’s called a cache.

When you set up a cache to work with your site, it memorizes your content when it loads and creates a static version of it. That way, the next time your site loads, it can quickly retrieve that content from memory and effectively load your site faster.

You can check out Caching for WordPress, Explained in Plain English, for details.

Caching and Memory

Similar to a computer’s memory, a cache is a compact, fast-performing memory. It stores data in a hierarchy of levels, starting at level one and progressing sequentially. They are labeled as L1, L2, L3, and so on.

A cache is further partitioned into blocks, which can also be called lines. When a page of your site first loads, data is transferred and written into the cache. On each subsequent page load, the cache is read, so content is transferred and loaded on the page.

A cache also gets written to if the site requests it, such as when there has been an update to the page and new content needs to be saved to the cache, replacing the older content that was saved.

Whether the cache is read or written, it’s done one block at a time.

Each block also has a tag that includes the location where the data was stored in the cache.

When data is requested from the cache, a search occurs through the tags to find the specific content that’s needed in level one (L1) of the memory. If the correct data isn’t found, more searches are conducted in L2.

If the data isn’t found there, searches are continued in L3, then L4, and so on until it has been found. Then, it’s read and loaded onto the page. If the data isn’t found in the cache at all, then it’s written into it for quick retrieval the next time the page is loaded.

The faster the data is found in the cache, the faster it can load on the corresponding page. If searches are conducted past L1, the slower the loading times. Also, for each level that’s accessed for the data, the more time it takes to retrieve it, which means the slower the page loads.

So, that means data transferred from L2 is slower than data retrieved from L1, but data from L4 creates much slower loading times than if it was read from L1, or L2.

A cache hit and a cache miss has to do with this process and if the data was read from the cache.

What is a Cache Hit?

A cache hit describes the situation where your site’s content is successfully served from the cache.

The tags are searched in the memory rapidly, and when the data is found and read, it’s considered as a cache hit.

A cache hit is when content is successfully served from the cache instead of the server.

Cold, Warm, and Hot Caches

A cache hit can also be described as cold, warm, or hot. In each of these, the speed at which the data is read is described.

A hot cache is an instance where data was read from the memory at the fastest possible rate. This happens when the data is retrieved from L1.

A cold cache is the slowest possible rate for data to be read, though, it’s still successful so it’s still considered a cache hit. The data is just found lower in the memory hierarchy such as in L3, or lower.

A warm cache is used to describe data that’s found in L2 or L3. It’s not as fast as a hot cache, but it’s still faster than a cold cache. Generally, calling a cache warm is used to express that it’s slower and closer to a cold cache than a hot one.

What is a Cache Miss?

A cache miss refers to the instance when the memory is searched and the data isn’t found. When this happens, the content is transferred and written into the cache.

The Difference Between a Cache Miss and Cache Hit

Now that both cache hit and cache miss have been defined, it may be clearer to see the main difference between the two: With a cache hit, data has been found in the cache, but the opposite is true for a cache miss.

If you want to learn more, check out our article on What are Hit and Miss Ratios? Learn how to calculate them!

Miss Penalties and Reducing Them

As mentioned earlier, when the cache is searched for the relevant content, it passes through L1, then L2, L3, and so forth.

For each level that’s searched, the more time it takes, which means the slower the web page loads.

This delay is known as a miss penalty. When your site experiences miss penalties, it kind of defeats the purpose of having a cache since their primary purpose is to speed up your page load times.

So, these delays are definitely best be avoided as much as possible. While you won’t be able to escape miss penalties altogether, you can reduce them.

Cutting down on the delays in getting your pages to load is certainly recommended for optimal performance.

How to Reduce Miss Penalties

As previously explained, a cache miss occurs when data is requested from the cache, and it’s not found. Then, the data is copied into the cache for later use.

The more cache misses you have piled up, the more data that has to be written into the memory. That means that if you’re able to reduce the amount of times that your content has to be saved to the cache, you’re able to reduce the amount of cache misses your site experiences.

You can do this by setting an expiry date to the lifespan of the cache.

A cache lifespan is the amount of time that data is stored in the cache before it’s purged, and your site is cached again.

If you set a low expiry, the cache is cleared more often leading to an increase in cache misses. If you set the expiry to a higher time, the cache is purged less often resulting in fewer cache misses.

It may be important to note that not every site can confidently set higher expiry times. If site content is updated frequently, then lower expiry times are necessary to continuously display updated content to end users.

Generally speaking, you should set the expiry time to reflect when your site is typically updated.

For example, if you rarely update your site, you can safely set a higher expiry time of 14 days or longer.

On the other hand, if you update your site a couple times a week, you should set your cache’s lifespan to expire in seven days at the absolute most. A daily or twice daily cache expiry would be more suitable.

If your site is constantly being updated such as with comments being posted every few minutes, then your expiry time should be set much lower such as one hour, or less.

At the same time, if you’re unsure of when your cache lifespan should expire, setting it to 10 hours is a good starting point. If you find your cache isn’t running optimally, you can adjust it as needed from there.

A Cache 22

It’s crucial to mention that it may not always be practical to set your cache’s lifespan to more than 10 hours. Otherwise, your site could break.

If you use plugins and themes that require the use of nonces, your expiry should be set to no more than 12 hours, though, 10 hours or less is ideal.

Nonces are used to validate a request to verify it’s coming from the intended souce. It helps prevent hackers from being able to disguise themselves as the user to execute actions as if they were the user such as in a Cross-Site Request Forgery (CSRF) attack.

Depending on when the nonces expire, the page could be cached long after the nonces are gone, breaking your site, and leaving it vulnerable.

While setting cache lifespan expiries higher can reduce miss penalties, it shouldn’t be done if you have plugins or themes that rely on nonces.

It’s a real catch 22.

Fortunately, there are other ways to reduce miss penalties such as optimizing your site in other ways including minifying your HTML, CSS, and JavaScript files, enabling CDN caching, enabling LazyLoad for images, and more.

For details, check out Nonces and Cache Lifespan.

Reducing Miss Penalties with WP Rocket

You can set the expiry of your cache lifespan to reduce cache misses with WP Rocket.

Once installed, go to Settings > WP Rocket. Then, click on the Cache tab in the menu that appears on the page.

In the last section, Cache Lifespan, you can set the expiry time by typing a number into the first field. Then, select either minutes, hours, or days in the adjacent drop down box.

Wrapping Up

Understanding what a cache miss and cache hit are as well as the difference between them will go a long way in helping you know how to optimize your site’s cache.

Try WP Rocket now, so you can diminish cache misses to enhance your site’s performance, and reduce page load times

Trying to figure out the difference between browser cache vs cookies?

Both of these technologies are a way to store data from your website on a visitor’s local device, but they both store different types of information and are used for different things.

In this post, we’ll set the stage by explaining what “browser cache” and “cookies” actually are. Then, we’ll dig into the difference between the two, as well as what you should use each for.

What is the Browser Cache?

In general terms, “caching” something means temporarily storing it in a spot that makes for easier/faster retrieval.

There are a lot of different ways that you can cache your WordPress website, but we’re obviously focused on one specific implementation – the browser cache.

Let’s start at the beginning – your site has a lot of static files that won’t change visit-to-visit. One common example is your site’s logo. You probably won’t change your logo that often, and your logo is likely the same on all or most of your site.

So let’s say a visitor views three separate pages on your site – it would be a waste to force that visitor to download the exact same logo file three times in a row, right?

The browser cache lets you avoid that situation by storing these static files on a visitor’s local computer. So with the browser cache, it would work like this instead:

• First visit – the visitor’s browser downloads the logo file from your server and saves it locally in the browser cache.
• Second and third visits – the visitor’s browser loads the logo from the visitor’s local storage (the browser cache), instead of downloading the logo again.

And as a result, your website loads faster, which is a great thing.

To control how long a visitor’s browser stores certain types of files, you can set expiration dates. For example, you can tell a visitor’s browser “store all JPEG images for 4 months, but only store MP4 videos for 1 month”.

Additionally, if you do need to change a file before the expiration is up (like your logo), you can employ a technique called cache busting to force visitors’ browsers to download the most recent version of a file.

Because browser caching is a great performance tip, WP Rocket automatically adds browser caching to your WordPress site as soon as you activate the WP Rocket plugin. You can learn more about this feature here.

What is a Cookie?

According to the dictionary, a cookie is a “small sweet cake, typically round, fl”…wait, that doesn’t sound right.

Let’s try again…

A cookie is a small file that’s stored on a visitor’s device and contains data specific to a particular client. “Client”, in this case, just means the device of the person who’s visiting.

Cookies help you store useful information about a visitor, like their login information/authentication so that they don’t have to manually log in each time, or the items in their shopping cart. Or, you can also use cookies to track and identify visitors, even between different website visits.

Cookies are only used to store text-based data, like IP addresses, session IDs, visit histories, etc. – you can’t use them to store an image, as the browser cache allows for.

Additionally, unlike a browser cache, which is a one-way transfer (from the server to the local cache), a client’s web browser will send the cookie to your web server on each visit – so the information can go from both:

• Server → client
• Client → server

There are two types of cookies:

• Persistent cookie – though this type of cookie has an expiration date, it stays on a visitor’s local machine while active and “persists” between visits to your website. It lets you identify a visitor even if they leave your site and come back.
• Session cookie – this type of cookie is stored in memory and never saved to your visitor’s local machine. It’s active during a visit, but as soon as your visitor closes their browser, a session cookie is permanently gone.

Browser Cache vs Cookies: What Are They Used For?

At this point, you probably have some idea about the difference in use between the browser cache vs cookies, but let’s cover the point in a little more detail to make sure.

Browser cache lets you store certain static files – including images, videos, CSS/JavaScript, etc. This is a one-way relationship – those files don’t communicate back to your server once they’re stored. Additionally, the browser cache doesn’t identify specific users – it treats all users the same.

The browser cache helps you speed up your site and lessen the load on your server – that’s all it’s used for.

Cookies are small text-based files that let you track, identify, or otherwise store information that’s unique to each visitor. This is a two-way relationship, where your server is able to read the information from the cookie.

Cookies help you provide a better user experience, like recognizing that a user is logged-in or identifying a visitor to show them the items in their shopping cart at an eCommerce store.

Or, cookies can help you track and identify specific visitors, like setting a cookie so that you don’t display an email opt-in popup after a visitor has already subscribed to your email list.

Finally, you can even use cookies to help with off-site functionality. For example, setting a retargeting cookie so that you can display ads to your site’s visitors even when they’re on other sites.

Browser Cache and Cookies in WP Rocket

If you’re a WP Rocket user, WP Rocket gives you ways to work with both the browser cache and cookies on your WordPress site.

First, as you learned above, WP Rocket automatically activates browser caching as soon as you activate the plugin. So if you’re using WP Rocket, your WordPress site is already benefiting from the performance-boosting effects of browser caching.

Second, WP Rocket lets you change your site’s page caching behavior based on cookies. In the Advanced Rules section, you can specify certain cookies to never serve cached content to:

Summing Up

Both browser caching and cookies let your store information on a visitor’s computer. However, they do it in different ways and have different purposes.

Browser caching helps you speed up your site, while cookies help you store information about specific users to identify or track them.

Do you have any questions about the best ways to use these two technologies? Ask away in the comments!

Caching is crucial for WordPress. It’s one of the primary ways to make WordPress sites load as fast as possible. Caching is what WP Rocket excels at. However, it’s not that easy to cache highly dynamic WordPress sites, especially those that display personalized pages to every user. But it’s possible to cache dynamic content with the right techniques and technology.

In this article you’ll learn what’s dynamic content, how dynamic content caching works, its various benefits, and the multiple ways you can implement it across different server configurations.

Let’s get started!

Static Content vs Dynamic Content

Static content remains the same on webpages for all users. The website owner can update it, but after that the new content will still be static for all users. Static content includes files such as HTML, CSS, JavaScript, images, and videos.

An example of static content is this very blog post you’re reading. Since static content doesn’t often change (or not at all), caching and delivering it is super easy.

Dynamic content isn’t the same on webpages for all users. It’s customized to every user based on several factors such as location, device, time of day, user profile settings, etc. Dynamic webpages can also change on-the-fly based on user input. This makes websites more interactive, engaging, and personalized for every user.

An example of dynamic content is your social media feed or shopping cart. Since it’s unique for every user, caching and delivering it is not that simple. 

Most modern websites are dynamic to some extent. They use server-side scripts to generate all the assets required for rendering a webpage. The browser compiles these assets to show unique, personalized content to every user.

Dynamic Content vs Event-Driven Content 

There’s also content that falls between static and dynamic content. It’s referred to as “Event-Driven Content” by some industry professionals.

A few examples of event-driven content include:

• Stock prices change rapidly while the markets are open and then remain static after the markets close.
• Comments on an old news article (it doesn’t attract much attention) versus a new trending story (it attracts tons of comments).
• If a news website is serving personalized content to users based on their locations, for many users from the same location, the content is static, but it’s dynamic if the users are from unique areas.

Since you cannot predict with certainty whether a particular content is event-driven or dynamic, most event-driven content is classified as dynamic content. 

To keep things simple, I will treat event-driven content as dynamic content in this article. Once you’ve understood how dynamic content caching works, you can explore this topic further.

How Does Dynamic Content Caching Work in WordPress?

Most WordPress sites are simple blogs or small business sites. The content on these sites is usually static.

As WordPress is a CMS that uses PHP scripts and database queries to generate all the site pages dynamically, each incoming request generates a new response from the server. Such responses aren’t necessary for most websites as it leads to a server crunch when the traffic shoots upwards.

A cache can store these page outputs the first time they’re generated, so that it can serve subsequent requests from the cache instead of from the server. This speeds up page load significantly.

While this works perfectly for static content, since dynamic content is unique for each user, you cannot cache it using regular caching techniques.

In the good ol’ days, caching dynamic content was next to impossible. Even today, most CDNs only cache static content by default.

But newer technologies have made it possible to serve dynamic content from a cache easily, significantly reducing the TTFB of such pages while still keeping the user experience great.

CDNs are one of the best ways to cache static content and deliver it swiftly to the end-user, but they can also serve dynamic content. One way CDNs “cache” dynamic content is by running scripts in a server closest to the user, rather than in the distant origin server. 

Thus, CDNs generate and deliver all the dynamic content from their edge servers. This speeds up the load time of dynamic web pages.

CDNs can also use a markup language called Edge Side Includes (ESI) to cache dynamic content. You can insert ESI element tags into the page HTML to show which elements are dynamic. This helps the edge-side processors (a CDN or an origin server) to cache only the static parts of a dynamic webpage.

HTTP reverse proxies like Varnish, NGINX, and IIS are another way to cache dynamic content. Some of them like NGINX and IIS also act as a primary web server.

Typically, a reverse proxy is a server (physical or virtual) placed between the client and the web server. Its primary purpose is to filter all the requests before they reach the site.

Varnish not only handles all inbound requests before they land on the server, it also caches all the server responses. By default, the Varnish cache refreshes every two minutes, but you can set it to whatever time you want. This is how Varnish helps with caching dynamic content.

Varnish stores its cache in server memory, making retrieving and delivering responses to clients much faster. For a detailed explanation, read WP Rocket’s article on HTTP reverse proxies. You can also watch this educational video to get a better understanding of how Varnish works.

Let’s move on to see how you can cache dynamic content through different means. 

Caching Dynamic Content on a CDN

The exact method to cache dynamic content using a CDN varies from one platform to another, but they’re all based on a set of technologies called Dynamic Site Acceleration (DSA).

For instance, if you’re using Cloudflare CDN, you can use Cloudflare Workers to set up serverless JavaScript functions that run on CDN PoPs placed all around the world.

You can use these custom serverless functions to modify your site’s HTTP requests and responses, generate new responses, and make parallel requests. Cloudflare Workers can help your site perform a variety of tasks based on multiple parameters such as user input, device type, location, time of day, third party APIs, etc. 

Thus, you can generate dynamic content from the CDN itself and then serve it to clients. You can also combine serverless functions with ESI tags to make this process even more efficient. 

To implement edge caching on your site easily, you can use the free Cloudflare Page Cache plugin. Going into further details is beyond this article’s purpose, but you can check out the official Cloudflare Workers docs to get started.

Likewise, KeyCDN provides two options to cache dynamic content. The first method is to use KeyCDN’s API to instantly purge the CDN cache based on user actions so that your users will always see the latest dynamic content.

The second option suggested by KeyCDN involves modifying Cache-Control headers to direct a client how and when to cache responses, and for how long. You can view an example in KeyCDN API docs to get a better understanding of how it’s deployed.

Fastly CDN’s API also provides features like instant cache purging, real-time logging and availability, and mechanisms such as Origin Shield. You can check out a few examples of how Fastly users have cached dynamic content using CDN: “How to cache with tracking cookies” and “API caching.”

Most of the top CDNs offer multiple ways to cache dynamic content. If you’re using or planning to use any of the CDNs mentioned above, the resources I’ve linked above will come in handy. If it’s any other CDN, then I suggest you to explore their docs or get in touch with their support team.

Further Reading: Refer to WP Rocket’s docs to learn more about how you can integrate various popular CDNs with WP Rocket. 

Caching Dynamic Content Using NGINX

There are many plugins and techniques to cache dynamic content generated by WordPress sites running on an NGINX server. The most recommended solution is to use FastCGI, which is an improved variation of the Common Gateway Interface (CGI) protocol.

FastCGI improves site performance by not opening a separate process for each incoming request. Any server that processes requests to generate dynamic content, like NGINX running WordPress, can benefit greatly from it.

As covered in WP Rocket’s NGINX FastCGI Caching for WordPress tutorial, getting started with it is super easy. The NGINX web server provides a native FastCGI module to help you set it up in minutes.

FastCGI eliminates the need to set up extra caching solutions like WordPress plugins and reverse proxies (e.g. Varnish) for most sites. 

NGINX’s ngx_http_fastcgi_module module allows the main web server to pass incoming requests to the FastCGI server. As with all NGINX modules, FastCGI is controlled by various directives you specify in its configuration file. 

Typically, the virtual host file to configure NGINX is found in the /etc/nginx/sites-available/domain.com directory, where domain.com is the name of your domain name (e.g. salmanravoof.com, www-staging.wp-rocket.me). 

sudo nano /etc/nginx/sites-available/domain.com

This will open the configuration file in the Nano text editor within your Linux terminal. Next, add the following NGINX directives before the server{} block inside your config file.

fastcgi_cache_path /var/run/nginx-fastcgi-cache levels=1:2 keys_zone=WPROCKET:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_cache_use_stale error timeout invalid_header http_500;
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;

Here’s a line-by-line breakdown of the directives used above:

• fastcgi_cache_path: This specifies the cache’s location, size, subdirectory levels, key_zone name, and the inactive duration. The cache’s location can be anywhere on the server. Since it’s faster to serve files from the RAM, I’ve used the /var/run folder as Ubuntu mounts this directory as tmpfs (a fast volatile memory).
• fastcgi_cache_key: This directs the FastCGI module on how to encrypt the cache files by generating unique key names. 
• fastcgi_cache_use_stale: This instructs NGINX to continue serving old (stale) page cache even if PHP crashes (and by extension WordPress). This is one of the many strengths of NGINX web servers.
• fastcgi_ignore_headers: This directive tells the FastCGI server not to process specific response header fields.

The above directives along with the default NGINX ones will enable caching for your entire site. But the current configuration isn’t ideal for serving a dynamic content site yet. 

Now, you need to direct NGINX not to cache certain pages. To do that, just add the following conditional directives before the first location{} block within your server{} block. 

set $skip_cache 0;
    # POST requests and URLs with query strings won't be cached
    if ($request_method = POST) {
        set $skip_cache 1;
    }   
    if ($query_string != "") {
        set $skip_cache 1;
    }   
    # URIs containing the following segments won't be cached
    if ($request_uri ~*  "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap(_index)?.xml") {
        set $skip_cache 1;
    }   
    # Don't serve cache for logged-in users or recent commentators
    if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
        set $skip_cache 1;
    }

The above directives will instruct NGINX to skip serving cached content for POST requests, URL requests with query strings attached to them, admin screens, pages for logged-in users, and a few other pages. 
Next, add the following directives within the PHP location{} block.

fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
fastcgi_cache WPROCKET;
fastcgi_cache_valid 60m;
add_header X-FastCGI-Cache $upstream_cache_status;

The fastcgi_cache_bypass directive defines when the server’s cache will be skipped, while the fastcgi_no_cache directive specifies the conditions when no server response will be saved to the cache.

The value under fastcgi_cache directive should match the keys_zone value you set before. In my case it’s WPROCKET. 

You can also specify how long the FastCGI cache is valid for. The default value is set to 60 minutes. It’s a decent duration for most sites. You can change it to whatever duration you want though. 

If you modify the value of fastcgi_cache_valid and set it to some other duration, then it’s an excellent idea to update the value of the inactive parameter too. You defined it earlier inside the fastcgi_cache_path directive. 

The inactive parameter specifies the max time the server allows any cached data to persist in its memory without being called. If it’s not accessed within the specified timeframe, the server will remove the cache.

The last line adds the X-FastCGI-Cache header to your server’s HTTP responses. You can use it to validate whether requests to your website are being served from FastCGI cache or not.

Once you’re happy with the configuration, save the file, exit the editor, and then restart NGINX.

sudo service nginx restart 

The last step to configure NGINX to work with your WordPress site is to install the free Nginx Cache plugin by Till Krüss. After activating the plugin, go to Tools > Nginx panel in your WordPress dashboard and set the Cache Zone Path. It should be the same as the one you defined in your NGINX hosts file earlier.

You can also enable automatic purging of NGINX cache in the same settings panel. Every time you modify any content on your site, it’ll automatically purge the NGINX cache. 

The Nginx Cache plugin also lets you purge the cache manually through its settings page and the admin bar. Nginx Helper is another great plugin that you can install to automate many other NGINX features. 

Now that you’ve learned how to cache pages selectively on your WordPress site, you can apply the same logic to specify custom FastCGI cache rules for dynamic WordPress sites  built with WooCommerce, BuddyPress, or Easy Digital Downloads.

For example, if you have an ecommerce site that runs on WooCommerce, you shouldn’t cache user account, shopping cart, or checkout pages as they’re unique for each user. To address this issue, you can set up additional cache exclusions by extending the conditional directives you used earlier.

if ($request_uri ~* "/(cart|checkout|my-account)/*$") {
    set $skip_cache 1;
}

You need to paste the above conditional directive in the same location where you entered them earlier. 

This code snippet instructs NGINX not to cache WooCommerce’s default pages such as  Cart, Checkout, and My Account pages. You can also use regex expressions to append even more pages to the cache exclusion list.

You should note that cache still doesn’t work for logged-in users as they’re shown highly personalized pages. To cache pages accessed by logged-in users, you can selectively cache all the static elements of a dynamic webpage by using an advanced technique called fragment caching. While it’s fairly complex, it’s worth checking out. 

Most WordPress plugins that create highly dynamic pages should have extensive documentation on how to exclude their dynamic pages from caching. WP Rocket plays well with NGINX servers after a few simple tweaks. Refer to the NGINX Configuration for WP Rocket for more information.

Caching Dynamic Content Using Varnish

Varnish is one of the most popular HTTP accelerators and reverse proxies in use today. It’s focused exclusively on HTTP and designed to speed up content-heavy dynamic websites. 

Varnish Cache uses a domain-specific configuration language called Varnish Configuration Language (VCL). If you’re familiar with C programming language, you’ll find VCL to be similar. It’s a highly flexible language that gives you the independence to test and implement Varnish the way you want.

For instance, if you want Varnish Cache to ignore AJAX requests, here’s how you implement it:

if (req.http.X-Requested-With == "XMLHttpRequest") {
    return(pass);
}

Similarly, if you want to instruct Varnish Cache to skip caching WordPress admin screens and edit pages, you need to add the following VCL code snippet to your config file.

if (req.url ~ "(wp-admin|post\.php|edit\.php|wp-login)") {
    return(pass);
}
if (req.url ~ "/wp-cron.php" || req.url ~ "preview=true") {
    return (pass);
}

Let’s get started with Varnishing your WordPress site!

If your web server runs on Ubuntu, here’s a quick guide to install and configure Varnish. Alternately, you can also go through this step-by-step tutorial to enable Varnish Cache on your WordPress site. 

Once you’ve set up your server to use Varnish to cache content, you can then direct WordPress to take care of the rest. WordPress sites with mostly static content won’t need much tweaking. There are a lot of helper plugins to aid you with optimizing your Varnish Cache configuration even more. Here are some of my favorites: 

• Proxy Cache Purge

Every time you modify a post or page on your website, Proxy Cache Purge will automatically send a PURGE request on behalf of the URL. For example, when you edit, publish, or delete a post, Proxy Cache Purge will purge its old cache automatically. The same applies for commenting on a post or changing your site’s theme. 

You can modify your Varnish Cache’s configuration to skip certain pages from being cached.

• WPBase Cache

WPBase Cache is a specialist plugin that optimizes WordPress deployment on a server stack comprising varnish + nginx + php-fpm + php-apc. It uses three types of cache to supercharge your website: full page cache, db cache, and opcode cache. 

This plugin also integrates code from nginx-compatibility and db-cache-reloaded-fix helper plugins. They’re fixes for nginx and database cache respectively.  

WPBase Cache also supports configuring Varnish Cache with the provided default.vcl file. You can learn more about WPBase Cache’s features and benefits on its website.

• WP Rocket + Varnish Add-on

WP Rocket’s Varnish add-on allows you to purge both Varnish and WP Rocket’s cache at the same time. Apart from enabling interoperability without causing any conflicts, the add-on will also ensure that the content served to your users is always up-to-date.

With the Varnish add-on installed, you can relax knowing that both Varnish and WP Rocket are compatible with each other and can work together. For more information, refer to WP Rocket’s documentation on Varnish add-on.

We’ve finished setting up Varnish Cache to cache and serve static content. But what about caching dynamic content? The solution is to use Varnish Modules (VMODs) to extend the features of Varnish Cache.

Varnish 6.0’s new XBody and Edgestash VMODs allow you to cache and accelerate dynamic content with ease. 

The XBody VMOD picks up all the dynamic content from the webpage and parses it into JSON data-interchange format and a Mustache web template. 

Later, the Edgestash VMOD picks up both the JSON data and the Mustache template, and then recombines them back into a new response. You can check out Varnish Software’s docs on personalized caching to learn  more about how it’s done. 

Caching Dynamic Content Using WP Rocket

Advanced caching plugins like WP Rocket can intelligently sense which assets are static or dynamic and cache only the static content. It also updates the cache automatically whenever any static content is updated.

WP Rocket also disables caching by default for dynamic pages such as cart, checkout, user profiles, etc. It also allows you to disable caching manually for pages.

If you have pages with a lot of static content and a few dynamic elements, then you can still cache those pages by serving the dynamic elements via JavaScript / AJAX. Since JS runs on the client-side (or browser), the dynamic elements will get updated on the cached page served to the user.

You can read this step-by-step AJAX tutorial to learn how you can dynamically update content on your WordPress website.

You can also use WP Rocket to cache pages with dynamic content. WooCommerce also provides an effortless way to ajaxify your cart viewer by adding a simple code snippet.

Wrapping Up

Caching isn’t just for static or event-driven sites anymore. You’ve seen many options above to cache highly dynamic WordPress sites. While it requires some configuration and tweaks initially, the final result is worth the effort. Dynamic content caching helps you to improve your site’s Time to First Byte (TTFB), reduce your hosting costs, achieve better SEO, and increase your conversion rates.

By expanding your cache to include dynamic content too, you can have a dramatic effect on your site’s performance. It’ll also ensure that your users receive the latest up-to-date information swiftly. 

And if you want to go further, WP Rocket works out-of-the-box with most of the server-level caching solutions discussed in this article. It’s time to supercharge your website with WP Rocket now!