Complete guide to conversion rate optimisation for static sites, headless CMS, and custom builds. Covers edge testing, feature flags, and advanced experimentation approaches.
When you strip away the content management layer, you gain control. Static site generators, headless CMS architectures, and custom-built applications offer capabilities that constrained platforms cannot match. For conversion rate optimisation, this means options: server-side testing, edge-based personalisation, feature flags, and experimentation integrated directly into your build pipeline.
This guide covers CRO for the category of sites that do not fit neatly into WordPress, Shopify, or other managed platforms. That includes static sites built with generators like Hugo, Jekyll, Eleventy, Next.js, and Astro. It includes headless architectures where a CMS like Contentful, Sanity, or Strapi provides content to a decoupled frontend. It includes fully custom applications built from scratch.
The common thread is developer control. You can implement testing however you choose. The trade-off is that nobody has pre-built the solution for you. CRO on custom architectures requires either development capability or resources to engage developers.
This increased complexity enables approaches unavailable on managed platforms. Server-side testing that never flickers. Edge-based experimentation that adapts to user context before the page renders. Feature flag systems that unify experimentation across product and marketing. If you have the capability to leverage these approaches, the results can exceed what constrained platforms achieve.
The "no CMS" category encompasses several distinct architectures, each with different CRO implications.
Static site generators (Hugo, Jekyll, Eleventy, 11ty, Gatsby) produce pre-built HTML files served from CDNs. Sites are fast, secure, and scalable, but content changes require rebuilds. For CRO, the static nature means traditional client-side testing works, but you also gain options for build-time variant generation.
Modern frameworks (Next.js, Nuxt, Astro, SvelteKit, Remix) blur the line between static and dynamic. Server-side rendering, static generation, and hybrid approaches are all possible. These frameworks enable sophisticated testing implementations integrated with the build and render process.
Headless CMS architectures separate content management from presentation. Content lives in systems like Contentful, Sanity, Strapi, or Hygraph, while the frontend is built with frameworks above. This separation enables content testing at the CMS level and presentation testing at the frontend level.
Custom applications built without framework constraints offer maximum flexibility. Testing can integrate at any level: database, API, server, client, or edge. The approach depends entirely on architecture decisions.
Jamstack sites (JavaScript, APIs, Markup) represent a common pattern within this category. The Jamstack survey shows continued growth in this architectural approach, with improved tooling for testing and personalisation at the edge.
The typical operator in this category is technically sophisticated or has access to development resources. CRO implementation requires either coding capability or budget for development work. If you lack both, managed platforms offer easier paths despite their constraints.
Custom architectures open testing approaches that managed platforms preclude.
Client-side testing works on any site that serves HTML to browsers. Traditional testing platforms (VWO, Optimizely, AB Tasty, Convert) install via script tags and manipulate the DOM after page load. This approach works identically regardless of how your HTML was generated.
Server-side testing becomes viable when you control your server or serverless functions. Instead of manipulating the DOM client-side, you serve different HTML to different users based on variant assignment. This eliminates flicker entirely and enables testing of elements that client-side tools cannot access.
Edge-based testing leverages CDN compute capabilities. Cloudflare Workers, Vercel Edge Functions, Netlify Edge Functions, and AWS CloudFront Functions can modify responses at the edge, enabling personalisation and variant delivery with minimal latency. This approach combines the performance benefits of static sites with the flexibility of dynamic testing.
Build-time variant generation is possible with static generators. Generate multiple versions of key pages at build time, then route users to appropriate variants via edge logic or split testing configuration. This approach trades build complexity for runtime performance.
Feature flag integration unifies testing with product development. Platforms like LaunchDarkly, Statsig, Eppo, and Split provide feature flagging that supports experimentation. You control feature exposure through code, enabling testing of any functionality you can wrap in a flag.
Performance considerations generally favour custom implementations. Without CMS overhead, base performance is typically strong. Testing implementations that leverage server-side or edge approaches avoid the client-side performance penalty of traditional tools.
Caching requires careful configuration. Static sites rely on aggressive caching for performance. Testing implementations must ensure that cached responses do not undermine variant assignment. Edge-based approaches handle this cleanly; CDN configuration handles it for static split testing.
Custom architectures can use traditional testing platforms or purpose-built tools that leverage the flexibility of custom code.
Traditional platforms on custom sites:
VWO, Optimizely, AB Tasty, and Convert all work on custom sites through standard script installation. These platforms provide visual editors, statistical analysis, and managed infrastructure. They represent the path of least resistance for teams wanting proven tools without custom development.
Purpose-built experimentation platforms:
Statsig provides experimentation infrastructure designed for product teams. Feature gates, experiments, and analytics integrate through SDKs for all major languages and frameworks. Server-side testing is first-class, and the platform handles statistical analysis. The product-focused approach suits applications more than marketing sites.
Eppo offers similar experimentation infrastructure with strong statistical methodology. The platform emphasises rigorous analysis and integrates with data warehouses for companies with sophisticated analytics practices. Server-side and client-side SDKs are available.
LaunchDarkly focuses primarily on feature management but includes experimentation capabilities. If your primary need is feature flagging with occasional A/B testing, LaunchDarkly provides unified tooling. The platform excels at controlling feature rollout across complex systems.
GrowthBook offers open-source experimentation infrastructure. Self-hosted or cloud options provide feature flags and A/B testing with warehouse-native analytics. For teams wanting control without vendor lock-in, GrowthBook merits consideration.
Split provides experimentation as part of a feature delivery platform. The combination suits product teams managing both rollout and testing across applications.
Edge-specific tools:
Vercel Edge Config enables A/B testing at the edge for Next.js applications deployed on Vercel. Configuration-driven testing integrates with the deployment platform.
Cloudflare Workers enables custom testing logic at the edge. You write the implementation, gaining complete control at the cost of development effort.
What to avoid: Building custom testing infrastructure from scratch unless you have specific requirements unmet by existing platforms. Statistical analysis, sample size calculation, and result interpretation are solved problems. Leverage existing solutions rather than reimplementing.
Custom architectures offer maximum flexibility for analytics implementation.
Google Analytics 4 works on any site serving HTML. Implementation via Google Tag Manager provides flexibility for event tracking configuration. For server-rendered applications, server-side GTM enables tracking that survives client-side privacy restrictions.
First-party data collection becomes practical with custom implementations. Instead of relying on third-party cookies, you can collect analytics data through your own infrastructure. This improves accuracy as browser privacy features increasingly restrict third-party tracking.
Warehouse-native analytics suits organisations with data infrastructure. Send events to your data warehouse (BigQuery, Snowflake, Databricks) and run analysis there rather than in analytics platform interfaces. This approach scales to complex analysis needs and integrates with experimentation platforms like Eppo and GrowthBook.
Privacy-friendly platforms work on any architecture. Plausible, Fathom, and Pirsch install via script tags and provide cookieless tracking. Simple Analytics offers similar functionality. These platforms suit sites prioritising privacy whilst maintaining adequate measurement.
Event tracking architecture deserves design attention on custom builds. Define your event taxonomy thoughtfully. Consistent naming, clear hierarchies, and documented schemas prevent the analytics debt that accumulates in rapidly developed applications.
Server-side tracking is more accessible on custom architectures than on managed platforms. Server-side GTM, first-party tracking endpoints, and direct warehouse integration all become viable when you control the server layer.
Custom architectures enable testing approaches unavailable on constrained platforms, alongside standard optimisation patterns.
Performance as conversion lever: Custom sites often have performance advantages. Test whether further performance improvements affect conversion. Lazy loading strategies, image optimisation, and code splitting all present testable hypotheses.
Progressive enhancement testing: Test whether features added for enhanced experience actually improve conversion or merely add complexity. JavaScript-dependent functionality, animations, and interactive elements may not serve conversion goals despite developer enthusiasm.
API response testing: For applications with backend integration, test different API response structures or content. This server-side testing is unavailable on client-side-only platforms.
Navigation and information architecture: Custom builds can test radical navigation changes that managed platforms constrain. Test whether your carefully designed navigation actually outperforms simpler alternatives.
Content personalisation: Edge-based approaches enable personalisation without client-side performance penalty. Test personalised versus generic experiences at levels of sophistication that client-side tools struggle to match.
Checkout and conversion flow: For e-commerce applications, control over checkout enables testing that Shopify and other managed platforms restrict. Multi-step versus single-page, field ordering, payment presentation, and error handling are all testable.
Feature introduction: Use experimentation infrastructure to test new features before full rollout. This product-focused testing integrates marketing optimisation with product development.
Mobile versus desktop divergence: Without template constraints, you can build genuinely different mobile experiences rather than responsive adaptations. Test whether mobile-specific designs outperform responsive approaches.
Custom architectures scale CRO programmes differently than managed platforms.
Testing velocity depends on development resources. Without visual editors, every test requires code. Teams with strong development capability can move quickly; teams dependent on external development may find velocity constrained.
Multi-environment testing becomes relevant for applications with staging, development, and production environments. Testing infrastructure must account for environment differences and ensure production parity.
Team capability requirements are higher than for managed platforms. Someone needs to understand both experimentation methodology and your specific technical architecture. This combination is less common than either skill alone.
Integration complexity increases with sophistication. Feature flag systems, experimentation platforms, analytics infrastructure, and data warehouses create integration surfaces that require maintenance and monitoring.
Vendor independence improves with custom implementation. You can switch testing platforms without rebuilding your entire approach. Data lives in your infrastructure rather than vendor systems.
Global distribution is often excellent for static and edge-based approaches. Testing that leverages edge compute inherits the distribution benefits of your CDN architecture.
A phased approach builds capability while delivering value at each stage.
Phase 1: Foundation (Weeks 1-4)
Audit your current architecture and identify where testing implementation fits naturally. Server-side rendering? Edge functions? Pure client-side? Your architecture determines your best testing approach.
Implement comprehensive analytics if not already present. GA4 via GTM is the default choice; warehouse-native approaches suit organisations with data infrastructure. Ensure event tracking covers conversion actions before testing begins.
Select your testing approach based on team capability and architecture. Traditional client-side tools (VWO, Optimizely) provide the fastest path to testing capability. Feature flag platforms (LaunchDarkly, Statsig) suit product-oriented teams with development resources.
Install and configure your chosen platform. Verify variant assignment works correctly across your infrastructure.
Phase 2: Quick Wins (Weeks 5-12)
Start with tests that leverage your architecture's strengths. If you have edge capabilities, test content personalisation. If you have server-side rendering, test layouts that would flicker with client-side tools.
Address obvious friction points visible through analytics. High bounce rate pages, confusing conversion flows, and performance-impaired experiences present clear opportunities regardless of architecture.
Build documentation and processes appropriate for development-integrated testing. Testing should work within your existing deployment pipeline rather than around it.
Phase 3: Systematic Programme (Ongoing)
Develop integrated experimentation practices that unify product and marketing testing. Feature flags and A/B tests should use consistent infrastructure and methodology.
Establish hypothesis development that leverages your data capabilities. With warehouse-native analytics and sophisticated segmentation, you can form hypotheses that simpler infrastructures cannot support.
Consider whether your testing capabilities create competitive advantage. The flexibility of custom architecture enables experimentation approaches that constrained competitors cannot match.
Custom architectures enable CRO approaches that managed platforms preclude. Server-side testing, edge personalisation, feature flag integration, and warehouse-native analytics create possibilities that WordPress, Shopify, and their peers simply cannot offer. The price is capability requirement: someone needs to build and maintain testing infrastructure.
For organisations with development resources and sophisticated optimisation ambitions, custom architectures provide genuine advantage. Testing becomes part of the development process rather than a marketing bolt-on. Experimentation infrastructure scales with application complexity.
For organisations lacking development capability, the same flexibility becomes a barrier. Without visual editors and managed infrastructure, testing velocity depends on developer availability. Constrained platforms may actually deliver more value despite their limitations.
AWIP works with organisations across this spectrum, from simple Wix sites to complex custom applications. If you are building or maintaining custom architecture and want to develop experimentation capability that leverages your technical investment, get in touch.
(10).png)
(9).png)
(6).png)
(5).png)
(4).png)
(3).png)
(2).png)
(1).png)
.png)
.png)
(7).png)
.png)
