PSI/Lightrider: observedFirstPaint 1.1–2.2 s after the frame is on the filmstrip; reproducible on Shopify storefronts

[Naveed-756]

FAQ

• Yes, my issue is not about variability or throttling.
• Yes, my issue is not about a specific accessibility audit (file with axe-core instead).
• Yes, my issue is not answered by other FAQs.

URL

https://resinrock.com/

What happened?

On PageSpeed Insights (Lightrider), Shopify storefront pages intermittently report observedFirstPaint and observedFirstContentfulPaint 1.1 s or 2.2 s after the HTML has finished, while the screenshot filmstrip already shows the painted page at ~0.25 s (observedFirstVisualChange ≈ 0.25 s). The main thread is idle during the gap. Because Lantern includes every request that completed before the observed FCP, the simulated FCP/LCP of an affected run balloon (FCP 2.1 s → 3.9–4.8 s, LCP 3.1 s → 6.7–8.7 s) and the score drops from 91–95 to 61–68 for the same page.

Reproduction (mobile, pagespeed.web.dev or the PSI API; add a changing ?r= to avoid cached reports)

• https://resinrock.com/pages/speed-repro-a — no Shopify head: observedFirstPaint − document end ≈ 100 ms on every run.
• https://resinrock.com/pages/speed-repro-b — identical page plus Shopify's content_for_header: same ~100 ms on some runs, 1.1–2.2 s on the others (roughly 40 % of runs over ~40 cache-busted runs).

Other Shopify stores show the same pattern (tested: allbirds.com, gymshark.com, fashionnova.com).

What did you expect?

observedFirstPaint / observedFirstContentfulPaint to match the frame that is visible on the screenshot filmstrip (~0.25 s after the document arrives), on every run. Or, if the paint event is legitimately late because of a presentation-side delay on the Lightrider host, Lantern's FCP/LCP graphs should not absorb the unrelated requests that happen to complete during that delay.

Same page, one minute apart, cache-busted, on Google's fleet: score 97 / 77 / 69 / 96 / 94. The only difference between the runs is whether the first frame was presented at ~0.1 s or at 1.1–2.2 s after the HTML ended.

What have you tried?

• Two-page bisect on the same fleet: page A (theme CSS + fonts + content, no Shopify content_for_header) painted 99–223 ms after the HTML ended in 15/15 runs, score 99 every time. Page B (identical plus Shopify's head) was held on ~40 % of runs (6/15, 5/8, 2/5 across batches). The hold is stable at 1.1 s or 2.2 s, never in between.
• Checked the JSON of held runs: observedFirstVisualChange ≈ 250 ms while observedFirstPaint = observedFirstContentfulPaint = 1330–2200 ms; observedDomContentLoaded and observedLoad fall inside the gap; main-thread-tasks shows no task over ~60 ms in the gap; long-tasks is empty; every render-blocking resource finishes by ~300 ms.
• Ruled out page-side causes on the same fleet: blocking the shop.app cart-sync iframe via CSP (still held), blocking every iframe with frame-src 'none' (3/14 held vs 6/15 control, reduced but not removed), painting the first element before any body-level stylesheet (no change), starting all theme scripts only after the first frame (no change).
• Ran the same pages locally with Lighthouse CLI 13.4.1 (headless and headed Chrome 152, Windows) many times: the gap never occurs; first paint tracks the filmstrip.
• Ran other Shopify stores (allbirds.com, gymshark.com, fashionnova.com) on PSI: same bimodal observedFirstPaint.
• Reported to Shopify as well: https://community.shopify.com/t/storefront-head-code-delays-chromes-first-frame-by-1-2-s-on-googles-pagespeed-machines-reproducible-two-page-test/679801

How were you running Lighthouse?

PageSpeed Insights

Lighthouse Version

13.4.1 (PSI). Local comparison runs: CLI 13.4.1.

Chrome Version

PSI reports HeadlessChromium 151.0.7922.71 "with lr". Local comparison runs: Chrome 152 stable, headless and headed.

Node Version

24.14.0 (local CLI comparison runs only)

OS

PSI (Lightrider). Local comparison runs: Windows 11.

Relevant log output

Page B, five cache-busted PSI mobile runs, 10 Sept 2026 (times relative to the end of the HTML response):
run 1  observedFirstPaint +111 ms   score 97
run 2  observedFirstPaint +1149 ms  score 77   (observedFirstVisualChange +250 ms)
run 3  observedFirstPaint +2196 ms  score 69   (observedFirstVisualChange +250 ms)
run 4  observedFirstPaint +119 ms   score 96
run 5  observedFirstPaint +106 ms   score 94

Page A, same batch:
runs 1-5  observedFirstPaint +134 / +223 / +184 / +139 / +99 ms   score 99 x5

Held run example (page B): theme.css done +84 ms, checkout CSS done +298 ms, fonts done +278 ms,
DOMContentLoaded +887 ms, load +986 ms, observedFirstPaint +1333 ms, no main-thread task > 62 ms in the gap.

[Naveed-756]

Correction to the report above: the filmstrip of a held run is blank (white, with only a thin grey line at
the bottom of the viewport) until the paint event fires; the observedFirstVisualChange of ~250 ms is that
grey line, not the page content. So this is not "frame drawn but presented late". The accurate statement
is: on held runs the screen stays blank for 1.1–2.2 s after the HTML has arrived, while every
render-blocking resource has finished by ~0.3 s, the main thread is idle, and DOMContentLoaded and load
fire inside the blank period. The bimodal timing, the A/B page split (0/5 vs 9/27 held) and the fact that
local Chrome never reproduces it are unchanged. Apologies for the imprecision.
Full write-up with the store's numbers and the evidence pack: https://norvahl.com/learn/resin-rock-shopify-speed

[hanford]

Potentially related: #17227.

The corrected description here sounds similar: intermittent blank periods on PSI mobile after render-blocking resources have finished, with little recorded main-thread work explaining the wait. Both reports use Lighthouse 13.4.1 / HeadlessChromium 151.0.7922.71, and local runs haven't reliably reproduced it.

There's also a small text-and-timing-probe reproduction in #17227 using a delayed no-op script or stylesheet. In its slow runs, 50 ms timers keep firing while the first animation frame waits roughly 600 ms.

I wouldn't call these confirmed duplicates yet. Your Shopify head A/B gives a more specific trigger, while #17227 includes both paint-to-presentation and pre-paint waits. Linking them so the Chrome/Viz traces can be compared if the PSI team can retrieve them.