Runtime Walkthrough
An eight-part narrated series explaining the browser SDK, with written guides organized by runtime stage.
Copy this guide and your current settings as a prompt for your AI agent.
Preview agent promptSee the guide, code and settings included when you copy.
This section is the engineering deep-dive on the Coframe browser SDK
(sdk/sdk-js): how it loads, decides who sees what, renders, reports, and
keeps all of that true when the page never reloads. Each page pairs a narrated
video with the same material written out, so you can watch, read, or search.
The videos and text were produced from the SDK source in July and August 2026;
every function and constant named here can be found in the repository.
For the product-level view (what frames, treatments and sessions are) start with How Coframe Works. This section goes one level down.
01Reading order
Start with Core Concept for frames, visitor identity, and experiment assignment. Then watch this overview and follow the runtime stages below.
- Load and initialize: How Loading Works, Boot and Config, Identity and Consent, and Caching and Updates.
- Select and render: Frames, Audiences and Lanes, Assignment and Bucketing, and Applying Variants.
- Track and navigate: Sessions and Delivery, then Single-Page Apps.
Video episode numbers retain their original recording order. The documentation navigation follows the runtime sequence, so you can also go directly to the stage you need.
02The series
The overview covers the whole pipeline in under three minutes. The seven episodes below follow the runtime reading path; their original video numbers are retained.
| Video episode | Page | What it answers |
|---|---|---|
| 3 | Boot and Config | Every config option and the exact code that reads it, the four waits, and the reveal contract |
| 2 | Identity and Consent | Where the token comes from, how it is persisted, and what consent does and does not gate |
| 4 | Frames, Audiences and Lanes | The filter stack that decides which experiment a visitor can even enter |
| 1 | Assignment and Bucketing | How one hash of one token decides the variant, where it runs, and how the bins are made |
| 7 | Applying Variants | What a variant is, how elements are found, the three modification types, and the named failures |
| 5 | Sessions and Delivery | One pageview, one session, two records, three queues, and why delivery is a beacon |
| 6 | Single-Page Apps | How the SDK notices a navigation that never reloads and re-runs the pipeline |
03The pipeline in one paragraph
One script tag requests cf.js from the edge, which bakes the published
project (frames, experiments, seeds, bins) into the file it serves. Boot
resolves the config, the project and the visitor’s identity, attaches every
listener, and only then modifies the page. Assignment is three hashes of one
token, computed in the browser and reproducible offline. Each pageview writes
exactly two records: an impression (the denominator) and a page-view event.
Variants are lists of modifications applied to elements the SDK must first
find. Tracking runs on three queues delivered by sendBeacon, so a conversion
click that leaves the page still arrives. Single-page apps re-run the whole
thing on every URL change.
# Runtime Walkthrough An eight-part narrated series explaining the browser SDK, with written guides organized by runtime stage. This section is the engineering deep-dive on the Coframe browser SDK (`sdk/sdk-js`): how it loads, decides who sees what, renders, reports, and keeps all of that true when the page never reloads. Each page pairs a narrated video with the same material written out, so you can watch, read, or search. The videos and text were produced from the SDK source in July and August 2026; every function and constant named here can be found in the repository. For the product-level view (what frames, treatments and sessions are) start with [How Coframe Works](../docs/runtime-overview.html). This section goes one level down. ## Reading order Start with [Core Concept](../docs/sdk-internals.html) for frames, visitor identity, and experiment assignment. Then watch this overview and follow the runtime stages below. - Load and initialize: [How Loading Works](../docs/how-loading-works.html), [Boot and Config](../docs/boot-and-config.html), [Identity and Consent](../docs/identity-and-consent.html), and [Caching and Updates](../docs/caching-and-updates.html). - Select and render: [Frames, Audiences and Lanes](../docs/frames-audiences-lanes.html), [Assignment and Bucketing](../docs/bucketing.html), and [Applying Variants](../docs/applying-variants.html). - Track and navigate: [Sessions and Delivery](../docs/sessions-and-delivery.html), then [Single-Page Apps](../docs/single-page-apps.html). Video episode numbers retain their original recording order. The documentation navigation follows the runtime sequence, so you can also go directly to the stage you need. ## The series [Video: Video: Inside the Coframe SDK: load, decide, render, reveal, report, end to end (the companion to How Loading Works) (2m 50s, narrated)](assets/videos/sdk-internals-00-overview.mp4) Watch: 2m 50s — Inside the Coframe SDK: load, decide, render, reveal, report, end to end (the companion to How Loading Works) The overview covers the whole pipeline in under three minutes. The seven episodes below follow the runtime reading path; their original video numbers are retained. Video episode | Page | What it answers | 3 | [Boot and Config](../docs/boot-and-config.html) | Every config option and the exact code that reads it, the four waits, and the reveal contract | 2 | [Identity and Consent](../docs/identity-and-consent.html) | Where the token comes from, how it is persisted, and what consent does and does not gate | 4 | [Frames, Audiences and Lanes](../docs/frames-audiences-lanes.html) | The filter stack that decides which experiment a visitor can even enter | 1 | [Assignment and Bucketing](../docs/bucketing.html) | How one hash of one token decides the variant, where it runs, and how the bins are made | 7 | [Applying Variants](../docs/applying-variants.html) | What a variant is, how elements are found, the three modification types, and the named failures | 5 | [Sessions and Delivery](../docs/sessions-and-delivery.html) | One pageview, one session, two records, three queues, and why delivery is a beacon | 6 | [Single-Page Apps](../docs/single-page-apps.html) | How the SDK notices a navigation that never reloads and re-runs the pipeline | ## The pipeline in one paragraph One script tag requests `cf.js` from the edge, which bakes the published project (frames, experiments, seeds, bins) into the file it serves. Boot resolves the config, the project and the visitor’s identity, attaches every listener, and only then modifies the page. Assignment is three hashes of one token, computed in the browser and reproducible offline. Each pageview writes exactly two records: an impression (the denominator) and a page-view event. Variants are lists of modifications applied to elements the SDK must first find. Tracking runs on three queues delivered by `sendBeacon`, so a conversion click that leaves the page still arrives. Single-page apps re-run the whole thing on every URL change.