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
Traditional solutions for personalization are slow. In the past, you’d send a request to a remote server around the world, which could take 100-200 milliseconds just to reach a destination. Then, the server would pull in dynamic data, assemble the page on the fly, and send it back around the world. Then, in most cases, blocking Javascript would prevent the page from being visible, pulling in personalizations or other information, and only when that was done would the page load for the end-user. Now that's quite slow. We want fast pages that are immediately visible and personalized.
Static sites are generic
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.
Unfortunately, these methods also result in long load times. Round trips to the origin server are still required, as well as fetching and rendering personalized data on the fly, and blocking Javascript that might add additional content injections that are unique to the visitor. All of this ultimately results in poor performance on mobile.
The best of both worlds: a fast, personalized site
What we want is a cached response. And we want it locally, from the CDN edge network to eliminate travel time between the edge server and your visitor. Because it is cached, it is immediately available with a response time of milliseconds. No round trip, no blocking Javascript, you just get your personalized page without any hiccups.
You can deliver instant personalization using high-speed optimization with edge middleware. This will allow you to customize the experience based on what you know about the end-user, without impacting performance with blocking Javascript or other methods.
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 stack
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.
