Performance Validation
Validate Coframe's performance impact with a before/after comparison
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.
When you add any third-party script to a page, some performance impact is possible. This page describes how to measure that impact for Coframe: how to disable the SDK for a clean baseline, which metrics to compare, and how to interpret the results.
01The ?cf_disabled comparison
The most direct way to measure Coframe’s contribution to page performance is a controlled before/after comparison. Coframe’s install script includes a built-in disable guard: when the URL contains cf_disabled (for example, as a query parameter ?cf_disabled), the install script exits before loading the SDK. The page loads exactly as it would without Coframe present.
To run the comparison:
- Load the page normally and record your performance metrics.
- Append
?cf_disabledto the same URL and load it again under the same conditions. - Compare the two sets of measurements.
# With Coframe active
https://yoursite.com/landing
# With Coframe disabled
https://yoursite.com/landing?cf_disabledWhen the parameter is present, the install script logs [Coframe] Disabled via URL parameter to the console and returns without loading the SDK or making any network requests to the edge worker. This gives you a clean baseline that reflects your page performance without Coframe.
For a step-by-step walkthrough of this comparison — including how to use the browser Performance panel and where to look for LCP and flicker differences — see Testing and Validation. For testing with specific variant previews enabled, see Preview and Debug.
02What to measure
When comparing the active and disabled states, focus on the Core Web Vitals most sensitive to third-party script behavior:
Largest Contentful Paint (LCP) is the primary metric to watch. It measures when the largest visible content element finishes rendering. Google’s published threshold for a good LCP is under 2.5 seconds; needs improvement is 2.5–4 seconds; poor is above 4 seconds.
Cumulative Layout Shift (CLS) captures unexpected layout movement during and after load. If a variant changes the size or position of a visible element, that change can contribute to CLS. Google’s published threshold for good CLS is under 0.1.
Interaction to Next Paint (INP) measures responsiveness to user input. Google’s published threshold for good INP is under 200 ms.
See Core Web Vitals and LCP Monitoring for how these metrics apply specifically to a Coframe integration.
Tools
- Lighthouse (built into Chrome DevTools): run an audit in a private window to minimize interference from extensions. Run once with Coframe active and once with
?cf_disabledto isolate the SDK’s contribution. - Chrome DevTools Performance panel: provides a frame-level timeline. The Timings row shows LCP, and the Main thread row shows where the SDK’s execution falls relative to paint.
- Field data: lab tools measure a single synthetic page load. Field data from sources like the Chrome User Experience Report (CrUX), PageSpeed Insights, or your own real user monitoring (RUM) captures the distribution across real users and network conditions. For understanding actual user experience, field data takes precedence over lab results.
03Interpreting results
A difference between the active and disabled measurements does not automatically indicate a problem. The comparison quantifies Coframe’s contribution; whether that contribution is acceptable depends on your site’s existing performance baseline and requirements.
A few factors to account for when reading the numbers:
Anti-flicker timeout. Coframe’s anti-flicker snippet hides the page body until either the SDK has applied its changes or the timeoutMs window has elapsed — the default in the generated install script is 1000 ms. If you see a consistent delay near that duration before the page becomes visible in the active state, determine whether the SDK is completing within the timeout or whether the page is consistently waiting for the full timeout to expire before revealing content. See Anti-Flicker for how the reveal timing works and what the timeout failure mode looks like.
Network and run variance. Lab measurements can vary significantly between runs. Run each comparison in equivalent network conditions, use the same connection throttling settings, and average several runs before drawing conclusions.
Cached vs. uncached loads. The first page load fetches the SDK from the edge worker; subsequent loads within the same browser session may benefit from short-lived browser caching. Decide whether to compare cold or warm loads based on which scenario is most representative of your users.
Variant application timing. The edge worker delivers the SDK bundle and baked-in project initialization data in a single HTTP response. If a visible content element is modified by a variant, that change is applied before the anti-flicker reveal, so LCP may be measured against the variant content rather than the original. This is expected behavior, not a regression.
If the ?cf_disabled comparison reveals a meaningful regression, start with the Testing and Validation checklist to rule out configuration issues — such as a missing or mis-placed anti-flicker snippet — before investigating network or rendering bottlenecks.
# Performance Validation Validate Coframe's performance impact with a before/after comparison When you add any third-party script to a page, some performance impact is possible. This page describes how to measure that impact for Coframe: how to disable the SDK for a clean baseline, which metrics to compare, and how to interpret the results. ## The ?cf_disabled comparison The most direct way to measure Coframe’s contribution to page performance is a controlled before/after comparison. Coframe’s install script includes a built-in disable guard: when the URL contains `cf_disabled` (for example, as a query parameter `?cf_disabled`), the install script exits before loading the SDK. The page loads exactly as it would without Coframe present. To run the comparison: - Load the page normally and record your performance metrics. - Append `?cf_disabled` to the same URL and load it again under the same conditions. - Compare the two sets of measurements. TEXT ``` # With Coframe active https://yoursite.com/landing # With Coframe disabled https://yoursite.com/landing?cf_disabled ``` When the parameter is present, the install script logs `[Coframe] Disabled via URL parameter` to the console and returns without loading the SDK or making any network requests to the edge worker. This gives you a clean baseline that reflects your page performance without Coframe. For a step-by-step walkthrough of this comparison — including how to use the browser Performance panel and where to look for LCP and flicker differences — see [Testing and Validation](../docs/testing-and-validation.html). For testing with specific variant previews enabled, see [Preview and Debug](../docs/preview-and-debug.html). ## What to measure When comparing the active and disabled states, focus on the Core Web Vitals most sensitive to third-party script behavior: Largest Contentful Paint (LCP) is the primary metric to watch. It measures when the largest visible content element finishes rendering. Google’s published threshold for a good LCP is under 2.5 seconds; needs improvement is 2.5–4 seconds; poor is above 4 seconds. Cumulative Layout Shift (CLS) captures unexpected layout movement during and after load. If a variant changes the size or position of a visible element, that change can contribute to CLS. Google’s published threshold for good CLS is under 0.1. Interaction to Next Paint (INP) measures responsiveness to user input. Google’s published threshold for good INP is under 200 ms. See [Core Web Vitals](../docs/core-web-vitals.html) and [LCP Monitoring](../docs/lcp-monitoring.html) for how these metrics apply specifically to a Coframe integration. Tools - Lighthouse (built into Chrome DevTools): run an audit in a private window to minimize interference from extensions. Run once with Coframe active and once with `?cf_disabled` to isolate the SDK’s contribution. - Chrome DevTools Performance panel: provides a frame-level timeline. The Timings row shows LCP, and the Main thread row shows where the SDK’s execution falls relative to paint. - Field data: lab tools measure a single synthetic page load. Field data from sources like the Chrome User Experience Report (CrUX), PageSpeed Insights, or your own real user monitoring (RUM) captures the distribution across real users and network conditions. For understanding actual user experience, field data takes precedence over lab results. ## Interpreting results A difference between the active and disabled measurements does not automatically indicate a problem. The comparison quantifies Coframe’s contribution; whether that contribution is acceptable depends on your site’s existing performance baseline and requirements. A few factors to account for when reading the numbers: Anti-flicker timeout. Coframe’s anti-flicker snippet hides the page body until either the SDK has applied its changes or the `timeoutMs` window has elapsed — the default in the generated install script is 1000 ms. If you see a consistent delay near that duration before the page becomes visible in the active state, determine whether the SDK is completing within the timeout or whether the page is consistently waiting for the full timeout to expire before revealing content. See [Anti-Flicker](../docs/anti-flicker.html) for how the reveal timing works and what the timeout failure mode looks like. Network and run variance. Lab measurements can vary significantly between runs. Run each comparison in equivalent network conditions, use the same connection throttling settings, and average several runs before drawing conclusions. Cached vs. uncached loads. The first page load fetches the SDK from the edge worker; subsequent loads within the same browser session may benefit from short-lived browser caching. Decide whether to compare cold or warm loads based on which scenario is most representative of your users. Variant application timing. The edge worker delivers the SDK bundle and baked-in project initialization data in a single HTTP response. If a visible content element is modified by a variant, that change is applied before the anti-flicker reveal, so LCP may be measured against the variant content rather than the original. This is expected behavior, not a regression. If the `?cf_disabled` comparison reveals a meaningful regression, start with the [Testing and Validation](../docs/testing-and-validation.html) checklist to rule out configuration issues — such as a missing or mis-placed anti-flicker snippet — before investigating network or rendering bottlenecks. ## Related - [Testing and Validation](../docs/testing-and-validation.html) — step-by-step measurement walkthrough, including LCP comparison and flicker check - [Anti-Flicker](../docs/anti-flicker.html) — how the timeout and body-reveal work - [LCP Monitoring](../docs/lcp-monitoring.html) — LCP in the context of a Coframe integration - [Core Web Vitals](../docs/core-web-vitals.html) — which metrics matter and how they relate to Coframe - [Preview and Debug](../docs/preview-and-debug.html) — testing specific variants in isolation