search

GoogleChrome / lighthouse

Automated auditing, performance metrics, and best practices for the web.
https://developer.chrome.com/docs/lighthouse/overview/
Apache License 2.0
28.43k stars 9.39k forks source link

FCP is lower than TTFB/server response time in PageSpeed Insights #13296

Open issababble opened 3 years ago

issababble commented 3 years ago

FAQ

URL

https://

What happened?

Hello,

I posted a question about this in the Chrome UX forums and was directed here to file an issue.

Last week, I ran a URL through the Pagespeed Insights tool and it reported a 2500 FCP but a 3500 server response time.

I was asked not to share the URL by the site's owner but I'm sharing a snippet from the report below:

Screen Shot 2021-10-29 at 3 30 28 PM

Just to clarify, when does FCP and LCP start measuring? Does FCP include the TTFB, and does LCP include the TTFB as well as the FCP?

Thanks all.

What did you expect?

I expected the FCP to be inclusive of the server response time but this report indicates the FCP was shorter.

What have you tried?

No response

How were you running Lighthouse?

PageSpeed Insights

Lighthouse Version

Lighthouse 8.4.0

Chrome Version

hrome 92.0.4515.119

Node Version

No response

OS

MacOS

Relevant log output

No response

brendankenny commented 3 years ago

This should never happen but it definitely does. Incidence in two recent HTTP Archive runs is about 0.2%. I haven't been able to repro from any of those URLs yet, so it's at least partially dependent on (possibly transient) test conditions.

connorjclark commented 3 years ago

let's consider asking for a one-time ~0.1% artifacts save in HTTPArchive, would be great if we could just reach out and grab a repro :)

connorjclark commented 2 years ago

After @brendankenny investigated, plan is to detect this weird case and make sure we never present unsound data.

paulirish commented 2 years ago

@brendankenny to add a viewer link with an example LHR of this

adamraine commented 2 years ago

Possibly related, I produced a case where lantern FCP is lower than the observed FCP. It wasn't lower than TTFB or server response time though.

Contents of my latest-run: https://gist.github.com/adamraine/5c0db154123582e248099c2809aae7cb

paulirish commented 2 years ago

We suspect lantern is getting an average SRT per origin, and then using that in the simulation. But a slow HTML doc SRT will not be reused in the simulation, which can lead to this situation.

paulirish commented 2 years ago

Repro wise, i think we need a page with a slow HTML SRT but then plenty of fast SRT requests served from the same origin. https://cuzillion.com/ sadly can't add latency to the HTML payload.

connorjclark commented 1 year ago

Apparently we may keep around artifacts in cloud storage frm http archive runs? Gotta ask Rick.

bregenspan commented 10 months ago

Repro wise, i think we need a page with a slow HTML SRT but then plenty of fast SRT requests served from the same origin. https://cuzillion.com/ sadly can't add latency to the HTML payload.

This is a repro using a base page HTML response delayed by 3 seconds, which then fires off 3 fetch requests to the same origin (with fast SRTs):

https://pagespeed.web.dev/analysis/https-hello-world-super-salad-b94b-ben-regenspan-workers-dev/34glhc15x0?form_factor=desktop

(3,300 ms TTFB but 0.2 s FCP/LCP). I do see this behavior in the wild on a page with slow SRT for the base page and faster subresource requests from the same origin.