core(fr): split traceOfTab into timespan/navigation types #12633

patrickhulce · 2021-06-08T22:06:10Z

Summary
This PR is what it looks like to split trace of tab into two instead of going the optional properties route. Personally, I still don't think the amount of churn here is accompanied by a similar increase in clarity, but I do like finally eradicating the "trace of tab" lingering name and labeling the concepts clearly, so I'm ok with this direction if others agree that this is worth the effort :)

There is an inevitable tension between pushing timespan vs. navigation logic into audits compared to shared utilities and the split boundary (e.g. if we decide to split at TraceProcesor but preserve TraceOfTab as an object combining both processedTrace and processedNavigation as optional, we're back in the optional property boat, but individual audits mostly don't have to explicitly handle the gatherMode). I prefer using shared utilities for the handling, but I'm open to being convinced otherwise.

This PR doesn't fix most of the typedef issues in metric internals yet, nor does it include any test changes, and it's still ~500+ lines without any of the functionality in #12595 sooooo reviewers you be the judge if it's worth it 😄

Related Issues/PRs
ref #12595 (comment)
ref #11313

adamraine

I feel positive about these changes. Even if processedTrace and processedNavigation are optional, it's much more clear what trace data I can expect from a navigation vs a timespan.

adamraine · 2021-06-09T19:36:27Z

lighthouse-core/computed/metrics/navigation-metric.js

+      throw new Error(`${this.name} can only be computed on navigations`);
+    }
+
+    return Metric.compute_.call(this, data, context);


I feel like this could be simplified by extending this class from Metric.

yeah I'll replace it with super.compute_ 👍

adamraine · 2021-06-09T19:48:37Z

lighthouse-core/computed/trace-of-tab.js

-// TraceProcessor throws generic errors, but we'd like our special localized and code-specific LHError
-// objects to be thrown instead.
-class LHTraceProcessor extends TraceProcessor {
+class ProcessedTrace {


Is this just the same as processed-trace.js for the draft so you don't have to change every import?

It is. I meant to delete this file. I'd prefer not to have mismatched import names if we're already doing the massive rename split. Just rip the band-aid off at once, ya know? :)

adamraine · 2021-06-09T19:50:50Z

lighthouse-core/gather/gatherers/trace-elements.js

+    const processedTrace = TraceProcessor.processTrace(trace);
+    const {largestContentfulPaintEvt} = TraceProcessor.processNavigation(processedTrace);


Could use computed artifacts here.

yes! woohoo 🎉

adamraine · 2021-06-09T19:53:13Z

lighthouse-core/lib/lh-trace-processor.js

+// TraceProcessor throws generic errors, but we'd like our special localized and code-specific LHError
+// objects to be thrown instead.


I see this is a pre-existing behavior, but what is the purpose for keeping the generic errors?

The goal was to have 0 dependencies on any file outside of tracehouse so we could roll it out separately in a package for puppeteer consumption as well. That was a long time ago and the effort mostly ran out of steam without an interested consumer (see #9519 for the complete saga)

drive by api bikeshed: it'd be nicer if the tracehouse lib didn't concern itself about how other consumers might want to map its errors. for future consideration in this lib or another, I think removing the static create...Error functions and instead in LH-land wrapping the resultant class in a Proxy object that try/catch'd everything and did a mapping would be cleaner. Then the lib would only need to expose Error code numbers in a static property.

patrickhulce · 2021-06-11T01:27:27Z

Shoot, lighthouse-plugin-publisher-ads uses trace-of-tab and is part of our build process.

Hey @warrengm @jburger424 heads up trace-of-tab is going to disappear. I left a compat file in the same location along with a deprecation notice on require, but we'd like to remove it.

Also the data required to compute the metrics is changing (needs GatherContext now, https://github.com/GoogleChrome/lighthouse/pull/12633/checks?check_run_id=2797959749#step:16:299)

lighthouse-core/computed/metrics/navigation-metric.js

lighthouse-core/computed/trace-of-tab--deprecated.js

lighthouse-core/test/computed/processed-trace-test.js

adamraine · 2021-06-11T17:04:23Z

lighthouse-core/audits/screenshot-thumbnails.js

-    if (context.settings.throttlingMethod !== 'simulate') {
-      const devtoolsLog = artifacts.devtoolsLogs[Audit.DEFAULT_PASS];
-      const metricComputationData = {trace, devtoolsLog, settings: context.settings};
-      const tti = Interactive.request(metricComputationData, context);
-      try {
-        minimumTimelineDuration = Math.max((await tti).timing, minimumTimelineDuration);
-      } catch (_) {}
-    }


Why don't we need this anymore?

we could keep it and just fork the behavior in screenshot-thumbnails for timespans, but honestly in practice the past few years I've felt that this tends to devolve the screenshot thumbnails into being 9 copies of the exact same final frame.

I wasn't particularly interested in the extra dance to keep this bit around and viewed it as a slight negative behavior anyway, so I just removed it instead of fixing it. Open to doing the work to support both if folks feel differently!

I don't have an attachment to it, just curious. I'm ok leaving it out.

adamraine · 2021-06-11T17:27:25Z

lighthouse-core/computed/metrics/lantern-metric.js

-    const {trace, devtoolsLog, settings} = data;
+    const {trace, devtoolsLog, gatherContext, settings} = data;
+    if (gatherContext.gatherMode !== 'navigation') {
+      throw new Error(`Lantern metrics can only be computed on navigations`);


Do you think we can get away without this check (and similar one in metric.js)?

We're doing a bunch of work to pass the gather mode in to the metrics, but is it worth it just to avoid some undefined behavior when the metrics are accidentally called during the wrong gather mode during development?

That bing said, you have don't most of the annoying work already so my opinion isn't too strong here.

We certainly could (in fact to get tests to pass, I'll need to have a fallback for gatherContext for the ads plugin anyway).

My thinking here is that this direction was all about explicitness. I shared your concerns about whether the explicitness was worth it. The next PR makes processedNavigation optional in the metric implementation, and while we still have implicit workarounds like #12595 shows, it didn't feel like the spirit of explicitness to rely on those. This signal is also just critically important to integrity of the metrics, so making it a required input helps make that clear. Extra bonus: while the entire interface of trace passing is breaking anyway, it's a good time to plumb one more thing through for validation.

adamraine · 2021-06-11T17:28:36Z

lighthouse-core/computed/metrics/navigation-metric.js

+   * @param {LH.Artifacts.ComputedContext} context
+   * @return {Promise<LH.Artifacts.LanternMetric>}
+   */
+  static computeSimulatedMetric(data, context) { // eslint-disable-line no-unused-vars


Can we get rid of computeSimulatedMetric and computeObservedMetric now that we are extending Metric?

We can, but I thought it was useful to still capture the narrower type of data. All of this inheritance is really in "square is not a rectangle" territory anyway which is why I opted for the wonky Metric._compute.call style.

I'm up for either.

I thought it was useful to still capture the narrower type of data

This is a good enough reason to keep it, although I wish we could enforce this type when the functions are redefined in a child class.

Leaving as is SGTM

Co-authored-by: Adam Raine <[email protected]>

adamraine

Overall LGTM, last few comments.

types/artifacts.d.ts

lighthouse-core/computed/metrics/metric.js

lighthouse-core/lib/tracehouse/trace-processor.js

...mium-webtests/webtests/http/tests/devtools/lighthouse/lighthouse-successful-run-expected.txt

adamraine

LGTM nice job!

patrickhulce requested a review from adamraine June 8, 2021 22:06

google-cla bot added the cla: yes label Jun 8, 2021

devtools-bot assigned adamraine Jun 8, 2021

devtools-bot added the waiting4reviewer label Jun 8, 2021

ahmadeizran approved these changes Jun 9, 2021

View reviewed changes

adamraine reviewed Jun 9, 2021

View reviewed changes

patrickhulce added 2 commits June 10, 2021 11:24

core(fr): split traceOfTab into timespan/navigation types

98e004c

tests

7df7217

patrickhulce force-pushed the fr_trace_processor_split branch from 545e858 to 7df7217 Compare June 10, 2021 19:25

vercel bot deployed to Preview June 10, 2021 19:25 View deployment

add back trace-of-tab deprecated

24b1bd0

vercel bot deployed to Preview June 10, 2021 22:07 View deployment

fix lantern

335260a

vercel bot deployed to Preview June 11, 2021 01:27 View deployment

patrickhulce marked this pull request as ready for review June 11, 2021 01:28

patrickhulce requested a review from a team as a code owner June 11, 2021 01:28

adamraine reviewed Jun 11, 2021

View reviewed changes

Apply suggestions from code review

8ca0a4b

Co-authored-by: Adam Raine <[email protected]>

vercel bot deployed to Preview June 14, 2021 15:24 View deployment

remove weird --deprecated tot version

65a90ca

vercel bot deployed to Preview June 14, 2021 15:50 View deployment

fix integration tests

9c93efd

vercel bot deployed to Preview June 14, 2021 17:09 View deployment

adamraine reviewed Jun 14, 2021

View reviewed changes

fix computed metric duplication

b28f92b

vercel bot deployed to Preview June 14, 2021 20:39 View deployment

sample:json

8182e96

vercel bot deployed to Preview June 14, 2021 20:49 View deployment

adamraine approved these changes Jun 14, 2021

View reviewed changes

patrickhulce merged commit ced666d into master Jun 15, 2021

patrickhulce deleted the fr_trace_processor_split branch June 15, 2021 00:30

brendankenny mentioned this pull request Sep 20, 2021

updates for type changes in lighthouse 8.4 googleads/publisher-ads-lighthouse-plugin#298

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

core(fr): split traceOfTab into timespan/navigation types #12633

core(fr): split traceOfTab into timespan/navigation types #12633

patrickhulce commented Jun 8, 2021

adamraine left a comment

adamraine Jun 9, 2021

patrickhulce Jun 9, 2021

adamraine Jun 9, 2021

patrickhulce Jun 9, 2021

adamraine Jun 9, 2021

patrickhulce Jun 9, 2021

adamraine Jun 9, 2021

patrickhulce Jun 9, 2021

connorjclark Jun 10, 2021

patrickhulce commented Jun 11, 2021 •

edited

Loading

adamraine Jun 11, 2021

patrickhulce Jun 14, 2021

adamraine Jun 14, 2021

adamraine Jun 11, 2021

patrickhulce Jun 14, 2021

adamraine Jun 11, 2021

patrickhulce Jun 14, 2021

adamraine Jun 14, 2021

adamraine left a comment

adamraine left a comment

		const processedTrace = TraceProcessor.processTrace(trace);
		const {largestContentfulPaintEvt} = TraceProcessor.processNavigation(processedTrace);

		// TraceProcessor throws generic errors, but we'd like our special localized and code-specific LHError
		// objects to be thrown instead.

core(fr): split traceOfTab into timespan/navigation types #12633

core(fr): split traceOfTab into timespan/navigation types #12633

Conversation

patrickhulce commented Jun 8, 2021

adamraine left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

patrickhulce commented Jun 11, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

adamraine left a comment

Choose a reason for hiding this comment

adamraine left a comment

Choose a reason for hiding this comment

patrickhulce commented Jun 11, 2021 •

edited

Loading