Precompute

This page shows how to implement the precompute pattern in Next.js to keep pages static, even when multiple feature flags are used on a single page, or even when feature flags are used across multiple pages. Ensure you've read about the general precompute concept to understand the pattern and benefits:

The following assumes you've already set up the Flags SDK for SvelteKit as described in the Quickstart guide.

Manual approach

The simplest approach is to have a flag, evaluate it before the CDN is hit, and rewrite a path like /pricing to either /pricing-variant-a or /pricing-variant-b. At a high level you use Edge Middleware and SvelteKit's reroute hook to rewrite the incoming request between static versions of the page. These static versions are hardcoded, i.e. created upfront, and rewriting to one of them happens as hardcoded logic aswell.

This approach works well for simple cases, but has a few downsides:

• It can be cumbersome having to maintain both /pricing-variant-a/+page.svelte and /pricing-variant-b/+page.svelte.
• It doesn't scale well when a feature flag is used on more than one page, or when multiple feature flags or flags with many variants are used on a single page.

Why both Edge Middleware and reroute

You may wonder why we need to use both Edge Middleware and SvelteKit's reroute hook. In short:

• middleware.ts takes care of the initial full page visit
• reroute takes care of all subsequent client-side navigations
• middleware.ts will be ignored during development, as SvelteKit doesn't know about it. reroute will also take care of the initial full page visit in that case
• middleware.ts has access to cookies and private environment variables, reroute does not, which is why the latter needs to defer to the server to compute the result

Reroute hook

When SvelteKit resolves a URL to a route, it does so using a route manifest that is sent to the client on startup. Before the route is resolved, the reroute hook runs, which can rewrite the URL under the hood. That way we can keep the visible URL as e.g. /pricing while under the hood we reroute to one of the static versions of the page, e.g. /pricing-variant-a.

reroute runs on the client, but we need to access cookies and precompute a value to know which static version of the page to load, which in turn uses private environment variables. That means that reroute needs to make a request to the server to let the logic happen there.

export async function reroute({ url, fetch }) {
  if (url.pathname === '/pricing') {
    const destination = new URL('/api/reroute-manual', url);
 
    return fetch(destination).then((response) => response.text());
  }
}

The server can resolve the flag value (which may use cookies or headers which may be decrypted). Depending on that a rewritten pathname is returned, which SvelteKit's route resolution logic then uses to decide which components and data to load.

import { exampleFlag } from '$lib/flags.js';
import { text } from '@sveltejs/kit';
 
export async function GET({ request, cookies }) {
  const example = await exampleFlag(request);
  return text(example ? '/pricing-variant-a' : '/pricing-variant-b');
}

Edge Middleware

reroute is used at development time for all requests, both client and server-side. It is also called in production during soft navigations.

However when doing a full page visit (i.e. when a user first hits your page) in production we need to run something before the SvelteKit runtime, as we are using ISR or prerendering. reroute would run as part of the SvelteKit runtime, so it's too late. For that reason, we need to duplicate a bit of code within middleware.ts, which will be deployed by Vercel as Edge Middleware, which will run before the CDN is hit. Inside the middleware we use flags to rewrite the URL to a static variant of the page, similar to what we did in the server request as part of reroute.

import { rewrite } from '@vercel/edge';
import { exampleFlag } from './src/lib/flags';
 
export const config = {
  matcher: ['/pricing'],
};
 
export default async function middleware(request: Request) {
  const example = await exampleFlag(request);
 
    // Get destination URL based on the feature flag
  return rewrite(example ? '/pricing-variant-a' : '/pricing-variant-b');
}

Precomputing

Use the precompute functionality of the Flags SDK to work around the limitations of the manual approach. Use the precompute pattern to keep pages static, even when multiple feature flags are used on a single page, or even when feature flags are used across multiple pages.

At a high level you still use Edge Middleware and the reroute hook to rewrite the incoming request between static versions of the page. The difference is that you no longer hardcode those static versions, instead you create a dynamic route segment which is then filled with a hash that is generated from all the flag values used on that page.

Prerequisites

Make sure you've set up the Flags SDK for SvelteKit as described in the Quickstart guide. Additionally, install the @vercel/edge dependency from npm.

1. Create flags to be precomputed

Create one or multiple flags.

import { flag } from 'flags/sveltekit';
 
export const firstPricingABTest = flag({
  key: 'firstPricingABTest',
  decide: () => false,
});
 
export const secondPricingABTest = flag({
  key: 'secondPricingABTest',
  decide: () => false,
});

Export them as an array to be precomputed. Put them into a different file to later colocate other logic related to precomputing.

import { firstPricingABTest, secondPricingABTest } from './flags';
 
export const pricingFlags = [firstPricingABTest, secondPricingABTest];

2. Precompute flags from reroute hook

Set up the reroute hook to defer resolution of the pricing URL to the server.

export async function reroute({ url, fetch }) {
  if (url.pathname === '/pricing') {
    const destination = new URL('/api/reroute', url);
    destination.searchParams.set('pathname', url.pathname);
 
    return fetch(destination).then((response) => response.text());
  }
}

Add the server endpoint and compute the URL that should be routed to under the hood.

import { text } from '@sveltejs/kit';
import { computeInternalRoute } from '$lib/precomputed-flags';
 
export async function GET({ url, request, cookies, setHeaders }) {
  const destination = await computeInternalRoute(
    url.searchParams.get('pathname')!,
    request,
  );
  return text(destination);
}

This makes use of computeInternalRoute, which you add to the file where you exported the flags array from. This is where the precomputation happens by using the precompute function which you pass the flags used on that page and the current request. precompute will use these to invoke each flag, retrieve their value, and encode it as a route segment. As a result the user-visible URL /pricing is internally rewritten to something like /pricing/asd-qwe-123.

import { precompute } from 'flags/sveltekit';
 
export async function computeInternalRoute(pathname: string, request: Request) {
  if (pathname === '/pricing') {
    return '/pricing/' + (await precompute(pricingFlags, request));
  }
 
  // You can easily enhance this function to add more precomputed routes
 
  return pathname;
}

3. Precompute flags from middleware

Add similar logic to Edge Middleware, reusing the shared logic from precomputed-flags.ts.

import { rewrite } from '@vercel/edge';
import { normalizeUrl } from '@sveltejs/kit';
import { computeInternalRoute } from './src/lib/precomputed-flags';
 
export const config = {
  matcher: ['/pricing'],
};
 
export default async function middleware(request: Request) {
  const { url, denormalize } = normalizeUrl(request.url);
 
  if (url.pathname === '/pricing') {
    return rewrite(
      // Get destination URL based on the feature flag
      denormalize(await computeInternalRoute(url.pathname, request)),
    );
  }
}

4. Access the precomputation result from a page

Next, import the feature flags you created earlier while providing the code from the URL and the pricingFlags list of flags used in the precomputation.

When e.g. the firstPricingABTest flag is called within this server load function it reads the result from the precomputation, and it does not invoke the flag's decide function again:

import type { PageServerLoad } from './$types';
import { firstPricingABTest, secondPricingABTest } from '$lib/flags';
import { pricingFlags } from '$lib/precomputed-flags';
 
export const load: PageServerLoad = async ({ params }) => {
  const flag1 = await firstPricingABTest(params.code, pricingFlags);
  const flag2 = await secondPricingABTest(params.code, pricingFlags);
 
  return {
    first: `First flag evaluated to ${flag1}`,
    second: `Second flag evaluated to ${flag2}`,
  };
};

<script>
  let { data } = $props();
</script>
 
<p>{data.first}</p>
<p>{data.second}</p>

Enabling ISR (optional)

Now that the flags are precomputed, you should make sure to cache the result. You can do that by using Incremental Static Regeneration (ISR) on Vercel:

export const config = {
  isr: {
    expiration: false,
  },
};
 
export const load: PageServerLoad = async ({ params }) => {
  // ...
};

Enabling prerendering (optional)

You can precompute the results at build time instead of at runtime and prerender the results. For this, opt in to SvelteKit's prerendering using export const prerender = true. Then use generatePermutations within entries, through which you tell SvelteKit what variants of (in this example) the /pricing/[code] route exist, which it will then prerender.

import { pricingFlags } from '$lib/precomputed-flags';
import { generatePermutations } from 'flags/sveltekit';
 
export const prerender = true;
 
export async function entries() {
  return (await generatePermutations(pricingFlags)).map((code) => ({ code }));
}
 
export const load: PageServerLoad = async ({ params }) => {
  // ...
};

Next steps

You now know how to use the precompute pattern within SvelteKit. The above example didn't get into details about how to use e.g. cookies to determine the value of the flag. This and more is covered in the Marketing Pages guide.