We strongly believe feature flags should be used server-side.

When a feature flag is used on the client side, it can cause layout shifts and jank. The application needs to wait until the feature flags are bootstrapped over the network. In the meantime it has to take one of two bad choices:

• Show a loading spinner
• Speculatively show one version of the page

But if the feature flag turns out to have a different value, the page needs to be swapped out leading to jank.

When you use feature flags server-side, this problem is avoided. The server will only send the version of the page that matches the feature flag. No layout shift or jank.

Keeping pages static

A big benefit using client-side feature flags is that the page itself can stay fully static. Having static pages is great, as they can be served by the CDN around the world which has incredibly low latency globally.

A common misconception is that server-side usage of feature flags means that the page can no longer be static. This is not the case. The Flags SDK comes with multiple patterns which allow keeping the page static without falling back to client-side usage.

These patterns are made possible by using Routing Middleware. One or multiple feature flags can be evaluated in Routing Middleware, and the request can then be rewritten to serve a statically generated version of the page. This combines extremely well with Incremental Static Regeneration (ISR).

See the Marketing Pages example

Using feature flags on the client typically means the name of the feature flag is sent to the client. Often times teams then fall back to using cryptic alias for their feature flags in order to avoid leaking features.

When feature flags are used server-side, only the necessary code is sent to the client. In contrast, when using feature flags client-side it is common that both versions of the page are sent to the client, which leads to an increased bundle size.