How it works

Splitlab is a CDN-based engine. You add one small script to your pages; everything else — experiment config, variant assignment, and reporting — is served from Splitlab's edge and API.

The request flow

1. Load. Your page loads engine.js from cdn.splitlab.io. It's served from the edge and cached, so it's fast and never blocks rendering (async).
2. Resolve. The engine reads your data-project-key, then fetches the active experiment config for the current URL from the Splitlab API (api.splitlab.io).
3. Assign. The visitor is bucketed into a variant (sticky across visits). Client-side assignment keeps the config edge-cacheable and fast.
4. Apply. The engine applies the variant's changes to the DOM — swapping text, styles, or markup on the elements your campaign targets.
5. Reveal. The engine calls window.rmfk() to remove the anti-flicker style, revealing the final page. Conversions and metrics then flow back to your dashboard.

Anti-flicker

Without protection, a visitor could momentarily see the original page before a variant applies — the "flicker" that undermines A/B tests. Splitlab prevents it:

• An inline script hides the body (opacity: 0) the instant the page starts loading.
• The engine reveals the page (window.rmfk()) the moment the variant is applied.
• A failsafe timeout (default 3500ms) and an onerror handler guarantee the page is always revealed — even if the engine is blocked, offline, or hits a CSP — so visitors are never stuck on a blank page.

Where variants come from

You design experiments in the Splitlab dashboard (visual editor + campaign settings). The engine just fetches and applies whatever is currently active for the page — so you can launch, pause, and change experiments without touching your site's code again.

Next

• The install snippet — what to paste, and what each part does
• Quickstart — install and run your first experiment