Chykalophia Docs
Performance

Caching explained

What caching is, how it makes websites faster, the different types of caching, and the one important tradeoff to know about.

Difficulty
Beginner

Caching is one of the most effective ways to speed up a website. It is also one of the most misunderstood. This guide explains exactly what it is, how it works, and when it can cause problems.

Quick summary

Caching saves a ready-made copy of your page so visitors get it instantly, without the server rebuilding it from scratch each time. It makes sites significantly faster — but it means updates can sometimes take a few minutes to appear everywhere.

What caching is

Every time a visitor loads a page on your site, your server has to do work:

  1. Look up the page in the database
  2. Fetch all the content (text, images, settings)
  3. Run any plugins or logic
  4. Assemble the final HTML page
  5. Send it to the visitor

This can take a fraction of a second — or several seconds, depending on how complex your site is.

Caching skips most of this work. The first time someone visits a page, the server builds it as normal — and then saves a "snapshot" of the finished result. The next time someone visits, the server just sends that saved snapshot. No database lookup, no assembly. Fast.

WordPress's own documentation puts caching first for exactly this reason: it is the change that gives you the biggest benefit for the smallest hassle.

Types of caching

There are several layers where caching can happen. You do not need to manage all of them — but it helps to know they exist.

Browser caching

Your browser (Chrome, Safari, etc.) caches files from websites you visit — images, stylesheets, fonts. When you visit the same site again, your browser loads the cached copies from your own computer instead of downloading them again.

This is why sites feel faster on your second visit. It is mostly automatic.

Server-side caching (page caching)

This is the most impactful type for WordPress sites. A plugin or hosting tool saves a complete HTML copy of each page. When the next visitor arrives, they get the cached copy without any database work.

WordPress caching plugins include WP Rocket, WP-Optimize, LiteSpeed Cache, W3 Total Cache, and others. Many managed WordPress hosts run their own caching at the server level instead — WP Engine's EverCache and Flywheel's FlyCache are both listed as standard platform features, and Kinsta gives each site its own Caching section in the dashboard.

CDN caching

A CDN (Content Delivery Network) stores copies of your pages and files in data centers around the world. Visitors get content from the server closest to them, reducing travel time.

Object caching

Object caching moves data that is slow to fetch somewhere it is fast to fetch, so the same work does not have to be redone on the next request. WordPress's documentation names Redis, Memcached, APC and the file system as popular engines for this. It is mostly handled by your hosting provider on managed plans.

Where each type of caching sitsThree of the types of caching described above sit at different points on the path between a visitor and your content: the browser cache on the visitor's own computer, the CDN cache in data centers around the world, and the server-side page cache where your site is hosted. Only when none of them has a copy does the request reach WordPress and the database.asks for a page and its filesonly when none of those has a copyA visitorloads a page on your siteBrowser cacheimages, stylesheets, fontsCDN cachedata centers around the worldServer-side cachea plugin or hosting toolWordPress + databasebuilds the page from scratch

Each of these sits at a different point on the same path, and a request travels only as far down as the first layer that already has what it is asking for. Not every site has all of them — you do not need to manage them, but it helps to know they exist.

Read this as text

Three of the types of caching described above sit at different points on one path — the path a request takes from a visitor down to the content your pages are built from. The fourth, object caching, is not on this path: it works inside the site’s own work, saving the results of database queries so they do not have to be repeated.

Closest to the visitor is the browser cache, which keeps images, stylesheets and fonts on the visitor’s own computer. Next is the CDN cache, which keeps copies of your pages and files in data centers around the world, so content comes from the server closest to the visitor. Then the server-side page cache — a plugin or a hosting tool — which saves a complete HTML copy of each page.

Only when none of those has a copy does the request reach WordPress and the database, which look the page up, fetch the content, run the plugins and assemble the HTML.

Not every site has all of these. There are several layers where caching can happen, and you do not need to manage all of them — but it helps to know they exist.

The tradeoff: freshness vs. speed

Here is the honest part. Caching is powerful — but it comes with one important implication.

When you update your site, visitors may not see the change immediately. They might see the cached (old) version for a few minutes — or longer, depending on how the cache is configured.

This is rarely a big problem in practice, because:

  • Most caching tools clear (or "purge") the cache automatically when you make an edit
  • The window of inconsistency is usually short (minutes, not hours)
  • Most visitors are not watching for the exact moment you publish

But if you notice that your changes are not showing up after saving, cached content is often the reason.

Changes not showing up?

If you update your site but still see the old version, try a hard refresh (Ctrl+Shift+R on Windows, Cmd+Shift+R on Mac). If that does not work, clear your browser cache. If visitors are still seeing the old version after several minutes, the server cache may need to be cleared manually. See My changes aren't showing up for steps.

Caching and logged-in users

Many caching setups do not serve cached pages to logged-in users. If you are logged in to WordPress, you are usually seeing the live, uncached version of your site — which is why you always see your changes right away, but a regular visitor might not.

If someone says "I can't see the update," the first question is: are they logged in?

Common questions

Should I install a caching plugin on my WordPress site?

It depends on your host. If you are on a managed WordPress host (Flywheel, WP Engine, Kinsta), caching is usually already configured at the server level, so a second layer on top is often unnecessary. Two page-cache plugins genuinely cannot both run: they both need the same WordPress drop-in file, advanced-cache.php. If you are on shared hosting without built-in caching, a plugin like WP Rocket makes a significant difference. Ask us what is already in place on your site.

What does 'cache bust' mean?

Cache busting is a technique developers use to force browsers to download a fresh version of a file (like a CSS stylesheet or JavaScript file). It usually means putting a version number, or a code derived from the file's contents, into the filename — style.x234dff.css rather than style.css — so the browser sees a URL it has never fetched before. You do not need to do this manually; it is handled by your development team or caching plugin.

Can caching break my site?

Caching plugins can conflict with other plugins or themes, which can cause display issues. This is more likely when multiple caching tools are running at the same time. If your site looks broken after installing a caching plugin, try deactivating it and see if that fixes the issue.

Need a hand?

If you're stuck, email support@chykalophia.com and we'll help. Include your website address and a screenshot if you can.

Learn more

Last updated

On this page