the street sweeper metaphor — and a gotcha
every time someone visits a page on your WordPress site, a small sequence of events happens: PHP runs, the database gets queried, the theme templates fire, plugins add their bits, and the whole thing gets assembled into an HTML page and sent to the visitor’s browser.
for a low-traffic site this is fine. for a site getting hundreds or thousands of visitors, doing all that work for every single request is expensive — it slows things down and puts load on the server.
caching short-circuits that process. the first time someone visits a page, WordPress does all that work and assembles the page. the cache then saves a copy of the finished result. the next visitor gets that saved copy directly — no database query, no PHP assembly, no theme rendering. just the pre-built page, delivered fast.
If you’re asking any of the following questions, this article is for you.
- why does my website look different on my phone than my computer?
- i updated my logo but the old one is still showing
- why can my web designer see the changes but i can’t?
- i changed my prices but the old ones are still showing up
- my website says it’s still under construction but i launched it
- why is my website showing a old version?
- i published a new blog post but it’s not showing up on my site
- my contact form was fixed but it’s still broken on my end
- why does my site look fine in incognito but broken in my regular browser?
- i updated my hours but google still shows the old ones
the street sweeper is a great mental model because it captures both the benefit and the gotcha.
the benefit: the sweeper comes through regularly and clears out accumulated clutter. things run faster and cleaner. the neighborhood looks good.
the gotcha: you make a change to your site — update a page, publish a new post, change a price — but the street sweeper hasn’t come through since before your change. visitors are still getting the old cached version. from their perspective, nothing changed.
this is why “try clearing your cache” is such a common instruction after making changes. clearing the cache tells the sweeper to come through immediately so the fresh version gets served.
if someone else can see a change you can’t, it’s almost always cache. think of those old film projectors where the image freezes but the audio keeps going — your machine is stuck on an old frame while the rest of the internet has moved on. you’re not seeing a broken site. you’re seeing a saved copy of the old one. clearing your cache sends the projector back to the live feed.
if you update something on your site and it looks unchanged in the browser — clear your cache first. in wp-admin (if you’re using a cache plugin, for example) there’s usually a clear cache button in the top admin bar, but these can be hidden inside plugins like Elementor too. that’s the “send the sweeper now” button.
the gotcha — it takes a team to keep things clean
where cache lives — starting at your front door
cache isn’t one thing in one place. it exists at multiple points between your site and your visitor, like checkpoints along the delivery route. the closer the checkpoint to the visitor, the faster the delivery — and the more likely they’re seeing a saved copy rather than the live version.
your browser (the film machine) — your browser saved a recording of the site the last time you visited. you’re watching that recording, not the live feed. this is why a page sometimes loads faster on your second visit, and why you might see an old version of your own site even after clearing the server cache — your browser is still playing back what it recorded last time. clearing your browser cache (usually Cmd+Shift+R on a Mac, Ctrl+Shift+R on Windows) switches it back to live.
your router (your regular delivery driver) — your router knows your address by heart and stopped checking the map a long time ago. it keeps its own shortcut list so it doesn’t have to look things up every single time. if your site moved or something changed, the router is still sending traffic the old way — reading from its own notes instead of checking the updated record. rebooting your router forces it to put the notes away and check the map again.
your ISP (the paperboy) — your internet service provider caches DNS lookups and sometimes content at a level you have no control over. the paperboy picked up his papers at the start of his route and he’s delivering what he’s got — on his own schedule, with no way to reach him mid-delivery. if your site changed after he left the depot, his version is already out of date and there’s nothing you can do but wait for the next run. this is why the same site can look different on your phone (a different paperboy, a different route) than on your laptop at home.
a CDN (the distribution depot near every visitor) — if your site uses a CDN like Cloudflare, copies of your pages and assets are stored at servers physically close to visitors around the world. when a visitor in Texas hits your site and it’s hosted in Massachusetts, they’re loading files from a depot in Dallas. the CDN cache is typically the last one to update when you make a change — and on high-traffic sites it’s often the culprit when everyone else can see a change but visitors in certain regions still can’t.
the server (the house itself) — the server stores pre-built versions of your pages so they don’t have to be assembled from scratch on every request. this is the cache you’re clearing when you hit the button in wp-admin.
the practical upshot: when something looks wrong and you can’t figure out why, work outward from the house. clear the server cache first. then the browser cache. then try a different network (your phone on cellular vs. your laptop on wifi). if it still looks wrong, the CDN may need a nudge — most CDN dashboards have a “purge cache” button for exactly this reason.
caching and development
if we’re actively working on your site — making design changes, testing layouts, updating CSS — caching can be a nuisance. you make a change, reload the page, and see the old version because the cache hasn’t cleared.
during active development we either disable caching entirely on staging, or clear it constantly. on your live site it should always be on.