Monolithic Statamic architecture slows down when page count exceeds 200,000 — LCP jumps to 4 seconds, and TTFB increases due to overhead from Twig template execution. For example, an e-commerce store with 5,000 products after switching to headless reduced page load time from 3 to 1.2 seconds, boosting conversion by 15%. The solution: switch Statamic to headless mode, delegating rendering to a React application. On one project, we set up REST API in a couple of hours and added GraphQL within a day — performance improved by 40%: LCP dropped to 1.2 seconds, TTFB decreased by 35%.
REST API Setup in Statamic
To enable the REST API, simply set a flag in config/statamic/api.php. By default, all resources except forms and users are available — reasonable from a security standpoint. We recommend explicitly specifying the needed collections to avoid exposing extra data. After activation, you can fetch entries via GET requests with filtering, sorting, and pagination. For a blog, we use a filter by status, sorting by date, and a limit of 12 entries per page, reducing response time by 30%. For the frontend on Next.js, we wrote a simple helper that caches responses and updates them on publish via webhook.
Setup steps:
- Enable the API in
config/statamic/api.php. - Configure resources — disable unnecessary ones.
- Verify endpoint availability via
curl /api/v1/collections.
Example config:
return [ 'enabled' => env('STATAMIC_API_ENABLED', true), 'route' => '/api/v1', 'resources' => [ 'collections' => true, 'taxonomies' => true, 'assets' => true, 'globals' => true, 'forms' => false, 'users' => false, ], 'cache' => [ 'enabled' => env('STATAMIC_API_CACHE', true), 'expiry' => 60, ], ]; Example request to the blog collection:
const res = await fetch( `${STATAMIC_URL}/api/v1/collections/blog/entries?` + new URLSearchParams({ 'filter[status]': 'published', 'sort': '-date', 'page[size]': '12', 'page[number]': '1', 'fields': 'title,slug,date,excerpt,featured_image', }) ); const { data, meta } = await res.json(); Choosing GraphQL for Complex Queries
If there is a lot of data and the client needs precise selection, GraphQL offers flexibility. Install the addon for the Pro version (paid license). On one project with five related collections, we reduced the number of requests from seven to one, which lowered TTFB by 60% and decreased database load by 4 times.
Installation:
composer require statamic/graphql php artisan vendor:publish --tag=statamic-graphql-config Schema configuration:
// config/statamic/graphql.php return [ 'enabled' => true, 'route' => '/graphql', 'resources' => [ 'collections' => ['blog', 'pages', 'events'], 'taxonomies' => ['categories', 'tags'], 'globals' => ['site'], 'assets' => ['assets'], ], 'middleware' => ['web'], 'cache' => ['enabled' => true, 'expiry' => 3600], ]; Example query:
query BlogPosts($page: Int, $limit: Int) { entries( collection: "blog" filter: { status: { eq: "published" } } sort: [{ field: "date", order: "DESC" }] limit: $limit page: $page ) { data { id slug title date ... on Entry_Blog_Post { excerpt featured_image { id url width height alt } categories { title slug url } } } total per_page current_page last_page } } Which API to Choose?
| Criterion | REST | GraphQL |
|---|---|---|
| Time to implement | 4–8 hours | 1–2 days |
| Query flexibility | Limited by parameters | Full |
| Client load | More requests | One request |
| Caching | Simple | More complex |
| Free? | Yes | Requires Pro license (paid) |
REST is simpler, but GraphQL is faster for complex pages — in one project, we reduced load time by 35% by using a single query instead of five. Learn more about GraphQL in Statamic in the official documentation.
Why Headless Statamic Is Better Than Monolithic?
The headless approach offloads rendering to a CDN, reducing server load. In a project with 200,000 pages, we achieved hosting cost savings of up to 60%, with TTFB consistently below 200 ms. Additionally, frontend development on React or Next.js speeds up thanks to component reuse and rapid prototyping.
What’s Included in Headless Statamic Setup
- API deployment (REST/GraphQL) with required resources
- Custom GraphQL types for business logic
- Integration with frontend (React, Next.js, Vue)
- Caching configuration and webhooks for invalidation
- Documentation of endpoints and example requests
- Access to repository and dev server
- One-hour consultation on usage
Our team's experience: 5 years with Statamic and 12+ headless projects. We guarantee the API will work stably under load. Contact us to evaluate your project.
Common pitfalls during setup
- Caching not enabled — every request hits the database, TTFB increases.
- Too many resources exposed — e.g., enabling
formsandusersunnecessarily. - GraphQL schema without authorization — data accessible via public endpoint.
We account for these nuances at the design stage. For example, on one project after switching to headless, server costs dropped by 60% due to offloading rendering to a CDN.
Timeline
| Task | Time |
|---|---|
| REST API (basic) | 4–8 hours |
| GraphQL with custom types | 1–2 days |
| Frontend integration | from 1 day |
Pricing is determined individually. Get a consultation: send us a project description — we’ll provide a full estimate.







