There used to be a trade off between personalization and performance. Not anymore. Today, you can deliver high-speed tests and personalization from the edge using Next.js and Vercel’s recently announced edge middleware. And, with Builder, you can allow your non-technical teams to move faster and create all the pages and personalized variations they want, while ensuring everything meets your expectations, uses your design system, and is high performance.
Builder’s headless no-code platform plugs into any stack and works seamlessly with any website configuration. If you have a Next.js site, use these resources to get up and running quickly.
In this post we will cover:
1. How personalization has been implemented in the past, what went well, and what we have learned
2. How to personalize Next.js sites with edge middleware
3. How to allow non-technical teams to create personalized experiences and tests independently and within your guidelines
Static sites are extremely fast, but everybody sees the same content (your homepage is the same page for everyone). Most methods currently used to avoid this issue include loading placeholders, or empty boxes that pull personalized information client-side, like the items in your cart, or specifically personalized products.
Traditionally, there has always been a tradeoff between personalization and performance. We call this the conversion paradox. The conversion paradox is when you start introducing more tools to try and drive an increase in conversion, and in doing so, you shoot yourself in the foot because you ruin your performance, and actually make the experience worse.
That's why edge middleware is such an incredible solution! You can integrate in less than 10 lines of code and create synchronous, fast rewrites. You can then use Builder to empower anybody on the team to add personalized variations of pages to your current site, using your existing components and tech stack.
How does it work? Under the hood, the edge middleware is rewriting requests. For example, if someone visits your “about” page, we're going to extract personalized information from their cookies and rewrite the
/about page to add a delineator, like a semicolon. Then, at key value pairs, the path for the page is not just
/about. All of the personalization information, be it previous shopping purchases, browsing behavior, attributes from your CDP, or anything else such as UTM parameters, becomes part of the new path that becomes the cache key.
The secret sauce here is that Next.js is performing incremental static regeneration (ISR) using the
fallback: true option. As a result, any unique new combination of parameters for the "about" page path is fetched and catched at the edge, so that it is served instantly to subsequent users.
Overall, 99.99% of requests are going to get instant loads from cache due to real-time static generation, with only an extreme minority of visitors with unique combination parameters going through the full circle.
The beauty of Builder is that it seamlessly connects to whatever you have. Builder already supports edge middleware, ISR, SSG, as well as your choice of frontend framework, CMS, e-commerce platform, custom backend, and more. Once integrated into your stack, Builder adds the ability to build and optimize your current site visually, using your existing design system and React components.
Stop hard coding pages. Stop being limited to templates. A page might look good today with the hero on top and a couple columns below. But perhaps tomorrow, you’ll want your hero to be a carousel and an additional column below. And maybe you don't want to be constantly going back and forth between your CMS and committing code.
Maybe what you really need to do is provide a toolkit for non-developers to integrate a portion of your site and register a set of components from your design system, so that they can then rearrange the components, input the props and configure personalization and A/B testing using a UI. All of which will be blazing fast and high-performance at the edge, connected beautifully to React code and published remotely. So your content can publish and rollback separately from your actual code.
In practice, there are many flavors. Some people build their site completely with Builder and Next.js, as it doesn't require a lot of custom coding. Others will work Builder into an existing site. Either way, non-technical teams gain the ability to add and rearrange elements using their design system, code components, or even drag and drop to create bespoke experiences from scratch. They can run personalized tests, like showing different images or products by locale, and schedule them to publish live. And developers can focus on components, not templates, knowing everything meets their expectations, uses their design system, and is high performance all the time.