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(fr): add navigation phase + trace gatherer #12098

Merged
merged 6 commits into from
Feb 22, 2021
Merged

core(fr): add navigation phase + trace gatherer #12098

merged 6 commits into from
Feb 22, 2021

Conversation

patrickhulce
Copy link
Collaborator

Summary
The primary goal of this PR is to add the trace gatherer and support performance metrics in Fraggle Rock navigation mode (as well as pave the way for upgrades to support timespan metrics). That change is pretty small, but this triggered a number of other changes.

  • Add new beforeNavigation/afterNavigation methods to distinguish this new category of "navigation-only" gatherers.
  • Adjust config validation rules to disallow navigation gatherers from depending on snapshot artifacts.
  • Refactor navigation runner to reduce duplication in collection of artifacts of each phase (there are now 5 instead of just 3)
  • Refactor default trace categories list to new gatherer, import from legacy driver.
  • Add more test coverage for these refactored areas.

Primary Point of Discussion

This PR sets the new execution sequence to the following phase order.

  • beforeNavigation
  • beforeTimespan
  • afterTimespan
  • afterNavigation
  • snapshot

The primary question IMO is when exactly beforeNavigation and afterNavigation should take place.

There is an argument for moving afterNavigation to happen after snapshot so it can depend on snapshot artifacts, but that means any timespan style recording would include all of the snapshot gatherer work which seems undesirable. I've kept it before snapshot and if anything truly needs the snapshot dependency we can think of something like afterSnapshot to fill that gap in the future.

Implications for Gatherer Authoring

There are 5 potential phases, and this is where that array of supported modes starts enter the territory that concerned me. Really we only have 3 types of valid gatherers. Timespan, Snapshot, or Navigation. We can enforce that fact in config validation if we like. The gatherer of each type should only truly implement the set of methods that are related to it but all the methods of the supported modes will be invoked.

Example: A timespan gatherer says it works for both timespans and navigations, but it only implements beforeTimespan and afterTimespan, leaving the rest as noops. When run in navigation mode, beforeNavigation and afterNavigation will still be executed.

Related Issues/PRs
ref #11313

@patrickhulce patrickhulce requested a review from a team as a code owner February 17, 2021 17:50
@patrickhulce patrickhulce requested review from adamraine and removed request for a team February 17, 2021 17:50
@google-cla google-cla bot added the cla: yes label Feb 17, 2021
*/
snapshot(passContext) { }
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

moved this just to reflect the order in which they're invoked

@@ -139,43 +137,7 @@ class Driver {
}

static get traceCategories() {
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

this is part of our public API, so didn't remove

Copy link
Collaborator

Choose a reason for hiding this comment

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

should we mark deprecated?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

ya let's do it

@@ -816,15 +778,7 @@ class Driver {
async beginTrace(settings) {
const additionalCategories = (settings && settings.additionalTraceCategories &&
settings.additionalTraceCategories.split(',')) || [];
const traceCategories = this._traceCategories.concat(additionalCategories);

// In Chrome <71, gotta use the chatty 'toplevel' cat instead of our own.
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

with Chrome stable up to 88 this feels pretty safe now :)

class TraceCompat extends FRGatherer {
/** @type {LH.Gatherer.GathererMeta<'Trace'>} */
meta = {
supportedModes: ['navigation'],
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

this is actually a fairly important signal that we shouldn't try to compute all the metrics over an arbitrary timespan

longer term I think this evolves into a Trace and NavigationTrace artifact or something where the latter is guaranteed to have been collected over a navigation

.toThrow(/Dependency.*is invalid/);
});

it('should throw when navigation needs snapshot', () => {
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

complete coverage is already in validation-test but covering some more important common mistakes seemed useful

@@ -100,9 +100,11 @@ declare global {
export interface FRGathererInstance<TDependencies extends DependencyKey = DefaultDependenciesKey> {
name: keyof LH.GathererArtifacts; // temporary COMPAT measure until artifact config support is available
meta: GathererMeta<TDependencies>;
snapshot(context: FRTransitionalContext<TDependencies>): PhaseResult;
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

rearranged to signal the order in which they're invoked

@@ -139,43 +137,7 @@ class Driver {
}

static get traceCategories() {
Copy link
Collaborator

Choose a reason for hiding this comment

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

should we mark deprecated?

lighthouse-core/gather/gatherers/trace.js Show resolved Hide resolved
@@ -139,43 +137,7 @@ class Driver {
}

static get traceCategories() {
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

ya let's do it

lighthouse-core/gather/driver.js Show resolved Hide resolved
@patrickhulce
Copy link
Collaborator Author

I take it there are no strong feelings about the order of phase execution yet. I wouldn't really expect there to be without hands-on experience yet, so let's leave this as a good first start and if we run into any issues while converting the remaining gatherers we can revisit the decision if necessary.

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