opened
javajawa
username_0
When running a full audit of an essentially static site, I discovered that the Performance Audits fail on a number of tests based on the fact that the captured log is not more than 5 seconds longer than the First Meaningful Paint.

The items that are failing are:
 - First Interactive
 - Consistently Interactive
 - Offscreen Images

You can see a comparison of my manual 3G request on the network tab and the Lighthourse result: ![lighthouse-result](https://user-images.githubusercontent.com/653482/38772847-ded02ec8-402f-11e8-8b26-eb98da1d31e8.png). 

Additionally, it appears that it is impossible to get a First Meaning Paint value below 1,250ms -- I consistently get that result for static pages, regardless of their size or components, and this value is much higher than apparant load time in the network tab, or on a device.

These tests were performed with Google Chrome Version 65.0.3325.181 (Official Build) (64-bit), Lighthouse 2.8.0 on Windows 7
Performance Audits gives nonsensical responses when no JS/Images present.
issue
created
patrickhulce
username_1
Thanks for reporting @username_0! Do you have a public URL where this is reproducible? We've seen a few cases of the 5 seconds issue, but those were some time ago and believed to have been fixed. It'd be great to have a test bed. The minimum FMP value you're seeing is likely a result of the network throttling. The default 3G throttling profile applies ~500+ms of latency to each network request, so for a page that requires 2 resources, the minimum time would be about ~1s.

You can run without network throttling by using Chrome Canary or the CLI with `--disable-network-throttling`
comment
created
javajawa
username_0
The page that exact test comes from is [1], and is consistently reproducible. 

Confusingly, two other pages on the same server pass. The first [2] is smaller, with no external resources at all; the second [3] has a very similar request profile, but more content.

My concern with the 1250 number is that it's both too round, and doesn't seem to match the capture timeline above it -- although, reviewing the underlying code, there is a delayed CSS load which would trigger a reflow, so maybe the actual issue is that it's not considering the pre-CSS state to be a meaningful paint?

1. https://static.harcourtprogramming.co.uk/template-2018.html
2. https://static.harcourtprogramming.co.uk/big-data.html
3. https://blog.harcourtprogramming.co.uk
comment
created
javajawa
username_0
Oh, I should note that the "big data" one ([2] in my last) does show a meaningful paint value less than 1250, so at least I am now convinced that is possible.
comment
created
patrickhulce
username_1
Thanks for the additional data!

I can assure you it definitely is possible to get less than 1250 :) but to explain what's going on here, your suspicion is correct. The extra forced layout when the CSS loads is being identified as the first meaningful paint even though it's clear from the screenshots that most people would label the first paint as the "first meaningful" one.

Lighthouse doesn't expect this sort of behavior from FMP either, which is why you see the other failures :) this should be fixed in v3 when we move to use FCP as the starting point for TTI.
comment