π° 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:
- Before: Client-side
- After: Server-side w/ Stub
- After: Server-side w/ Bootstrapping
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.
The user doesn't have to wait for an HTTP request to complete. The content is shown immediately. The feature flags and config values are bootstrapped into the page and evaluated server-side.
The user doesn't have to wait for an HTTP request to complete. The content is shown immediately. The feature flags and config values are bootstrapped into the page and evaluated server-side. The developer gets the full power of the JavaScript/React clients, and the client can still update the values as needed if the context changes.