Server and Browser Cache

When updating content on your site, you might not see your changes reflected immediately when viewing the site. The reason for this is most commonly caching. Heavy caching is one of the best ways to speed up your browsing experience. The primary caching layers that may cause issues with content not updating are server and local caching. Typically seeing your changes is as easy as purging both caches.


WP Engine Cache

Our servers employ heavy caching by default. This is part of what makes WP Engine the fastest WordPress website host. When using page caching, the typical flow for the first page request looks something like this:

Many of these steps are saved when you introduce a cached version:

Each layer of caching has its own default expiration times as well.

Page Cache — Stores the dynamically generated version of a page

  • 10 minute expiration

CDN CacheStores static assets on various global servers

  • Optional
  • 365 day static asset cache expiration

GES CacheGlobal Edge Security, partnered with Cloudflare

  • Optional add-on feature
  • 365 day static asset cache expiration
  • Caches based on file extension. Uses all of Cloudflare’s default file extensions, plus mp4.

Object CacheStores results of queries

  • Optional
  • 1MB Buffer

Local Cache — While we do not directly control this cache, it will impact how you see the site

  • All static assets on the WP Engine platform are cached 365 days by default
  • Cache expiration can be adjusted through cache headers

Cache Headers

Cache headers are rules that tell pages and assets how long to cache items locally. This means purging cache impacted by these headers can only be done from each local machine the item is cached on.

Cache-control headers cannot be set lower than 600 – anything lower requires a full cache exclusion rule.

If you want to increase cache expiration on your site to help improve performance/scalability, there are a couple methods of doing this:

Cache headers on static assets can only be adjusted through Nginx. This is true for any header set on a static asset.


Cache Exclusions

There are situations when a page should never be served from cache and the interaction should always be treated as unique, such as during checkout or login. Our servers will respect cache exclusion rules for pages, cookies and arguments.

Certain pages are excluded from server caching by default on all sites to help ensure functionality. Some of these default cache exclusions are:

  • Legacy staging environment
  • WP Admin area
  • wp-login.php
  • Pages named cart, checkout, or check-out
  • Pages where a cookie containing wordpress_ has a value set

If we see WooCommerce on the site we add some extra default exclusions, so you don’t have to worry. We exclude the following pages for WooCommerce sites:

  • /products-compare
  • /coupon
  • /my-account/lost-password
  • /wp-json/wc
  • /wc-api

As well as the arguments:

  • add-to-cart=.+
  • wp-api=.+

And finally, these cookies:

  • woocommerce_items_in_cart=[1-9]+
  • wp_woocommerce_session
  • woocommerce_cart_hash

While we’d added some default exclusions there are still situations you may need custom cache exclusions put in place.

If you’re having issues with a form not submitting, or use a custom checkout URL, you may need to reach out to our support team to have that page excluded from server caching on your site.
At times a plugin or theme may not be carrying data correctly from page to page. If this happens there may need to be a cookie or arg excluded from caching.

NOTE: Caching cannot be fully disabled on your website, or on your website’s homepage, as this will negatively impact your site’s performance.

Partial caching of a page is not possible- a page will either be served from cache, or the page will be generated fresh every time.

When setting cache exclusions, you should be as specific as possible. Too many pages excluded from cache by a cache exclusion rule will impact performance. We reserve the right to remove cache exclusion that are negatively impacting server performance.

NOTE: Nothing can be excluded from object cache.


Purge Server Caches

Extensive caching can complicate things if you’re working on your site and expecting to see changes immediately on the frontend. Purging cache is an essential part of the development process.

Purge Page, CDN, and Object Cache

  1. Log in to your website’s wp-admin dashboard
  2. Click on the WP Engine plugin tab
  3. Scroll down, click Purge All Caches 

Purge Page Cache Only

If you cannot access your site’s wp-admin area you may use this alternate method. This is not the recommended method typically, as it purges only the page cache and not object or CDN caches. However, it can help if you are unable to access the wp-admin dashboard area of your site.

  1. Log in to the User Portal
  2. Locate the environment name
  3. Click the 3 dot ... Quick Actions menu to the right of the environment
  1. Click Clear Cache

Alternatively, you can select the environment name from the Sites page, then click Utilities to locate the Clear page cache option displayed above.

Using the WP Engine API

The customer API can be leveraged to purge cache by making a POST request to the /installs/{install_id}/purge_cache endpoint. Learn how to enable the API and check out our API documentation.


Purge Page Cache for One URL

In most cases, caches for the entire site must be purged. However, there are cases where you want to only purge server cache for a single URL or post ID. For example, if you’ve made changes to a single product page during a high traffic sale period then you may not want to purge all caches and risk an impact performance.

Fortunately there are several ways to purge single page cache on WP Engine, using our Advanced Cache plugin or by using PHP code.

WP Engine Advanced Cache Plugin

  1. Log in to the wp-admin dashboard of your site
  2. Select Plugins
  3. Click Add New
  4. Search for WP Engine Advanced Cache
  5. Install and Activate this plugin
  6. Select Tools
  7. Click Cache Settings
  8. Locate the field labelled Purge Single Post or Purge Path
    1. Purge Single Post
      • Enter the ID of a post or a page
      • Click Purge Post
    2. Purge Path
      • Enter the URL for the single page you’d like to purge server caches for
        • Must be the full URL including protocol, meaning with http:// or https://
  9. Click Verify URL
    • If the URL is not valid you cannot purge the path. Be sure to copy it exactly from your browser’s address bar.
  10. Click Purge Path

Purge Cache with PHP

Through the WP Engine MU plugin there is a function called purge_varnish_cache(). The post ID you want to purge can be passed into this function. Varnish page cache is purged only for that post URL, and not for the entire domain. This can have a positive impact on a website’s performance by keeping all other pages stored in cached.

If purge_varnish_cache() is called without being passed a post ID, then Varnish will be purged for the entire domain.

This function can be built into your PHP code, if you so choose.


Purge Global Edge Security (GES) Cache

Global Edge Security server caches can only be purged with the following steps.

  1. Log in to the User Portal
  2. Click on the environment name you wish to purge GES caches for
  3. Click Domains
  4. Locate the domain you’d like to purge the GES zone for
  5. Click the 3 dot menu to the right of this domain
  6. Select Clear GES Cache


Purge Browser Cache

Your browser may cache items such as: css styles, cookies and sessions, auth boxes, DNS/IP Addresses, and permalinks. Browser cache generally respects the cache-control headers sent back with the request from the web server.

Meaning if someone requests the /about-me/ page on your site and it has a cache-control time of 10 minutes/600 seconds, the page is not only cached on our server, it’s also cached in the browser for that amount of time.

For static assets, which have long-cache expiration times (images, css, etc), this means the browser will also cache them for the time specified by the server when sending the request back. The default cache expiration for static assets on WP Engine is 365 days.

Most browsers respect ctrl + F5 for a hard-refresh, which reloads the page and ignores any existing browser cache.

NOTE: Browser cache can only be purged for your own machine. There is no way to force other visitors to purge their browser cache.


Purge Common Theme or Plugin Cache

Plugins and themes will often cache content as well, which can cause old data to be stored and served. We’ve gathered some common plugins with cache below as an example:

  • Autoptimize
  • WP Minify
  • WP Super Cache
  • Fast Velocity Minify

We also recommend checking out our guide with the team at Flywheel for more information on clearing theme cache.


Still Not Seeing Your Changes?

  • Check your site for caching or compression plugins and purge their cache.
  • Are you using Cloudflare? Login and purge Cloudflare cache.
    • We also suggest installing the Cloudflare plugin to easily purge Cloudflare cache from your wp-admin dashboard.
  • Are you using a firewall service, like Sucuri? Log in to their portal and purge caches.
  • Are you using a highly customized .htaccess? Try using a default .htaccess file instead.
  • Check the page in a proxy, like GeoPeeker or kproxy, to see how it looks in other locations.
  • DNS caching could be at play as well. This easiest way to purge this is simply by restarting your computer or device. Otherwise, you can try flushing your DNS manually.

If you’re still not seeing your updated content, just open a Live Chat (available 24/7) with our Support Team from within your User Portal, and we will gladly help troubleshoot further.


Cache Busting

If you’d like to see an updated version of a specific page, but don’t want to clear caches for their whole website, you can manually “bust cache” locally, by adding an argument onto the end of the URL.

EX: To see a newly generated version of http://somedomain.com/updated-page/ you could go to http://somedomain.com/updated-page/?somearg1 to force the page to be generated new from the server.

Once it’s loaded, the URL is cached on the server again. Meaning simply reloading the URL will show the same cached version. If you want a new version each time you must change the arg value each reload:

This will only address WP Engine server cache because our server sees the change in URL as a completely different page. Your local browser, caching plugins, and some firewall or proxy service could still see this as the same page and serve from their cache.


Testing Cache

A cURL can tell you quite a bit about where the URL may be getting cached. You can curl from your terminal or with a tool like Online Curl.

You may have to cURL a page a few times in a row to generate cached hits.

This page can be cached but it is the first time it’s been generated by the server, so this specific hit was not served from cache:

This page is cached and this version is served from cache. It is the first time this page has been served from cached.


NEXT STEP: Learn how PHP sessions and cookies work on WP Engine

Still need help? Contact support!

We offer support 24 hours a day, 7 days a week, 365 days a year. Log in to your account to get expert one-on-one help.

The best in WordPress hosting.

See why more customers prefer WP Engine over the competition.