When Developing, Does Caching Frustrate You to no End? Check out these 4 Easy Protips!

Here is the ideal order to purge out cache. Not every site will likely be using all of these caching systems, but whichever are in play, this is the highly recommended order to have the most favorable outcome:

1. Site Level: First purge all caching implemented by plugins. A plugin like WP Rocket or Autoptimize would typically create a /wp-content/cache/ folder that you can even manually delete if necessary. Some page builders also utilize this same concept.
2. Server Level: If your web host provides any caching at the server level, then purge that next.
3. Network Level: After purging the above two, then clear any network cache, such as CloudFlare or CDN services.

If you follow that order, you’ll typically have better success in seeing your changes.

Also, if you are manually editing the site files, like PHP, CSS or JS, and you’re uploading those via SFTP or git, then purging the caches are especially important. If you’re not using CSS versioning, then that’s likely where most of the pain comes from.

In rare cases, there could also be local network cache, such as your ISP, VPN, Modem, Router or even your device. These are typically an issue in rural areas or if using obsolete hardware from roughly 5-10+ years ago. Some ISP’s may have very outdated infrastructure.

Chrome, for me, can be especially stubborn at times. Try the site in incognito or use a different browser, like Edge, Firefox or Safari. If possible, try a different device or internet connection. To further rule out the browser cache, you could test on a different device, if possible. Or test in proxy sites, like krpoxy.com or GeoPeeker.com.

When possible, try to disable all the cache when doing long rounds of dev work.

Start with deactivating all your caching/optimizing related plugins while you work. And if your hosting provider has server side cache, see if they’ll allow you to disable it for an extended period of time. Note, not all hosts are friendly with this request. And if there is cache at the DNS level, see what options are available to disable caching on that end.

If you’re worried about the user experience during those times of no cache, it may be worth the sacrifice since it’s only temporary. But if you can’t risk it, then you could try doing your dev work in a staging environment, or locally.

Another thing to consider, if it suits your workflow, is to work on your site locally instead of on the web. You can use localwp.com or use a WAMP/MAMP configuration.

If your site is mostly informational based, with no changes being made by users while in development, then consider taking advantage of having a local copy of the site! When your dev work is complete, then push up your changes to production when ready. Aside from any plugin added cache and possibly browser cache, there is typically no other caching done on your local machine, so this should help with viewing your changes right away!

Then after you publish the new content, you can go pester with the cache on the live site lol, as instructed above.

---

If you found this post was of use to you, please check out my next post about a fairly new WordPress plugin that can diagnose your sites performance quickly, robustly and for free! I believe this new project will catch on soon!

---

I hope this information is clear and helpful. Please don’t hesitate to let me know if you have any questions, concerns or new info I should add to this post. Simply leave a comment below or hit me up on Twitter.