Configuring Statamic: Where Content Delivery Speed Is Lost
The first request to a page in such a configuration almost always means building it from scratch: the system finds the entry, pulls in relationships and taxonomies, parses the template, and only then returns the finished HTML.
While there are dozens of pages, this goes unnoticed, but the cost of the operation does not decrease as traffic grows — it is multiplied by the number of concurrent requests.
Page delivery speed begins to be determined not by the quality of the markup, but by how much work is repeated on every visit.
The bottleneck is the content storage. When entries are stored as files, and there are many indexes and relationships between them, the engine is forced to traverse the directory tree and read entire listings to assemble navigation, pagination, and archives.
The more materials there are, the wider the traversal, and response time grows non-linearly: a page that was served instantly with a hundred entries hits disk operations at several thousand.
The second problem is contention: the control panel and the public-facing part work with the same files.
An editor saves a material, rebuilding of derived data starts, lists and the template cache are updated — and it is precisely at this moment that public requests queue up for access to the storage.
This leads to typical degradation under traffic peaks: the site goes down not from the number of visitors, but from the coincidence of content publication with a surge of readers.
The third point of failure is cache overflow.
If keys are not tied to entry modification dates, the volume of accumulated files grows uncontrollably, invalidation happens less often, and after clearing, the site meets traffic completely “cold” and rebuilds every page from scratch.
Below we discuss how this is addressed: choosing a storage driver for the project profile and static caching with correct invalidation based on content change events.
What a Correctly Chosen Driver and Static Cache Deliver
The cache driver determines where compiled templates, navigation, and the results of heavy queries are stored. The file driver reads them from disk, the in-memory option keeps them next to the application, and the database driver reuses an already open connection.
The difference is visible not in calm mode, but at peak: one storage degrades smoothly, another starts returning failures — we eliminate this class of failures at the configuration stage.
Static caching changes the very model of page delivery. The finished HTML is served by the web server, not by the application with template compilation and database queries on every visit.
Response time drops to fractions of a second, and the load on the application server stops depending on the number of concurrent visitors.
Next is warming after publication. While the cache is empty, the first requests rebuild the page, and that is exactly the moment an editor who clicks “publish” catches.
We start crawling the sitemap immediately after the build: the visitor arrives at ready static content, not at a site that is still warming up.
Resilience to peaks is a side effect: static content is served from disk or from a delivery network, so a surge of traffic does not require urgent server scaling.
The stack itself is secondary here — what matters more is that the chosen mode keeps Statamic within predictable bounds.
Configuring Statamic: Storage Drivers and Cache Modes
The storage driver in Statamic determines where content edits live and how other nodes see them, while the cache mode determines how much work the application does on each request.
These two choices are related: an aggressive cache forgives slow storage, while an external cache storage does not help if invalidation clears everything at once. Below are the alternatives that are actually chosen between at the start.
| Option | When it fits | Limitations |
|---|---|---|
| Built-in file storage (file driver) | single node, infrequent edits, content and templates versioned together with code | on multiple nodes, copies diverge and synchronization is needed; reads and writes hit the local disk |
| External cache storage | multiple nodes, high request frequency, shared cache for all processes | extra network round-trips on every miss; separate availability and invalidation control is needed |
| Full static cache | marketing pages and a catalog without personalization | forms, search, and the account area require dynamic behavior; a content edit resets the finished page |
| Partial caching of sections | shared header, menu, footer, and lists with personalized blocks | harder to mark fragment boundaries; an error leaves a “stuck” block on all pages |
Scheduled Cache Warming
A cold cache after deployment or a mass edit causes a spike in response time: the first visitors wait while the heaviest pages warm up.
Scheduled cache warming crawls the page map in advance — via a publication hook or on a timer, with rate limiting so that the crawl does not compete with live traffic. A full static cache is warmed entirely, while partial section caching is warmed only for shared fragments.
Workflow: From Content Inventory to Load Testing
The order of stages here is not arbitrary: each subsequent decision relies on a measurement obtained in the previous one.
If you set the cache lifetime without knowing which materials editors revise ten times a day, some pages will serve outdated content, and support will receive a stream of tickets. That is why configuring Statamic starts with an inventory, not with editing the configuration.
- Content and traffic audit. We collect collections and entry types, edit frequency, the share of pages that change once a month, and hot addresses from logs. The output is a map of “what is cached for a long time and what is not cached at all.”
- Caching scheme. We define levels: full-page response, template fragments, service queries. For each — lifetime and invalidation rule: on entry save, on publication, on manual editor signal.
- Driver configuration. We choose cache storage for the load profile: file, external in-memory, or on top of the database. For each option, we describe what is lost on restart and how an empty cache is warmed.
- Staging verification. The staging environment replicates production by versions, extensions, and permissions: we run publication, delayed output, cache invalidation, and work of editors with limited rights.
- Comparative measurements. We take metrics before and after on the same set of pages: response time, cache hit ratio, number of disk and database accesses. A discrepancy in measurements is a reason to return to the scheme, not to “tweak” timings at random.
- Load test. The profile replicates real traffic with peaks; separately we check behavior on a cache miss, when hundreds of requests simultaneously go to rebuild.
- Handover. We provide configurations, the caching scheme, the warming procedure after deployment, the rollback map to previous settings, and instructions for the on-call engineer.
Set of Delivered Files, Schemes, and Procedures
We hand over the Statamic configuration package together with a working environment, not as an archive “for later.” It is designed for an engineer who will open it during an incident or the next enhancement: to reproduce the staging configuration, understand the caching logic, and safely roll back a setting.
- Configuration files — sets for the local environment, staging, and production with comments: which cache driver is chosen and why, where static caching is enabled, and where secrets are injected from.
- Cache layer scheme — what is served statically, what lives in shared storage, which invalidation keys and tags are tied to collections and templates, and what happens when an entry is published.
- Access policies — a matrix of roles and keys: who changes the configuration, who can only clear the cache, which actions require confirmation, and where traces are left.
- Cache invalidation instructions — step-by-step scenarios: full warming, targeted invalidation by tag, invalidation of a single static file; after each step, it states how to verify data freshness.
- Configuration change log — a table of “date, parameter, before and after, author, reason, rollback method”; maintained from day one so that incident analysis does not turn into archaeology.
- On-call procedure — response times for degradation, escalation order, and a checklist of first actions when response time grows and the cache diverges from the database.
We update the sections when the caching scheme or access rights change, so the package describes the current state, not a past release.
Case Study: A Catalog with Tens of Thousands of Pages After Enabling Caching
Baseline: A Catalog That Could Not Withstand Peaks
The catalog on Statamic grew organically — tens of thousands of cards with filters by category, properties, and availability.
Every request spun up the application and went to file storage for data, so under steady traffic everything looked great, but during seasonal promotions and at the moment of mailings the catalog responded in 2.4 seconds, and every twentieth page ended in an error.
What We Changed and What It Led To
Catalog delivery was moved to static caching: finished pages are written to disk, and the application serves them without accessing storage.
Invalidation is tied to tags — editing a card invalidates only related pages, warming starts immediately after publication, and filters are split into keyed pages so that heavy result sets are not rebuilt every time.
The median catalog response time dropped to 180 milliseconds, and the 95th percentile to 400. The error rate at peaks decreased from 5.8% to 0.3%, because requests stopped competing for storage.
The peak load on the application server decreased approximately fourfold, and disk accesses during page delivery became background — catalog growth no longer requires proportional resource growth.
How Does Static Cache Differ from Application Cache?
Application cache is formed at request time: the engine assembles the page, renders templates, queries the database, and places the result — finished HTML or a set of fragments — into storage under a key made from the address, language, and request parameters.
The driver is chosen based on load: file storage works on a single server, while a shared in-memory cache is needed when there are multiple nodes and the cache must be unified. The lifetime is set explicitly, and when it expires, the page is rebuilt.
Static cache works differently: the page is assembled in advance — on publication or by command — and written as a separate file into the serving directory. The web server serves this file directly; the application does not start at all.
Hence the predictable time to first byte: the request pays for neither the template engine, nor database queries, nor markup parsing.
The difference shows up during editing. The Statamic application cache is invalidated by tags: when an entry is saved, all pages where it is displayed are invalidated, and the next build serves the current version.
A static file knows nothing about the edit: until it is rebuilt, the visitor sees the previous revision, and this can only be fixed by explicit deletion or regeneration.
That is why rebuilding is hooked to the publication event, and sections with frequent edits are either kept with a short lifetime or served from the application cache.
What goes into storage is also different. In the application cache, it is a serialized response with a limited lifetime that will expire on its own; in static cache, it is a file that lives until forced clearing.
In practice, a combination is used: catalog, blog, and landing pages — statically; account area, forms, and search — dynamically. We fix this in the configuration and verify it on real traffic, not on a test sample.
Technical Concerns and Limitations Before Starting Work
The concerns come down to five scenarios: whether the markup will be preserved, what happens if external storage fails, how to edit content without a developer, what goes into partial cache, and whether the file driver will withstand the content volume. We address each before starting Statamic configuration.
Will templates have to be rewritten?
The markup remains — the output points change: instead of queries to the former database, we substitute template engine tags and collections. We rewrite fragments with lists, filters, and pagination.
What happens if external storage fails?
Content and files are duplicated locally, and rendering does not depend on the external service. During a failure, we serve the last consistent version, and edits from the panel are applied after connectivity is restored.
Will an editor be able to edit content independently?
Edits go through the control panel with roles and drafts, and publication is a separate action. The file source remains: changes go through review and enter the version history.
Will the cache have to be cleared entirely?
Caching is configured by section: static content, catalog, and feed update independently. Editing one entry invalidates only related pages, and the rest of the site is served from cache.
Will the file driver withstand the content volume?
Up to tens of thousands of entries — yes, with splitting into collections and enabled indexes. Beyond that, we calculate the load profile and move some entities to the database driver without changing templates.
Let’s Discuss the Task and Return with an Estimate and Plan
To make the Statamic configuration estimate based on facts rather than assumptions, we need just one pass over the current configuration. Usually this is a short call and access to the staging environment — after that, we return with a work plan and implementation timelines.
What we need from you to get started:
- Current state: which cache driver is connected, where static caching is enabled, and which environments live separately.
- Access for the audit: a repository with templates and configuration, a staging environment, the control panel, and error logs.
- Change boundaries: which sections can be touched, in which windows a release can be deployed, and whether there are integrations tied to the URL structure.
- Acceptance criteria: what we consider the result — static build time, the share of pages served from cache, and predictability of invalidation.
- A person responsible on your side who approves content and infrastructure changes.
- Documentation handover requirements: whom it is addressed to and in what form it is convenient — a description of settings, an environment scheme, and an update procedure.
In response, we send a staged work plan: audit, changing the driver and static caching rules, verification on staging, migration to production, and documentation handover.
We calculate implementation timelines from the moment access is received and mark the points where your confirmation is needed. Describe the task — we will return with an estimate and a plan.
