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 · PSI report. The browser records 1,040 ms between its paint timestamp and presentation.
• Images removed, CSS kept: test page · PSI report. 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, 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 and Site 2. 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 and Site 2 run 1. 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 and Site 2 run 2 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 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	97	2.03 s	2.10 s	604 ms	High delay
2	93	1.97 s	2.93 s	1108 ms	Suspected stall
3	98	1.97 s	1.97 s	109 ms	Shorter delay
4	98	1.98 s	1.98 s	181 ms	Shorter delay
5	97	1.98 s	2.10 s	204 ms	Shorter delay
6	87	1.99 s	3.79 s	974 ms	Suspected stall
7	97	2.01 s	2.10 s	201 ms	Shorter delay
8	97	2.01 s	2.10 s	201 ms	Repeated result; excluded from counts
9	98	1.98 s	1.98 s	130 ms	Shorter delay
10	98	1.98 s	1.98 s	205 ms	Shorter delay
11	97	2.00 s	2.10 s	528 ms	High delay
12	97	2.00 s	2.10 s	121 ms	Shorter delay
13	97	1.99 s	2.10 s	325 ms	Shorter delay
14	97	1.98 s	2.10 s	308 ms	Shorter delay
15	97	1.97 s	2.10 s	161 ms	Shorter delay

Site 2

Run	Score	FCP	LCP	Element render delay	Observation
1	93	2.25 s	2.85 s	687 ms	Suspected stall
2	96	2.25 s	2.25 s	167 ms	Shorter delay
3	96	2.25 s	2.25 s	167 ms	Repeated result; excluded from counts
4	88	2.25 s	3.62 s	44 ms	Shorter delay
5	96	2.28 s	2.28 s	151 ms	Shorter delay
6	93	2.25 s	2.85 s	1057 ms	Suspected stall
7	97	1.82 s	2.28 s	67 ms	Shorter delay
8	97	1.82 s	2.25 s	115 ms	Shorter delay
9	96	2.25 s	2.25 s	342 ms	Shorter delay
10	96	2.25 s	2.25 s	141 ms	Shorter delay
11	96	2.28 s	2.28 s	88 ms	Shorter delay
12	96	2.28 s	2.28 s	397 ms	Shorter delay
13	96	2.25 s	2.25 s	153 ms	Shorter delay
14	97	1.83 s	2.28 s	41 ms	Shorter delay
15	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.