How Do You Compare Web Performance Across Pages Frame by Frame?
Frame-by-frame comparison means capturing a visual filmstrip of each page's load on a shared timeline, then aligning the frames so you can see which page renders first, which one shows meaningful content sooner, and which one stalls. It works best when you compare pages that serve the same purpose (two product pages, two news articles, your page versus a competitor's) under the same network and device conditions. A single Lighthouse score tells you that a page is slow; a shared-timeline filmstrip shows you where the time goes.
Why a shared timeline beats a single score
A performance score compresses many events into one number. That number can't tell you whether a page was blank for two seconds or whether it painted instantly but then blocked on a font. When you place two or more pages on the same horizontal time axis, differences become visible:
- Start offset — when the first pixel appears relative to navigation start.
- Content progression — how much of the page is usable at 0.5s, 1s, 2s, 3s.
- Stall points — frames that look identical across several hundred milliseconds, which usually mean the main thread is busy or a render-blocking resource is pending.
Lightest is built around exactly this idea: its tagline is "Speed made visible," and its description is "Compare how pages load, frame by frame, on a shared timeline." That framing is the useful mental model — the tool's job is to make the timeline the unit of comparison, not the score.
The key timestamps to read on a filmstrip
You don't need to interpret every frame. Anchor your comparison on four moments, and note the time each page hits them:
| Moment | What it looks like in the filmstrip | What it usually indicates |
|---|---|---|
| First paint | The first non-blank frame | HTML and critical CSS arrived; server/TTFB is done |
| First contentful paint | First text or image appears | Render-blocking CSS/JS is largely resolved |
| Main content visible | The part users came for is on screen | Above-the-fold resources (hero image, headline) loaded |
| Visually complete | Frames stop changing meaningfully | Remaining images, fonts, and below-fold work finished |
If you also have Lighthouse or Core Web Vitals data for the same URLs, map the metrics onto these visual anchors: LCP should correspond roughly to your "main content visible" frame, and CLS shows up as frames where elements jump position between captures. The filmstrip explains why a metric is what it is; the metric tells you whether the number is good.
How to run a comparison
- Pick comparable URLs. Same page type, same rough content weight. Comparing a text article to a video-heavy landing page produces a filmstrip that's interesting but not actionable.
- Fix the conditions. Use the same connection profile and device/emulation for every URL. If the tool lets you choose a preset (mobile, slow 4G, etc.), apply one preset to all pages in the run — otherwise you're comparing networks, not pages.
- Capture all pages on one timeline. This is the core requirement. Separate runs with separate start times can't be aligned reliably.
- Read left to right and mark the four timestamps above for each page. Write them down; the numbers are what you'll act on.
- Identify the first divergence. Find the earliest point where one page falls behind. That gap is your primary target — later gaps often cascade from it.
- Inspect the likely cause. A blank early frame points to server response or render-blocking head resources. A late main-content frame points to a large hero image, a lazy-loaded element that should be eager, or a font swap. A long stall after content appears points to third-party scripts or heavy JS.
- Change one thing, then re-run the same comparison. Same URLs, same conditions, same timeline. If the divergence point moves earlier, the change worked.
What the stalls usually turn out to be
Across most real comparisons, the frames that lag fall into a few recurring buckets:
- Images — an oversized hero image or one served without modern formats delays the "main content visible" frame.
- Fonts — text renders in a fallback, then reflows when the web font arrives; you'll see a visible swap between frames.
- Scripts — a synchronous or late-loading script blocks rendering or freezes the main thread, producing identical consecutive frames.
- Third parties — analytics, chat widgets, and ad scripts often land after content and extend the "visually complete" time without changing what the user sees.
- Server/TTFB — if every page from one site starts late, the problem is upstream of the browser.
The filmstrip won't name the culprit, but it narrows the window: you know which few hundred milliseconds to open DevTools for.
Turning the comparison into a decision
Use the comparison to answer a specific question rather than to collect a score:
- "Is my page slower than a competitor's, and from which moment?" — if the divergence is at first paint, it's a delivery problem; if it's at main content, it's a resource-weight problem.
- "Did my last change help?" — re-run the identical comparison; a moved divergence point is your evidence.
- "Which of these two designs loads better?" — the one that reaches main content visible earlier on the shared timeline wins for perceived speed, even if its final completion time is similar.
If you want the visual comparison itself, Lightest is the entry point referenced here. Pair it with Lighthouse or Core Web Vitals measurement for the numeric side — the filmstrip tells you where to look, and the metrics tell you whether the fix landed.