Eating Our Own Dog Food: How We Redesigned Sulu.io with Headless Sulu and Remix
We decided to put our headless capabilities through the ultimate test: rebuilding our own website to understand when this approach truly makes sense.
While Sulu has supported headless projects for years, our own website remained traditionally built with Symfony and Twig. When redesign time arrived, we saw an opportunity to gain real-world experience with the headless path — not because it's inherently better, but because we wanted to understand its trade-offs firsthand.
Building for Modern Performance Standards
Beyond a fresh design and great UX, our technical requirements were clear from the start. We needed excellent SEO performance with proper server-side rendering, millisecond response times across all device types, and a development workflow that scales with our growing team.
We weren't debating headless versus traditional — we knew what we needed to accomplish. This redesign gave us the chance to validate newer technologies while hitting the same core performance benchmarks that matter to our users.
The Technology Stack
- Backend: Sulu CMS handling content management and API delivery
- Frontend: Remix providing server-side rendering with selective client-side hydration
Sulu's decoupled architecture proved its worth in this setup. As a CMS that supports both traditional server-side rendering and modern headless approaches, it gave us exactly the flexibility we needed to optimize for our specific use case.
Why React Feels Right for Interface Development
Let’s be honest — React was built for this kind of work. Its component-based architecture feels incredibly natural when building web interfaces. Where Twig templates can sometimes feel like you’re pushing against the grain, React components just flow.
Frontend engineers immediately feel at home because they can:
- Think in reusable components from day one
- Leverage the entire JavaScript ecosystem
- Use familiar tooling and development patterns
- Build interactive interfaces without mental context switching
This component-based approach isn’t just a convenience — it fundamentally changes how you architect the frontend. Need a hero section? Create a <Hero> component. Complex navigation? Build a <Navigation> component. Each piece is self-contained, testable, and reusable.
Design systems and atomic design patterns also come more naturally. Building from atoms (buttons, inputs) to molecules (search bars, cards) to organisms (headers, content sections) feels intuitive when each level represents an actual React component. This systematic approach to interface development is exactly what React was designed for.
Learning That Benefits Our Entire Community
This wasn't just a website redesign — it was a learning expedition. By using our own product in a new way, we gained valuable insights into performance optimization in headless setups, developer experience when working with Sulu's APIs, and the real-world challenges our users face when going headless.
Every bug we fixed, every performance bottleneck we hit, every "aha!" moment we had — all of it feeds back into making Sulu better for everyone. This learning process isn't just about our website; every insight we gained gets folded back into Sulu's development, helping our entire community tackle similar headless challenges more effectively.
The Headless Performance Myth
There's a widespread belief that going headless automatically delivers better performance. We need to be precise here: which performance are we talking about? Response times? Development velocity? User experience?
Let's examine response times first. Headless setups introduce more moving parts — separate backend and frontend services, API calls, multi-layer caching, and complex deployment pipelines. Each request travels through more layers than traditional setups, and every additional hop introduces latency.
We experienced this reality firsthand. Without proper HTTP caching strategies, our headless architecture wasn't viable at scale. Our performance only improved through deliberate implementation of API response caching, HTML caching, and CDN strategies working together. The same optimization principles apply to traditional server-rendered websites.
Development velocity? That depends entirely on your team's expertise and how you structure your workflow. User experience improvements? Possibly, but modern approaches like Symfony UX with Turbo can deliver similar interactive experiences through traditional server-rendered architecture.
The answer is clear: headless doesn't automatically mean better performance. Choose based on your specific requirements, not assumptions.
The Reality of Headless Complexity
Going headless introduced complexity that traditional Symfony deployments simply don't have. We encountered these challenges so our community can learn from our experience:
Deployment Complexity
Deployment complexity became our first reality check. What used to be straightforward Symfony deployment became coordinating multiple services — managing Symfony/PHP backend deployments alongside Node.js frontend runtimes, juggling environment variables across services, handling API calls, configuring the reverse proxy properly, defining x-forwarded and trusted proxy headers correctly, and ensuring both PHP and Node applications stay perfectly synchronized.
Caching Becomes Trickier
Caching strategy also required more thought. Where traditional Sulu offered straightforward caching through the framework or simple Varnish setup, our headless architecture now demands careful orchestration of API response caching, HTML caching for the frontend, and cache invalidation across both levels.
Form Handling Gets Complex
Form handling evolved from simple to complex. Remember those straightforward Symfony forms that just worked? Now every form submission needs to call the backend API, handle loading states gracefully on the frontend, manage error responses with finesse, and maintain validation synchronization between client and server.
The Traditional Symfony/Twig Alternative
It’s worth noting that the traditional approach isn’t going anywhere — and for good reason. If you want to see how productive and organized Twig templating can be, check out Alex’s upcoming talk “A Productive Frontend Stack with Symfony UX” at SymfonyCon 2025 in Amsterdam.
Recent projects using Symfony UX with well-structured Twig components demonstrate that the traditional approach often provides exactly what projects need. Symfony UX has evolved dramatically, bringing Stimulus, Turbo, and Live Components that make server-side rendering more dynamic and interactive than ever.
Why This Matters for Sulu Users
Our journey from traditional to headless wasn't just an internal experiment — it's a real-world test that helps us better guide our users on when each approach makes sense.
Go headless when you have:
- Frontend teams experienced in JS frameworks
- Complex interactivity that benefits from React/Vue/Angular
- Independent frontend/backend deployment needs
Stick with traditional Symfony/Twig when you have:
- Teams comfortable with server-side rendering patterns
- Projects that benefit from simpler deployment and caching
- Straightforward content websites without heavy interactivity
- Tight timelines where reduced complexity is a must
Consider Sulu's hybrid approach for projects that need traditional server-side rendering in the CMS while consuming content through APIs for mobile apps, digital signage, or specialized interfaces.
The Bottom Line
The real test isn't whether you choose headless or traditional — it's whether your choice aligns with your team's strengths and project requirements. Our headless journey gave us the insights to help you make that decision with confidence.
Would we choose headless again for our own website? Most likely not. There are no specific requirements pushing us in this direction for a content-focused site like ours. But this was an incredibly valuable learning experience that deepened our understanding of when headless truly makes sense.
Both approaches have earned their place in modern web development. Sulu supports your decision either way, and our own experience proves that the right tool for the job always beats the trendy one. Choose based on requirements, not headlines.
