For most Craft CMS projects, stick with Twig templates. They ship faster, they are easier to maintain, and they give you Craft’s best editorial features – like Live Preview – without extra work. Go headless when you have a concrete reason: your frontend needs data from multiple sources beyond Craft, you have real hosting or performance requirements that call for static builds, or your project is genuinely more app than website. If you do not have one of those reasons, you are not falling behind by using Twig. The overlooked middle ground – Twig templates for pages with selective GraphQL for interactive components – handles the vast majority of real-world Craft projects.
That 73% of businesses now use some form of headless architecture (Storyblok/WP Engine, 2025) makes it sound like Twig templates are a dead end. The headless CMS market is projected to grow from $3.94 billion to $22.28 billion by 2034, a 21.4% compound annual growth rate (Market Research Future). The pressure is real, and I hear it constantly from developers who worry they are making a legacy bet.
But here is the thing: choosing the wrong architecture adds 30-50% development overhead and can quietly break your editorial workflow (Happy Cog). This is not a decision to make because of conference buzz or a trending blog post. It should come down to your project requirements and your team.
The headless hype has been pretty big, and it is unsurprising that some people think everything needs to be headless. But what are you really gaining by going headless? There has to be a real reason – it has to be more than just “this is cool tech to work on.”
Twig is the right call when the website is the primary output of the CMS. Marketing sites, content-heavy publications, blogs, portfolio sites, and small-to-mid e-commerce builds with Craft Commerce all fit here. If you are building one website and it does not need to behave like a single-page application, Twig gets you to launch faster with less infrastructure to manage.
The team factor matters more than most people admit. If your team knows PHP and Twig but does not have deep React, Vue, or Next.js experience, going headless means learning a new frontend framework and learning how to wire it to Craft’s API – at the same time, on a deadline. Client projects should not be your learning ground for keeping up with new technology.
A technical detail worth knowing: both Twig templates and GraphQL queries use Craft’s Element Queries under the hood. As Andrew Welch of nystudio107 has documented, the underlying query engine is identical – the GraphQL API is auto-generated from your content models and resolves through the same Element Query layer that powers Twig. Twig is not a slower or less capable way to access your content. It is a different delivery mechanism on the same foundation.
Then there is Live Preview. With Twig, content authors see exactly what they are publishing, in real time, inside the Craft control panel. There are ways to use Live Preview with headless Craft CMS setups, and it is easier than it used to be – so this is not the dealbreaker it once was. But with Twig, it works out of the box with zero configuration, while headless setups still require building custom preview targets in your frontend framework.
One codebase. One deployment. No separate frontend application to build, host, and keep in sync. For most Craft projects, that simplicity is a feature, not a limitation.
Sometimes your frontend application is handling data from multiple sources, not just from Craft CMS. When it makes more sense to have that frontend layer stand alone and fetch data from a CMS and other data sources via an API or GraphQL, headless is the right architecture. This is the original and still strongest case for going headless, and 82% of headless adopters cite simplified content reuse across channels as a primary benefit (Storyblok/WP Engine, 2025).
The second case is hosting and performance requirements. Sometimes the client wants the site built statically and rebuilt with content updates. Headless makes that workflow much easier – frameworks like Astro and Next.js are built around this pattern.
The third factor is team composition. If your developers already build in Next.js, Nuxt, or Astro and would have to learn Twig from scratch, headless lets them stay in their strongest tools. Craft released official Next.js and Astro starters in 2025, making this path significantly smoother. And with Craft 6 set to run as a Laravel component, the headless integration story will keep expanding.
As Happy Cog noted, headless can reduce long-term cost of ownership and enable faster iteration – but only when the project genuinely requires the architectural separation. The upfront investment needs to be justified by the use case, not by industry trends.
For what it is worth, I have not yet had a project where headless was clearly the right call – and that is not for lack of looking. It is just not that common for the kinds of Craft CMS work most developers are doing. Headless in Craft is not that large right now, but it will get bigger in the future. You should definitely learn those skills and be prepared. But just do not do it for no reason.
Yes, and this is the approach I recommend most often.
Craft does not force an either/or choice. As Working Concept wrote: “Craft is not forcing you to change anything.” Their recommendation is to “sprinkle a little Vue or React” into a Twig-rendered site before committing to a full headless rewrite. You can render your pages with Twig templates and use GraphQL or the Element API to power specific interactive components – search, filtering, dashboards, dynamic forms – wherever client-side interactivity genuinely adds value.
The incremental path looks like this: start with Twig. Ship your site. When a specific feature needs richer interactivity than server-rendered HTML provides, add a Vue or React component that pulls data from Craft’s GraphQL API. You keep Twig’s speed, editorial features, and simple deployment for 90% of the site and reach for JavaScript only where it matters.
CraftQuest has some material on hybrid approaches, but most of our training focuses on the Twig-native setup – because that is what the majority of Craft projects call for. That said, we plan to expand our hybrid and headless coverage in the coming months as more developers explore these patterns.
This avoids the trap Working Concept warns about: treating headless, JAMstack, and GraphQL as a single package deal. They are separate decisions, and you can adopt each one independently based on actual needs.
Headless is not the only way to learn how to use a tool like Next.js or other modern JavaScript frameworks. I would not use a client project to learn the technology. If it is a personal project or a play project or a learning project, that is one thing – definitely do that, learn. But not for customer or client projects. They should not be your learning ground for how you keep up.
The CraftQuest project uses a combination of Twig and Vue. It isn’t a headless setup, but we get the reactivity and ease of use of Vue while not having the complexity and overhead of a pure headless setup.
The most common mistake we see is developers choosing headless because it sounds like the modern thing to do, then spending weeks rebuilding features Craft gives you for free with Twig – Live Preview, template caching, dynamic routing, native pagination. The headless versions of those features work, but you have to build each one yourself.
The trajectory is clear: more developers are asking about headless now than two years ago. But the majority of CraftQuest learners still build with Twig templates. The ratio is shifting, not flipping.
“You should make requirements for a project tech stack based on the needs of the project; not because you as a developer are having some FOMO or feeling like you’re being left behind. You’re not being left behind. This stuff moves so quickly.” – Ryan Irelan, CraftQuest
If you are leaning headless, start with the CraftQuest headless Craft CMS course, which covers both Element API and GraphQL approaches with real project examples.
If Twig templates are the right fit, CraftQuest has deep training on Craft’s templating system that will get you building production sites quickly.
Either way, grab a free Craft Solo license and prototype both approaches on a small project. Thirty minutes with each will tell you more than any blog post.
Yes. There are ways to use Live Preview with headless setups, and it is easier now than it was in the past. Craft’s native Live Preview works automatically with Twig templates, while headless mode requires setting up custom preview targets in your frontend framework. It is no longer a dealbreaker, but it is still extra configuration to plan for.
Next.js and Astro have official Craft CMS starters, making them the smoothest options right now. Nuxt and SvelteKit also work well via Craft’s GraphQL API. Choose based on your team’s existing skills rather than framework popularity.
Expect 30-50% more initial development time for headless, mainly from building the frontend application separately and configuring preview, routing, and caching that Twig handles automatically. Long-term maintenance costs depend on your team’s framework expertise.
Yes. Craft’s content modeling is independent of the delivery layer, so you can switch from Twig to headless without restructuring your content. The migration effort is in rebuilding your templates as frontend components – not in reworking your CMS.
Craft gives you the option to go headless while keeping traditional templating as a fallback. Dedicated headless platforms like Contentful are API-only with no template layer. Choose Craft if you want flexibility between both approaches; choose a dedicated headless CMS if you are certain you will never need server-rendered templates.