Web developers love to blame all sorts of things on caching issues. One reason we do that is that most all web users don’t fully understand what a cache is, so it buys us some time to diagnose the real problem… But sometimes, it really is the cache’s fault! So, what the heck is a website cache, why do we use them, and how do you fix it?
What is a cache?
Before I can explain to you what a cache is, I need to explain how modern websites work (and why caches are necessary)
Basically how modern websites work is all the component pieces to your site live in different spots: the code that makes the header lives in its own text file separate from the code that makes the footer and the text file that sets the styles. Then the website building script (aka PHP) also has to go to a database to grab things like your settings and the blog/page content, and your images probably live in subfolders on your hosting account. Like so:

You can imagine PHP as a little robot that runs around grabbing the component chunks of the site from their various homes on the hotbar and assembling them for you while you wait, like a build-your-own subway sandwich. Obviously, this takes some doing- both processing power on your website’s host computers, and also time that your viewers have to wait while the website is assembled just for them.

This style of website design is great for developers- it lets us add new blog posts quickly, or change the header in one place and have it automagically update across all the many pages of your site. But the dark side of that is the additional processing power needed to assemble the site. In the good old days (like, 1994) websites were simpler: we had one text file for each website page and that was that. If you had to update the header, you’d better bust out your copy/paste skills to update it on every page.
But with the added power and ease of updates dynamically-robot-built sites comes a much bigger load time compared to their static counterparts. This is where someone smart came in and said, hey, why not keep the dynamic tools for us website builders, and just take a snapshot of the finished pages and save those to show to everyone else? You get the best of both worlds!
And thus website caching was born.
Caching, essentially, is saving a combination of those website components we discussed earlier- a finished, assembled webpage (sandwich). This makes it much easier to serve up to customers (visitors), because it’s already pre-packaged and ready to go.

To do this, many modern web developers will we have a script running on the website that takes a snapshot of all the pages fully built (cached), saves those somewhere on the server, and serves those to visitors instead of assembling the pages on-demand fresh for every user. But nobody likes a stale sandwich. The robot can be set to update and re-create those cached pages every so often (typically from once a day to a couple times per week).
Why are visitors seeing old versions of my website? They look updated to me when I’m logged in!
There is a tradeoff to cacheing- sometimes you need to wait a little while to see changes you made publish to the live version of your website (the version that other logged out viewers will see). Caching scripts usually have exceptions so logged in users never see the saved copies, they always get a fresh sandwich made just for them. So, if you are logged in as an admin and see the correct (new) version of your site, but Mary Jane in the next office over isn’t seeing those new blog posts, you know the reason: the website cache needs to be updated. You can take a coffee break and rest easy knowing it will automatically be flushed in the next cycle.
But my boss is breathing down my neck! I need this published now!!!!!
I hear ya, friend. Luckily, there’s a button you can press. It varies based on the caching plugin used, but check the admin area of your website for something that says “flush cache” or “purge cache”- that oughta do the trick!

Ok.. I think I understand website caches, but are there other kinds?
You betcha! So far, we’ve talked about the kinds of caches websites make for themselves, but there are other kinds as well, which can sometimes throw a wrench in our website update plans. If flushing your website cache didn’t solve your problem, try these:
type of cache | what is it? | how to flush it |
server cache | the computer that stores the website keeps a copy of the finished site to take pressure off of their machines | ask your website host or check for caching options in their admin area |
website cache | a website saves a finished copy of itself to make itself load faster | “flush cache” button in your website backend |
dns cache | the information about your (whatever.com) domain name is saved across the internet so lookups can happen faster | wait it out, or ask your domain name registrar or cloudflare to flush it for you |
browser cache | your website viewing app (chrome, safari, firefox, etc) saves a copy of the website you’ve already looked at to show it to you faster the next time you try to visit it. | many options: delete your browser cache, open in incognito mode, try using a different browser, or do a hard refresh (Windows: ctrl + F5 Apple: command + R) |
device cache | your computer/tablet/phone itself saves a copy of the website you’ve already looked at to show it to you faster the next time you try to visit it. | try from a different device or clear your device cache (Mac or PC) |
network cache | your internet provider or router saves the .com lookup information so it can find it again faster next time | reset your router, try from a different network, or add a “do not cache” exception to the domain name |
I hope this helps shed some light on a sometimes confusing subject. Like many things with computers, the trick is not to get bamboozled! If you need more help figuring out how to clear your website’s cache or just have other website puzzles, feel free to book a time to chat with me for a free 30 minute consult and I’ll point you in the right direction. 🙂
Now, excuse me, I need to go eat a sandwich.
No Responses