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 extensive 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 cache expiration
Network Caches — Includes CDN and advanced network caches:
- CDN Cache — Stores static assets on various global servers
- CDN is a free optional feature
- 365 day static asset cache expiration
- Advanced Network Cache — DNS-level cache, powered by Cloudflare
- Advanced network is a free optional feature
- 365 day static asset cache expiration
- GES Cache — Global Edge Security, partnered with Cloudflare
- GES is an optional add-on feature with a monthly cost
- 365 day static asset cache expiration
- Caches based on file extension. Uses all of Cloudflare’s default file extensions, plus mp4.
Object Cache — Stores results of queries
- Object cache an optional feature
- No cache expiration
- 1MB buffer size, data is stored based on what was request most recently
Browser Cache — Stores assets in a user’s local browser
- All static assets on the WP Engine platform are cached 365 days by default
- Cache expiration can be adjusted through 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:
- Use WP Engine Advanced Cache plugin
- Extend Cache Expiration in .htaccess
- Extend Cache Expiration in Nginx (must contact Support)
Cache headers on static assets can only be adjusted through Nginx by contacting Support. This is true for any header set on a static asset.
To learn more about testing and adjusting cache headers see the full guide.
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
- Pages named
- 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:
As well as the arguments:
And finally, these cookies:
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. There are two different methods to trigger the purge cache functionality.
Purging cache through the User Portal is considered the recommended method because it does not require access to the wp-admin of your website and allows you to purge individual caches, page and object cache.
- Log in to the User Portal
- Click the environment name
- Select Caching
- You will see the following options:
- Clear All Caches – This button clears page cache, network caches, and and object cache. Your website will be slower for a period of time until the pages become newly cached.
- Clear Page cache – Clears only the dynamically generated version of your pages (Varnish caching).
- Clear Network caches – Purges the global caches for CDN, and advanced network. This option displays only if you are using one of these features and have added a domain. GES cache is not purged, it must be purged from the Domains page.
- Clear object cache – If enabled, clears stored query results.
NOTE: You may still need to purge browser caches, which is done locally, to see your changes appear.
Cache can be purged from the wp-admin dashboard of your website. This method will purge page cache, CDN cache. Advanced network cache and GES cache can only be purged through the User Portal.
- Log in to your website’s wp-admin dashboard
- Click on the WP Engine plugin tab
- Scroll down, click Purge All Caches
WP Engine API
This leverages the same cache purge functionality as the wp-admin button, meaning this method will purge page cache, CDN cache, object cache. Currently advanced network cache and GES cache can only be purged through the User Portal.
Purge Cache with PHP
Through the WP Engine MU plugin there is a function called
wpecommon::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.
wpecommon::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 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 or cmd + 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:
- WP Minify
- WP Super Cache
- Fast Velocity Minify
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.
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.
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.