# CacheBoost — Automatic Cache Warming for Your Website

> CacheBoost warms your cache before visitors arrive. Boost performance, improve SEO, and deliver instant page loads — compatible with WordPress, Magento, PrestaShop and more.

Source: https://www.cache-boost.com/home.md
Language: en

---



## What is CacheBoost?

CacheBoost is a distributed cache warming platform. It pre-warms CDN and reverse-proxy caches by simulating real HTTP traffic — ensuring end users always hit cached content instead of a cold origin.

CacheBoost automatically crawls your pages before visitors arrive: better page rendering, better TTFB for users and search engine crawlers (SEO/GEO).

**Key stats:** 5M+ URLs warmed per day — 4× average speed improvement — available in 4 regions.

## The problem: cold caches

Without warming, the first visitor after a cache flush pays the full generation cost — sometimes 5× slower than cached pages.

- **Slow first byte** — Cold pages are generated on each request. Your server works hard, your visitor waits.
- **SEO impact** — Core Web Vitals (LCP, TTFB) degrade when crawlers hit an empty cache.
- **Lost conversions** — Every 100ms of latency costs up to 1% in conversions. Cold caches add seconds.

## How it works

1. **Add your site** — Verify domain ownership with a file upload or meta tag.
2. **Configure a boost** — Point CacheBoost at your sitemap, choose regions, user-agents, and a schedule.
3. **Stay warm** — CacheBoost crawls and pre-loads your pages automatically, on your schedule.

## Key features

- **Sitemap-based crawling** — Automatically discovers and warms all URLs from standard or nested XML sitemaps.
- **Multi-region warming** — Warm from France, USA, Germany, UK — reduce TTFB for visitors worldwide.
- **User-agent variations** — Simulate desktop, mobile, bots, and AI crawlers — fills every cache variant.
- **Flexible scheduling** — Run on a cron schedule. Choose interval, time of day, or trigger after deployments.
- **Email reports** — Get a summary after each warming run: URLs hit, errors, and performance data.
- **CMS compatible** — Works with WordPress, WooCommerce, Magento, PrestaShop, Shopify, Drupal, Symfony, Laravel, TYPO3, Joomla, and custom stacks.

## AI-powered cache recommendations

Pro and Unlimited plans include AI-powered cache recommendations to help you optimize warming strategy.

## Frequently asked questions

**What is cache warming?**
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.

**What is a cold cache?**
A 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, so the origin server has to rebuild the page from scratch, making it markedly slower than a cached response.

**What is cache hit ratio?**
Cache hit ratio is the percentage of requests served directly from cache instead of the origin server. A ratio above 90% is considered healthy; below 70% usually signals a configuration issue or an unwarmed cache.

**What is TTFB (Time to First Byte)?**
TTFB 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.

**Does CacheBoost work with my CDN?**
Yes. CacheBoost works with any CDN that serves content via HTTP — Cloudflare, Fastly, BunnyCDN, KeyCDN, and more.

**Does it work without a CDN?**
Absolutely. CacheBoost works with any caching layer — Varnish, Redis, file cache, database cache, or any HTTP-based caching system.

**Will warming requests affect server load?**
Warming requests are sent at a controlled rate. You can configure concurrency and request rate per job.

**How does the post-deploy trigger work?**
CacheBoost provides a webhook URL you add to your CI/CD pipeline (GitHub Actions, GitLab CI, etc.). Warming starts automatically when your deploy finishes.

**What if my site has thousands of URLs?**
No limit. CacheBoost handles multi-level sitemaps, sitemap index files, and Google Shopping feeds natively.

**Is my data safe?**
CacheBoost only sends HTTP requests to your public URLs — the same requests any visitor would make. No credentials or private data is ever accessed.

**Can I cancel anytime?**
Yes. No commitment, no cancellation fee. Cancel at any time from your dashboard.

## Pricing

Start free (500 URLs/month, no credit card). Paid plans from €9/month.
See: https://www.cache-boost.com/pricing



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Features — CacheBoost

> Scheduled warming, multi-region, multiple user-agents, sitemap parsing, email reports and more.

Source: https://www.cache-boost.com/features.md
Language: en

---



## Smart crawling

**XML Sitemap parsing** — Automatically discovers all URLs from standard or nested XML sitemaps.

**Multi-sitemap support** — Add multiple sitemaps per site: products, categories, blog, landing pages.

**Concurrent requests** — Control concurrency per booster to balance speed vs. server load.

## Warming engine

**Multiple user-agents** — Desktop Chrome, iPhone Safari, Googlebot, GPTBot — warm each cache bucket independently.

**Cookie variations** — Provide cookie name/value pairs to warm authenticated or segmented caches.

**Custom headers** — Send custom HTTP headers — useful for staging environments or CDN bypass.

**Content-type targeting** — Restrict warming to HTML pages, assets (CSS/JS), or images independently.

## Operations

**Cron scheduling** — Pick any cron interval. Runs happen server-side with no browser tab needed.

**Run history** — Full log of every run: URLs processed, duration, errors, and status.

**Email reports** — Optional post-run email with a summary of the warming session.

**Multiple regions** — Deploy booster agents worldwide. Each region warms independently.

## Integrations

**WordPress & WooCommerce** — Install our free plugin to warm your cache automatically after every update or purchase. See: https://www.cache-boost.com/wordpress

**Magento** — Native Magento 2 integration to warm product and category caches. *(In progress)*

## Global reach

Available regions: France (Paris), United States (Iowa), Germany (Frankfurt), United Kingdom (London).
Coming soon: Asia Pacific (Singapore), Canada (Toronto), Australia (Sydney), Brazil (São Paulo).

See: https://www.cache-boost.com/regions



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Pricing — CacheBoost

> Simple, transparent pricing. Start for free, upgrade when you grow.

Source: https://www.cache-boost.com/pricing.md
Language: en

---



Simple, transparent pricing. Start free, upgrade as you grow. No credit card required to try.

## Plans

| Plan | Monthly quota | Monthly price | Annual price (per month) |
|------|--------------|---------------|--------------------------|
| Free | 500 URLs | €0 | €0 |
| Starter | 60,000 URLs | €9 | €7 |
| Pro | 250,000 URLs | €35 | €28 |
| Unlimited | Unlimited URLs | €78 | €62 |

Annual billing saves approximately 20%. Annual plans are billed upfront (Starter: €84/yr, Pro: €336/yr, Unlimited: €744/yr).

## All plans include

- Unlimited sites
- Unlimited projects (boosts)
- Multi-region warming
- Multiple user-agents
- Cookie and header variations
- Sitemap crawling
- Cron scheduling
- Email reports

Pro and Unlimited plans also include AI-powered cache recommendations.

## Frequently asked questions

**What counts as a URL?**
Each HTTP request made during a warming run counts as one URL. One page warmed across 2 user-agents = 2 URLs.

**Can I cancel anytime?**
Yes. No contracts, no cancellation fees. Cancel from your dashboard at any time.

**Does it work with Cloudflare or Varnish?**
Yes. CacheBoost works with any HTTP cache layer — Cloudflare, Varnish, Redis, WP Super Cache, and more.

**What happens when I hit my URL quota?**
Warming runs stop when the quota is reached. We notify you by email and you can upgrade at any time.

## Start free

14-day free trial. No credit card required.
Sign up: https://www.cache-boost.com/try



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Available Regions — CacheBoost

> Warm your cache from multiple regions around the world for global performance.

Source: https://www.cache-boost.com/regions.md
Language: en

---



CacheBoost operates booster agents in multiple regions. Serve cache-hit responses everywhere.

## Available regions

| Region | City | Status |
|--------|------|--------|
| France | Paris | Available |
| United States | Iowa | Available |
| Germany | Frankfurt | Available |
| United Kingdom | London | Available |
| Asia Pacific | Singapore | Coming soon |
| Canada | Toronto | Coming soon |
| Australia | Sydney | Coming soon |
| Brazil | Sao Paulo | Coming soon |

## Why multi-region warming?

**CDN priming** — When your CDN misses, the origin pays. Warming from the right region primes the nearest edge node.

**Global consistency** — A cache flush in one region should not leave other regions cold. Multi-region warming solves this.

**Search engine coverage** — Googlebot crawls from US datacenters. Keep your US region warm for crawl-time performance.

## Getting started

Create a free account and configure multi-region warming in minutes.
Sign up: https://www.cache-boost.com/try



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# CacheBoost for WordPress & WooCommerce — Automatic cache warming after every update

> Install the CacheBoost Warmer plugin and your WordPress or WooCommerce cache warms automatically after every post save, plugin update, or product change.

Source: https://www.cache-boost.com/wordpress.md
Language: en

---



## CacheBoost for WordPress & WooCommerce

Automatic cache warming after every post save, plugin update, product change, or theme switch — without touching your server.

CacheBoost integrates with WordPress and WooCommerce via a lightweight plugin or the REST API. When content changes, CacheBoost immediately re-warms the affected pages so visitors always hit a hot cache.

## The problem: stale and cold caches

WordPress and WooCommerce sites flush their cache constantly — on every post save, product update, plugin upgrade, or theme change. Each flush exposes your visitors to cold pages:

- **Slow first byte** — The first visitor after a flush pays the full PHP/database generation cost.
- **SEO impact** — Googlebot and Core Web Vitals measurements degrade on cold pages.
- **Lost conversions** — Every 100ms of latency costs up to 1% in conversions on e-commerce pages.

## Two integration paths

### Path 1 — WordPress plugin (recommended)

Install the CacheBoost Warmer plugin. Zero configuration: the plugin automatically detects your cache layer (WP Rocket, W3 Total Cache, LiteSpeed Cache, WP Super Cache, and more) and triggers a warm after every relevant event.

Download: https://www.cache-boost.com/downloads/cacheboost-warmer.zip — the WordPress.org directory listing (slug `cacheboost-warmer`) is under review and coming soon. Source code: https://github.com/nhodin/cacheboost-wordpress-plugin

**Installation:**
```
wp plugin install https://www.cache-boost.com/downloads/cacheboost-warmer.zip --activate
```

Or upload the .zip in your WordPress admin under Plugins → Add New → Upload Plugin. Once the WordPress.org listing is live: `wp plugin install cacheboost-warmer --activate`.

After activation, enter your CacheBoost API key in the CacheBoost → Settings admin menu.

### Path 2 — REST API

Call the CacheBoost REST API directly from your theme's `functions.php` or a custom plugin. Full control over which events trigger a warm and which URLs are targeted.

```php
add_action('save_post', function(int $postId): void {
    if (wp_is_post_revision($postId) || wp_is_post_autosave($postId)) return;
    wp_remote_post('https://api.cache-boost.com/v1/sites/YOUR_SITE_ID/warm', [
        'headers' => ['Authorization' => 'Bearer YOUR_API_KEY'],
        'body'    => json_encode(['urls' => [get_permalink($postId)]]),
    ]);
});
```

## WordPress hooks covered by the plugin

The plugin listens to these native WordPress events:

- `save_post` — Post/page published or updated
- `deleted_post` — Post or page deleted
- `edit_term` — Category, tag, or custom taxonomy updated
- `switch_theme` — Theme activated
- `wp_update_nav_menu` — Navigation menu updated
- `customize_save_after` — Customizer changes saved
- `upgrader_process_complete` — Plugin or theme updated

WooCommerce hooks (when WooCommerce is active):

- `woocommerce_update_product` — Product updated
- `woocommerce_new_product` — New product created
- `woocommerce_product_set_stock` — Stock level changed

Third-party cache plugin hooks (auto-detected):

- `after_rocket_clean_domain` — WP Rocket full-cache flush
- `w3tc_flush_all` — W3 Total Cache full flush
- `litespeed_purge_all` — LiteSpeed Cache full purge

## How warming works

1. WordPress event fires (e.g. `save_post`)
2. Plugin or API call notifies CacheBoost
3. CacheBoost queues the affected URLs
4. Distributed booster agents crawl the URLs from your chosen regions
5. Cache is hot before the next visitor arrives

## Features

- **Multi-region warming** — Warm from France, USA, Germany, UK — fills CDN edge caches worldwide.
- **Compatible with all cache layers** — Cloudflare, Varnish, Redis, WP Rocket, LiteSpeed, W3TC, and more.
- **User-agent variations** — Warm desktop, mobile, and bot cache buckets independently.
- **WooCommerce stock warming** — Re-warms product pages when inventory changes.
- **No server-side dependencies** — Warming runs on CacheBoost infrastructure, not your hosting.
- **Email reports** — Summary after each warming run: URLs hit, errors, cache HIT ratio.

## Pricing

- **Free** — 500 URLs/month. No credit card required.
- **Starter — €9/month (€7/month billed yearly)** — 60,000 URLs/month.
- **Pro — €35/month (€28/month billed yearly)** — 250,000 URLs/month. AI-powered recommendations.
- **Unlimited — €78/month (€62/month billed yearly)** — Unlimited URLs. Dedicated support.

All plans include multi-region warming, multiple user-agents, sitemap crawling, cron scheduling, and a 14-day free trial.

Start free: https://www.cache-boost.com/try

## Frequently asked questions

**Does it work with WP Rocket, LiteSpeed Cache, and W3 Total Cache?**
Yes. The plugin auto-detects these plugins and hooks into their purge events so warming starts immediately after any cache flush.

**Does it work with Cloudflare?**
Yes. CacheBoost sends real HTTP requests that populate Cloudflare's edge cache, just like a real visitor would.

**Will it slow down my WordPress admin?**
No. Warming requests are dispatched asynchronously after the WordPress action completes. There is no impact on save times.

**Can I warm only specific pages instead of the full site?**
Yes. The API path gives you full control over which URLs are warmed. The plugin warms the specific post/product URL plus its parent archive pages.

**Does it work with headless WordPress (REST API / WPGraphQL)?**
Yes. Point CacheBoost at the sitemap of your front-end domain. The plugin triggers a full-site warm after content updates.

**What if I have thousands of products?**
CacheBoost handles multi-level XML sitemaps with no URL limit. For WooCommerce stores with large catalogs, use the Unlimited plan.

See: https://www.cache-boost.com/wordpress



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Terms of Service — CacheBoost

> CacheBoost terms of service governing the use of our cache warming platform.

Source: https://www.cache-boost.com/terms.md
Language: en

---



These Terms of Service govern the use of the CacheBoost cache warming platform accessible at https://www.cache-boost.com.

By creating an account or using CacheBoost, you agree to these terms.

## Service description

CacheBoost provides an automated cache warming service. The service sends HTTP requests to URLs you configure in order to pre-populate caches on your web infrastructure.

## Acceptable use

You may use CacheBoost only for URLs and domains you own or are authorized to warm. You must not use CacheBoost to:
- Warm domains you do not own or control
- Generate traffic to harm or disrupt third-party services
- Circumvent rate limits or abuse the platform

## Account and quotas

URL quotas are counted per calendar month per plan. Unused quota does not roll over. Warming stops automatically when the monthly quota is reached.

## Subscriptions and billing

Paid subscriptions are billed monthly or annually. Annual plans are non-refundable once the billing period has started. You may cancel at any time; cancellation takes effect at the end of the current billing period.

## Service availability

CacheBoost aims for high availability but does not guarantee uninterrupted service. Scheduled maintenance may temporarily interrupt warming runs.

## Limitation of liability

CacheBoost is provided "as is". We are not liable for indirect, incidental, or consequential damages resulting from use of the service.

## Changes to terms

We may update these terms at any time. Continued use of the service after changes constitutes acceptance of the new terms.

## Contact

For questions about these terms: https://www.cache-boost.com/contact



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Introduction — CacheBoost Docs

> Learn what CacheBoost is and how it works.

Source: https://www.cache-boost.com/support/getting-started/introduction.md
Language: en

---



CacheBoost warms your site's cache by crawling URLs after each deploy, so visitors never hit a cold cache.

CacheBoost is a cache warming service. You give it a list of URLs or a sitemap, and it fetches them so your CDN or server-side cache is populated before real users arrive.

## Key concepts

**Site** — A domain you've registered with CacheBoost. Each site has a validation token you add to your server to prove ownership.

**Sitemap / Feed** — An XML sitemap or Google Shopping feed URL registered under a site. CacheBoost parses it to discover URLs to warm.

**Boost** — A warming campaign attached to a site. A boost defines which URLs to crawl, the crawl concurrency, and optionally a schedule.

**Run** — A single execution of a boost. Each run records the URLs fetched, response codes, and timing.

## Pricing

CacheBoost charges per URL crawled per month. Plans start at €0 (free tier, 500 URLs/month).
See: https://www.cache-boost.com/pricing

## Next steps

- Authentication: https://www.cache-boost.com/support/getting-started/authentication
- Quickstart: https://www.cache-boost.com/support/getting-started/quickstart
- Allow traffic: https://www.cache-boost.com/support/guides/allow-traffic



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Authentication — CacheBoost Docs

> Create and manage API keys for the CacheBoost API.

Source: https://www.cache-boost.com/support/getting-started/authentication.md
Language: en

---



All API requests require a Bearer token. This page explains how to create and manage API keys.

Every request to the CacheBoost API must include an `Authorization` header:

```
Authorization: Bearer cb_live_<your-api-key>
```

## Create an API key

1. Go to your profile page: https://app.cache-boost.com/profile
2. Click **Create API key**.
3. Give the key a name and select the scopes it needs.
4. Optionally restrict the key to specific sites.
5. Click **Create**. Copy the key — it is shown only once.

## Scopes

| Scope | Access |
|-------|--------|
| `sites:read` | List and get sites |
| `sites:write` | Create and delete sites, manage sitemaps |
| `boosts:read` | List and get boosts |
| `boosts:write` | Create, update, delete, and run boosts |
| `runs:read` | List and get runs |

## Key format

API keys have the format `cb_live_` followed by 32 hex characters. Only the first 8 characters of the key suffix are stored in the dashboard — the full key cannot be retrieved after creation.

## Revoking a key

On the profile page, click **Revoke** next to any key. Revocation is immediate.

> Store keys in environment variables or a secrets manager. Never commit them to source control.

## Next

- Quickstart: https://www.cache-boost.com/support/getting-started/quickstart
- API reference: https://www.cache-boost.com/support/api-reference/overview



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Quickstart — CacheBoost Docs

> Warm your cache in 5 minutes.

Source: https://www.cache-boost.com/support/getting-started/quickstart.md
Language: en

---



Register a site, add a sitemap, create a boost, and trigger your first run in 5 minutes.

## Prerequisites

- An API key with `sites:write`, `boosts:write`, and `runs:read` scopes
- A domain you control

## Step 1 — Register your site

```bash
curl -X POST https://api.cache-boost.com/v1/sites \
  -H "Authorization: Bearer cb_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"domain": "www.example.com"}'
```

The response includes a `validation_token`. Add it to your server before proceeding.

## Step 2 — Allow CacheBoost traffic

CacheBoost sends the `X-CacheBoost-Token` header on every warm-up request. If your site has a WAF, CDN, or rate limiter, create a rule that allows requests carrying this header.

Find your token in the dashboard under **My Sites** → key icon. See: https://www.cache-boost.com/support/guides/allow-traffic

## Step 3 — Add a sitemap

```bash
curl -X POST https://api.cache-boost.com/v1/sites/42/sitemaps \
  -H "Authorization: Bearer cb_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://www.example.com/sitemap.xml"}'
```

Replace `42` with your site ID from step 1. Google Shopping feeds (RSS/Atom) are also accepted.

## Step 4 — Create a boost

```bash
curl -X POST https://api.cache-boost.com/v1/sites/42/boosts \
  -H "Authorization: Bearer cb_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "Full site warm", "source": "sitemap", "concurrency": 3}'
```

## Step 5 — Run the boost

```bash
curl -X POST https://api.cache-boost.com/v1/sites/42/boosts/1/run \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

The response includes a `run_id`. Poll `GET /v1/runs/{runId}` to check progress.

## Next steps

- Schedule a boost: https://www.cache-boost.com/support/guides/schedule-a-boost
- Automate with GitHub Actions: https://www.cache-boost.com/support/guides/automate-with-github-actions



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Allow traffic — CacheBoost Docs

> Verify site ownership and allowlist CacheBoost IPs.

Source: https://www.cache-boost.com/support/guides/allow-traffic.md
Language: en

---



Verify site ownership and authorize CacheBoost requests using a security token header.

CacheBoost needs to reach your site to warm it. Instead of managing IP addresses, CacheBoost identifies itself with a per-site security token sent on every request. Configure your WAF, CDN, or firewall to allow requests that carry this header.

## Site verification

When you register a site, CacheBoost gives you a `validation_token`. Choose one method, then click **Verify** in the dashboard.

### Method 1: HTML file

Create a file named `{validation_token}.html` at the root of your site:

```
https://www.example.com/a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4.html
```

The file must return HTTP 200. Its content is not checked. You can delete it after verification.

### Method 2: Meta tag

Add a `<meta>` tag to the `<head>` of your homepage:

```html
<meta name="cacheboost-token" content="YOUR_VALIDATION_TOKEN" />
```

CacheBoost fetches your homepage and checks for this tag. The token must match exactly.

## Security token header

CacheBoost sends the `X-CacheBoost-Token` header on all warm-up requests and sitemap downloads. Whitelist this header in your firewall, CDN, or WAF to authorize CacheBoost traffic.

### Find your token

Go to **My Sites** in the dashboard and click the key icon next to your site. Your header value is displayed ready to copy:

```
X-CacheBoost-Token: YOUR_SECURITY_TOKEN
```

### Configure your firewall / WAF / CDN

Create a rule that bypasses blocking or rate-limiting for requests where `X-CacheBoost-Token` matches your site's token. The exact steps depend on your provider — consult its documentation for header-based allowlist rules.

You can regenerate your token at any time from the key icon menu. Update your firewall rule whenever you regenerate it.

## Test the configuration

After configuring the header rule, trigger a manual run from the dashboard or via:

```
POST /v1/sites/{siteId}/boosts/{boostId}/run
```

Check the run results — a successful fetch for each URL confirms CacheBoost traffic is getting through.



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Schedule a boost — CacheBoost Docs

> Use cron expressions to schedule automatic cache warming.

Source: https://www.cache-boost.com/support/guides/schedule-a-boost.md
Language: en

---



Use cron expressions to run a boost automatically on a recurring schedule.

Boosts can run on a schedule using standard cron expressions. Set the `schedule` field when creating or updating a boost.

## Cron expression format

```
┌─ minute (0–59)
│ ┌─ hour (0–23)
│ │ ┌─ day of month (1–31)
│ │ │ ┌─ month (1–12)
│ │ │ │ ┌─ day of week (0–7, 0 and 7 = Sunday)
│ │ │ │ │
* * * * *
```

## Common schedules

| Schedule | Cron |
|----------|------|
| Every hour | `0 * * * *` |
| Every day at 2 AM UTC | `0 2 * * *` |
| Every Monday at 8 AM UTC | `0 8 * * 1` |
| Every 6 hours | `0 */6 * * *` |

All schedule times are in UTC.

## Set a schedule via the API

Include `schedule` in the request body when creating or updating a boost:

```bash
curl -X POST https://api.cache-boost.com/v1/sites/42/boosts \
  -H "Authorization: Bearer cb_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "Nightly warm", "source": "sitemap", "concurrency": 3, "schedule": "0 3 * * *"}'
```

To remove a schedule, set `"schedule": null` via `PATCH`.

## On-demand runs

A scheduled boost can also be triggered manually at any time via `POST /v1/sites/{siteId}/boosts/{boostId}/run`. Manual runs do not affect the next scheduled run.



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Automate with GitHub Actions — CacheBoost Docs

> Trigger a cache warm after each deployment.

Source: https://www.cache-boost.com/support/guides/automate-with-github-actions.md
Language: en

---



Trigger a cache warm automatically after each deployment using GitHub Actions.

## Prerequisites

- A boost already created via the API or dashboard
- Your site ID and boost ID
- An API key with `boosts:write` scope

## Workflow

Add this workflow to `.github/workflows/warm-cache.yml` in your repository:

```yaml
name: Warm cache

on:
  deployment_status:

jobs:
  warm:
    if: github.event.deployment_status.state == 'success'
    runs-on: ubuntu-latest
    steps:
      - name: Trigger CacheBoost run
        run: |
          curl -sf -X POST \
            https://api.cache-boost.com/v1/sites/${{ vars.CACHEBOOST_SITE_ID }}/boosts/${{ vars.CACHEBOOST_BOOST_ID }}/run \
            -H "Authorization: Bearer ${{ secrets.CACHEBOOST_API_KEY }}"
```

## Configuration

Add the following to your repository (Settings → Secrets and variables → Actions):

| Name | Where | Value |
|------|-------|-------|
| `CACHEBOOST_API_KEY` | Secrets | Your API key (`cb_live_...`) |
| `CACHEBOOST_SITE_ID` | Variables | Your site ID |
| `CACHEBOOST_BOOST_ID` | Variables | Your boost ID |

## Wait for the run to finish

If you want the workflow to wait until the run completes:

```yaml
      - name: Wait for run
        run: |
          RUN_ID=$(curl -sf -X POST \
            https://api.cache-boost.com/v1/sites/${{ vars.CACHEBOOST_SITE_ID }}/boosts/${{ vars.CACHEBOOST_BOOST_ID }}/run \
            -H "Authorization: Bearer ${{ secrets.CACHEBOOST_API_KEY }}" \
            | jq -r '.id')

          for i in $(seq 1 30); do
            STATUS=$(curl -sf \
              https://api.cache-boost.com/v1/runs/$RUN_ID \
              -H "Authorization: Bearer ${{ secrets.CACHEBOOST_API_KEY }}" \
              | jq -r '.status')
            echo "Run status: $STATUS"
            [ "$STATUS" = "done" ] && exit 0
            [ "$STATUS" = "failed" ] && exit 1
            sleep 10
          done
          echo "Timed out waiting for run"
          exit 1
```

> The poll loop above times out after 5 minutes (30 x 10s). Adjust `seq 1 30` and `sleep 10` to match your expected crawl duration.



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# API overview — CacheBoost Docs

> Base URL, authentication, response format, errors, and pagination.

Source: https://www.cache-boost.com/support/api-reference/overview.md
Language: en

---



Base URL, authentication, response format, errors, and pagination.

OpenAPI spec: https://www.cache-boost.com/openapi.yaml

## Base URL

```
https://api.cache-boost.com/v1
```

## Authentication

Pass your API key as a Bearer token in every request:

```
Authorization: Bearer cb_live_YOUR_KEY
```

See: https://www.cache-boost.com/support/getting-started/authentication

## Response format

All responses are JSON. Single resources return the object directly; collections return an array.

Paginated endpoints (e.g. `GET /runs`) wrap results:

```json
{
  "data": [ ... ],
  "limit": 20,
  "offset": 0
}
```

## Errors

```json
{ "error": "Invalid or expired API key." }
```

| HTTP status | Meaning |
|-------------|---------|
| `401` | Missing or invalid API key |
| `403` | Key lacks the required scope |
| `404` | Resource not found |
| `409` | Conflict (boost already running, duplicate sitemap) |
| `422` | Validation error |
| `500` | Server error |

## Pagination

`GET /runs` accepts `limit` (default: 20, max: 100) and `offset` query parameters:

```
GET /v1/runs?limit=50&offset=100
```

## Available endpoints

### Sites
- `GET /v1/sites` — https://www.cache-boost.com/support/api-reference/sites/list
- `POST /v1/sites` — https://www.cache-boost.com/support/api-reference/sites/create
- `GET /v1/sites/{siteId}` — https://www.cache-boost.com/support/api-reference/sites/get
- `DELETE /v1/sites/{siteId}` — https://www.cache-boost.com/support/api-reference/sites/delete
- `POST /v1/sites/{siteId}/validate` — https://www.cache-boost.com/support/api-reference/sites/validate

### Sitemaps
- `GET /v1/sites/{siteId}/sitemaps` — https://www.cache-boost.com/support/api-reference/sitemaps/list
- `POST /v1/sites/{siteId}/sitemaps` — https://www.cache-boost.com/support/api-reference/sitemaps/create
- `DELETE /v1/sites/{siteId}/sitemaps/{sitemapId}` — https://www.cache-boost.com/support/api-reference/sitemaps/delete

### Boosts
- `GET /v1/sites/{siteId}/boosts` — https://www.cache-boost.com/support/api-reference/boosts/list
- `POST /v1/sites/{siteId}/boosts` — https://www.cache-boost.com/support/api-reference/boosts/create
- `GET /v1/sites/{siteId}/boosts/{boostId}` — https://www.cache-boost.com/support/api-reference/boosts/get
- `PATCH /v1/sites/{siteId}/boosts/{boostId}` — https://www.cache-boost.com/support/api-reference/boosts/update
- `DELETE /v1/sites/{siteId}/boosts/{boostId}` — https://www.cache-boost.com/support/api-reference/boosts/delete
- `POST /v1/sites/{siteId}/boosts/{boostId}/run` — https://www.cache-boost.com/support/api-reference/boosts/run

### Runs
- `GET /v1/runs` — https://www.cache-boost.com/support/api-reference/runs/list
- `GET /v1/runs/{runId}` — https://www.cache-boost.com/support/api-reference/runs/get



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Get current key — CacheBoost API

> Returns the identity and scopes granted to the authenticated API key.

Source: https://www.cache-boost.com/support/api-reference/me.md
Language: en

---



Returns the identity and scopes granted to the authenticated API key.

**`GET /v1/me`** — No scope required.

## Example request

```bash
curl https://api.cache-boost.com/v1/me \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`200 OK`

```json
{
  "user_id": 42,
  "scopes": ["sites:read", "boosts:read", "boosts:write"],
  "site_ids": null
}
```

`site_ids` is `null` when the key has access to all sites, or an array of integers when restricted to specific sites.

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# List sites — CacheBoost API

> Retrieve all sites for the authenticated user.

Source: https://www.cache-boost.com/support/api-reference/sites/list.md
Language: en

---



Returns all sites belonging to the authenticated user. If the API key is restricted to specific sites, only those are returned.

**`GET /v1/sites`** — Scope: `sites:read`

## Example request

```bash
curl https://api.cache-boost.com/v1/sites \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`200 OK` — array of site objects.

```json
[
  {
    "id": 42,
    "domain": "www.example.com",
    "validated": true,
    "created_at": "2025-01-15T10:30:00Z"
  }
]
```

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Create a site — CacheBoost API

> Add a new site and get a validation token.

Source: https://www.cache-boost.com/support/api-reference/sites/create.md
Language: en

---



Add a new site. Returns a `validation_token` needed to prove site ownership. Unverified sites are capped at 10 URLs per boost.

**`POST /v1/sites`** — Scope: `sites:write`

## Body parameters

| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| `domain` | string | Required | Domain without scheme or trailing slash. `https://` prefix is stripped automatically. |

## Example request

```bash
curl -X POST https://api.cache-boost.com/v1/sites \
  -H "Authorization: Bearer cb_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"domain": "www.example.com"}'
```

## Response

`201 Created` — new site object.

```json
{
  "id": 42,
  "domain": "www.example.com",
  "validated": false,
  "validation_token": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4",
  "created_at": "2025-01-15T10:30:00Z"
}
```

Use the `validation_token` to verify site ownership. See: https://www.cache-boost.com/support/guides/allow-traffic

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope |
| `422` | Missing or invalid `domain` |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Get a site — CacheBoost API

> Retrieve a single site by ID.

Source: https://www.cache-boost.com/support/api-reference/sites/get.md
Language: en

---



Retrieve a single site by ID.

**`GET /v1/sites/{id}`** — Scope: `sites:read`

## Example request

```bash
curl https://api.cache-boost.com/v1/sites/42 \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`200 OK` — site object.

```json
{
  "id": 42,
  "domain": "www.example.com",
  "validated": true,
  "validation_token": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4",
  "created_at": "2025-01-15T10:30:00Z"
}
```

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope or access denied |
| `404` | Site not found |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Delete a site — CacheBoost API

> Permanently delete a site and all associated data.

Source: https://www.cache-boost.com/support/api-reference/sites/delete.md
Language: en

---



Permanently deletes the site and all associated sitemaps, boosts, and run history. This action is irreversible.

**`DELETE /v1/sites/{id}`** — Scope: `sites:write`

## Example request

```bash
curl -X DELETE https://api.cache-boost.com/v1/sites/42 \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`204 No Content` — no response body.

> Deleting a site permanently removes all associated sitemaps, boosts, and run history.

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope or access denied |
| `404` | Site not found |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Validate a site — CacheBoost API

> Trigger an ownership check and mark the site as validated.

Source: https://www.cache-boost.com/support/api-reference/sites/validate.md
Language: en

---



Triggers an ownership check for a site. CacheBoost makes an HTTP request to the site and looks for the validation token. The check is synchronous — the result is returned immediately.

**`POST /v1/sites/{id}/validate`** — Scope: `sites:write`

CacheBoost tries two methods (HTTPS then HTTP):
1. **HTML file** — `{validation_token}.html` must be accessible at the site root and return HTTP 200.
2. **Meta tag** — the homepage must contain `<meta name="cacheboost-token" content="{validation_token}">` in `<head>`.

The `validation_token` is returned when creating a site (`POST /v1/sites`) and via `GET /v1/sites/{id}`.

## Example request

```bash
curl -X POST https://api.cache-boost.com/v1/sites/42/validate \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Responses

`200` — Validation succeeded:
```json
{ "validated": true }
```

`200` — Already validated:
```json
{ "validated": true, "already_validated": true }
```

`422` — Token not found:
```json
{ "validated": false, "error": "Validation token not found on the site." }
```

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope (`sites:write` required) |
| `404` | Site not found |
| `422` | Validation token not found on the site |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Warm URLs — CacheBoost API

> Trigger an on-demand cache warm for a list of URLs.

Source: https://www.cache-boost.com/support/api-reference/sites/warm.md
Language: en

---



Trigger an on-demand cache warm for a specific list of URLs. The response is `202 Accepted` — the run is queued and processed asynchronously.

**`POST /v1/sites/{id}/warm`** — Scope: `boosts:write`

## Body parameters

| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| `urls` | array | Required | List of URLs to warm. All URLs must belong to the site's domain. Maximum 5,000. |
| `region` | array | Optional | Target regions: `fr`, `us`, `eu`, `as`. Default: `["fr"]`. |
| `variations` | object | Optional | `user_agents` (mobile, desktop, bot, ai_crawler) and `languages`. Each combination counts as one call per URL. |

## Example request

```bash
curl -X POST https://api.cache-boost.com/v1/sites/42/warm \
  -H "Authorization: Bearer cb_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"urls": ["https://www.example.com/", "https://www.example.com/about"], "region": ["fr", "us"]}'
```

## Response

`202 Accepted`

```json
{
  "run_id": 91,
  "url_count": 2,
  "status": "pending"
}
```

The site must be validated before warming. Use the returned `run_id` to poll `GET /v1/runs/{id}` for progress.
See: https://www.cache-boost.com/support/api-reference/runs/get

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope, access denied, or quota exceeded |
| `404` | Site not found |
| `409` | Site is not validated, or a warm run is already in progress |
| `422` | Validation error — missing or invalid fields, or URLs outside the site's domain |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# List warm runs — CacheBoost API

> List on-demand warm run history for a site.

Source: https://www.cache-boost.com/support/api-reference/sites/warm-runs.md
Language: en

---



Returns on-demand warm run history for a site, newest first.

**`GET /v1/sites/{id}/warm-runs`** — Scope: `boosts:read`

## Query parameters

| Parameter | Type | Description |
|-----------|------|-------------|
| `limit` | integer | Number of results to return. Default: 20, max: 100. |
| `offset` | integer | Pagination offset. Default: 0. |

## Example request

```bash
curl https://api.cache-boost.com/v1/sites/42/warm-runs \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`200 OK`

```json
{
  "data": [
    {
      "id": 91,
      "status": "done",
      "status_message": null,
      "source_urls": ["https://www.example.com/", "https://www.example.com/about"],
      "run_region": ["fr", "us"],
      "started_at": "2025-01-15T10:31:00Z",
      "finished_at": "2025-01-15T10:31:45Z",
      "summary": {
        "total_calls": 4,
        "successful_calls": 4,
        "failed_calls": 0,
        "cache_hits": 3,
        "average_response_time_ms": 98.2,
        "pops": { "CDG": 2, "IAD": 2 }
      },
      "created_at": "2025-01-15T10:30:58Z"
    }
  ],
  "total": 1,
  "limit": 20,
  "offset": 0
}
```

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope or access denied |
| `404` | Site not found |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# List sitemaps — CacheBoost API

> Retrieve all sitemaps for a site.

Source: https://www.cache-boost.com/support/api-reference/sitemaps/list.md
Language: en

---



Returns all top-level sitemaps for a site. Child sitemaps (from sitemap indexes) are not included.

**`GET /v1/sites/{id}/sitemaps`** — Scope: `sites:read`

## Example request

```bash
curl https://api.cache-boost.com/v1/sites/42/sitemaps \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`200 OK` — array of sitemap objects.

```json
[
  {
    "id": 7,
    "url": "https://www.example.com/sitemap.xml",
    "status": "ready",
    "status_message": null,
    "last_processed_at": "2025-01-15T02:00:00Z",
    "created_at": "2025-01-10T09:00:00Z"
  }
]
```

### Status values

| Value | Description |
|-------|-------------|
| `waiting` | Queued for download |
| `downloading` | Currently downloading the sitemap file |
| `parsing` | Extracting URLs from the sitemap |
| `ready` | Processed successfully — URLs are available |
| `error` | Processing failed — see `status_message` |

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope or access denied |
| `404` | Site not found |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Add a sitemap — CacheBoost API

> Add a sitemap URL to a site.

Source: https://www.cache-boost.com/support/api-reference/sitemaps/create.md
Language: en

---



Add an XML sitemap or Google Shopping feed URL to a site. CacheBoost downloads and parses it automatically in the background. Sitemap indexes are supported — child sitemaps are followed automatically.

**`POST /v1/sites/{id}/sitemaps`** — Scope: `sites:write`

## Body parameters

| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| `url` | string | Required | Full URL of an XML sitemap or Google Shopping feed (RSS/Atom). Must belong to the site's domain. |

## Example request

```bash
curl -X POST https://api.cache-boost.com/v1/sites/42/sitemaps \
  -H "Authorization: Bearer cb_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://www.example.com/sitemap.xml"}'
```

## Response

`201 Created` — new sitemap object.

```json
{
  "id": 7,
  "url": "https://www.example.com/sitemap.xml",
  "status": "waiting",
  "status_message": null,
  "last_processed_at": null,
  "created_at": "2025-01-15T10:30:00Z"
}
```

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope or access denied |
| `404` | Site not found |
| `409` | Sitemap URL already exists for this site |
| `422` | Missing or invalid `url` |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Delete a sitemap — CacheBoost API

> Remove a sitemap and all its extracted URLs.

Source: https://www.cache-boost.com/support/api-reference/sitemaps/delete.md
Language: en

---



Removes a sitemap and all its extracted URLs.

**`DELETE /v1/sitemaps/{id}`** — Scope: `sites:write`

## Example request

```bash
curl -X DELETE https://api.cache-boost.com/v1/sitemaps/7 \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`204 No Content` — no response body.

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope or access denied |
| `404` | Sitemap not found |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# List boosts — CacheBoost API

> Retrieve all boost campaigns for the authenticated user.

Source: https://www.cache-boost.com/support/api-reference/boosts/list.md
Language: en

---



Returns all boosts belonging to the authenticated user.

**`GET /v1/boosts`** — Scope: `boosts:read`

## Example request

```bash
curl https://api.cache-boost.com/v1/boosts \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`200 OK` — array of boost objects.

```json
[
  {
    "id": 15,
    "site_id": 42,
    "name": "Daily warm",
    "status": "pending",
    "source_type": "sitemap",
    "region": ["fr"],
    "schedule": "0 1 * * *",
    "next_run_at": "2025-01-16T01:00:00Z",
    "created_at": "2025-01-10T09:00:00Z"
  }
]
```

### Boost status values

| Value | Description |
|-------|-------------|
| `pending` | Waiting to be scheduled or triggered |
| `running` | A run is currently in progress |
| `paused` | Boost is paused (manually or due to high error rate) |
| `done` | Last run completed successfully |
| `failed` | Last run failed |

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Create a boost — CacheBoost API

> Create a new cache warming campaign.

Source: https://www.cache-boost.com/support/api-reference/boosts/create.md
Language: en

---



Create a new cache warming campaign.

**`POST /v1/boosts`** — Scope: `boosts:write`

## Body parameters

| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| `name` | string | Required | Display name for the boost. |
| `site_id` | integer | Required | ID of the site to warm. |
| `source_type` | string | Required | `sitemap` or `csv`. |
| `region` | array | Required | Target regions: `fr`, `us`, `eu`, `as`. |
| `sitemap_ids` | array | Optional | IDs of sitemaps to warm (required when `source_type` is `sitemap`). |
| `source_url` | string | Optional | CSV file URL (required when `source_type` is `csv`). |
| `url_root` | string | Optional | Only warm URLs starting with this path. Default: `/`. |
| `exclude_ext` | array | Optional | File extensions to skip (e.g. `jpg`, `png`, `css`, `js`). |
| `variations` | object | Optional | `user_agents` (mobile, desktop, bot, ai_crawler) and `languages`. Each combination counts as one call per URL. |
| `schedule` | string | Optional | Cron expression (UTC) for automatic scheduling. |
| `call_limit` | integer | Optional | Maximum number of calls for this boost. |
| `ignore_errors` | boolean | Optional | If `true`, the boost will not auto-pause on high error rates. Default: `false`. |
| `report_email_enabled` | boolean | Optional | Send an email report when a run completes. Default: `true`. |

## Example request

```bash
curl -X POST https://api.cache-boost.com/v1/boosts \
  -H "Authorization: Bearer cb_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "Daily warm", "site_id": 42, "source_type": "sitemap", "region": ["fr"], "sitemap_ids": [7], "schedule": "0 1 * * *"}'
```

## Response

`201 Created` — full boost object.

```json
{
  "id": 15,
  "site_id": 42,
  "name": "Daily warm",
  "status": "pending",
  "source_type": "sitemap",
  "region": ["fr"],
  "sitemap_ids": [7],
  "schedule": "0 1 * * *",
  "next_run_at": "2025-01-16T01:00:00Z",
  "created_at": "2025-01-15T10:30:00Z"
}
```

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope or access denied |
| `404` | Site or sitemap not found |
| `422` | Validation error — missing or invalid fields |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Get a boost — CacheBoost API

> Retrieve a single boost by ID.

Source: https://www.cache-boost.com/support/api-reference/boosts/get.md
Language: en

---



Retrieve a single boost by ID.

**`GET /v1/boosts/{id}`** — Scope: `boosts:read`

## Example request

```bash
curl https://api.cache-boost.com/v1/boosts/15 \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`200 OK` — full boost object.

```json
{
  "id": 15,
  "site_id": 42,
  "name": "Daily warm",
  "status": "pending",
  "source_type": "sitemap",
  "region": ["fr"],
  "sitemap_ids": [7],
  "variations": null,
  "report_email_enabled": true,
  "schedule": "0 1 * * *",
  "next_run_at": "2025-01-16T01:00:00Z",
  "call_limit": null,
  "created_at": "2025-01-15T10:30:00Z"
}
```

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope or access denied |
| `404` | Boost not found |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Update a boost — CacheBoost API

> Update a boost configuration.

Source: https://www.cache-boost.com/support/api-reference/boosts/update.md
Language: en

---



Update a boost's configuration. All fields are optional — only include what you want to change. Returns `409` if the boost is currently running.

**`PUT /v1/boosts/{id}`** — Scope: `boosts:write`

## Body parameters (all optional)

| Parameter | Type | Description |
|-----------|------|-------------|
| `name` | string | Display name for the boost. |
| `region` | array | Target regions. |
| `url_root` | string | Only warm URLs starting with this path. |
| `exclude_ext` | array | File extensions to skip. |
| `variations` | object | Warming variations (user agents and languages). |
| `sitemap_ids` | array | IDs of sitemaps to warm. |
| `schedule` | string\|null | Cron expression (UTC). Set to `null` to remove the schedule. |
| `call_limit` | integer\|null | Maximum number of calls. Set to `null` to remove the limit. |
| `ignore_errors` | boolean | If `true`, boost will not auto-pause on high error rates. |
| `report_email_enabled` | boolean | Send an email report when a run completes. |

## Example request

```bash
curl -X PUT https://api.cache-boost.com/v1/boosts/15 \
  -H "Authorization: Bearer cb_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"schedule": "0 3 * * *", "region": ["fr", "eu"]}'
```

## Response

`200 OK` — updated boost object.

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope or access denied |
| `404` | Boost not found |
| `409` | Boost is currently running — cannot be updated |
| `422` | Validation error — invalid field values |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Delete a boost — CacheBoost API

> Permanently delete a boost and its run history.

Source: https://www.cache-boost.com/support/api-reference/boosts/delete.md
Language: en

---



Permanently deletes a boost and all its run history.

**`DELETE /v1/boosts/{id}`** — Scope: `boosts:write`

## Example request

```bash
curl -X DELETE https://api.cache-boost.com/v1/boosts/15 \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`204 No Content` — no response body.

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope or access denied |
| `404` | Boost not found |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Trigger a run — CacheBoost API

> Manually trigger a boost run immediately.

Source: https://www.cache-boost.com/support/api-reference/boosts/run.md
Language: en

---



Manually trigger a boost run immediately. The response is `202 Accepted` — the run is queued and processed asynchronously. Poll `GET /v1/runs/{run_id}` to track progress.

**`POST /v1/boosts/{id}/run`** — Scope: `boosts:write`

## Example request

```bash
curl -X POST https://api.cache-boost.com/v1/boosts/15/run \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`202 Accepted`

```json
{
  "run_id": 88,
  "status": "pending"
}
```

Use the returned `run_id` to poll `GET /v1/runs/{id}` for progress.
See: https://www.cache-boost.com/support/api-reference/runs/get

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope or access denied |
| `404` | Boost not found |
| `409` | A run is already in progress for this boost |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# List runs — CacheBoost API

> Retrieve run history across all boosts.

Source: https://www.cache-boost.com/support/api-reference/runs/list.md
Language: en

---



Returns run history across all boosts, newest first.

**`GET /v1/runs`** — Scope: `runs:read`

## Query parameters

| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| `boost_id` | integer | Optional | Filter by boost ID. |
| `limit` | integer | Optional | Results per page. Default: 20, max: 100. |
| `offset` | integer | Optional | Pagination offset. Default: 0. |

## Example request

```bash
curl "https://api.cache-boost.com/v1/runs?boost_id=15&limit=20" \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`200 OK` — paginated list of run objects.

```json
{
  "data": [
    {
      "id": 88,
      "boost_id": 15,
      "status": "done",
      "started_at": "2025-01-15T01:00:05Z",
      "finished_at": "2025-01-15T01:04:22Z",
      "summary": {
        "total_calls": 1240,
        "successful_calls": 1238,
        "failed_calls": 2,
        "cache_hits": 1165,
        "average_response_time_ms": 112.5
      }
    }
  ],
  "limit": 20,
  "offset": 0
}
```

### Run status values

| Value | Description |
|-------|-------------|
| `pending` | Queued and waiting to start |
| `running` | Currently in progress |
| `done` | Completed successfully |
| `failed` | Ended with errors |
| `paused` | Paused due to high error rate |

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Get a run — CacheBoost API

> Retrieve a single run by ID with summary statistics.

Source: https://www.cache-boost.com/support/api-reference/runs/get.md
Language: en

---



Retrieve a single run by ID, including full summary statistics.

**`GET /v1/runs/{id}`** — Scope: `runs:read`

## Example request

```bash
curl https://api.cache-boost.com/v1/runs/88 \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`200 OK` — run object with boost name and site ID.

```json
{
  "id": 88,
  "boost_id": 15,
  "boost_name": "Daily warm",
  "site_id": 42,
  "status": "done",
  "status_message": null,
  "started_at": "2025-01-15T01:00:05Z",
  "finished_at": "2025-01-15T01:04:22Z",
  "summary": {
    "total_calls": 1240,
    "successful_calls": 1238,
    "failed_calls": 2,
    "cache_hits": 1165,
    "average_response_time_ms": 112.5,
    "pops": {"CDG": 620, "AMS": 618}
  },
  "created_at": "2025-01-15T01:00:00Z"
}
```

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope or access denied |
| `404` | Run not found |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Cache Warming Services Compared: TTFB, Hit Ratios & Cost — CacheBoost Blog

> No warming, manual cron warming, or automated cache warming: a data-driven comparison of TTFB, cache hit ratio, setup time, and maintenance cost across all three approaches.

Source: https://www.cache-boost.com/blog/cache-warming-services-compared.md
Language: en

---


Tags: comparison, performance
Published: 2026-07-31
Author: Nicolas Hodin
Reading time: 8 min

---

**In summary:**
- Compares no warming, manual cron warming, and automated warming on TTFB, hit ratio, setup time, and cost
- Shows in real numbers what a cold cache actually costs you
- Explains when each approach makes sense for your site
- Explains why warming from your own server doesn't warm your CDN's edge caches
- Covers how to measure whether cache warming is actually working
Choosing the right cache warming approach can be the difference between a 98% cache hit ratio and a site that serves cold pages to every third visitor. This comparison breaks down three common approaches (no warming, manual cron-based warming, and automated cache warming via CacheBoost) across the metrics that matter to web performance teams and agencies. Use the table and benchmarks below to make a fast, evidence-based decision.

## The core problem: what a cold cache costs you

A cold cache occurs when a page hasn't been pre-loaded and must be generated from scratch on the first request. The server has to query the database, execute application logic, and render the response before delivering it, a process that can multiply time-to-first-byte (TTFB) by a factor of five or more compared to a cached response. For high-traffic sites this is a periodic inconvenience; for low-to-medium traffic sites, it's the default state for a significant share of real visitors.

The cold cache problem is made worse by cache expiry cycles. Most caching plugins and CDN configurations expire cached pages on a schedule (anywhere from one hour to 24 hours) meaning every page starts cold again after each expiry window. A site with 500 URLs and a four-hour cache TTL will experience cold-cache penalties continuously throughout the day unless something actively re-warms those pages before visitors arrive.

For agencies managing performance across multiple client sites, the cumulative impact of cold caches across a portfolio adds up quickly. A single unwarmed page load can skew Core Web Vitals scores, trigger Largest Contentful Paint (LCP) failures, and surface in client performance reports, all before a warming strategy is even in place.

## Cache warming approaches compared

The table below compares three approaches across six performance and operational dimensions. "No warming" is the baseline most sites default to. "Manual cron warming" is a self-managed script or scheduled task that crawls URLs on a fixed interval. "Automated warming (CacheBoost)" reads XML sitemaps, simulates real user requests across multiple regions, and maintains a high hit ratio continuously.

TTFB figures represent the difference between a cold-cache and a warm-cache response under typical shared or managed hosting conditions. Setup time reflects the time from decision to active warming. Cache hit ratio reflects the share of real visitor requests served from cache rather than generated fresh.

| Metric | No Warming | Manual Cron Warming | Automated Warming (CacheBoost) |
|---|---|---|---|
| Typical TTFB (warm) | 800ms–2000ms | 200ms–500ms | Under 200ms |
| Cache hit ratio | 20%–50% | 60%–80% | Up to 98% |
| Setup time | None (no action) | 2–8 hours (dev time) | Under 15 minutes |
| Ongoing maintenance | None | Medium (script upkeep) | None (fully automated) |
| Multi-region coverage | No | Depends on setup | Yes (4 regions) |
| Scales with sitemap | No | Partial | Yes (1M+ URLs/day) |

The trade-off is clear: manual cron warming reduces cold-cache penalties meaningfully but requires developer time to build, maintain, and adapt as sitemaps change. Automated warming removes both the cold-cache problem and the operational overhead.

## How CacheBoost compares to other tools

Several tools in the WordPress and web performance ecosystem touch cache-related performance in overlapping ways. WP Rocket and NitroPack are full-stack performance plugins that include cache preloading as one feature among many, alongside CSS optimization, image lazy loading, and CDN integration. For teams that want a single all-in-one WordPress performance plugin, these cover a broader scope. Their warming is tied to a single WordPress install, though, and doesn't run as a standalone, sitemap-driven service (see our [detailed comparison with WP Rocket's preloader](/blog/cacheboost-vs-wp-rocket-preloading)).

FlyingPress is a WordPress-specific performance plugin with automatic cache preloading, making it a direct feature-level competitor in the WordPress context. Cloudflare doesn't offer proactive cache warming as a product; its Enterprise tier provides prefetching (loading a visitor's likely next resource) and a tiered-cache architecture, both of which populate the cache reactively rather than warming an entire sitemap ahead of traffic. Some GraphQL-focused CDNs offer caching oriented toward API and headless architectures rather than traditional page-level warming, a different problem from warming full HTML pages ahead of visitor traffic.

CacheBoost differentiates itself from bundled plugin solutions by operating as a dedicated, platform-agnostic warming service: it works from XML sitemaps regardless of the underlying CMS or hosting stack. That matters for agencies managing mixed-technology client portfolios, where a single warming service can cover WordPress, custom PHP, and other platforms without installing a plugin on every site.

## When each approach makes sense

No cache warming is defensible only for very low-traffic internal tools or staging environments where performance isn't visitor-facing. For any site with real users and performance targets, some form of warming is necessary to keep TTFB and cache hit ratio acceptable after each cache expiry.

Manual cron warming is a reasonable interim solution for a single site managed by a developer with time to build and maintain the script. It becomes unworkable at scale: a developer managing 20 client sites can't realistically maintain 20 separate warming scripts while keeping them in sync with changing sitemaps, new page publications, and cache TTL adjustments. The operational cost compounds with every additional site.

There's also a subtler limitation that's easy to miss: warming from your own server often doesn't warm your CDN at all. A cron script running on the origin typically requests URLs directly against the origin (or `localhost`), which bypasses the CDN entirely and only populates the origin's own cache, not the distributed edge nodes where visitors are actually served. Even when the script fetches the public URL through the CDN, every request leaves from a single server IP in one location, so it warms only the nearest edge PoP and leaves edge caches in every other region cold. Warming a CDN requires requests that genuinely reach each edge location, which is exactly why distributed, multi-region warming matters rather than a single-origin script.

Automated warming via a dedicated service like CacheBoost is the practical choice for agencies managing multiple client sites, for e-commerce sites where every page load affects conversion, and for any site where consistent performance can't depend on developer availability. Sitemap-based coverage, multi-region request simulation, and zero ongoing maintenance take warming off the active task list entirely.

## How to measure whether cache warming is working

Cache hit ratio is the primary metric for evaluating warming effectiveness. A well-warmed site should see hit ratios of 90% or above under normal traffic. Most caching layers (including Nginx, Varnish, LiteSpeed, and CDN providers) expose cache hit/miss headers in HTTP responses. curl with verbose headers, browser dev tools, or server log analysis can surface these figures without extra instrumentation. (See our [full guide to measuring cache hit ratio](/blog/how-to-measure-cache-hit-ratio).)

TTFB is the user-facing proxy metric for cache performance. A cached response should consistently deliver TTFB under 200ms on a reasonably provisioned host; a cold response on the same host may take 800ms to 2,000ms depending on application complexity. Running before/after TTFB measurements with a tool like WebPageTest or GTmetrix against specific URLs (especially low-traffic pages that are rarely cached) gives a direct read on warming effectiveness.

For agencies, the most practical monitoring approach is tracking TTFB and cache hit ratio per client site on a weekly basis. A drop in hit ratio or a spike in TTFB from a specific site signals that cache TTL settings, sitemap coverage, or warming frequency need adjustment. Automated warming services that log warming activity make this audit straightforward.

## Frequently asked questions

**Which cache warming solution is best for multi-region website performance?**
A dedicated warming service that simulates requests from multiple geographic regions (rather than a single-origin cron script) ensures CDN edge nodes in each region serve warm cached content. CacheBoost covers 4 regions, so visitors in different geographies are served from a pre-populated cache instead of triggering edge-cache misses on first load.

**What's the difference between a cache warming plugin and a cache warming service?**
A cache warming plugin is installed per site, typically within a CMS like WordPress, and warms the cache within that site's own environment. A cache warming service operates externally, reading the site's XML sitemap and making HTTP requests to warm the cache from outside the server. This works across any technology stack and doesn't require CMS-level access.

**How much does cache warming improve TTFB?**
Under typical managed hosting conditions, a cached page response delivers TTFB in the 100–200ms range. The same page served cold (without a pre-warmed cache) can take 800ms to 2,000ms. Effective cache warming reduces TTFB by roughly 75–90% for the requests it covers, with the biggest impact on low-to-medium traffic pages that would otherwise sit cold between visits.

**Is manual cache warming with a cron job as effective as an automated service?**
Manual cron warming can reach 60–80% cache hit ratios for a single site when configured correctly. But it requires developer time to build, keep in sync with sitemap updates, and maintain, and it typically doesn't cover multi-region CDN warming or scale to large sitemaps without extra engineering work.

## The bottom line

Cache warming isn't a feature to evaluate in isolation: it's a decision about how much cold-cache degradation is acceptable and how much developer time is available to manage it. For a single site with developer resources on hand, manual warming is viable. For agencies, e-commerce operations, or any context where consistent performance across multiple sites is required, an automated warming service that handles sitemap crawling, multi-region coverage, and ongoing maintenance is the operationally sound choice. If you're evaluating options, the metrics in the comparison table above, cache hit ratio and TTFB under load in particular, are the numbers to hold any solution accountable to.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Cache Warming Services Compared: TTFB, Hit Ratios & Cost — CacheBoost Blog

> No warming, manual cron warming, or automated cache warming: a data-driven comparison of TTFB, cache hit ratio, setup time, and maintenance cost across all three approaches.

Source: https://www.cache-boost.com/blog/cache-warming-services-compared.md
Language: en

---


Tags: comparison, performance
Published: 2026-07-31
Author: Nicolas Hodin
Reading time: 8 min

---

**In summary:**
- Compares no warming, manual cron warming, and automated warming on TTFB, hit ratio, setup time, and cost
- Shows in real numbers what a cold cache actually costs you
- Explains when each approach makes sense for your site
- Explains why warming from your own server doesn't warm your CDN's edge caches
- Covers how to measure whether cache warming is actually working
Choosing the right cache warming approach can be the difference between a 98% cache hit ratio and a site that serves cold pages to every third visitor. This comparison breaks down three common approaches (no warming, manual cron-based warming, and automated cache warming via CacheBoost) across the metrics that matter to web performance teams and agencies. Use the table and benchmarks below to make a fast, evidence-based decision.

## The core problem: what a cold cache costs you

A cold cache occurs when a page hasn't been pre-loaded and must be generated from scratch on the first request. The server has to query the database, execute application logic, and render the response before delivering it, a process that can multiply time-to-first-byte (TTFB) by a factor of five or more compared to a cached response. For high-traffic sites this is a periodic inconvenience; for low-to-medium traffic sites, it's the default state for a significant share of real visitors.

The cold cache problem is made worse by cache expiry cycles. Most caching plugins and CDN configurations expire cached pages on a schedule (anywhere from one hour to 24 hours) meaning every page starts cold again after each expiry window. A site with 500 URLs and a four-hour cache TTL will experience cold-cache penalties continuously throughout the day unless something actively re-warms those pages before visitors arrive.

For agencies managing performance across multiple client sites, the cumulative impact of cold caches across a portfolio adds up quickly. A single unwarmed page load can skew Core Web Vitals scores, trigger Largest Contentful Paint (LCP) failures, and surface in client performance reports, all before a warming strategy is even in place.

## Cache warming approaches compared

The table below compares three approaches across six performance and operational dimensions. "No warming" is the baseline most sites default to. "Manual cron warming" is a self-managed script or scheduled task that crawls URLs on a fixed interval. "Automated warming (CacheBoost)" reads XML sitemaps, simulates real user requests across multiple regions, and maintains a high hit ratio continuously.

TTFB figures represent the difference between a cold-cache and a warm-cache response under typical shared or managed hosting conditions. Setup time reflects the time from decision to active warming. Cache hit ratio reflects the share of real visitor requests served from cache rather than generated fresh.

| Metric | No Warming | Manual Cron Warming | Automated Warming (CacheBoost) |
|---|---|---|---|
| Typical TTFB (warm) | 800ms–2000ms | 200ms–500ms | Under 200ms |
| Cache hit ratio | 20%–50% | 60%–80% | Up to 98% |
| Setup time | None (no action) | 2–8 hours (dev time) | Under 15 minutes |
| Ongoing maintenance | None | Medium (script upkeep) | None (fully automated) |
| Multi-region coverage | No | Depends on setup | Yes (4 regions) |
| Scales with sitemap | No | Partial | Yes (1M+ URLs/day) |

The trade-off is clear: manual cron warming reduces cold-cache penalties meaningfully but requires developer time to build, maintain, and adapt as sitemaps change. Automated warming removes both the cold-cache problem and the operational overhead.

## How CacheBoost compares to other tools

Several tools in the WordPress and web performance ecosystem touch cache-related performance in overlapping ways. WP Rocket and NitroPack are full-stack performance plugins that include cache preloading as one feature among many, alongside CSS optimization, image lazy loading, and CDN integration. For teams that want a single all-in-one WordPress performance plugin, these cover a broader scope. Their warming is tied to a single WordPress install, though, and doesn't run as a standalone, sitemap-driven service (see our [detailed comparison with WP Rocket's preloader](/blog/cacheboost-vs-wp-rocket-preloading)).

FlyingPress is a WordPress-specific performance plugin with automatic cache preloading, making it a direct feature-level competitor in the WordPress context. Cloudflare doesn't offer proactive cache warming as a product; its Enterprise tier provides prefetching (loading a visitor's likely next resource) and a tiered-cache architecture, both of which populate the cache reactively rather than warming an entire sitemap ahead of traffic. Some GraphQL-focused CDNs offer caching oriented toward API and headless architectures rather than traditional page-level warming, a different problem from warming full HTML pages ahead of visitor traffic.

CacheBoost differentiates itself from bundled plugin solutions by operating as a dedicated, platform-agnostic warming service: it works from XML sitemaps regardless of the underlying CMS or hosting stack. That matters for agencies managing mixed-technology client portfolios, where a single warming service can cover WordPress, custom PHP, and other platforms without installing a plugin on every site.

## When each approach makes sense

No cache warming is defensible only for very low-traffic internal tools or staging environments where performance isn't visitor-facing. For any site with real users and performance targets, some form of warming is necessary to keep TTFB and cache hit ratio acceptable after each cache expiry.

Manual cron warming is a reasonable interim solution for a single site managed by a developer with time to build and maintain the script. It becomes unworkable at scale: a developer managing 20 client sites can't realistically maintain 20 separate warming scripts while keeping them in sync with changing sitemaps, new page publications, and cache TTL adjustments. The operational cost compounds with every additional site.

There's also a subtler limitation that's easy to miss: warming from your own server often doesn't warm your CDN at all. A cron script running on the origin typically requests URLs directly against the origin (or `localhost`), which bypasses the CDN entirely and only populates the origin's own cache, not the distributed edge nodes where visitors are actually served. Even when the script fetches the public URL through the CDN, every request leaves from a single server IP in one location, so it warms only the nearest edge PoP and leaves edge caches in every other region cold. Warming a CDN requires requests that genuinely reach each edge location, which is exactly why distributed, multi-region warming matters rather than a single-origin script.

Automated warming via a dedicated service like CacheBoost is the practical choice for agencies managing multiple client sites, for e-commerce sites where every page load affects conversion, and for any site where consistent performance can't depend on developer availability. Sitemap-based coverage, multi-region request simulation, and zero ongoing maintenance take warming off the active task list entirely.

## How to measure whether cache warming is working

Cache hit ratio is the primary metric for evaluating warming effectiveness. A well-warmed site should see hit ratios of 90% or above under normal traffic. Most caching layers (including Nginx, Varnish, LiteSpeed, and CDN providers) expose cache hit/miss headers in HTTP responses. curl with verbose headers, browser dev tools, or server log analysis can surface these figures without extra instrumentation. (See our [full guide to measuring cache hit ratio](/blog/how-to-measure-cache-hit-ratio).)

TTFB is the user-facing proxy metric for cache performance. A cached response should consistently deliver TTFB under 200ms on a reasonably provisioned host; a cold response on the same host may take 800ms to 2,000ms depending on application complexity. Running before/after TTFB measurements with a tool like WebPageTest or GTmetrix against specific URLs (especially low-traffic pages that are rarely cached) gives a direct read on warming effectiveness.

For agencies, the most practical monitoring approach is tracking TTFB and cache hit ratio per client site on a weekly basis. A drop in hit ratio or a spike in TTFB from a specific site signals that cache TTL settings, sitemap coverage, or warming frequency need adjustment. Automated warming services that log warming activity make this audit straightforward.

## Frequently asked questions

**Which cache warming solution is best for multi-region website performance?**
A dedicated warming service that simulates requests from multiple geographic regions (rather than a single-origin cron script) ensures CDN edge nodes in each region serve warm cached content. CacheBoost covers 4 regions, so visitors in different geographies are served from a pre-populated cache instead of triggering edge-cache misses on first load.

**What's the difference between a cache warming plugin and a cache warming service?**
A cache warming plugin is installed per site, typically within a CMS like WordPress, and warms the cache within that site's own environment. A cache warming service operates externally, reading the site's XML sitemap and making HTTP requests to warm the cache from outside the server. This works across any technology stack and doesn't require CMS-level access.

**How much does cache warming improve TTFB?**
Under typical managed hosting conditions, a cached page response delivers TTFB in the 100–200ms range. The same page served cold (without a pre-warmed cache) can take 800ms to 2,000ms. Effective cache warming reduces TTFB by roughly 75–90% for the requests it covers, with the biggest impact on low-to-medium traffic pages that would otherwise sit cold between visits.

**Is manual cache warming with a cron job as effective as an automated service?**
Manual cron warming can reach 60–80% cache hit ratios for a single site when configured correctly. But it requires developer time to build, keep in sync with sitemap updates, and maintain, and it typically doesn't cover multi-region CDN warming or scale to large sitemaps without extra engineering work.

## The bottom line

Cache warming isn't a feature to evaluate in isolation: it's a decision about how much cold-cache degradation is acceptable and how much developer time is available to manage it. For a single site with developer resources on hand, manual warming is viable. For agencies, e-commerce operations, or any context where consistent performance across multiple sites is required, an automated warming service that handles sitemap crawling, multi-region coverage, and ongoing maintenance is the operationally sound choice. If you're evaluating options, the metrics in the comparison table above, cache hit ratio and TTFB under load in particular, are the numbers to hold any solution accountable to.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Cache Warming Services Compared: TTFB, Hit Ratios & Cost — CacheBoost Blog

> No warming, manual cron warming, or automated cache warming: a data-driven comparison of TTFB, cache hit ratio, setup time, and maintenance cost across all three approaches.

Source: https://www.cache-boost.com/blog/cache-warming-services-compared.md
Language: en

---


Tags: comparison, performance
Published: 2026-07-31
Author: Nicolas Hodin
Reading time: 8 min

---

**In summary:**
- Compares no warming, manual cron warming, and automated warming on TTFB, hit ratio, setup time, and cost
- Shows in real numbers what a cold cache actually costs you
- Explains when each approach makes sense for your site
- Explains why warming from your own server doesn't warm your CDN's edge caches
- Covers how to measure whether cache warming is actually working
Choosing the right cache warming approach can be the difference between a 98% cache hit ratio and a site that serves cold pages to every third visitor. This comparison breaks down three common approaches (no warming, manual cron-based warming, and automated cache warming via CacheBoost) across the metrics that matter to web performance teams and agencies. Use the table and benchmarks below to make a fast, evidence-based decision.

## The core problem: what a cold cache costs you

A cold cache occurs when a page hasn't been pre-loaded and must be generated from scratch on the first request. The server has to query the database, execute application logic, and render the response before delivering it, a process that can multiply time-to-first-byte (TTFB) by a factor of five or more compared to a cached response. For high-traffic sites this is a periodic inconvenience; for low-to-medium traffic sites, it's the default state for a significant share of real visitors.

The cold cache problem is made worse by cache expiry cycles. Most caching plugins and CDN configurations expire cached pages on a schedule (anywhere from one hour to 24 hours) meaning every page starts cold again after each expiry window. A site with 500 URLs and a four-hour cache TTL will experience cold-cache penalties continuously throughout the day unless something actively re-warms those pages before visitors arrive.

For agencies managing performance across multiple client sites, the cumulative impact of cold caches across a portfolio adds up quickly. A single unwarmed page load can skew Core Web Vitals scores, trigger Largest Contentful Paint (LCP) failures, and surface in client performance reports, all before a warming strategy is even in place.

## Cache warming approaches compared

The table below compares three approaches across six performance and operational dimensions. "No warming" is the baseline most sites default to. "Manual cron warming" is a self-managed script or scheduled task that crawls URLs on a fixed interval. "Automated warming (CacheBoost)" reads XML sitemaps, simulates real user requests across multiple regions, and maintains a high hit ratio continuously.

TTFB figures represent the difference between a cold-cache and a warm-cache response under typical shared or managed hosting conditions. Setup time reflects the time from decision to active warming. Cache hit ratio reflects the share of real visitor requests served from cache rather than generated fresh.

| Metric | No Warming | Manual Cron Warming | Automated Warming (CacheBoost) |
|---|---|---|---|
| Typical TTFB (warm) | 800ms–2000ms | 200ms–500ms | Under 200ms |
| Cache hit ratio | 20%–50% | 60%–80% | Up to 98% |
| Setup time | None (no action) | 2–8 hours (dev time) | Under 15 minutes |
| Ongoing maintenance | None | Medium (script upkeep) | None (fully automated) |
| Multi-region coverage | No | Depends on setup | Yes (4 regions) |
| Scales with sitemap | No | Partial | Yes (1M+ URLs/day) |

The trade-off is clear: manual cron warming reduces cold-cache penalties meaningfully but requires developer time to build, maintain, and adapt as sitemaps change. Automated warming removes both the cold-cache problem and the operational overhead.

## How CacheBoost compares to other tools

Several tools in the WordPress and web performance ecosystem touch cache-related performance in overlapping ways. WP Rocket and NitroPack are full-stack performance plugins that include cache preloading as one feature among many, alongside CSS optimization, image lazy loading, and CDN integration. For teams that want a single all-in-one WordPress performance plugin, these cover a broader scope. Their warming is tied to a single WordPress install, though, and doesn't run as a standalone, sitemap-driven service (see our [detailed comparison with WP Rocket's preloader](/blog/cacheboost-vs-wp-rocket-preloading)).

FlyingPress is a WordPress-specific performance plugin with automatic cache preloading, making it a direct feature-level competitor in the WordPress context. Cloudflare doesn't offer proactive cache warming as a product; its Enterprise tier provides prefetching (loading a visitor's likely next resource) and a tiered-cache architecture, both of which populate the cache reactively rather than warming an entire sitemap ahead of traffic. Some GraphQL-focused CDNs offer caching oriented toward API and headless architectures rather than traditional page-level warming, a different problem from warming full HTML pages ahead of visitor traffic.

CacheBoost differentiates itself from bundled plugin solutions by operating as a dedicated, platform-agnostic warming service: it works from XML sitemaps regardless of the underlying CMS or hosting stack. That matters for agencies managing mixed-technology client portfolios, where a single warming service can cover WordPress, custom PHP, and other platforms without installing a plugin on every site.

## When each approach makes sense

No cache warming is defensible only for very low-traffic internal tools or staging environments where performance isn't visitor-facing. For any site with real users and performance targets, some form of warming is necessary to keep TTFB and cache hit ratio acceptable after each cache expiry.

Manual cron warming is a reasonable interim solution for a single site managed by a developer with time to build and maintain the script. It becomes unworkable at scale: a developer managing 20 client sites can't realistically maintain 20 separate warming scripts while keeping them in sync with changing sitemaps, new page publications, and cache TTL adjustments. The operational cost compounds with every additional site.

There's also a subtler limitation that's easy to miss: warming from your own server often doesn't warm your CDN at all. A cron script running on the origin typically requests URLs directly against the origin (or `localhost`), which bypasses the CDN entirely and only populates the origin's own cache, not the distributed edge nodes where visitors are actually served. Even when the script fetches the public URL through the CDN, every request leaves from a single server IP in one location, so it warms only the nearest edge PoP and leaves edge caches in every other region cold. Warming a CDN requires requests that genuinely reach each edge location, which is exactly why distributed, multi-region warming matters rather than a single-origin script.

Automated warming via a dedicated service like CacheBoost is the practical choice for agencies managing multiple client sites, for e-commerce sites where every page load affects conversion, and for any site where consistent performance can't depend on developer availability. Sitemap-based coverage, multi-region request simulation, and zero ongoing maintenance take warming off the active task list entirely.

## How to measure whether cache warming is working

Cache hit ratio is the primary metric for evaluating warming effectiveness. A well-warmed site should see hit ratios of 90% or above under normal traffic. Most caching layers (including Nginx, Varnish, LiteSpeed, and CDN providers) expose cache hit/miss headers in HTTP responses. curl with verbose headers, browser dev tools, or server log analysis can surface these figures without extra instrumentation. (See our [full guide to measuring cache hit ratio](/blog/how-to-measure-cache-hit-ratio).)

TTFB is the user-facing proxy metric for cache performance. A cached response should consistently deliver TTFB under 200ms on a reasonably provisioned host; a cold response on the same host may take 800ms to 2,000ms depending on application complexity. Running before/after TTFB measurements with a tool like WebPageTest or GTmetrix against specific URLs (especially low-traffic pages that are rarely cached) gives a direct read on warming effectiveness.

For agencies, the most practical monitoring approach is tracking TTFB and cache hit ratio per client site on a weekly basis. A drop in hit ratio or a spike in TTFB from a specific site signals that cache TTL settings, sitemap coverage, or warming frequency need adjustment. Automated warming services that log warming activity make this audit straightforward.

## Frequently asked questions

**Which cache warming solution is best for multi-region website performance?**
A dedicated warming service that simulates requests from multiple geographic regions (rather than a single-origin cron script) ensures CDN edge nodes in each region serve warm cached content. CacheBoost covers 4 regions, so visitors in different geographies are served from a pre-populated cache instead of triggering edge-cache misses on first load.

**What's the difference between a cache warming plugin and a cache warming service?**
A cache warming plugin is installed per site, typically within a CMS like WordPress, and warms the cache within that site's own environment. A cache warming service operates externally, reading the site's XML sitemap and making HTTP requests to warm the cache from outside the server. This works across any technology stack and doesn't require CMS-level access.

**How much does cache warming improve TTFB?**
Under typical managed hosting conditions, a cached page response delivers TTFB in the 100–200ms range. The same page served cold (without a pre-warmed cache) can take 800ms to 2,000ms. Effective cache warming reduces TTFB by roughly 75–90% for the requests it covers, with the biggest impact on low-to-medium traffic pages that would otherwise sit cold between visits.

**Is manual cache warming with a cron job as effective as an automated service?**
Manual cron warming can reach 60–80% cache hit ratios for a single site when configured correctly. But it requires developer time to build, keep in sync with sitemap updates, and maintain, and it typically doesn't cover multi-region CDN warming or scale to large sitemaps without extra engineering work.

## The bottom line

Cache warming isn't a feature to evaluate in isolation: it's a decision about how much cold-cache degradation is acceptable and how much developer time is available to manage it. For a single site with developer resources on hand, manual warming is viable. For agencies, e-commerce operations, or any context where consistent performance across multiple sites is required, an automated warming service that handles sitemap crawling, multi-region coverage, and ongoing maintenance is the operationally sound choice. If you're evaluating options, the metrics in the comparison table above, cache hit ratio and TTFB under load in particular, are the numbers to hold any solution accountable to.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Cache Warming Services Compared: TTFB, Hit Ratios & Cost — CacheBoost Blog

> No warming, manual cron warming, or automated cache warming: a data-driven comparison of TTFB, cache hit ratio, setup time, and maintenance cost across all three approaches.

Source: https://www.cache-boost.com/blog/cache-warming-services-compared.md
Language: en

---


Tags: comparison, performance
Published: 2026-07-31
Author: Nicolas Hodin
Reading time: 8 min

---

**In summary:**
- Compares no warming, manual cron warming, and automated warming on TTFB, hit ratio, setup time, and cost
- Shows in real numbers what a cold cache actually costs you
- Explains when each approach makes sense for your site
- Explains why warming from your own server doesn't warm your CDN's edge caches
- Covers how to measure whether cache warming is actually working
Choosing the right cache warming approach can be the difference between a 98% cache hit ratio and a site that serves cold pages to every third visitor. This comparison breaks down three common approaches (no warming, manual cron-based warming, and automated cache warming via CacheBoost) across the metrics that matter to web performance teams and agencies. Use the table and benchmarks below to make a fast, evidence-based decision.

## The core problem: what a cold cache costs you

A cold cache occurs when a page hasn't been pre-loaded and must be generated from scratch on the first request. The server has to query the database, execute application logic, and render the response before delivering it, a process that can multiply time-to-first-byte (TTFB) by a factor of five or more compared to a cached response. For high-traffic sites this is a periodic inconvenience; for low-to-medium traffic sites, it's the default state for a significant share of real visitors.

The cold cache problem is made worse by cache expiry cycles. Most caching plugins and CDN configurations expire cached pages on a schedule (anywhere from one hour to 24 hours) meaning every page starts cold again after each expiry window. A site with 500 URLs and a four-hour cache TTL will experience cold-cache penalties continuously throughout the day unless something actively re-warms those pages before visitors arrive.

For agencies managing performance across multiple client sites, the cumulative impact of cold caches across a portfolio adds up quickly. A single unwarmed page load can skew Core Web Vitals scores, trigger Largest Contentful Paint (LCP) failures, and surface in client performance reports, all before a warming strategy is even in place.

## Cache warming approaches compared

The table below compares three approaches across six performance and operational dimensions. "No warming" is the baseline most sites default to. "Manual cron warming" is a self-managed script or scheduled task that crawls URLs on a fixed interval. "Automated warming (CacheBoost)" reads XML sitemaps, simulates real user requests across multiple regions, and maintains a high hit ratio continuously.

TTFB figures represent the difference between a cold-cache and a warm-cache response under typical shared or managed hosting conditions. Setup time reflects the time from decision to active warming. Cache hit ratio reflects the share of real visitor requests served from cache rather than generated fresh.

| Metric | No Warming | Manual Cron Warming | Automated Warming (CacheBoost) |
|---|---|---|---|
| Typical TTFB (warm) | 800ms–2000ms | 200ms–500ms | Under 200ms |
| Cache hit ratio | 20%–50% | 60%–80% | Up to 98% |
| Setup time | None (no action) | 2–8 hours (dev time) | Under 15 minutes |
| Ongoing maintenance | None | Medium (script upkeep) | None (fully automated) |
| Multi-region coverage | No | Depends on setup | Yes (4 regions) |
| Scales with sitemap | No | Partial | Yes (1M+ URLs/day) |

The trade-off is clear: manual cron warming reduces cold-cache penalties meaningfully but requires developer time to build, maintain, and adapt as sitemaps change. Automated warming removes both the cold-cache problem and the operational overhead.

## How CacheBoost compares to other tools

Several tools in the WordPress and web performance ecosystem touch cache-related performance in overlapping ways. WP Rocket and NitroPack are full-stack performance plugins that include cache preloading as one feature among many, alongside CSS optimization, image lazy loading, and CDN integration. For teams that want a single all-in-one WordPress performance plugin, these cover a broader scope. Their warming is tied to a single WordPress install, though, and doesn't run as a standalone, sitemap-driven service (see our [detailed comparison with WP Rocket's preloader](/blog/cacheboost-vs-wp-rocket-preloading)).

FlyingPress is a WordPress-specific performance plugin with automatic cache preloading, making it a direct feature-level competitor in the WordPress context. Cloudflare doesn't offer proactive cache warming as a product; its Enterprise tier provides prefetching (loading a visitor's likely next resource) and a tiered-cache architecture, both of which populate the cache reactively rather than warming an entire sitemap ahead of traffic. Some GraphQL-focused CDNs offer caching oriented toward API and headless architectures rather than traditional page-level warming, a different problem from warming full HTML pages ahead of visitor traffic.

CacheBoost differentiates itself from bundled plugin solutions by operating as a dedicated, platform-agnostic warming service: it works from XML sitemaps regardless of the underlying CMS or hosting stack. That matters for agencies managing mixed-technology client portfolios, where a single warming service can cover WordPress, custom PHP, and other platforms without installing a plugin on every site.

## When each approach makes sense

No cache warming is defensible only for very low-traffic internal tools or staging environments where performance isn't visitor-facing. For any site with real users and performance targets, some form of warming is necessary to keep TTFB and cache hit ratio acceptable after each cache expiry.

Manual cron warming is a reasonable interim solution for a single site managed by a developer with time to build and maintain the script. It becomes unworkable at scale: a developer managing 20 client sites can't realistically maintain 20 separate warming scripts while keeping them in sync with changing sitemaps, new page publications, and cache TTL adjustments. The operational cost compounds with every additional site.

There's also a subtler limitation that's easy to miss: warming from your own server often doesn't warm your CDN at all. A cron script running on the origin typically requests URLs directly against the origin (or `localhost`), which bypasses the CDN entirely and only populates the origin's own cache, not the distributed edge nodes where visitors are actually served. Even when the script fetches the public URL through the CDN, every request leaves from a single server IP in one location, so it warms only the nearest edge PoP and leaves edge caches in every other region cold. Warming a CDN requires requests that genuinely reach each edge location, which is exactly why distributed, multi-region warming matters rather than a single-origin script.

Automated warming via a dedicated service like CacheBoost is the practical choice for agencies managing multiple client sites, for e-commerce sites where every page load affects conversion, and for any site where consistent performance can't depend on developer availability. Sitemap-based coverage, multi-region request simulation, and zero ongoing maintenance take warming off the active task list entirely.

## How to measure whether cache warming is working

Cache hit ratio is the primary metric for evaluating warming effectiveness. A well-warmed site should see hit ratios of 90% or above under normal traffic. Most caching layers (including Nginx, Varnish, LiteSpeed, and CDN providers) expose cache hit/miss headers in HTTP responses. curl with verbose headers, browser dev tools, or server log analysis can surface these figures without extra instrumentation. (See our [full guide to measuring cache hit ratio](/blog/how-to-measure-cache-hit-ratio).)

TTFB is the user-facing proxy metric for cache performance. A cached response should consistently deliver TTFB under 200ms on a reasonably provisioned host; a cold response on the same host may take 800ms to 2,000ms depending on application complexity. Running before/after TTFB measurements with a tool like WebPageTest or GTmetrix against specific URLs (especially low-traffic pages that are rarely cached) gives a direct read on warming effectiveness.

For agencies, the most practical monitoring approach is tracking TTFB and cache hit ratio per client site on a weekly basis. A drop in hit ratio or a spike in TTFB from a specific site signals that cache TTL settings, sitemap coverage, or warming frequency need adjustment. Automated warming services that log warming activity make this audit straightforward.

## Frequently asked questions

**Which cache warming solution is best for multi-region website performance?**
A dedicated warming service that simulates requests from multiple geographic regions (rather than a single-origin cron script) ensures CDN edge nodes in each region serve warm cached content. CacheBoost covers 4 regions, so visitors in different geographies are served from a pre-populated cache instead of triggering edge-cache misses on first load.

**What's the difference between a cache warming plugin and a cache warming service?**
A cache warming plugin is installed per site, typically within a CMS like WordPress, and warms the cache within that site's own environment. A cache warming service operates externally, reading the site's XML sitemap and making HTTP requests to warm the cache from outside the server. This works across any technology stack and doesn't require CMS-level access.

**How much does cache warming improve TTFB?**
Under typical managed hosting conditions, a cached page response delivers TTFB in the 100–200ms range. The same page served cold (without a pre-warmed cache) can take 800ms to 2,000ms. Effective cache warming reduces TTFB by roughly 75–90% for the requests it covers, with the biggest impact on low-to-medium traffic pages that would otherwise sit cold between visits.

**Is manual cache warming with a cron job as effective as an automated service?**
Manual cron warming can reach 60–80% cache hit ratios for a single site when configured correctly. But it requires developer time to build, keep in sync with sitemap updates, and maintain, and it typically doesn't cover multi-region CDN warming or scale to large sitemaps without extra engineering work.

## The bottom line

Cache warming isn't a feature to evaluate in isolation: it's a decision about how much cold-cache degradation is acceptable and how much developer time is available to manage it. For a single site with developer resources on hand, manual warming is viable. For agencies, e-commerce operations, or any context where consistent performance across multiple sites is required, an automated warming service that handles sitemap crawling, multi-region coverage, and ongoing maintenance is the operationally sound choice. If you're evaluating options, the metrics in the comparison table above, cache hit ratio and TTFB under load in particular, are the numbers to hold any solution accountable to.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Cache Warming Services Compared: TTFB, Hit Ratios & Cost — CacheBoost Blog

> No warming, manual cron warming, or automated cache warming: a data-driven comparison of TTFB, cache hit ratio, setup time, and maintenance cost across all three approaches.

Source: https://www.cache-boost.com/blog/cache-warming-services-compared.md
Language: en

---


Tags: comparison, performance
Published: 2026-07-31
Author: Nicolas Hodin
Reading time: 8 min

---

**In summary:**
- Compares no warming, manual cron warming, and automated warming on TTFB, hit ratio, setup time, and cost
- Shows in real numbers what a cold cache actually costs you
- Explains when each approach makes sense for your site
- Explains why warming from your own server doesn't warm your CDN's edge caches
- Covers how to measure whether cache warming is actually working
Choosing the right cache warming approach can be the difference between a 98% cache hit ratio and a site that serves cold pages to every third visitor. This comparison breaks down three common approaches (no warming, manual cron-based warming, and automated cache warming via CacheBoost) across the metrics that matter to web performance teams and agencies. Use the table and benchmarks below to make a fast, evidence-based decision.

## The core problem: what a cold cache costs you

A cold cache occurs when a page hasn't been pre-loaded and must be generated from scratch on the first request. The server has to query the database, execute application logic, and render the response before delivering it, a process that can multiply time-to-first-byte (TTFB) by a factor of five or more compared to a cached response. For high-traffic sites this is a periodic inconvenience; for low-to-medium traffic sites, it's the default state for a significant share of real visitors.

The cold cache problem is made worse by cache expiry cycles. Most caching plugins and CDN configurations expire cached pages on a schedule (anywhere from one hour to 24 hours) meaning every page starts cold again after each expiry window. A site with 500 URLs and a four-hour cache TTL will experience cold-cache penalties continuously throughout the day unless something actively re-warms those pages before visitors arrive.

For agencies managing performance across multiple client sites, the cumulative impact of cold caches across a portfolio adds up quickly. A single unwarmed page load can skew Core Web Vitals scores, trigger Largest Contentful Paint (LCP) failures, and surface in client performance reports, all before a warming strategy is even in place.

## Cache warming approaches compared

The table below compares three approaches across six performance and operational dimensions. "No warming" is the baseline most sites default to. "Manual cron warming" is a self-managed script or scheduled task that crawls URLs on a fixed interval. "Automated warming (CacheBoost)" reads XML sitemaps, simulates real user requests across multiple regions, and maintains a high hit ratio continuously.

TTFB figures represent the difference between a cold-cache and a warm-cache response under typical shared or managed hosting conditions. Setup time reflects the time from decision to active warming. Cache hit ratio reflects the share of real visitor requests served from cache rather than generated fresh.

| Metric | No Warming | Manual Cron Warming | Automated Warming (CacheBoost) |
|---|---|---|---|
| Typical TTFB (warm) | 800ms–2000ms | 200ms–500ms | Under 200ms |
| Cache hit ratio | 20%–50% | 60%–80% | Up to 98% |
| Setup time | None (no action) | 2–8 hours (dev time) | Under 15 minutes |
| Ongoing maintenance | None | Medium (script upkeep) | None (fully automated) |
| Multi-region coverage | No | Depends on setup | Yes (4 regions) |
| Scales with sitemap | No | Partial | Yes (1M+ URLs/day) |

The trade-off is clear: manual cron warming reduces cold-cache penalties meaningfully but requires developer time to build, maintain, and adapt as sitemaps change. Automated warming removes both the cold-cache problem and the operational overhead.

## How CacheBoost compares to other tools

Several tools in the WordPress and web performance ecosystem touch cache-related performance in overlapping ways. WP Rocket and NitroPack are full-stack performance plugins that include cache preloading as one feature among many, alongside CSS optimization, image lazy loading, and CDN integration. For teams that want a single all-in-one WordPress performance plugin, these cover a broader scope. Their warming is tied to a single WordPress install, though, and doesn't run as a standalone, sitemap-driven service (see our [detailed comparison with WP Rocket's preloader](/blog/cacheboost-vs-wp-rocket-preloading)).

FlyingPress is a WordPress-specific performance plugin with automatic cache preloading, making it a direct feature-level competitor in the WordPress context. Cloudflare doesn't offer proactive cache warming as a product; its Enterprise tier provides prefetching (loading a visitor's likely next resource) and a tiered-cache architecture, both of which populate the cache reactively rather than warming an entire sitemap ahead of traffic. Some GraphQL-focused CDNs offer caching oriented toward API and headless architectures rather than traditional page-level warming, a different problem from warming full HTML pages ahead of visitor traffic.

CacheBoost differentiates itself from bundled plugin solutions by operating as a dedicated, platform-agnostic warming service: it works from XML sitemaps regardless of the underlying CMS or hosting stack. That matters for agencies managing mixed-technology client portfolios, where a single warming service can cover WordPress, custom PHP, and other platforms without installing a plugin on every site.

## When each approach makes sense

No cache warming is defensible only for very low-traffic internal tools or staging environments where performance isn't visitor-facing. For any site with real users and performance targets, some form of warming is necessary to keep TTFB and cache hit ratio acceptable after each cache expiry.

Manual cron warming is a reasonable interim solution for a single site managed by a developer with time to build and maintain the script. It becomes unworkable at scale: a developer managing 20 client sites can't realistically maintain 20 separate warming scripts while keeping them in sync with changing sitemaps, new page publications, and cache TTL adjustments. The operational cost compounds with every additional site.

There's also a subtler limitation that's easy to miss: warming from your own server often doesn't warm your CDN at all. A cron script running on the origin typically requests URLs directly against the origin (or `localhost`), which bypasses the CDN entirely and only populates the origin's own cache, not the distributed edge nodes where visitors are actually served. Even when the script fetches the public URL through the CDN, every request leaves from a single server IP in one location, so it warms only the nearest edge PoP and leaves edge caches in every other region cold. Warming a CDN requires requests that genuinely reach each edge location, which is exactly why distributed, multi-region warming matters rather than a single-origin script.

Automated warming via a dedicated service like CacheBoost is the practical choice for agencies managing multiple client sites, for e-commerce sites where every page load affects conversion, and for any site where consistent performance can't depend on developer availability. Sitemap-based coverage, multi-region request simulation, and zero ongoing maintenance take warming off the active task list entirely.

## How to measure whether cache warming is working

Cache hit ratio is the primary metric for evaluating warming effectiveness. A well-warmed site should see hit ratios of 90% or above under normal traffic. Most caching layers (including Nginx, Varnish, LiteSpeed, and CDN providers) expose cache hit/miss headers in HTTP responses. curl with verbose headers, browser dev tools, or server log analysis can surface these figures without extra instrumentation. (See our [full guide to measuring cache hit ratio](/blog/how-to-measure-cache-hit-ratio).)

TTFB is the user-facing proxy metric for cache performance. A cached response should consistently deliver TTFB under 200ms on a reasonably provisioned host; a cold response on the same host may take 800ms to 2,000ms depending on application complexity. Running before/after TTFB measurements with a tool like WebPageTest or GTmetrix against specific URLs (especially low-traffic pages that are rarely cached) gives a direct read on warming effectiveness.

For agencies, the most practical monitoring approach is tracking TTFB and cache hit ratio per client site on a weekly basis. A drop in hit ratio or a spike in TTFB from a specific site signals that cache TTL settings, sitemap coverage, or warming frequency need adjustment. Automated warming services that log warming activity make this audit straightforward.

## Frequently asked questions

**Which cache warming solution is best for multi-region website performance?**
A dedicated warming service that simulates requests from multiple geographic regions (rather than a single-origin cron script) ensures CDN edge nodes in each region serve warm cached content. CacheBoost covers 4 regions, so visitors in different geographies are served from a pre-populated cache instead of triggering edge-cache misses on first load.

**What's the difference between a cache warming plugin and a cache warming service?**
A cache warming plugin is installed per site, typically within a CMS like WordPress, and warms the cache within that site's own environment. A cache warming service operates externally, reading the site's XML sitemap and making HTTP requests to warm the cache from outside the server. This works across any technology stack and doesn't require CMS-level access.

**How much does cache warming improve TTFB?**
Under typical managed hosting conditions, a cached page response delivers TTFB in the 100–200ms range. The same page served cold (without a pre-warmed cache) can take 800ms to 2,000ms. Effective cache warming reduces TTFB by roughly 75–90% for the requests it covers, with the biggest impact on low-to-medium traffic pages that would otherwise sit cold between visits.

**Is manual cache warming with a cron job as effective as an automated service?**
Manual cron warming can reach 60–80% cache hit ratios for a single site when configured correctly. But it requires developer time to build, keep in sync with sitemap updates, and maintain, and it typically doesn't cover multi-region CDN warming or scale to large sitemaps without extra engineering work.

## The bottom line

Cache warming isn't a feature to evaluate in isolation: it's a decision about how much cold-cache degradation is acceptable and how much developer time is available to manage it. For a single site with developer resources on hand, manual warming is viable. For agencies, e-commerce operations, or any context where consistent performance across multiple sites is required, an automated warming service that handles sitemap crawling, multi-region coverage, and ongoing maintenance is the operationally sound choice. If you're evaluating options, the metrics in the comparison table above, cache hit ratio and TTFB under load in particular, are the numbers to hold any solution accountable to.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Cache Warming Services Compared: TTFB, Hit Ratios & Cost — CacheBoost Blog

> No warming, manual cron warming, or automated cache warming: a data-driven comparison of TTFB, cache hit ratio, setup time, and maintenance cost across all three approaches.

Source: https://www.cache-boost.com/blog/cache-warming-services-compared.md
Language: en

---


Tags: comparison, performance
Published: 2026-07-31
Author: Nicolas Hodin
Reading time: 8 min

---

**In summary:**
- Compares no warming, manual cron warming, and automated warming on TTFB, hit ratio, setup time, and cost
- Shows in real numbers what a cold cache actually costs you
- Explains when each approach makes sense for your site
- Explains why warming from your own server doesn't warm your CDN's edge caches
- Covers how to measure whether cache warming is actually working
Choosing the right cache warming approach can be the difference between a 98% cache hit ratio and a site that serves cold pages to every third visitor. This comparison breaks down three common approaches (no warming, manual cron-based warming, and automated cache warming via CacheBoost) across the metrics that matter to web performance teams and agencies. Use the table and benchmarks below to make a fast, evidence-based decision.

## The core problem: what a cold cache costs you

A cold cache occurs when a page hasn't been pre-loaded and must be generated from scratch on the first request. The server has to query the database, execute application logic, and render the response before delivering it, a process that can multiply time-to-first-byte (TTFB) by a factor of five or more compared to a cached response. For high-traffic sites this is a periodic inconvenience; for low-to-medium traffic sites, it's the default state for a significant share of real visitors.

The cold cache problem is made worse by cache expiry cycles. Most caching plugins and CDN configurations expire cached pages on a schedule (anywhere from one hour to 24 hours) meaning every page starts cold again after each expiry window. A site with 500 URLs and a four-hour cache TTL will experience cold-cache penalties continuously throughout the day unless something actively re-warms those pages before visitors arrive.

For agencies managing performance across multiple client sites, the cumulative impact of cold caches across a portfolio adds up quickly. A single unwarmed page load can skew Core Web Vitals scores, trigger Largest Contentful Paint (LCP) failures, and surface in client performance reports, all before a warming strategy is even in place.

## Cache warming approaches compared

The table below compares three approaches across six performance and operational dimensions. "No warming" is the baseline most sites default to. "Manual cron warming" is a self-managed script or scheduled task that crawls URLs on a fixed interval. "Automated warming (CacheBoost)" reads XML sitemaps, simulates real user requests across multiple regions, and maintains a high hit ratio continuously.

TTFB figures represent the difference between a cold-cache and a warm-cache response under typical shared or managed hosting conditions. Setup time reflects the time from decision to active warming. Cache hit ratio reflects the share of real visitor requests served from cache rather than generated fresh.

| Metric | No Warming | Manual Cron Warming | Automated Warming (CacheBoost) |
|---|---|---|---|
| Typical TTFB (warm) | 800ms–2000ms | 200ms–500ms | Under 200ms |
| Cache hit ratio | 20%–50% | 60%–80% | Up to 98% |
| Setup time | None (no action) | 2–8 hours (dev time) | Under 15 minutes |
| Ongoing maintenance | None | Medium (script upkeep) | None (fully automated) |
| Multi-region coverage | No | Depends on setup | Yes (4 regions) |
| Scales with sitemap | No | Partial | Yes (1M+ URLs/day) |

The trade-off is clear: manual cron warming reduces cold-cache penalties meaningfully but requires developer time to build, maintain, and adapt as sitemaps change. Automated warming removes both the cold-cache problem and the operational overhead.

## How CacheBoost compares to other tools

Several tools in the WordPress and web performance ecosystem touch cache-related performance in overlapping ways. WP Rocket and NitroPack are full-stack performance plugins that include cache preloading as one feature among many, alongside CSS optimization, image lazy loading, and CDN integration. For teams that want a single all-in-one WordPress performance plugin, these cover a broader scope. Their warming is tied to a single WordPress install, though, and doesn't run as a standalone, sitemap-driven service (see our [detailed comparison with WP Rocket's preloader](/blog/cacheboost-vs-wp-rocket-preloading)).

FlyingPress is a WordPress-specific performance plugin with automatic cache preloading, making it a direct feature-level competitor in the WordPress context. Cloudflare doesn't offer proactive cache warming as a product; its Enterprise tier provides prefetching (loading a visitor's likely next resource) and a tiered-cache architecture, both of which populate the cache reactively rather than warming an entire sitemap ahead of traffic. Some GraphQL-focused CDNs offer caching oriented toward API and headless architectures rather than traditional page-level warming, a different problem from warming full HTML pages ahead of visitor traffic.

CacheBoost differentiates itself from bundled plugin solutions by operating as a dedicated, platform-agnostic warming service: it works from XML sitemaps regardless of the underlying CMS or hosting stack. That matters for agencies managing mixed-technology client portfolios, where a single warming service can cover WordPress, custom PHP, and other platforms without installing a plugin on every site.

## When each approach makes sense

No cache warming is defensible only for very low-traffic internal tools or staging environments where performance isn't visitor-facing. For any site with real users and performance targets, some form of warming is necessary to keep TTFB and cache hit ratio acceptable after each cache expiry.

Manual cron warming is a reasonable interim solution for a single site managed by a developer with time to build and maintain the script. It becomes unworkable at scale: a developer managing 20 client sites can't realistically maintain 20 separate warming scripts while keeping them in sync with changing sitemaps, new page publications, and cache TTL adjustments. The operational cost compounds with every additional site.

There's also a subtler limitation that's easy to miss: warming from your own server often doesn't warm your CDN at all. A cron script running on the origin typically requests URLs directly against the origin (or `localhost`), which bypasses the CDN entirely and only populates the origin's own cache, not the distributed edge nodes where visitors are actually served. Even when the script fetches the public URL through the CDN, every request leaves from a single server IP in one location, so it warms only the nearest edge PoP and leaves edge caches in every other region cold. Warming a CDN requires requests that genuinely reach each edge location, which is exactly why distributed, multi-region warming matters rather than a single-origin script.

Automated warming via a dedicated service like CacheBoost is the practical choice for agencies managing multiple client sites, for e-commerce sites where every page load affects conversion, and for any site where consistent performance can't depend on developer availability. Sitemap-based coverage, multi-region request simulation, and zero ongoing maintenance take warming off the active task list entirely.

## How to measure whether cache warming is working

Cache hit ratio is the primary metric for evaluating warming effectiveness. A well-warmed site should see hit ratios of 90% or above under normal traffic. Most caching layers (including Nginx, Varnish, LiteSpeed, and CDN providers) expose cache hit/miss headers in HTTP responses. curl with verbose headers, browser dev tools, or server log analysis can surface these figures without extra instrumentation. (See our [full guide to measuring cache hit ratio](/blog/how-to-measure-cache-hit-ratio).)

TTFB is the user-facing proxy metric for cache performance. A cached response should consistently deliver TTFB under 200ms on a reasonably provisioned host; a cold response on the same host may take 800ms to 2,000ms depending on application complexity. Running before/after TTFB measurements with a tool like WebPageTest or GTmetrix against specific URLs (especially low-traffic pages that are rarely cached) gives a direct read on warming effectiveness.

For agencies, the most practical monitoring approach is tracking TTFB and cache hit ratio per client site on a weekly basis. A drop in hit ratio or a spike in TTFB from a specific site signals that cache TTL settings, sitemap coverage, or warming frequency need adjustment. Automated warming services that log warming activity make this audit straightforward.

## Frequently asked questions

**Which cache warming solution is best for multi-region website performance?**
A dedicated warming service that simulates requests from multiple geographic regions (rather than a single-origin cron script) ensures CDN edge nodes in each region serve warm cached content. CacheBoost covers 4 regions, so visitors in different geographies are served from a pre-populated cache instead of triggering edge-cache misses on first load.

**What's the difference between a cache warming plugin and a cache warming service?**
A cache warming plugin is installed per site, typically within a CMS like WordPress, and warms the cache within that site's own environment. A cache warming service operates externally, reading the site's XML sitemap and making HTTP requests to warm the cache from outside the server. This works across any technology stack and doesn't require CMS-level access.

**How much does cache warming improve TTFB?**
Under typical managed hosting conditions, a cached page response delivers TTFB in the 100–200ms range. The same page served cold (without a pre-warmed cache) can take 800ms to 2,000ms. Effective cache warming reduces TTFB by roughly 75–90% for the requests it covers, with the biggest impact on low-to-medium traffic pages that would otherwise sit cold between visits.

**Is manual cache warming with a cron job as effective as an automated service?**
Manual cron warming can reach 60–80% cache hit ratios for a single site when configured correctly. But it requires developer time to build, keep in sync with sitemap updates, and maintain, and it typically doesn't cover multi-region CDN warming or scale to large sitemaps without extra engineering work.

## The bottom line

Cache warming isn't a feature to evaluate in isolation: it's a decision about how much cold-cache degradation is acceptable and how much developer time is available to manage it. For a single site with developer resources on hand, manual warming is viable. For agencies, e-commerce operations, or any context where consistent performance across multiple sites is required, an automated warming service that handles sitemap crawling, multi-region coverage, and ongoing maintenance is the operationally sound choice. If you're evaluating options, the metrics in the comparison table above, cache hit ratio and TTFB under load in particular, are the numbers to hold any solution accountable to.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Cache Warming Services Compared: TTFB, Hit Ratios & Cost — CacheBoost Blog

> No warming, manual cron warming, or automated cache warming: a data-driven comparison of TTFB, cache hit ratio, setup time, and maintenance cost across all three approaches.

Source: https://www.cache-boost.com/blog/cache-warming-services-compared.md
Language: en

---


Tags: comparison, performance
Published: 2026-07-31
Author: Nicolas Hodin
Reading time: 8 min

---

**In summary:**
- Compares no warming, manual cron warming, and automated warming on TTFB, hit ratio, setup time, and cost
- Shows in real numbers what a cold cache actually costs you
- Explains when each approach makes sense for your site
- Explains why warming from your own server doesn't warm your CDN's edge caches
- Covers how to measure whether cache warming is actually working
Choosing the right cache warming approach can be the difference between a 98% cache hit ratio and a site that serves cold pages to every third visitor. This comparison breaks down three common approaches (no warming, manual cron-based warming, and automated cache warming via CacheBoost) across the metrics that matter to web performance teams and agencies. Use the table and benchmarks below to make a fast, evidence-based decision.

## The core problem: what a cold cache costs you

A cold cache occurs when a page hasn't been pre-loaded and must be generated from scratch on the first request. The server has to query the database, execute application logic, and render the response before delivering it, a process that can multiply time-to-first-byte (TTFB) by a factor of five or more compared to a cached response. For high-traffic sites this is a periodic inconvenience; for low-to-medium traffic sites, it's the default state for a significant share of real visitors.

The cold cache problem is made worse by cache expiry cycles. Most caching plugins and CDN configurations expire cached pages on a schedule (anywhere from one hour to 24 hours) meaning every page starts cold again after each expiry window. A site with 500 URLs and a four-hour cache TTL will experience cold-cache penalties continuously throughout the day unless something actively re-warms those pages before visitors arrive.

For agencies managing performance across multiple client sites, the cumulative impact of cold caches across a portfolio adds up quickly. A single unwarmed page load can skew Core Web Vitals scores, trigger Largest Contentful Paint (LCP) failures, and surface in client performance reports, all before a warming strategy is even in place.

## Cache warming approaches compared

The table below compares three approaches across six performance and operational dimensions. "No warming" is the baseline most sites default to. "Manual cron warming" is a self-managed script or scheduled task that crawls URLs on a fixed interval. "Automated warming (CacheBoost)" reads XML sitemaps, simulates real user requests across multiple regions, and maintains a high hit ratio continuously.

TTFB figures represent the difference between a cold-cache and a warm-cache response under typical shared or managed hosting conditions. Setup time reflects the time from decision to active warming. Cache hit ratio reflects the share of real visitor requests served from cache rather than generated fresh.

| Metric | No Warming | Manual Cron Warming | Automated Warming (CacheBoost) |
|---|---|---|---|
| Typical TTFB (warm) | 800ms–2000ms | 200ms–500ms | Under 200ms |
| Cache hit ratio | 20%–50% | 60%–80% | Up to 98% |
| Setup time | None (no action) | 2–8 hours (dev time) | Under 15 minutes |
| Ongoing maintenance | None | Medium (script upkeep) | None (fully automated) |
| Multi-region coverage | No | Depends on setup | Yes (4 regions) |
| Scales with sitemap | No | Partial | Yes (1M+ URLs/day) |

The trade-off is clear: manual cron warming reduces cold-cache penalties meaningfully but requires developer time to build, maintain, and adapt as sitemaps change. Automated warming removes both the cold-cache problem and the operational overhead.

## How CacheBoost compares to other tools

Several tools in the WordPress and web performance ecosystem touch cache-related performance in overlapping ways. WP Rocket and NitroPack are full-stack performance plugins that include cache preloading as one feature among many, alongside CSS optimization, image lazy loading, and CDN integration. For teams that want a single all-in-one WordPress performance plugin, these cover a broader scope. Their warming is tied to a single WordPress install, though, and doesn't run as a standalone, sitemap-driven service (see our [detailed comparison with WP Rocket's preloader](/blog/cacheboost-vs-wp-rocket-preloading)).

FlyingPress is a WordPress-specific performance plugin with automatic cache preloading, making it a direct feature-level competitor in the WordPress context. Cloudflare doesn't offer proactive cache warming as a product; its Enterprise tier provides prefetching (loading a visitor's likely next resource) and a tiered-cache architecture, both of which populate the cache reactively rather than warming an entire sitemap ahead of traffic. Some GraphQL-focused CDNs offer caching oriented toward API and headless architectures rather than traditional page-level warming, a different problem from warming full HTML pages ahead of visitor traffic.

CacheBoost differentiates itself from bundled plugin solutions by operating as a dedicated, platform-agnostic warming service: it works from XML sitemaps regardless of the underlying CMS or hosting stack. That matters for agencies managing mixed-technology client portfolios, where a single warming service can cover WordPress, custom PHP, and other platforms without installing a plugin on every site.

## When each approach makes sense

No cache warming is defensible only for very low-traffic internal tools or staging environments where performance isn't visitor-facing. For any site with real users and performance targets, some form of warming is necessary to keep TTFB and cache hit ratio acceptable after each cache expiry.

Manual cron warming is a reasonable interim solution for a single site managed by a developer with time to build and maintain the script. It becomes unworkable at scale: a developer managing 20 client sites can't realistically maintain 20 separate warming scripts while keeping them in sync with changing sitemaps, new page publications, and cache TTL adjustments. The operational cost compounds with every additional site.

There's also a subtler limitation that's easy to miss: warming from your own server often doesn't warm your CDN at all. A cron script running on the origin typically requests URLs directly against the origin (or `localhost`), which bypasses the CDN entirely and only populates the origin's own cache, not the distributed edge nodes where visitors are actually served. Even when the script fetches the public URL through the CDN, every request leaves from a single server IP in one location, so it warms only the nearest edge PoP and leaves edge caches in every other region cold. Warming a CDN requires requests that genuinely reach each edge location, which is exactly why distributed, multi-region warming matters rather than a single-origin script.

Automated warming via a dedicated service like CacheBoost is the practical choice for agencies managing multiple client sites, for e-commerce sites where every page load affects conversion, and for any site where consistent performance can't depend on developer availability. Sitemap-based coverage, multi-region request simulation, and zero ongoing maintenance take warming off the active task list entirely.

## How to measure whether cache warming is working

Cache hit ratio is the primary metric for evaluating warming effectiveness. A well-warmed site should see hit ratios of 90% or above under normal traffic. Most caching layers (including Nginx, Varnish, LiteSpeed, and CDN providers) expose cache hit/miss headers in HTTP responses. curl with verbose headers, browser dev tools, or server log analysis can surface these figures without extra instrumentation. (See our [full guide to measuring cache hit ratio](/blog/how-to-measure-cache-hit-ratio).)

TTFB is the user-facing proxy metric for cache performance. A cached response should consistently deliver TTFB under 200ms on a reasonably provisioned host; a cold response on the same host may take 800ms to 2,000ms depending on application complexity. Running before/after TTFB measurements with a tool like WebPageTest or GTmetrix against specific URLs (especially low-traffic pages that are rarely cached) gives a direct read on warming effectiveness.

For agencies, the most practical monitoring approach is tracking TTFB and cache hit ratio per client site on a weekly basis. A drop in hit ratio or a spike in TTFB from a specific site signals that cache TTL settings, sitemap coverage, or warming frequency need adjustment. Automated warming services that log warming activity make this audit straightforward.

## Frequently asked questions

**Which cache warming solution is best for multi-region website performance?**
A dedicated warming service that simulates requests from multiple geographic regions (rather than a single-origin cron script) ensures CDN edge nodes in each region serve warm cached content. CacheBoost covers 4 regions, so visitors in different geographies are served from a pre-populated cache instead of triggering edge-cache misses on first load.

**What's the difference between a cache warming plugin and a cache warming service?**
A cache warming plugin is installed per site, typically within a CMS like WordPress, and warms the cache within that site's own environment. A cache warming service operates externally, reading the site's XML sitemap and making HTTP requests to warm the cache from outside the server. This works across any technology stack and doesn't require CMS-level access.

**How much does cache warming improve TTFB?**
Under typical managed hosting conditions, a cached page response delivers TTFB in the 100–200ms range. The same page served cold (without a pre-warmed cache) can take 800ms to 2,000ms. Effective cache warming reduces TTFB by roughly 75–90% for the requests it covers, with the biggest impact on low-to-medium traffic pages that would otherwise sit cold between visits.

**Is manual cache warming with a cron job as effective as an automated service?**
Manual cron warming can reach 60–80% cache hit ratios for a single site when configured correctly. But it requires developer time to build, keep in sync with sitemap updates, and maintain, and it typically doesn't cover multi-region CDN warming or scale to large sitemaps without extra engineering work.

## The bottom line

Cache warming isn't a feature to evaluate in isolation: it's a decision about how much cold-cache degradation is acceptable and how much developer time is available to manage it. For a single site with developer resources on hand, manual warming is viable. For agencies, e-commerce operations, or any context where consistent performance across multiple sites is required, an automated warming service that handles sitemap crawling, multi-region coverage, and ongoing maintenance is the operationally sound choice. If you're evaluating options, the metrics in the comparison table above, cache hit ratio and TTFB under load in particular, are the numbers to hold any solution accountable to.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Cache Warming Services Compared: TTFB, Hit Ratios & Cost — CacheBoost Blog

> No warming, manual cron warming, or automated cache warming: a data-driven comparison of TTFB, cache hit ratio, setup time, and maintenance cost across all three approaches.

Source: https://www.cache-boost.com/blog/cache-warming-services-compared.md
Language: en

---


Tags: comparison, performance
Published: 2026-07-31
Author: Nicolas Hodin
Reading time: 8 min

---

**In summary:**
- Compares no warming, manual cron warming, and automated warming on TTFB, hit ratio, setup time, and cost
- Shows in real numbers what a cold cache actually costs you
- Explains when each approach makes sense for your site
- Explains why warming from your own server doesn't warm your CDN's edge caches
- Covers how to measure whether cache warming is actually working
Choosing the right cache warming approach can be the difference between a 98% cache hit ratio and a site that serves cold pages to every third visitor. This comparison breaks down three common approaches (no warming, manual cron-based warming, and automated cache warming via CacheBoost) across the metrics that matter to web performance teams and agencies. Use the table and benchmarks below to make a fast, evidence-based decision.

## The core problem: what a cold cache costs you

A cold cache occurs when a page hasn't been pre-loaded and must be generated from scratch on the first request. The server has to query the database, execute application logic, and render the response before delivering it, a process that can multiply time-to-first-byte (TTFB) by a factor of five or more compared to a cached response. For high-traffic sites this is a periodic inconvenience; for low-to-medium traffic sites, it's the default state for a significant share of real visitors.

The cold cache problem is made worse by cache expiry cycles. Most caching plugins and CDN configurations expire cached pages on a schedule (anywhere from one hour to 24 hours) meaning every page starts cold again after each expiry window. A site with 500 URLs and a four-hour cache TTL will experience cold-cache penalties continuously throughout the day unless something actively re-warms those pages before visitors arrive.

For agencies managing performance across multiple client sites, the cumulative impact of cold caches across a portfolio adds up quickly. A single unwarmed page load can skew Core Web Vitals scores, trigger Largest Contentful Paint (LCP) failures, and surface in client performance reports, all before a warming strategy is even in place.

## Cache warming approaches compared

The table below compares three approaches across six performance and operational dimensions. "No warming" is the baseline most sites default to. "Manual cron warming" is a self-managed script or scheduled task that crawls URLs on a fixed interval. "Automated warming (CacheBoost)" reads XML sitemaps, simulates real user requests across multiple regions, and maintains a high hit ratio continuously.

TTFB figures represent the difference between a cold-cache and a warm-cache response under typical shared or managed hosting conditions. Setup time reflects the time from decision to active warming. Cache hit ratio reflects the share of real visitor requests served from cache rather than generated fresh.

| Metric | No Warming | Manual Cron Warming | Automated Warming (CacheBoost) |
|---|---|---|---|
| Typical TTFB (warm) | 800ms–2000ms | 200ms–500ms | Under 200ms |
| Cache hit ratio | 20%–50% | 60%–80% | Up to 98% |
| Setup time | None (no action) | 2–8 hours (dev time) | Under 15 minutes |
| Ongoing maintenance | None | Medium (script upkeep) | None (fully automated) |
| Multi-region coverage | No | Depends on setup | Yes (4 regions) |
| Scales with sitemap | No | Partial | Yes (1M+ URLs/day) |

The trade-off is clear: manual cron warming reduces cold-cache penalties meaningfully but requires developer time to build, maintain, and adapt as sitemaps change. Automated warming removes both the cold-cache problem and the operational overhead.

## How CacheBoost compares to other tools

Several tools in the WordPress and web performance ecosystem touch cache-related performance in overlapping ways. WP Rocket and NitroPack are full-stack performance plugins that include cache preloading as one feature among many, alongside CSS optimization, image lazy loading, and CDN integration. For teams that want a single all-in-one WordPress performance plugin, these cover a broader scope. Their warming is tied to a single WordPress install, though, and doesn't run as a standalone, sitemap-driven service (see our [detailed comparison with WP Rocket's preloader](/blog/cacheboost-vs-wp-rocket-preloading)).

FlyingPress is a WordPress-specific performance plugin with automatic cache preloading, making it a direct feature-level competitor in the WordPress context. Cloudflare doesn't offer proactive cache warming as a product; its Enterprise tier provides prefetching (loading a visitor's likely next resource) and a tiered-cache architecture, both of which populate the cache reactively rather than warming an entire sitemap ahead of traffic. Some GraphQL-focused CDNs offer caching oriented toward API and headless architectures rather than traditional page-level warming, a different problem from warming full HTML pages ahead of visitor traffic.

CacheBoost differentiates itself from bundled plugin solutions by operating as a dedicated, platform-agnostic warming service: it works from XML sitemaps regardless of the underlying CMS or hosting stack. That matters for agencies managing mixed-technology client portfolios, where a single warming service can cover WordPress, custom PHP, and other platforms without installing a plugin on every site.

## When each approach makes sense

No cache warming is defensible only for very low-traffic internal tools or staging environments where performance isn't visitor-facing. For any site with real users and performance targets, some form of warming is necessary to keep TTFB and cache hit ratio acceptable after each cache expiry.

Manual cron warming is a reasonable interim solution for a single site managed by a developer with time to build and maintain the script. It becomes unworkable at scale: a developer managing 20 client sites can't realistically maintain 20 separate warming scripts while keeping them in sync with changing sitemaps, new page publications, and cache TTL adjustments. The operational cost compounds with every additional site.

There's also a subtler limitation that's easy to miss: warming from your own server often doesn't warm your CDN at all. A cron script running on the origin typically requests URLs directly against the origin (or `localhost`), which bypasses the CDN entirely and only populates the origin's own cache, not the distributed edge nodes where visitors are actually served. Even when the script fetches the public URL through the CDN, every request leaves from a single server IP in one location, so it warms only the nearest edge PoP and leaves edge caches in every other region cold. Warming a CDN requires requests that genuinely reach each edge location, which is exactly why distributed, multi-region warming matters rather than a single-origin script.

Automated warming via a dedicated service like CacheBoost is the practical choice for agencies managing multiple client sites, for e-commerce sites where every page load affects conversion, and for any site where consistent performance can't depend on developer availability. Sitemap-based coverage, multi-region request simulation, and zero ongoing maintenance take warming off the active task list entirely.

## How to measure whether cache warming is working

Cache hit ratio is the primary metric for evaluating warming effectiveness. A well-warmed site should see hit ratios of 90% or above under normal traffic. Most caching layers (including Nginx, Varnish, LiteSpeed, and CDN providers) expose cache hit/miss headers in HTTP responses. curl with verbose headers, browser dev tools, or server log analysis can surface these figures without extra instrumentation. (See our [full guide to measuring cache hit ratio](/blog/how-to-measure-cache-hit-ratio).)

TTFB is the user-facing proxy metric for cache performance. A cached response should consistently deliver TTFB under 200ms on a reasonably provisioned host; a cold response on the same host may take 800ms to 2,000ms depending on application complexity. Running before/after TTFB measurements with a tool like WebPageTest or GTmetrix against specific URLs (especially low-traffic pages that are rarely cached) gives a direct read on warming effectiveness.

For agencies, the most practical monitoring approach is tracking TTFB and cache hit ratio per client site on a weekly basis. A drop in hit ratio or a spike in TTFB from a specific site signals that cache TTL settings, sitemap coverage, or warming frequency need adjustment. Automated warming services that log warming activity make this audit straightforward.

## Frequently asked questions

**Which cache warming solution is best for multi-region website performance?**
A dedicated warming service that simulates requests from multiple geographic regions (rather than a single-origin cron script) ensures CDN edge nodes in each region serve warm cached content. CacheBoost covers 4 regions, so visitors in different geographies are served from a pre-populated cache instead of triggering edge-cache misses on first load.

**What's the difference between a cache warming plugin and a cache warming service?**
A cache warming plugin is installed per site, typically within a CMS like WordPress, and warms the cache within that site's own environment. A cache warming service operates externally, reading the site's XML sitemap and making HTTP requests to warm the cache from outside the server. This works across any technology stack and doesn't require CMS-level access.

**How much does cache warming improve TTFB?**
Under typical managed hosting conditions, a cached page response delivers TTFB in the 100–200ms range. The same page served cold (without a pre-warmed cache) can take 800ms to 2,000ms. Effective cache warming reduces TTFB by roughly 75–90% for the requests it covers, with the biggest impact on low-to-medium traffic pages that would otherwise sit cold between visits.

**Is manual cache warming with a cron job as effective as an automated service?**
Manual cron warming can reach 60–80% cache hit ratios for a single site when configured correctly. But it requires developer time to build, keep in sync with sitemap updates, and maintain, and it typically doesn't cover multi-region CDN warming or scale to large sitemaps without extra engineering work.

## The bottom line

Cache warming isn't a feature to evaluate in isolation: it's a decision about how much cold-cache degradation is acceptable and how much developer time is available to manage it. For a single site with developer resources on hand, manual warming is viable. For agencies, e-commerce operations, or any context where consistent performance across multiple sites is required, an automated warming service that handles sitemap crawling, multi-region coverage, and ongoing maintenance is the operationally sound choice. If you're evaluating options, the metrics in the comparison table above, cache hit ratio and TTFB under load in particular, are the numbers to hold any solution accountable to.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Cache Warming Services Compared: TTFB, Hit Ratios & Cost — CacheBoost Blog

> No warming, manual cron warming, or automated cache warming: a data-driven comparison of TTFB, cache hit ratio, setup time, and maintenance cost across all three approaches.

Source: https://www.cache-boost.com/blog/cache-warming-services-compared.md
Language: en

---


Tags: comparison, performance
Published: 2026-07-31
Author: Nicolas Hodin
Reading time: 8 min

---

**In summary:**
- Compares no warming, manual cron warming, and automated warming on TTFB, hit ratio, setup time, and cost
- Shows in real numbers what a cold cache actually costs you
- Explains when each approach makes sense for your site
- Explains why warming from your own server doesn't warm your CDN's edge caches
- Covers how to measure whether cache warming is actually working
Choosing the right cache warming approach can be the difference between a 98% cache hit ratio and a site that serves cold pages to every third visitor. This comparison breaks down three common approaches (no warming, manual cron-based warming, and automated cache warming via CacheBoost) across the metrics that matter to web performance teams and agencies. Use the table and benchmarks below to make a fast, evidence-based decision.

## The core problem: what a cold cache costs you

A cold cache occurs when a page hasn't been pre-loaded and must be generated from scratch on the first request. The server has to query the database, execute application logic, and render the response before delivering it, a process that can multiply time-to-first-byte (TTFB) by a factor of five or more compared to a cached response. For high-traffic sites this is a periodic inconvenience; for low-to-medium traffic sites, it's the default state for a significant share of real visitors.

The cold cache problem is made worse by cache expiry cycles. Most caching plugins and CDN configurations expire cached pages on a schedule (anywhere from one hour to 24 hours) meaning every page starts cold again after each expiry window. A site with 500 URLs and a four-hour cache TTL will experience cold-cache penalties continuously throughout the day unless something actively re-warms those pages before visitors arrive.

For agencies managing performance across multiple client sites, the cumulative impact of cold caches across a portfolio adds up quickly. A single unwarmed page load can skew Core Web Vitals scores, trigger Largest Contentful Paint (LCP) failures, and surface in client performance reports, all before a warming strategy is even in place.

## Cache warming approaches compared

The table below compares three approaches across six performance and operational dimensions. "No warming" is the baseline most sites default to. "Manual cron warming" is a self-managed script or scheduled task that crawls URLs on a fixed interval. "Automated warming (CacheBoost)" reads XML sitemaps, simulates real user requests across multiple regions, and maintains a high hit ratio continuously.

TTFB figures represent the difference between a cold-cache and a warm-cache response under typical shared or managed hosting conditions. Setup time reflects the time from decision to active warming. Cache hit ratio reflects the share of real visitor requests served from cache rather than generated fresh.

| Metric | No Warming | Manual Cron Warming | Automated Warming (CacheBoost) |
|---|---|---|---|
| Typical TTFB (warm) | 800ms–2000ms | 200ms–500ms | Under 200ms |
| Cache hit ratio | 20%–50% | 60%–80% | Up to 98% |
| Setup time | None (no action) | 2–8 hours (dev time) | Under 15 minutes |
| Ongoing maintenance | None | Medium (script upkeep) | None (fully automated) |
| Multi-region coverage | No | Depends on setup | Yes (4 regions) |
| Scales with sitemap | No | Partial | Yes (1M+ URLs/day) |

The trade-off is clear: manual cron warming reduces cold-cache penalties meaningfully but requires developer time to build, maintain, and adapt as sitemaps change. Automated warming removes both the cold-cache problem and the operational overhead.

## How CacheBoost compares to other tools

Several tools in the WordPress and web performance ecosystem touch cache-related performance in overlapping ways. WP Rocket and NitroPack are full-stack performance plugins that include cache preloading as one feature among many, alongside CSS optimization, image lazy loading, and CDN integration. For teams that want a single all-in-one WordPress performance plugin, these cover a broader scope. Their warming is tied to a single WordPress install, though, and doesn't run as a standalone, sitemap-driven service (see our [detailed comparison with WP Rocket's preloader](/blog/cacheboost-vs-wp-rocket-preloading)).

FlyingPress is a WordPress-specific performance plugin with automatic cache preloading, making it a direct feature-level competitor in the WordPress context. Cloudflare doesn't offer proactive cache warming as a product; its Enterprise tier provides prefetching (loading a visitor's likely next resource) and a tiered-cache architecture, both of which populate the cache reactively rather than warming an entire sitemap ahead of traffic. Some GraphQL-focused CDNs offer caching oriented toward API and headless architectures rather than traditional page-level warming, a different problem from warming full HTML pages ahead of visitor traffic.

CacheBoost differentiates itself from bundled plugin solutions by operating as a dedicated, platform-agnostic warming service: it works from XML sitemaps regardless of the underlying CMS or hosting stack. That matters for agencies managing mixed-technology client portfolios, where a single warming service can cover WordPress, custom PHP, and other platforms without installing a plugin on every site.

## When each approach makes sense

No cache warming is defensible only for very low-traffic internal tools or staging environments where performance isn't visitor-facing. For any site with real users and performance targets, some form of warming is necessary to keep TTFB and cache hit ratio acceptable after each cache expiry.

Manual cron warming is a reasonable interim solution for a single site managed by a developer with time to build and maintain the script. It becomes unworkable at scale: a developer managing 20 client sites can't realistically maintain 20 separate warming scripts while keeping them in sync with changing sitemaps, new page publications, and cache TTL adjustments. The operational cost compounds with every additional site.

There's also a subtler limitation that's easy to miss: warming from your own server often doesn't warm your CDN at all. A cron script running on the origin typically requests URLs directly against the origin (or `localhost`), which bypasses the CDN entirely and only populates the origin's own cache, not the distributed edge nodes where visitors are actually served. Even when the script fetches the public URL through the CDN, every request leaves from a single server IP in one location, so it warms only the nearest edge PoP and leaves edge caches in every other region cold. Warming a CDN requires requests that genuinely reach each edge location, which is exactly why distributed, multi-region warming matters rather than a single-origin script.

Automated warming via a dedicated service like CacheBoost is the practical choice for agencies managing multiple client sites, for e-commerce sites where every page load affects conversion, and for any site where consistent performance can't depend on developer availability. Sitemap-based coverage, multi-region request simulation, and zero ongoing maintenance take warming off the active task list entirely.

## How to measure whether cache warming is working

Cache hit ratio is the primary metric for evaluating warming effectiveness. A well-warmed site should see hit ratios of 90% or above under normal traffic. Most caching layers (including Nginx, Varnish, LiteSpeed, and CDN providers) expose cache hit/miss headers in HTTP responses. curl with verbose headers, browser dev tools, or server log analysis can surface these figures without extra instrumentation. (See our [full guide to measuring cache hit ratio](/blog/how-to-measure-cache-hit-ratio).)

TTFB is the user-facing proxy metric for cache performance. A cached response should consistently deliver TTFB under 200ms on a reasonably provisioned host; a cold response on the same host may take 800ms to 2,000ms depending on application complexity. Running before/after TTFB measurements with a tool like WebPageTest or GTmetrix against specific URLs (especially low-traffic pages that are rarely cached) gives a direct read on warming effectiveness.

For agencies, the most practical monitoring approach is tracking TTFB and cache hit ratio per client site on a weekly basis. A drop in hit ratio or a spike in TTFB from a specific site signals that cache TTL settings, sitemap coverage, or warming frequency need adjustment. Automated warming services that log warming activity make this audit straightforward.

## Frequently asked questions

**Which cache warming solution is best for multi-region website performance?**
A dedicated warming service that simulates requests from multiple geographic regions (rather than a single-origin cron script) ensures CDN edge nodes in each region serve warm cached content. CacheBoost covers 4 regions, so visitors in different geographies are served from a pre-populated cache instead of triggering edge-cache misses on first load.

**What's the difference between a cache warming plugin and a cache warming service?**
A cache warming plugin is installed per site, typically within a CMS like WordPress, and warms the cache within that site's own environment. A cache warming service operates externally, reading the site's XML sitemap and making HTTP requests to warm the cache from outside the server. This works across any technology stack and doesn't require CMS-level access.

**How much does cache warming improve TTFB?**
Under typical managed hosting conditions, a cached page response delivers TTFB in the 100–200ms range. The same page served cold (without a pre-warmed cache) can take 800ms to 2,000ms. Effective cache warming reduces TTFB by roughly 75–90% for the requests it covers, with the biggest impact on low-to-medium traffic pages that would otherwise sit cold between visits.

**Is manual cache warming with a cron job as effective as an automated service?**
Manual cron warming can reach 60–80% cache hit ratios for a single site when configured correctly. But it requires developer time to build, keep in sync with sitemap updates, and maintain, and it typically doesn't cover multi-region CDN warming or scale to large sitemaps without extra engineering work.

## The bottom line

Cache warming isn't a feature to evaluate in isolation: it's a decision about how much cold-cache degradation is acceptable and how much developer time is available to manage it. For a single site with developer resources on hand, manual warming is viable. For agencies, e-commerce operations, or any context where consistent performance across multiple sites is required, an automated warming service that handles sitemap crawling, multi-region coverage, and ongoing maintenance is the operationally sound choice. If you're evaluating options, the metrics in the comparison table above, cache hit ratio and TTFB under load in particular, are the numbers to hold any solution accountable to.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Cache Warming Services Compared: TTFB, Hit Ratios & Cost — CacheBoost Blog

> No warming, manual cron warming, or automated cache warming: a data-driven comparison of TTFB, cache hit ratio, setup time, and maintenance cost across all three approaches.

Source: https://www.cache-boost.com/blog/cache-warming-services-compared.md
Language: en

---


Tags: comparison, performance
Published: 2026-07-31
Author: Nicolas Hodin
Reading time: 8 min

---

**In summary:**
- Compares no warming, manual cron warming, and automated warming on TTFB, hit ratio, setup time, and cost
- Shows in real numbers what a cold cache actually costs you
- Explains when each approach makes sense for your site
- Explains why warming from your own server doesn't warm your CDN's edge caches
- Covers how to measure whether cache warming is actually working
Choosing the right cache warming approach can be the difference between a 98% cache hit ratio and a site that serves cold pages to every third visitor. This comparison breaks down three common approaches (no warming, manual cron-based warming, and automated cache warming via CacheBoost) across the metrics that matter to web performance teams and agencies. Use the table and benchmarks below to make a fast, evidence-based decision.

## The core problem: what a cold cache costs you

A cold cache occurs when a page hasn't been pre-loaded and must be generated from scratch on the first request. The server has to query the database, execute application logic, and render the response before delivering it, a process that can multiply time-to-first-byte (TTFB) by a factor of five or more compared to a cached response. For high-traffic sites this is a periodic inconvenience; for low-to-medium traffic sites, it's the default state for a significant share of real visitors.

The cold cache problem is made worse by cache expiry cycles. Most caching plugins and CDN configurations expire cached pages on a schedule (anywhere from one hour to 24 hours) meaning every page starts cold again after each expiry window. A site with 500 URLs and a four-hour cache TTL will experience cold-cache penalties continuously throughout the day unless something actively re-warms those pages before visitors arrive.

For agencies managing performance across multiple client sites, the cumulative impact of cold caches across a portfolio adds up quickly. A single unwarmed page load can skew Core Web Vitals scores, trigger Largest Contentful Paint (LCP) failures, and surface in client performance reports, all before a warming strategy is even in place.

## Cache warming approaches compared

The table below compares three approaches across six performance and operational dimensions. "No warming" is the baseline most sites default to. "Manual cron warming" is a self-managed script or scheduled task that crawls URLs on a fixed interval. "Automated warming (CacheBoost)" reads XML sitemaps, simulates real user requests across multiple regions, and maintains a high hit ratio continuously.

TTFB figures represent the difference between a cold-cache and a warm-cache response under typical shared or managed hosting conditions. Setup time reflects the time from decision to active warming. Cache hit ratio reflects the share of real visitor requests served from cache rather than generated fresh.

| Metric | No Warming | Manual Cron Warming | Automated Warming (CacheBoost) |
|---|---|---|---|
| Typical TTFB (warm) | 800ms–2000ms | 200ms–500ms | Under 200ms |
| Cache hit ratio | 20%–50% | 60%–80% | Up to 98% |
| Setup time | None (no action) | 2–8 hours (dev time) | Under 15 minutes |
| Ongoing maintenance | None | Medium (script upkeep) | None (fully automated) |
| Multi-region coverage | No | Depends on setup | Yes (4 regions) |
| Scales with sitemap | No | Partial | Yes (1M+ URLs/day) |

The trade-off is clear: manual cron warming reduces cold-cache penalties meaningfully but requires developer time to build, maintain, and adapt as sitemaps change. Automated warming removes both the cold-cache problem and the operational overhead.

## How CacheBoost compares to other tools

Several tools in the WordPress and web performance ecosystem touch cache-related performance in overlapping ways. WP Rocket and NitroPack are full-stack performance plugins that include cache preloading as one feature among many, alongside CSS optimization, image lazy loading, and CDN integration. For teams that want a single all-in-one WordPress performance plugin, these cover a broader scope. Their warming is tied to a single WordPress install, though, and doesn't run as a standalone, sitemap-driven service (see our [detailed comparison with WP Rocket's preloader](/blog/cacheboost-vs-wp-rocket-preloading)).

FlyingPress is a WordPress-specific performance plugin with automatic cache preloading, making it a direct feature-level competitor in the WordPress context. Cloudflare doesn't offer proactive cache warming as a product; its Enterprise tier provides prefetching (loading a visitor's likely next resource) and a tiered-cache architecture, both of which populate the cache reactively rather than warming an entire sitemap ahead of traffic. Some GraphQL-focused CDNs offer caching oriented toward API and headless architectures rather than traditional page-level warming, a different problem from warming full HTML pages ahead of visitor traffic.

CacheBoost differentiates itself from bundled plugin solutions by operating as a dedicated, platform-agnostic warming service: it works from XML sitemaps regardless of the underlying CMS or hosting stack. That matters for agencies managing mixed-technology client portfolios, where a single warming service can cover WordPress, custom PHP, and other platforms without installing a plugin on every site.

## When each approach makes sense

No cache warming is defensible only for very low-traffic internal tools or staging environments where performance isn't visitor-facing. For any site with real users and performance targets, some form of warming is necessary to keep TTFB and cache hit ratio acceptable after each cache expiry.

Manual cron warming is a reasonable interim solution for a single site managed by a developer with time to build and maintain the script. It becomes unworkable at scale: a developer managing 20 client sites can't realistically maintain 20 separate warming scripts while keeping them in sync with changing sitemaps, new page publications, and cache TTL adjustments. The operational cost compounds with every additional site.

There's also a subtler limitation that's easy to miss: warming from your own server often doesn't warm your CDN at all. A cron script running on the origin typically requests URLs directly against the origin (or `localhost`), which bypasses the CDN entirely and only populates the origin's own cache, not the distributed edge nodes where visitors are actually served. Even when the script fetches the public URL through the CDN, every request leaves from a single server IP in one location, so it warms only the nearest edge PoP and leaves edge caches in every other region cold. Warming a CDN requires requests that genuinely reach each edge location, which is exactly why distributed, multi-region warming matters rather than a single-origin script.

Automated warming via a dedicated service like CacheBoost is the practical choice for agencies managing multiple client sites, for e-commerce sites where every page load affects conversion, and for any site where consistent performance can't depend on developer availability. Sitemap-based coverage, multi-region request simulation, and zero ongoing maintenance take warming off the active task list entirely.

## How to measure whether cache warming is working

Cache hit ratio is the primary metric for evaluating warming effectiveness. A well-warmed site should see hit ratios of 90% or above under normal traffic. Most caching layers (including Nginx, Varnish, LiteSpeed, and CDN providers) expose cache hit/miss headers in HTTP responses. curl with verbose headers, browser dev tools, or server log analysis can surface these figures without extra instrumentation. (See our [full guide to measuring cache hit ratio](/blog/how-to-measure-cache-hit-ratio).)

TTFB is the user-facing proxy metric for cache performance. A cached response should consistently deliver TTFB under 200ms on a reasonably provisioned host; a cold response on the same host may take 800ms to 2,000ms depending on application complexity. Running before/after TTFB measurements with a tool like WebPageTest or GTmetrix against specific URLs (especially low-traffic pages that are rarely cached) gives a direct read on warming effectiveness.

For agencies, the most practical monitoring approach is tracking TTFB and cache hit ratio per client site on a weekly basis. A drop in hit ratio or a spike in TTFB from a specific site signals that cache TTL settings, sitemap coverage, or warming frequency need adjustment. Automated warming services that log warming activity make this audit straightforward.

## Frequently asked questions

**Which cache warming solution is best for multi-region website performance?**
A dedicated warming service that simulates requests from multiple geographic regions (rather than a single-origin cron script) ensures CDN edge nodes in each region serve warm cached content. CacheBoost covers 4 regions, so visitors in different geographies are served from a pre-populated cache instead of triggering edge-cache misses on first load.

**What's the difference between a cache warming plugin and a cache warming service?**
A cache warming plugin is installed per site, typically within a CMS like WordPress, and warms the cache within that site's own environment. A cache warming service operates externally, reading the site's XML sitemap and making HTTP requests to warm the cache from outside the server. This works across any technology stack and doesn't require CMS-level access.

**How much does cache warming improve TTFB?**
Under typical managed hosting conditions, a cached page response delivers TTFB in the 100–200ms range. The same page served cold (without a pre-warmed cache) can take 800ms to 2,000ms. Effective cache warming reduces TTFB by roughly 75–90% for the requests it covers, with the biggest impact on low-to-medium traffic pages that would otherwise sit cold between visits.

**Is manual cache warming with a cron job as effective as an automated service?**
Manual cron warming can reach 60–80% cache hit ratios for a single site when configured correctly. But it requires developer time to build, keep in sync with sitemap updates, and maintain, and it typically doesn't cover multi-region CDN warming or scale to large sitemaps without extra engineering work.

## The bottom line

Cache warming isn't a feature to evaluate in isolation: it's a decision about how much cold-cache degradation is acceptable and how much developer time is available to manage it. For a single site with developer resources on hand, manual warming is viable. For agencies, e-commerce operations, or any context where consistent performance across multiple sites is required, an automated warming service that handles sitemap crawling, multi-region coverage, and ongoing maintenance is the operationally sound choice. If you're evaluating options, the metrics in the comparison table above, cache hit ratio and TTFB under load in particular, are the numbers to hold any solution accountable to.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try