Skip to main content

Feature Flags with a Seat for Everyone

Say goodbye to per-user pricing and hello to feature flags in your IDE.

Learn More

Your users deserve zero-ms A/B Tests, Feature Flags, and Live Config

· 7 min read
Jeffrey Chupp
Jeffrey Chupp
Prefab Founding Engineer. Three-time dad. Polyglot. I am a pleaser. He/him.

💰 Front-end performance is critical​

Fred Wilson once said

We believe speed is more than a feature. Speed is the most important feature.

He's not wrong. The faster your app becomes interactive, the more likely your users are to stick around. The more likely they are to stick around, the more likely they are to convert. The more likely they are to convert, the more money you make.

It isn't hard to follow the trail from Speed to Money. But keeping things speedy isn't easy as you add features.

📉 Every HTTP request is a performance hit​

As a web developer, you'll eventually be asked to add A/B testing or feature flags to your app. But you're wizened enough to know that every HTTP request is a performance hit. Slapping in a third-party SaaS JavaScript library to handle A/B testing or feature flags will slow down your app.

A/B testing is particularly egregious because you don't even know what content to show until you've made a request to a third-party server. The user is either watching spinners while waiting for the content to load or they see a FOOC (Flash of Original Content) where the default content is shown before the A/B test content is loaded.

FOOC is the new FOUC (Flash of Unstyled Content). It's jarring, confusing, and makes things feel broken.

Spinners are not the answer. They're a band-aid on a bullet wound.

Your users deserve better.

The best way to avoid FOOC and performance hits is to render the content server-side.

🔧 Client-side Rendering is a wrench in the works​

If you're rendering your content client-side (like with React or Vue), you're already taking a performance hit. You're asking the user to download a bunch of JavaScript and have it execute before they can interact with the page.

This is a calculated trade-off. You're betting that the rest of the user experience will be so good that they'll forgive the initial load time.

Hybrid apps (server-side rendered with client-side interactivity) attempt to be the best of both worlds. You get the speed of server-side rendering with the interactivity of client-side rendering.

This makes the bet a little safer. You can show the user the content immediately and then let the JavaScript take over to make the page interactive.

How do you add A/B testing, feature flags, and live config to your hybrid app without the performance hit? If you can't render the entire content server-side, then you need to evaluate the rules server-side to bootstrap the page. Many A/B testing and feature flag services can't provide this because they're built around an HTTP request. Prefab can.

🦸 Prefab's server-side SDKs save the day​

Prefab's server-side SDKs let you do A/B testing, feature flags, and live config without the overhead of a blocking HTTP request (0ms).

How is this possible? Prefab SDKs load the entire ruleset for your organization into memory on your server, so lookups are instant. They’re kept up-to-date with an SSE push-based system, so you don't have to worry about stale data.

Since this data is already in memory, why not use it to evaluate all the rules server-side and skip the HTTP request? That's what Prefab does.

Starting with our Ruby SDK, you can bootstrap your page with feature flags and config values. There are two flavors to choose from.

Bootstrap: Faster but just as powerful​

Prefab.bootstrap_javascript(context) can be used in conjunction with our JavaScript Client or React Client. It bootstraps the page with the evaluated rules for the current context but still allows you to use the built-in goodness of those clients (like updating the values when contexts change, polling, telemetry, etc). You don't need an HTTP request unless something changes about the evaluation context.

Stub: Faster and dependency-free​

When I took a step back to behold my beloved zero HTTP-request client-side Feature Flags, I realized I still wanted more. What's better than zero HTTP requests? Zero JavaScript dependencies.

Prefab.generate_javascript_stub(context, callback = nil) will give you feature flags and config values for your current context. You can provide an optional callback to record experiment exposures or other metrics. You'll get a global prefab object for get and isEnabled checks. There's no dependency on the JavaScript or React clients.

The choice is yours​

You can use either in your ERB (or other server-side templates) to render the content server-side. No FOOC. No spinners. Just fast, interactive content.

Give it a try today! Your users will thank you.

Here's a before and after to help visualize the difference:

The user has to wait for the HTTP request to complete before the final content is shown. We either show the original content or a spinner while we wait for the response. This is a performance hit and can lead to a FOOC.

🚀 Coming soon to more SDKs​

We're starting with Ruby but working to add this functionality to all of our server-side SDKs. We want to make it as easy as possible for you to get the benefits of A/B testing, feature flags, and live config without the performance hit.

Let me know if you’d like to help us test this functionality in your favorite language. I'd love to hear from you.

But what if I don't have a server?​

Well, it isn't 0ms, but the good news is that we've spent a lot of time and effort making a robust global delivery network to serve this data as fast as possible and as close to your users as possible.

Like what you read? You might want to check out what we're building at Prefab. Feature flags, dynamic config, and dynamic log levels. Free trials and great pricing for all of it.
See our Feature Flags