Advanced warming
Schedule windows, multi-region warming, browser/SSR rendering, and mobile user agents.
12 min read
Four capabilities for setups that a plain hourly HTTP crawl does not cover. All are plan-gated — if one is missing from your form, it is not included in your subscription.
Warm schedule windows
By default an active warmer starts a new run every auto-start interval, around the clock. Schedule windows restrict that to hours you choose.
Outside a window, scheduled auto-starts are skipped. Manual starts, deploy triggers, and CDN purge-rewarm actions still work — the window governs the schedule, not the warmer as a whole.
Why you would want this
- Warm hard before peak. Ramp up in the hours before your busiest period so everything is hot when traffic lands.
- Back off overnight. Save request budget and origin load when nobody is visiting.
- Protect maintenance windows. Stop warming during backups, migrations, or batch jobs.
- Match an editorial rhythm. Newsrooms often warm heavily before the morning read.
The JSON format
The warm schedule field takes a JSON object with a timezone and a list of windows:
{
"timezone": "Europe/Amsterdam",
"windows": [
{ "days": [1, 2, 3, 4, 5], "startHour": 8, "endHour": 20, "intensity": 1 }
]
}| Field | Meaning |
|---|---|
timezone | An IANA timezone name such as Europe/Amsterdam, America/New_York, or UTC. Windows are evaluated in this zone, so daylight saving is handled for you. |
windows | A list of time windows. Runs are allowed inside any of them. |
days | Days of the week the window applies to, where 1 is Monday and 7 is Sunday. |
startHour | Hour the window opens, 0–23. |
endHour | Hour the window closes, 0–23. |
intensity | Relative warming effort during the window. 1 is normal; a lower value warms more gently. |
{
"timezone": "Europe/Amsterdam",
"windows": [
{ "days": [1, 2, 3, 4, 5], "startHour": 6, "endHour": 10, "intensity": 1 },
{ "days": [1, 2, 3, 4, 5, 6, 7], "startHour": 0, "endHour": 5, "intensity": 0.3 }
]
}Check the window is wide enough to finish
If a full pass takes three hours and your window is two, runs will be cut short and later URLs never warmed. Either widen the window, raise the rate limit, or narrow the warmer's scope.
Tip
Leave the field empty to warm around the clock. That is the right choice for most sites — only add windows when you have a specific reason.
Multi-region warming
Most CDNs cache independently at each point of presence. A page warmed from Europe fills the European edge node — it does nothing for a visitor in Singapore hitting a different POP that has never served that page.
Multi-region warming runs a warmer from a chosen regional crawler instance, so geographically distributed caches actually get filled where your audience is. It is set with the Crawler region field, and is a Business-plan capability.
When you need it
- You have meaningful traffic on more than one continent.
- Your CDN caches per POP or per region rather than globally.
- You serve localised content from region-specific origins.
- You run a multi-CDN setup where behaviour differs by geography.
If nearly all your visitors are in one country, a single region is fine and multi-region adds cost without benefit.
Warming from more regions multiplies requests
Each region issues its own requests, so covering three regions roughly triples the request volume — against both your origin and your plan's URL budget. Size your rate limits accordingly.
Pick regions from your actual analytics, not aspiration. Warming a region that generates two percent of your traffic is rarely worth triple the request budget.
Browser / SSR warming
A plain HTTP fetch retrieves the HTML a server returns. For most sites that is exactly what gets cached, and it is all you need.
Some stacks are different. If the cache layer you care about only fills after a full render — a JavaScript-heavy front end, or a framework whose cache populates on a complete navigation rather than a raw request — a simple fetch warms nothing useful.
Browser / SSR warming uses a real browser engine to load the page properly. It is a Business-plan capability, enabled per warmer.
| Use plain HTTP warming when… | Use browser warming when… |
|---|---|
| Your server returns complete HTML | The page is assembled client-side |
| A CDN or page cache stores the response | The cache only fills after a full render pass |
| You want maximum throughput cheaply | Correctness matters more than volume |
| Most static and traditional CMS sites | SSR/ISR app-router style routes that are not filling |
Browser warming is much heavier
Rendering a page in a browser costs far more time and resources than fetching it. Use it selectively for routes that genuinely need it, and keep lightweight HTTP warming for everything else. Do not switch an entire large warmer to browser mode without lowering the rate limit.
The practical test: run a normal HTTP warmer first. If Cache health shows those routes still cold while the rest of your site improves, browser warming is worth trying.
Mobile warming
If your CDN varies its cached copy by user agent, or you serve distinct mobile templates, warming only with a desktop agent leaves phone visitors on a cold cache — usually the majority of your traffic.
Turn on Warm mobile version to crawl with mobile user agents as well. On plans that allow it you can also supply your own mobile user agents for exact control.
- Essential if your cache key includes the user agent or a device class.
- Essential if you serve a separate mobile theme or an
m.subdomain. - Unnecessary if you serve identical responsive HTML to every device — one cached copy already serves everyone.
Note
Warming desktop and mobile variants roughly doubles request volume, since each URL is fetched under both agents. Check your rate limits and plan budget before enabling it on a large site.
Custom user agents
The User agents field lets you set exactly which agent strings requests are sent with. Reasons you might:
- Your CDN keys its cache on specific agent strings and you need to match them exactly.
- A bot filter blocks unknown agents, and you have allow-listed a particular one.
- You want warm requests identifiable in your server logs, to separate them from real traffic.
Tip
Using a distinctive, identifiable user agent for warming is good practice. It makes Cache Rocket traffic obvious in your analytics and access logs, and easy to exclude from reporting.