PSI sometimes stalls for a full second to show content, even without app JS or web fonts

Mobile PSI sometimes records about a one-second delay before content appears on a landing page I'm working on. I haven't been able to reliably reproduce the same stall locally, so I'm looking for help understanding what the browser is waiting for.

I've stripped the page down in two different ways and captured the delay in both:

- **CSS removed, images kept:** [test page](https://nipponcurryl299---f97f09ef.preview-web.ordersave.com/dev-render-cut?__apollo_render_trace=2&cut=no-css) · [PSI report](https://pagespeed.web.dev/analysis/https-nipponcurryl299---f97f09ef-preview-web-ordersave-com-dev-render-cut/eegyngf6x6?form_factor=mobile). The browser records **1,040 ms** between its paint timestamp and presentation.
- **Images removed, CSS kept:** [test page](https://nipponcurryl299---f97f09ef.preview-web.ordersave.com/dev-render-cut?__apollo_render_trace=2&cut=no-images) · [PSI report](https://pagespeed.web.dev/analysis/https-nipponcurryl299---f97f09ef-preview-web-ordersave-com-dev-render-cut/zw1oegmn0f?form_factor=mobile). The same gap is **955 ms**. This version makes no successful image requests; inline SVG remains.

Both versions have the application scripts and downloaded web fonts removed. They still include a small timing probe. The first also keeps the image preloads and a logo decoder; the second removes those. CSS and images haven't both been removed in either of these failing examples.

The first report shows the problem most clearly:

| Browser event | Time after navigation |
| --- | ---: |
| FCP `paintTime` | 240 ms |
| Animation-frame callback requested | 299 ms |
| Callback runs | 1,272 ms |
| FCP presentation | 1,280 ms |

A timer requested alongside that animation frame ran after just **1.7 ms**. That doesn't show what the main thread did for the rest of the wait, but it gives us another timing signal to investigate.

These values come from the browser's own timestamps, saved under `apollo.render.v2.*` in the report's User Timing audit. The simulated headline FCP is a separate number: 1,682 ms in this run. I'm aware of the reporting mismatch in #16769. Also, `paintTime` doesn't mean rasterization has finished, so I don't yet know which part of rendering is responsible.

To try it, run either test page through PSI and inspect Mobile. It is intermittent: repeated runs can be fast, and I don't have a reliable trigger yet. The linked reports preserve two slow cases.

**Could someone on the PSI team retrieve the full Chrome trace for either report?** We'd like to see what held up the first presentation and the animation-frame callback during that second. The public reports have timings and screenshots, but we couldn't find a full trace. I can share the probe and exact page source if useful.

Both reports were captured on **September 8, 2026**, with **Lighthouse 13.4.1**, **Linux HeadlessChromium 151.0.7922.71**, and mobile simulated throttling. I don't know PSI's GPU or host configuration. Local Mac and Linux tests haven't reliably reproduced this same stall.

I've also [commented on #17148](https://github.com/GoogleChrome/lighthouse/issues/17148#issuecomment-5592193135), which looks related, but we haven't confirmed a shared cause or established whether the issue is in the page, Chrome, Lighthouse, or PSI's environment.

---

**Repeated tests on the live sites**

I ran PSI 15 times each on two sites that manage [Site 1](https://nipponcurry.com/) and [Site 2](https://spielmanbagels.co/). These are the normal production pages, with application scripts and web fonts enabled. Both use the same Application. I kept the exact homepage URLs and made no code, image-quality, or cache-setting changes.

| Site | Distinct mobile results | Score range | Render-delay range | Delays ≥500 ms |
| --- | ---: | ---: | ---: | ---: |
| Site 1 | 14 | 87–98 | 109–1108 ms | 4 |
| Site 2 | 14 | 88–97 | 41–1057 ms | 2 |

All 30 submissions returned mobile results. 2 returned an already-seen mobile capture; those rows are kept below but excluded from the counts. 4 desktop tests failed with PSI server-capacity errors; their mobile results were valid. Both mobile and desktop jobs reached a terminal result before starting the next test for that site; all reports were retained.

The clearest production examples to investigate are [Site 1 run 2](https://pagespeed.web.dev/analysis/https-nipponcurry-com/z5tdjfbva5?form_factor=mobile) and [Site 2 run 1](https://pagespeed.web.dev/analysis/https-spielmanbagels-co/uquh3uudda?form_factor=mobile). Their render delays were **1,108 ms** and **687 ms**. In each case, the recorded main-thread tasks leave a large part of the delay unexplained: about **803 ms** and **528 ms**, respectively. For comparison, [Site 1 run 3](https://pagespeed.web.dev/analysis/https-nipponcurry-com/4jfb7skx5i?form_factor=mobile) and [Site 2 run 2](https://pagespeed.web.dev/analysis/https-spielmanbagels-co/v9csuwzezm?form_factor=mobile) had delays of **109 ms** and **167 ms** with the same hero-image URLs and reported sizes.

In Site 1 run 2, the hero finished loading at about 425 ms, but observed FCP was at 1,487 ms and observed LCP at 1,533 ms. The filmstrip is still blank at 1,125 ms. [Site 2 run 6](https://pagespeed.web.dev/analysis/https-spielmanbagels-co/oifou55qos?form_factor=mobile) also shows a **1,057 ms** render delay, although more of its gap overlaps recorded work.

In the tables, **Suspected stall** means at least 500 ms of the render delay is not accounted for by the recorded main-thread tasks. I calculated this from the observed `main-thread-tasks` audit and `diagnostics.totalTaskTime`, charging the gap for every omitted small task in the whole capture. That is a conservative way to pick reports to inspect; it does not prove one continuous pause or identify a Chrome/Lighthouse bug. Other high-delay rows may have a different cause. These production pages do not have the native timing probe used in the stripped-down examples above, and PSI runner benchmark values vary between runs.

All rows below are **mobile**, Lighthouse **13.4.1**, Linux HeadlessChromium **151.0.7922.71**, with PSI’s default simulated throttling. Score, FCP and LCP are the headline simulated results; **element render delay is observed**, so it is on a different timing basis. Click a run number to open its report.

**Site 1**

| Run | Score | FCP | LCP | Element render delay | Observation |
| --- | ---: | ---: | ---: | ---: | --- |
| [1](https://pagespeed.web.dev/analysis/https-nipponcurry-com/j92mm2z02r?form_factor=mobile) | 97 | 2.03 s | 2.10 s | **604 ms** | High delay |
| [2](https://pagespeed.web.dev/analysis/https-nipponcurry-com/z5tdjfbva5?form_factor=mobile) | 93 | 1.97 s | 2.93 s | **1108 ms** | **Suspected stall** |
| [3](https://pagespeed.web.dev/analysis/https-nipponcurry-com/4jfb7skx5i?form_factor=mobile) | 98 | 1.97 s | 1.97 s | 109 ms | Shorter delay |
| [4](https://pagespeed.web.dev/analysis/https-nipponcurry-com/ulxgdgthua?form_factor=mobile) | 98 | 1.98 s | 1.98 s | 181 ms | Shorter delay |
| [5](https://pagespeed.web.dev/analysis/https-nipponcurry-com/w9ubp6rus5?form_factor=mobile) | 97 | 1.98 s | 2.10 s | 204 ms | Shorter delay |
| [6](https://pagespeed.web.dev/analysis/https-nipponcurry-com/ucfu1ncyb3?form_factor=mobile) | 87 | 1.99 s | 3.79 s | **974 ms** | **Suspected stall** |
| [7](https://pagespeed.web.dev/analysis/https-nipponcurry-com/l2ok0hgydl?form_factor=mobile) | 97 | 2.01 s | 2.10 s | 201 ms | Shorter delay |
| [8](https://pagespeed.web.dev/analysis/https-nipponcurry-com/pdze4s1iyz?form_factor=mobile) | 97 | 2.01 s | 2.10 s | 201 ms | Repeated result; excluded from counts |
| [9](https://pagespeed.web.dev/analysis/https-nipponcurry-com/zznhv3p9ew?form_factor=mobile) | 98 | 1.98 s | 1.98 s | 130 ms | Shorter delay |
| [10](https://pagespeed.web.dev/analysis/https-nipponcurry-com/fsu2rhln75?form_factor=mobile) | 98 | 1.98 s | 1.98 s | 205 ms | Shorter delay |
| [11](https://pagespeed.web.dev/analysis/https-nipponcurry-com/3gbiqe6wng?form_factor=mobile) | 97 | 2.00 s | 2.10 s | **528 ms** | High delay |
| [12](https://pagespeed.web.dev/analysis/https-nipponcurry-com/k8dwjl35zj?form_factor=mobile) | 97 | 2.00 s | 2.10 s | 121 ms | Shorter delay |
| [13](https://pagespeed.web.dev/analysis/https-nipponcurry-com/8e4umcz9rw?form_factor=mobile) | 97 | 1.99 s | 2.10 s | 325 ms | Shorter delay |
| [14](https://pagespeed.web.dev/analysis/https-nipponcurry-com/byw67jfgrq?form_factor=mobile) | 97 | 1.98 s | 2.10 s | 308 ms | Shorter delay |
| [15](https://pagespeed.web.dev/analysis/https-nipponcurry-com/zz79p6gvsq?form_factor=mobile) | 97 | 1.97 s | 2.10 s | 161 ms | Shorter delay |

**Site 2**

| Run | Score | FCP | LCP | Element render delay | Observation |
| --- | ---: | ---: | ---: | ---: | --- |
| [1](https://pagespeed.web.dev/analysis/https-spielmanbagels-co/uquh3uudda?form_factor=mobile) | 93 | 2.25 s | 2.85 s | **687 ms** | **Suspected stall** |
| [2](https://pagespeed.web.dev/analysis/https-spielmanbagels-co/v9csuwzezm?form_factor=mobile) | 96 | 2.25 s | 2.25 s | 167 ms | Shorter delay |
| [3](https://pagespeed.web.dev/analysis/https-spielmanbagels-co/qqswdwupb6?form_factor=mobile) | 96 | 2.25 s | 2.25 s | 167 ms | Repeated result; excluded from counts |
| [4](https://pagespeed.web.dev/analysis/https-spielmanbagels-co/612zxqiszy?form_factor=mobile) | 88 | 2.25 s | 3.62 s | 44 ms | Shorter delay |
| [5](https://pagespeed.web.dev/analysis/https-spielmanbagels-co/y76sfuuirk?form_factor=mobile) | 96 | 2.28 s | 2.28 s | 151 ms | Shorter delay |
| [6](https://pagespeed.web.dev/analysis/https-spielmanbagels-co/oifou55qos?form_factor=mobile) | 93 | 2.25 s | 2.85 s | **1057 ms** | Suspected stall |
| [7](https://pagespeed.web.dev/analysis/https-spielmanbagels-co/pzs8xyidzq?form_factor=mobile) | 97 | 1.82 s | 2.28 s | 67 ms | Shorter delay |
| [8](https://pagespeed.web.dev/analysis/https-spielmanbagels-co/qcd7gsyxui?form_factor=mobile) | 97 | 1.82 s | 2.25 s | 115 ms | Shorter delay |
| [9](https://pagespeed.web.dev/analysis/https-spielmanbagels-co/evei9d6iso?form_factor=mobile) | 96 | 2.25 s | 2.25 s | 342 ms | Shorter delay |
| [10](https://pagespeed.web.dev/analysis/https-spielmanbagels-co/jnlurmrmyn?form_factor=mobile) | 96 | 2.25 s | 2.25 s | 141 ms | Shorter delay |
| [11](https://pagespeed.web.dev/analysis/https-spielmanbagels-co/5rhe8vaxh2?form_factor=mobile) | 96 | 2.28 s | 2.28 s | 88 ms | Shorter delay |
| [12](https://pagespeed.web.dev/analysis/https-spielmanbagels-co/jxskms88uo?form_factor=mobile) | 96 | 2.28 s | 2.28 s | 397 ms | Shorter delay |
| [13](https://pagespeed.web.dev/analysis/https-spielmanbagels-co/iop1bo4nbf?form_factor=mobile) | 96 | 2.25 s | 2.25 s | 153 ms | Shorter delay |
| [14](https://pagespeed.web.dev/analysis/https-spielmanbagels-co/4q9q8f00af?form_factor=mobile) | 97 | 1.83 s | 2.28 s | 41 ms | Shorter delay |
| [15](https://pagespeed.web.dev/analysis/https-spielmanbagels-co/g1ds6wjci4?form_factor=mobile) | 96 | 2.25 s | 2.25 s | 150 ms | Shorter delay |

**Could the PSI team retrieve the full Chrome traces for Site 1 run 2 or Site 2 run 1?** Those look like useful places to check what the browser was waiting for after the resources arrived.

Start with the linked PSI reports for Site 1 run 2 and Site 2 run 1, and the stripped-down test pages. Retrieve or request the full Chrome traces, then compare the paint, animation-frame, timer, and main-thread-task timings. Done means identifying what accounts for the stall or narrowing it to Chrome, Lighthouse, PSI, or the test environment.

Written by the indexing model from the issue text.