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

sort trace by timestamp before calculating FMP #756

Merged
merged 1 commit into from
Oct 7, 2016
Merged

sort trace by timestamp before calculating FMP #756

merged 1 commit into from
Oct 7, 2016

Conversation

brendankenny
Copy link
Member

@brendankenny brendankenny commented Oct 7, 2016

re: #753

This makes sure events in the trace are sorted by timestamp (event.ts) before we start digging into FMP. This probably gives us more -1s in extension reports but makes us more correct in the answers we report. Will have to remain this way until we figure out why trace events are timestamped the way they are or #618 with m54.

Also adds example trace from extension from #753 with weird timing for testing.

});
});

it('scores a -1 when faulty trace data is present', () => {
return Audit.audit({boo: 'ya'}).then(response => {
Copy link
Member Author

Choose a reason for hiding this comment

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

this test was not actually testing faulty trace data after the trace artifact format change :)

Copy link
Member

Choose a reason for hiding this comment

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

Newer tests are more robust. Looking good.

Copy link
Member

Choose a reason for hiding this comment

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

and my earlier comment is caught by the tests you've written. Gotcha.

// navigationStart is currently essential to FMP calculation.
// see: https://github.com/GoogleChrome/lighthouse/issues/753
if (!navigationStart) {
throw new Error('No `navigationStart` event found after `TracingStartedInPage` in trace');
Copy link
Member

Choose a reason for hiding this comment

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

I'm trying to reason what this throw will mean for the reporter output. Talking in person, it looks like it should still result in a -1 debug string.

@addyosmani
Copy link
Member

LGTM

@addyosmani addyosmani merged commit 4539e10 into master Oct 7, 2016
@addyosmani addyosmani deleted the ts branch October 7, 2016 21:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants