The problem with cold cache pages
Cold cache is the state of a page whose cached copy is missing or has just expired. The next request can't be served from cache (the origin has to rebuild the page from scratch (database queries, template rendering, full execution)) which is why the first hit after a flush is so much slower than a cached one.
Every time your cache gets flushed (after a deployment, a content update, or a scheduled expiry), the next visitor hits an uncached page. Your server has to regenerate it from scratch: database queries, template rendering, full PHP execution. The result? A page that can be 3 to 10 times slower than a cached response.
This is bad for your users. But it's especially bad for your SEO.
Why Google cares about TTFB
TTFB (Time to First Byte) is the time between a browser sending an HTTP request and receiving the first byte of the server's response. It measures raw server responsiveness and is the foundation Google's LCP (Largest Contentful Paint) metric is built on, a slow TTFB delays everything that renders after it.
Google's Core Web Vitals, specifically LCP (Largest Contentful Paint), are direct ranking signals, and TTFB (Time to First Byte) is the foundation LCP is built on: a slow first byte delays everything that follows. Googlebot doesn't get special treatment: when it crawls a cold page, it measures the same slow response time your users see.
Akamai's research found that 100ms of added load time correlated with a 7% drop in conversion rate. For search engines, slow crawl times can reduce crawl budget and lower page scores in ranking algorithms.
The cache warming solution
Cache warming is the practice of proactively requesting a site's pages right after a cache flush (before real visitors or crawlers arrive) so every subsequent request is served from a warm cache instead of triggering a slow, uncached rebuild.
Cache warming means pre-loading your pages before visitors (or crawlers) arrive. Instead of waiting for the first request to build the cache, you send a warm-up request to each URL after every flush, filling the cache so that all subsequent requests get the fast, cached version.
Deploy → Cache flush → CacheBoost warms URLs → First real visitor hits warm cacheWith CacheBoost, this happens automatically:
- You configure a boost pointing at your XML sitemap
- You set a schedule (cron expression) or trigger it via the API after each deploy
- CacheBoost crawls all your URLs from one or more regions, filling the cache
What gets warmed
A typical setup warms:
- All pages listed in your XML sitemap
- Multiple user-agent variants (desktop, mobile, Googlebot, GPTBot)
- From multiple geographic regions if you have a CDN
This ensures that both your real users and search engine crawlers always hit a warm, fast cache.
Measuring the impact
Cache hit ratio is the percentage of requests served directly from cache instead of the origin server. A ratio above 90% means most visitors and crawlers get the fast, cached version of a page instead of triggering a slow rebuild.
After enabling cache warming, check your:
- TTFB in Google Search Console (Page Experience report)
- LCP scores in Core Web Vitals
- Cache hit ratio in your CDN or reverse proxy dashboard
Most teams see a measurable improvement in Core Web Vitals within a few weeks, especially after deploy events that previously caused traffic spikes on cold pages.
Getting started
CacheBoost offers a free plan with 500 URLs per month, enough to get started with any small to medium site. Add your sitemap, configure your first boost, and your cache stays warm automatically.
