Static and response cache
This page is for managers deciding how to keep public pages fast and available under load, and for the operator who switches the caches on. Both caches described here answer a visitor without starting the application, so they are the strongest protection against a traffic spike. They work differently, and they have different costs. The general picture is on Caching for availability.
Warning
.htaccess slows down every request. When .htaccess files are enabled (AllowOverride anything but None), let alone
used, Apache looks for them and reads and evaluates them on every request, in every directory of the path, and
page loading times go up drastically (measured). The only real fix is to switch the feature off for
the virtual host: AllowOverride None in the HTTPS virtual host, and the rules in the virtual host's own
configuration as mod_rewrite rules. That is far faster in production speed tests and well worth the time it takes
to optimize a production configuration. Switch over right away: copy the rules of the
example HTTPS virtual host into your virtual host (with the static cache, also
staticcache_offload.conf), set AllowOverride None, run apachectl configtest, reload Apache and
test the site. The same rules for other servers: nginx, LiteSpeed,
Caddy, IIS, Velocity (built in); where virtual host rules go in a control
panel: Plesk, cPanel, DirectAdmin, ISPConfig.
On LiteSpeed or OpenLiteSpeed, the server's own page cache can also answer anonymous visitors and crawlers without PHP: Page caching with LiteSpeed and OpenLiteSpeed.
Contents
- Two caches compared
- The Velocity response cache
- The static cache
- Which one for which business
- Keeping personal pages out
- After a change
- Checklist
Two caches compared
| Velocity response cache | Static cache | |
|---|---|---|
| Where it lives | Inside the Velocity server | Plain files under var/<site>/static, sent by the web server |
| Needs | Velocity serving the site | Web server rules that answer from the files |
| Shipped state | On in Exponential's settings/velocity.ini ([CacheSettings] Enabled=enabled) | Off ([ContentSettings] StaticCache=disabled) |
| Who is served from it | Anonymous visitors only | Anonymous visitors only: no query string, no session |
| How pages get in | The first request for a page stores it | A crawl of the site, then refreshes on publish |
| How long a page lives | [CacheSettings] DefaultTtl, 30 seconds shipped, unless the page states its own | Until a publish refreshes it |
| Cleared by | exp:velocity cache clear | php bin/php/cache.php static clear |
Sources: settings/velocity.ini, Caching layers,
Static cache generator,
Operating a site, turn on the static cache.
The Velocity response cache
It "keeps rendered public pages and answers repeat requests inside the server process, before a worker is chosen, so a hit costs no worker at all" (Velocity response cache). It behaves like a small reverse proxy. The features that protect availability:
| Feature | What it does for you |
|---|---|
| Stale-while-revalidate | An expired page is still served while one request renders a new copy, so a busy page never sends every visitor to PHP at once |
| Negative caching | "Not found" answers can be kept for a while, so repeated requests for a missing page cost little |
Conditional requests (304) and ETag | A returning browser gets a short "not modified" answer instead of the whole page |
| A reload does not bypass it | "A visitor's own Cache-Control: no-cache does not bypass the cache, so pressing reload cannot make the server render every page again" |
| Maintenance aware | While maintenance mode is on, the cache does not answer, so the maintenance page is shown (Maintenance mode guide) |
The feature page documents its own measurement: "A cached public page is served in about 0.2 ms of CPU (measured on a 12-core host: a front page over TLS with gzip, about 2,950 pages a second from one server, 11,985 from four servers on one port)". As with every benchmark, your pages and hardware decide your result; see Velocity for businesses.
The trade-off is written into the shipped settings: with DefaultTtl=30 "a visitor may see a page up to this old"
(settings/velocity.ini, [CacheSettings]). For most public pages half a minute is invisible; for a stock counter or
a live score it may not be. Ask your developer which pages must never be cached and how they say so.
The static cache
"The static cache stores public pages as plain files that the web server can send without starting Exponential" (Operating a site). It suits sites with mostly public, rarely changing pages (Static cache generator).
How it is switched on, in outline:
- Generate the pages: Setup > Cache > Static content cache, or
php bin/php/makestaticcache.php --site=site --allow-root-user(defaults: up to 2,500 pages, link depth 12). - Switch on
StaticCache=enabledin[ContentSettings]and clear the INI cache. - Make the web server answer from the files: on Apache with
.htaccess, the shipped.htaccess_root_staticadds the rules.
Only siteaccesses that need no login are offered, because their pages are the same for everybody; forms, searches and signed-in visitors always get the live page.
Note
The website creators' guide recommends leaving the static cache off unless you need it: with it on, a publish regenerates the affected pages over HTTP inside the editor's request, which made publishing slower (Static cache and the Velocity response cache). Since 1 October 2026 a publish fetches each page once and several at a time (Static cache generator), but the cost still grows with the number of pages a publish touches. Measure on a copy of your site.
Which one for which business
| Your situation | Suggestion |
|---|---|
| Velocity serves the site | Rely on the response cache; it is on in the shipped settings |
| Shared hosting with Apache, mostly public pages that rarely change | Consider the static cache, after measuring publish times |
| Many editors publishing all day | Avoid the static cache; let the view cache and the response cache work |
| Most traffic signed in (intranet, member area, checkout) | Neither helps much; plan capacity for rendered pages (Peak traffic planning) |
| A CDN in front | It can cache public pages too; it does not store the maintenance page, but may hold older pages after a change (Maintenance mode guide) |
Keeping personal pages out
Both caches are for anonymous pages only, and both protect personal pages by design:
- The response cache skips any request with an
Authorizationheader or a session cookie, and any response that sets a cookie or saysprivateorno-store(Velocity response cache). - The static cache answers from a file only for a plain
GETorHEADwith no query string and no session.
The response cache page warns: "Do not cache personalised pages." If your developer builds pages that differ between anonymous visitors without a cookie to tell them apart (for example by location), they must mark them so.
After a change
- After a template, stylesheet or settings change:
php bin/php/console exp:velocity cache clear --apply --allow-root-user.exp:velocity deployclears it as its last step (Static cache and the Velocity response cache). - Static cache files are refreshed on publish; remove all with
php bin/php/cache.php static clear --allow-root-user. - Check the response cache works: a second anonymous request for the same page carries an
Ageheader andX-Cache: HIT.
Checklist
- To do: You know which of the two caches your site uses, and why.
- To do: The response cache lifetime fits your content (no page shown older than the business accepts).
- To do: Pages that must never be cached are marked so by your developer.
- To do: If the static cache is on, publish times were measured and are acceptable to editors.
- To do: Caches are cleared after deploys in the right order (Graceful deploys).
Related pages
- Caching for availability
- Velocity response cache (hosting)
- Static cache (hosting)
- Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.
Become an Exponential Partner
Partners share their information, provide funding, contribute back and develop the products with us, and that is how Exponential grows. A partner website and dashboard are planned for mid-2027: please become a partner today to speed up our growth rate and land new features faster.