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

### FAQ

- [x] Yes, my issue is not about [variability](https://github.com/GoogleChrome/lighthouse/blob/main/docs/variability.md) or [throttling](https://github.com/GoogleChrome/lighthouse/blob/main/docs/throttling.md).
- [x] Yes, my issue is not about a specific accessibility audit (file with [axe-core](https://github.com/dequelabs/axe-core) instead).
- [x] Yes, my issue is not answered by [other FAQs](https://github.com/GoogleChrome/lighthouse#faq).

### 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

```sh
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.
```

No Lighthouse source file or test is named. Start by reproducing the issue in PageSpeed Insights with cache-busted versions of the two Shopify URLs, then compare observedFirstPaint, observedFirstVisualChange, and Lantern inputs in the JSON across held and normal runs. Done means identifying whether the timing discrepancy is in Lighthouse/Lantern or the Lightrider environment and defining a reproducible regression case.

Written by the indexing model from the issue text.