Replacing Google Optimize with the Vercel Edge Network

The End of Google Optimize

Google has announced that Optimize will be sunset on September 30, 2023. Since 2012, it has been a common tool for running A/B tests and UI experiments, but its architecture was never ideal for performance. The scripts required on every page add weight and delay load times; client-side variant switching often introduces Cumulative Layout Shift (CLS); and server-side calls to Optimize add latency. As the shutdown date approaches, teams need a replacement that doesn't compromise on speed or data quality.

Vercel offers a path forward by moving experimentation logic to the edge, where configuration reads can be sub-millisecond and content is served from the geographically closest CDN node. This approach recreates Optimize's core functionality while addressing its key performance drawbacks.

Edge Config and Routing Middleware

Two Vercel features form the backbone of this migration strategy: Edge Config and Routing Middleware.

Edge Config is a small data store that replicates configuration data across Vercel regions globally. Experiment variants and feature flags become instantly available, with average read times under 10ms. This data can be fetched either in Routing Middleware for request-routing decisions or in Vercel Functions for backend logic.

Routing Middleware executes at the edge, between the CDN and your deployment. It can read the Edge Config to determine which variant of a page to serve—before the request reaches the origin server.

Together, these primitives allow you to serve the correct experiment variant statically, at the speed of dynamic content, without any client-side computation after initial load.

Eliminating Layout Shift

By computing variants in Routing Middleware instead of on the client, you avoid the CLS that plagues client-side experimentation. The page arrives with the correct variant already rendered.

This strategy is proven: Speedway Motors reduced their CLS by 50% by moving experiments to the edge, as measured with Vercel Analytics.

Tracking With Your Existing Stack

For analyzing results, there's no need to change your analytics infrastructure. Pass the experiment context—such as variant ID and experiment name—as properties to whatever data solution you already use.

For example, a checkout button experiment might log event data like this:

import { saveData } from'@your-data-provider/sdk';
export const CheckoutButton = () => { 
  useEffect(() => {
    // Track how many times button was rendered
    // and which experiments were active
    saveData("Checkout button impression", {
      isWinterSale: true,
      saleColor: "red", 
      buttonColor: "blue"
    })
  }, [])
  const handleClick = () => {
    // Track when a user clicks the button
    // and which experiments were active  
    saveData("Checkout button click", {
      isWinterSale: true,
      saleColor: "red", 
      buttonColor: "blue"
    })
    // Your checkout logic
    console.log("Check out!")
  }
  return (
    <button onClick={() => handleClick()}>
      Checkout
    </button>
  )
}

This keeps your data pipeline intact while allowing for gradual migration of experiments from Optimize to the edge. Each test you move over improves performance while preserving the experimentation data your business depends on.

Incremental Migration

The move from Google Optimize can be done incrementally, experiment by experiment. The edge-based approach gives you:

• Sub-millisecond configuration reads
• No code changes required in your Vercel dashboard
• Compatibility with your existing data ingestion workflow

You keep the experimentation methodology that works for your team, while eliminating the performance bottlenecks Optimize introduced. Every migrated test delivers the same insights—with better page performance, no layout shift, and data that's simply a function call away.