core(lantern): create network graph from trace (experimental) #16026

connorjclark · 2024-05-30T20:12:50Z

This PR does not change the default behavior of Lighthouse.

The most interesting part of this PR is createGraphFromTrace - given a trace (and TraceEngine result), produces the network records from the trace. Also handles making the CPU nodes too and returns the graph.

In Lighthouse, CDP is still used for the network portion of the graph, except in the presence of INTERNAL_LANTERN_USE_TRACE=1 env variable. This includes the lantern smoke tests. The CI scripts have been modified minimally to run both variants. When we switch to using the trace totally, this internal control should be removed.

Note that the unit tests in core/test/lib/lantern only use the trace to build the graph - INTERNAL_LANTERN_USE_TRACE is only for Lighthouse tests.

The only change in these Lantern unit test results is core/test/lib/lantern/metrics/lantern-largest-contentful-paint-test.js - a minor difference in the results due to missing requests in the trace for pre-flight CORs, which doesn't actually impact the simulation except for having one less sample when estimating the RTT/throughput. Adding these requests to the trace is non-trivial and this change in results does not yet warrant further work.

ref #15841

paulirish · 2024-06-01T00:18:56Z

core/lib/lantern/page-dependency-graph.js

-  static async createGraphFromTrace(mainThreadEvents, trace, traceEngineResult, URL) {
-    // TODO: trace engine should handle this.
+  static _findServiceWorkerThreads(trace) {
+    // TODO: trace engine should provide a map of service workers, like it does for workers.


it's possible that map already includes (same-process) serviceworkers… do you know it doesn't?
regardless having pid matching for it too seems like a requirement.

good catch, by looking at core/test/fixtures/traces/amp-m86.trace.json I see that service worker threads also get the same events a worker thread does for purposes of WorkersHandler

I modified this method to account for all workers, so we build our own comprehensive pid/tid worker map.

paulirish · 2024-06-01T00:22:32Z

core/audits/byte-efficiency/render-blocking-resources.js

@@ -53,7 +53,7 @@ function getNodesAndTimingByRequestId(nodeTimings) {
  for (const [node, nodeTiming] of nodeTimings) {
    if (node.type !== 'network') continue;

-    requestIdToNode.set(node.record.requestId, {node, nodeTiming});
+    requestIdToNode.set(node.request.requestId, {node, nodeTiming});


yay! i so appreciate this rename. :) thanks

connorjclark · 2024-06-01T03:43:25Z

so far the test skips from what I've checked seem to be

lacking feature parity in createTestTrace
bug in redirect stuff in createGraphFromTrace
could be other real bugs

connorjclark · 2024-06-03T19:05:44Z

core/lib/lantern/page-dependency-graph.js

+        const redirectedRequest = structuredClone(request);
+        if (redirectedRequest.timing) {
+          // TODO: These are surely wrong for when there is more than one redirect. Would be
+          // simpler if each redirect remembered it's `timing` object in this `redirects` array.


Just realized that our network requests don't even have timing when a request is to be redirected. Only gets set onResponse, which we don't get for redirected requests. This code was written against a test case in redirects-test that did not adhere to that constraint, so this can be disregarded.

I will send a PR that makes sure none of our mock network record tests set a timing on redirected requests, and then update this block of code.

I did overlook how onRedirectResponse calls onResponse, but from what I can tell redirectResponse never has a timing object

welll.... sometimes the timing is present on redirectResponse and sometimes its not. so my claim that "redirects don't have timings" is wrong

I'll leave this TODO as a followup, it's gonna be a tricky change to get these timings to match.

adamraine · 2024-06-03T19:17:28Z

core/test/computed/metrics/largest-contentful-paint-test.js

@@ -52,6 +52,12 @@ Object {

  ['provided', 'simulate'].forEach(throttlingMethod => {
    it(`should fail to compute a value for old trace (${throttlingMethod})`, async () => {
+      // TODO(15841): fails... but instead w/ "No frames found in trace data" (not NO_LCP).
+      // ... handle error when calling code uses lantern? or update expected error? idk


I'm not sure this test is particularly useful anymore. At this point any pre-LCP trace is going to be complete foobar and we shouldn't need to maintain that NO_LCP is always the first error that comes up.

OK - removed

package.json

adamraine · 2024-06-03T19:42:59Z

core/lib/lantern/page-dependency-graph.js

+   * @return {Map<number, number[]>}
+   */
+  static _findWorkerThreads(trace) {
+    // TODO: WorkersHandler in TraceEngine needs to be updated to also include `pid` (only had `tid`).


Is this why we have this function instead of using the TraceEngine directly?

core/lib/lantern/page-dependency-graph.js

adamraine · 2024-06-03T19:47:30Z

core/lib/lantern/page-dependency-graph.js

+    // There are some minor differences in the fields, accounted for here.
+    // Most importantly, there seems to be fewer frames in the trace than the equivalent
+    // events over the CDP. This results in less accuracy in determining the initiator request,
+    // which means less edges in the graph, which mean worse results. Should fix.


Should fix

Meaning we should add more info to the trace events?

yes - this is chromium work

Maybe we should track in b/324059246

initiator (and any relevant js callstack)

i think it is known already that these call stack frames are missing data.

cc @paulirish @adrianaixba

relevant: https://chromium-review.googlesource.com/c/chromium/src/+/5280651/7..11/third_party/blink/renderer/core/inspector/inspector_trace_events.cc#b848

adamraine · 2024-06-03T20:43:31Z

package.json

    "unit-report": "yarn mocha --testMatch report/**/*-test.js",
    "unit-treemap": "yarn mocha --testMatch treemap/**/*-test.js",
    "unit-viewer": "yarn mocha --testMatch viewer/**/*-test.js",
    "unit-flow": "bash flow-report/test/run-flow-report-tests.sh",
-    "unit": "yarn unit-flow && yarn mocha",
+    "unit": "yarn unit-flow && yarn mocha && yarn unit-lantern-trace",


I think this will still run the lantern-trace tests as part of the normal unit test step (in addition to the new CI step you just added). IDK maybe it would be to confusing to separate this so I won't die on this hill.

I don't want to create a new step to really run all the unit tests locally, when it will go away soon.

adamraine · 2024-06-03T20:45:17Z

core/test/create-test-trace.js

+    }
+
+    traceEvents.push({
+      name: 'ResourceReceiveResponse',


What about ResourceReceivedData / ResourceChangePriority? Do we just not need those for this PR?

ResourceReceivedData

never used by trace engine

ResourceChangePriority

should be added, but may not be necessary. dont think we even set priority / changing priority in unit tests

adamraine

Assuming all of the TODOs will be addressed as follow-ups before closing #15841 I think this is a really good first step! Thanks Connor!

connorjclark added 30 commits May 14, 2024 12:57

start on lantern from trace

b4fa823

redirects

a487855

timings

acaa25c

typescript

5bde7b5

update

aca1615

more redirect stuff

6a50568

update

171f7b7

update

bc5ebbf

initiator call stack

318c6de

add a testing tool

037e690

xhr

4e07d3a

types

5a916b2

fix timestamps

9802496

fix test

f955dd6

update

0c27d0b

update

2b7d434

update te

53b713d

test: update interactive test trace

2b19b21

Merge branch 'inter-trace' into lantern-from-trace

0ccc87e

update

300ed78

fix timing

96d2ed7

Merge remote-tracking branch 'origin/main' into lantern-from-trace

9d8969e

passing tests

78e66e5

vary

4166ca8

update

c2927c3

wip

552dda9

move to lantern lib

c0c75d0

wip

862cda9

:wqerge remote-tracking branch 'origin/main' into lantern-from-trace

32944ce

wip

d23acb0

vercel bot deployed to Preview May 31, 2024 18:40 View deployment

fix minor things with createTestTrace, disabled tests

20f72d0

vercel bot deployed to Preview May 31, 2024 19:30 View deployment

network sizes

6edccfe

vercel bot deployed to Preview May 31, 2024 19:36 View deployment

lint

a436e25

vercel bot deployed to Preview May 31, 2024 19:37 View deployment

more tweaks to redirect stuff

6b85157

vercel bot deployed to Preview May 31, 2024 22:02 View deployment

fix type

6126b22

vercel bot deployed to Preview May 31, 2024 22:10 View deployment

fix wrong access for requestId in Lantern node

b0a78af

vercel bot deployed to Preview May 31, 2024 23:41 View deployment

paulirish reviewed Jun 1, 2024

View reviewed changes

account for all workers in our lookup

007a6f7

vercel bot deployed to Preview June 3, 2024 17:49 View deployment

be more explicit

34316d5

vercel bot deployed to Preview June 3, 2024 17:53 View deployment

connorjclark changed the title ~~core(lantern): create graph from trace (experimental)~~ core(lantern): create network graph from trace (experimental) Jun 3, 2024

connorjclark commented Jun 3, 2024

View reviewed changes

adamraine reviewed Jun 3, 2024

View reviewed changes

connorjclark added 2 commits June 3, 2024 13:09

pr

bf7b5d2

Merge remote-tracking branch 'origin/main' into lantern-from-trace

df982f7

vercel bot deployed to Preview June 3, 2024 20:10 View deployment

vercel bot deployed to Preview June 3, 2024 20:11 View deployment

adamraine reviewed Jun 3, 2024

View reviewed changes

adamraine approved these changes Jun 3, 2024

View reviewed changes

connorjclark merged commit cc62c81 into main Jun 3, 2024
27 checks passed

connorjclark deleted the lantern-from-trace branch June 3, 2024 22:43

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

core(lantern): create network graph from trace (experimental) #16026

core(lantern): create network graph from trace (experimental) #16026

connorjclark commented May 30, 2024

paulirish Jun 1, 2024

connorjclark Jun 3, 2024

connorjclark Jun 3, 2024

paulirish Jun 1, 2024

connorjclark commented Jun 1, 2024

connorjclark Jun 3, 2024 •

edited

Loading

connorjclark Jun 3, 2024 •

edited

Loading

connorjclark Jun 3, 2024

adamraine Jun 3, 2024

connorjclark Jun 3, 2024

adamraine Jun 3, 2024

connorjclark Jun 3, 2024

adamraine Jun 3, 2024

connorjclark Jun 3, 2024 •

edited

Loading

adamraine Jun 3, 2024

connorjclark Jun 3, 2024

adamraine Jun 3, 2024

connorjclark Jun 3, 2024

adamraine Jun 3, 2024

connorjclark Jun 3, 2024 •

edited

Loading

adamraine left a comment •

edited

Loading

core(lantern): create network graph from trace (experimental) #16026

core(lantern): create network graph from trace (experimental) #16026

Conversation

connorjclark commented May 30, 2024

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

connorjclark commented Jun 1, 2024

connorjclark Jun 3, 2024 • edited Loading

Choose a reason for hiding this comment

connorjclark Jun 3, 2024 • 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

connorjclark Jun 3, 2024 • 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

connorjclark Jun 3, 2024 • edited Loading

Choose a reason for hiding this comment

adamraine left a comment • edited Loading

Choose a reason for hiding this comment

connorjclark Jun 3, 2024 •

edited

Loading

connorjclark Jun 3, 2024 •

edited

Loading

connorjclark Jun 3, 2024 •

edited

Loading

connorjclark Jun 3, 2024 •

edited

Loading

adamraine left a comment •

edited

Loading