Availability. The speed guardrail panel is listed from the Pro
plan upward on the pricing page.
Where you see it
On the results page, below the primary and guardrail goals, look for the Performance panel. One row per variant per device with its p75 LCP, the delta against baseline, the Core Web Vitals band, and the number of page loads the number is based on. The panel is quiet when there is no usable data yet. Each row says “Collecting speed data”.Devices
Rows are grouped into Mobile and Desktop only. Tablet and unrecognised devices are counted as mobile. There is no separate tablet row. Splitting matters because mobile and desktop LCP are qualitatively different. A change that costs desktop 50 ms and mobile 800 ms can win overall while quietly harming your mobile experience.What p75 LCP means
- LCP, the moment the largest element in the visitor’s viewport finished rendering. Roughly, “the page looks done”.
- p75, the 75th percentile of the distribution. Three quarters of visitors saw an LCP faster than the p75. This is the standard Core Web Vitals bar.
How the number is collected
The browser’s standardPerformanceObserver LCP entry, with no third
party service. ABTestly keeps the last LCP candidate and finalises it
on the first trusted click or keypress, or when the page is hidden or
unloaded, whichever comes first. Prerendered pages are adjusted by
their activation time. A page that was loaded in the background and
never became visible reports nothing.
That means the reading is finalised later than the exposure, often
much later. The measurement is sent as its own beacon to the same /e
endpoint the exposure used, not attached to the exposure beacon.
When a variant is called slower
The rule is a fixed threshold comparison against the control on the same device. There is no confidence interval, no bootstrap, and no significance test. The panel is a descriptive guardrail, not an inferential one. A row is judged in this order, and stops at the first that applies:
A row that clears all four is called slower when either of these is
true:
- Its p75 is at least 400 ms above control on that device.
- Its Core Web Vitals band is worse than control’s, for example control is good and the variant is needs improvement.
Overlapping experiments
A page load produces one LCP reading, and that reading is credited to every experiment the visitor was bucketed into on that page load. When two experiments run on the same page at the same time, both panels show the same measurements, and neither can tell you which variation caused a difference.Why you might see nothing yet
- The test has not run long enough. The panel needs 100 page loads per variant per device, and enough capture on both arms, before it will show a number.
- Speed data resets on republish. Vitals are scoped to the published config version, so any republish of the experiment starts the speed dataset over. New variation code should be measured on its own readings, not blended with the code it replaced.
What to do with a bad LCP
- Small regression, big conversion win. Judgment call.
- Big regression, small conversion win. Rarely worth it. The conversion win may regress toward the mean, and the slowdown is real for every visitor.
- Any regression on mobile. Take it seriously. Mobile is where LCP matters most.