Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

core(metrics): support FCP for all frames with devtools throttling #11874

Merged
merged 17 commits into from
Jan 19, 2021

Conversation

adamraine
Copy link
Member

@adamraine adamraine commented Dec 22, 2020

Follow up to #11701, #11713 and #11760

A lot of test traces are incompatible with these changes because they were minified without FrameCommittedInBrowser events. The FCP from all frames will be set to the main frame FCP in these cases.

Unlike LCP, FCP all frames will not throw when using simulated throttling because that breaks some tests. FCP all frames will fall back to main frame FCP from lantern in this case. This fallback will be removed once support for metrics in lantern is added.

Related to:
#11500
#11311

@google-cla google-cla bot added the cla: yes label Dec 22, 2020
@adamraine adamraine changed the title start core(metrics): support FCP for all frames with devtools throttling Dec 22, 2020
@adamraine adamraine marked this pull request as ready for review December 22, 2020 21:58
@adamraine adamraine requested a review from a team as a code owner December 22, 2020 21:58
@adamraine adamraine requested review from connorjclark and removed request for a team December 22, 2020 21:58
Co-authored-by: Connor Clark <cjamcl@google.com>
Copy link
Collaborator

@patrickhulce patrickhulce left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks @adamraine! you really set yourself up for success with the prior work on frameTreeEvents, nice and easy addition here 👍

types/artifacts.d.ts Outdated Show resolved Hide resolved
Copy link
Collaborator

@patrickhulce patrickhulce left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just the one extra assertion request but LGTM! 👍

lighthouse-core/lib/tracehouse/trace-processor.js Outdated Show resolved Hide resolved
lighthouse-core/lib/tracehouse/trace-processor.js Outdated Show resolved Hide resolved
@@ -85,8 +93,8 @@ Object {
"observedFirstVisualChange": 1105,
"observedFirstVisualChangeTs": 713038128064,
"observedLargestContentfulPaint": 1122,
"observedLargestContentfulPaintAllFrames": undefined,
"observedLargestContentfulPaintAllFramesTs": undefined,
"observedLargestContentfulPaintAllFrames": 1122,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm, why did this one change? I wouldn't have expected movement here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previously, if there were no FrameTreeCommittedInBrowser events, only FCP-AF would fall back to FCP because we needed to avoid a NO_FCP error. LCP-AF didn't need to fall back because a NO_LCP_ALL_FRAMES error didn't brick a bunch of existing tests.

Now that frameTreeEvents falls back to frameEvents, LCP-AF falls back to LCP because it looks at frameTreeEvents.

@@ -46,13 +46,16 @@ describe('Metrics: LCP from all frames', () => {
await expect(resultPromise).rejects.toThrow('NO_LCP_ALL_FRAMES');
});

it('should fail if even if main frame LCP is available', async () => {
it('should use main frame LCP if no other frames', async () => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah I'm guessing this was the LCP change then? I imagine it might make querying a smidge harder than it was before, but this is consistent with FCP behavior now and I like it 👍

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this is the change in #11874 (comment)

@patrickhulce
Copy link
Collaborator

oh and a smoke please 😃

@adamraine
Copy link
Member Author

@patrickhulce Is there a way to check equivalence between two fields in a smoke test? I think the best thing to test would be LCP != LCP-AF and FCP != FCP-AF.

@patrickhulce
Copy link
Collaborator

Is there a way to check equivalence between two fields in a smoke test? I think the best thing to test would be LCP != LCP-AF and FCP != FCP-AF.

Not really. I would set FCP to be very far out (~10s maybe?), FCP-AF to be instant and assert > and < on each for now.

firstContentfulPaintAllFrames: '<1000',
largestContentfulPaint: '>1000',
largestContentfulPaintAllFrames: '<1000',
firstContentfulPaint: '>5000',
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

beautiful 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants