Short answer
We configure page caching on the server or platform, set browser cache headers with versioned file names, enable compression and, where it helps, put a CDN in front of the site. Pages that must stay personal, such as carts, checkouts and account areas, are kept out of the cache.
Why server response matters
Time to first byte is the first subpart of Largest Contentful Paint, and web.dev suggests it should account for roughly 40% of the total [1]. If the server takes 1.5 seconds to start answering, there is little time left for anything else before the 2.5-second threshold. Google lists "use a CDN to optimize TTFB" among its most effective LCP improvements, and notes that only 33% of HTML document requests were served from a CDN, according to HTTP Archive's 2024 Web Almanac, as cited by web.dev [2].
The three layers of caching
Page caching
Many sites build each page on request from a database and templates. A page cache stores the finished HTML so the next visitor gets it straight away. WordPress's own administration handbook describes caching plugins that "will cache your WordPress posts and pages as static files" and notes this helps most for pages that rarely change [3].
Object caching
For sites with logged-in users, stores or heavy queries, an object cache keeps the results of expensive database work in memory between requests. The WordPress handbook describes such caches as typically persistent [3]. Whether this helps depends on your hosting, so we check what is available before recommending it.
Browser caching
Browser caching lets a returning visitor reuse images, styles and scripts. MDN explains that a response with max-age is "fresh" until that age passes, and that the immutable directive tells the browser revalidation is not required because the content never changes [4]. The safe way to use long cache lifetimes is cache busting, "a technique to make a response cacheable over a long period by changing the URL when the content changes" [4]. We add version strings to file names so long lifetimes never serve stale files.
What stays out of the cache
Caching the wrong page can show one visitor's cart to another. WooCommerce's performance guide says caching should allow dynamic content "such as cart and checkout pages to remain uncached" [5]. We apply the same rule to account areas, forms with security tokens and any page that shows personal data. MDN distinguishes two directives here: no-cache still lets a response be stored but requires revalidation before reuse, while no-store means "you don't want a response stored in any cache" [4].
There is a trade-off. web.dev notes that pages sent with no-store may not be eligible for the back/forward cache, which makes back-button navigation instant, and recommends no-store only for pages with sensitive information [6]. So we use no-store narrowly and prefer shorter, revalidated caching elsewhere.
CDN setup
A content delivery network serves files from locations closer to the visitor. For a business whose customers are spread across the United States, that can cut the distance a request travels. The WordPress handbook notes that "using a CDN can greatly reduce the load on your website" [7]. We help choose between your host's built-in CDN and a separate service, configure which files are cached at the edge, and make sure purging works when content changes.
Compression and protocols
We enable Gzip or Brotli compression for text files, check that the server uses HTTP/2 or newer, and confirm that redirects do not add extra round trips, for example from http to https and then from www to the bare domain.
What you receive
- The cache rules in plain English, page type by page type, so your team knows what is cached and for how long.
- Before and after measurements of time to first byte on key templates, with dates.
- Instructions for clearing the cache safely after content changes.
- A note of anything the hosting plan prevents, with options if it matters.
How we test caching changes
Caching mistakes can be invisible until a customer reports seeing someone else's cart, so testing is part of every change. We check public pages from a fresh browser and confirm they are served from the cache. We log in, add items to a cart and fill in forms, and confirm none of those pages are cached for anyone else. We publish a small content change and confirm it appears within the expected time. We check that back-button navigation still restores pages instantly where it should [6]. Only then does the change go live.
Common small-site setups and what each needs
| Setup | Where caching work starts |
|---|---|
| Shared hosting with a CMS | A single page caching layer, browser cache headers and versioned static files |
| Managed WordPress hosting | Using the host's built-in cache and CDN properly instead of adding plugins on top |
| Hosted store platform | Theme and app changes, since the platform manages server caching and CDN |
| Custom application | Cache headers per route, an edge cache for public pages, and careful handling of sessions |
What we need from you
Access to the hosting control panel or server configuration, access to the CDN account if there is one, and a list of pages that must always show live, personal information. If your hosting plan does not allow the changes the audit recommends, we will explain the limit and the options, from adjusting the plan to moving to a host that fits the site better, so you can decide with the facts in front of you.
Questions about caching setup
Will caching stop my updates from showing?
Not if it is set up with sensible lifetimes and purging. We test that publishing a change clears the right pages, and we document how to clear the cache by hand.
Do I need a CDN for a local business?
Sometimes not. If your server is fast and your visitors are close to it, the benefit is small. We measure first and recommend a CDN only where the numbers support it.
Can caching break my store?
It can if carts, checkouts or accounts are cached, which is why we exclude them and test add-to-cart and checkout after every change.
Sources
Opened and checked on November 3, 2026.
- Optimize Largest Contentful Paint, web.dev. Primary documentation, last updated March 31, 2025.
- The most effective ways to improve Core Web Vitals, web.dev. Primary documentation (cites HTTP Archive and Chrome data), last updated October 31, 2024.
- Cache, Advanced Administration Handbook, Developer.WordPress.org. Primary documentation, checked November 3, 2026.
- HTTP caching, MDN Web Docs. Reference documentation, checked November 3, 2026.
- How to optimize performance for WooCommerce stores, WooCommerce developer docs. Primary platform documentation, checked November 3, 2026.
- Back/forward cache, web.dev. Primary documentation, last updated October 16, 2026.
- Optimization, Advanced Administration Handbook, Developer.WordPress.org. Primary documentation, checked November 3, 2026.