Software always has a bottleneck somewhere. A flat file CMS's bottleneck is usually I/O request response time. The more content in the site, the slower it gets. When working with a few hundred entries you may never notice it, but as a site grows into the thousands the response time grows right along with it.
If you don't need dynamic content, static caching tucks away the sluggish requests, revealing them to the world only when the cache needs busting and the HTML needs regenerating. Whether this is a reasonable solution or not depends entirely on the site. That's why we've taken measures to abstract the data storage system so you can swap in a database or other drivers for those larger sites.
We weren't satisfied to stop there though. While switching to a database may be a good solution for some, it will always come with a trade-off (like inability to version control content).
We wanted to push the limits of what a flat file system could handle. So we re-engineered the Stache, Statamic's content storage system. The new architecture extensively leverages configurable and on-demand indexes to keep the cache size small, eliminate over-hydrating, and reduce per-request memory usage. It has built-in intelligence and even makes suggestions on how to fine-tune your settings.
Want see some stats?
Response Time Metrics
We used Apache Benchmark to test performance. Both sites are using an identical data set and requesting an average request: a collection index sorted by date and limited to 10 results.
|Statamic 2||Statamic 3||Time Decrease||Performance Increase|
You can see Statamic 3 has shaved the response time down on typical small site by a third. Not bad. You can now spend those
Big sites go from unusable to sorting 5000 entries and serving a page request in less than a second. Flip on caching and you'll be able build huge websites and never have to worry about swapping in a database driver.
And in case you're wondering, this affects control panel performance too. Large sites in Statamic 2 whose front-ends leverage caching may very well load fast, but their control panels do not. Not so in v3.
Based on this benchmark it looks like Statamic 3 is 1.4x to 5.5x faster than Statamic 2. But that's not the complete picture. Not by a long shot.
Cache Build Process
Cache builds are 20-30% faster and use 20-80% less memory. We've tested sites with more than 10k entries — an amount of content that crashed an equivalent test in v2 — and it didn't even sweat.
On Demand Requests
Data is requested on demand, only when your templates request it, and not before.
Statamic 3 automatically creates indexes for meta fields, like
id, and so on.
Additional indexes are created on demand automatically whenever you sort or filter. Our Stache Doctor tool logs and suggests additional indexes that will help speed your site up permanently.
Statamic adds virtually no overhead when on "regular" Laravel routes.
Statamic 3 leverages Laravel's cache, which gives you the option to use Redis, Memcached, or any other driver to manage and even speed up your cache further.
The Words at the Bottom of the Post
Everywhere you turn, Statamic 3 is faster, smarter, and more capable. It's equipped to scale with you and your data, and we can't wait for you to start building sites with it.
If you want to see even more Statamic 2 vs 3 benchmark results, be our guest! We've measured various concurrency levels, empty loads, and more. All benchmarks performed on a 2013 Macbook Pro with 2.8GHz Intel Core i7, 16 GB 1600 MHz DDR3.
I know it's been a quiet few weeks here at Statamic HQ. We've been working out the final kinks, writing migration scripts, and smoothing out workflows, making sure it plays nice with Laravel 5.7, 5.8, and 6.0, testing new use cases, fleshing out APIs, and writing a lot of documentation. It's been grueling work, very little of it the sort of exciting announcement-level features we've been dishing out all year.
We want your first experience with it — beta or not — to be as smooth and joyful as possible.
So hang in there, we're almost ready for you! 😁