[connorjclark]

Roll @paulirish/trace_engine from 0.0.67 to 0.0.68 (6527f725a4...f892080018).

https://chromium.googlesource.com/devtools/devtools-frontend.git/+log/6527f725a4..f892080018

Highlights for Lighthouse

• Lantern:
  • Build critical-path optimistic graph for image LCP (CL 8715464): Constructs LargestContentfulPaint.getOptimisticGraph from FirstContentfulPaint.getOptimisticGraph plus the LCP image NetworkNode (and its transitive dependencies and script evaluation CPUNodes) when LCP is an image, reducing p90/p95 LCP and LCP load delay overestimation and eliminating false metricSavings.LCP attributions on unrelated pre-LCP requests in NavigationInsights.
  • Reset H2 overflow bytes for sequential requests (CL 8638201): Resets h2OverflowBytesDownloaded when a request is queued after all prior requests on an H2 connection have finished (queuedTime === totalElapsedTime), improving p50 simulation accuracy across FCP, LCP, LCP Load Duration, TTI, and SI on the Lantern golden dataset.
  • Fix multi-navigation URL inference in createGraph (CL 8646212): Infers requestedUrl / mainDocumentUrl from the first and last main-frame Document request chains and creates ProcessedNavigation before building the graph in Processor.#createLanternContext.
  • Strip #hash fragments from trace request URLs (CL 8646989): Strips #hash fragments from request and redirect URLs in LanternComputationData so NetworkAnalyzer and linkInitiators match URLs consistently.
  • Expose queuedTime on Simulation.NodeTiming (CL 8646214): Exposes queuedTime on Simulation.NodeTiming for downstream consumers such as LCPBreakdown.
• Trace Handlers & CPU Profile:
  • Defer to X-ProtocolIsH2 for request protocol in Lightrider (CL 8633258): Sets protocol = 'h2' in NetworkRequestsHandler when isLightrider is set and the X-ProtocolIsH2 response header is present, enabling accurate ModernHTTP and Lantern H2 handling in Lightrider/PSI.
  • Scope InitiatorsHandler IDs by process and execution context (CL 8654418): Keys timer, RequestIdleCallback, WebSocket, and SchedulePostTaskCallback IDs by (eventKind, pid, frameOrWorkerId, id) to prevent cross-frame collisions.
  • Derive LayoutShift cluster.dur from clusterWindow (CL 8653009): Sets cluster.ts and cluster.dur directly from the clipped cluster.clusterWindow.
  • Round CPU profile sample bounds to integer microseconds (CL 8654598): Prevents 1-ULP float overshoot in SamplesHandler.
• Performance:
  • Memoize cache-hit request IDs in BottomUpRootNode (CL 8669460), key FlowsHandler bindings by small-integer timestamp (CL 8654282), and key synthetic events by raw event in a WeakMap (CL 8529493).

git log 6527f725a4...f892080018 -- front_end/models/trace:

Changelog (just front_end/models/trace, mostly relevant to our usage in LH)

commit f89208001880b934796105ff176241aa44c6a779
Author: Connor Clark <cjamcl@chromium.org>
Date:   Tue Nov 3 20:54:59 2026 +0000

    [Lantern] Build critical-path optimistic graph for image LCP
    
    Previously, LargestContentfulPaint.getOptimisticGraph included nearly
    every request and CPU task completed before LCP (only filtering out
    low-priority images), making it nearly identical to getPessimisticGraph.
    
    As a result:
    
    - Unrelated non-blocking requests before LCP (such as modulepreload,
      <script type="module">, and early fetch() calls) inflated optimistic
      LCP estimates and received false metricSavings.LCP attributions in
      insights and byte-efficiency audits.
    - Actual LCP images loaded at Low/VeryLow priority (e.g. loading="lazy")
      were excluded from optimistic LCP simulation.
    
    Update LargestContentfulPaint so that when LCP is an image and its
    corresponding NetworkNode is found in the dependency graph:
    
    - Populate lcpRequestId and lcpImageUrl on ProcessedNavigation from
      LargestImagePaintHandler.
    - Construct getOptimisticGraph as the union of
      FirstContentfulPaint.getOptimisticGraph, the LCP image NetworkNode
      (and its transitive dependencies), and any pre-LCP CPUNodes that
      evaluated an initiating Script dependency of the LCP image.
    - Return simulationResult directly in getEstimateFromSimulation when
      extras.optimistic is true so low-priority LCP images remain in the
      optimistic estimate while keeping pessimistic estimation unchanged.
    
    Lantern dataset accuracy (% error, lower is better): Substantially
    reduces p90/p95 overestimation on LCP, LCP load delay, and TTI (via the
    TTI >= LCP floor), with FCP, SI, TTFB, and pessimisticLCP unchanged:
    
    | Metric         | p50 (% err)     | p90 (% err)     | p95 (% err)     |
    | -------------- | --------------- | --------------- | --------------- |
    | optimisticLCP  | 40.3 -> 42.7%   | 206.6 -> 81.0%  | 385.5 -> 93.9%  |
    | LCP            | 40.1 -> 36.7%   | 230.4 -> 159.2% | 385.5 -> 230.4% |
    | LCPLoadDelay   | 212.0 -> 100.0% | 2437 -> 1425%   | 3506 -> 2320%   |
    | TTI            | 27.8 -> 27.8%   | 66.1 -> 61.7%   | 104.7 -> 89.0%  |
    | All metrics    | 38.5 -> 37.5%   | 156.2 -> 117.0% | 362.2 -> 246.2% |
    
    https://github.com/GoogleChrome/lighthouse/issues/15737
    https://github.com/GoogleChrome/lighthouse/issues/16539
    
    Bug: None
    Change-Id: I8530ce95c2f115f9983fd1238d4258c738ecabcc
    Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/8715464
    Presubmit-Verified: devtools-frontend-scoped@luci-project-accounts.iam.gserviceaccount.com <devtools-frontend-scoped@luci-project-accounts.iam.gserviceaccount.com>
    Reviewed-by: Paul Irish <paulirish@chromium.org>
    Commit-Queue: Connor Clark <cjamcl@chromium.org>

commit 4fe097072f233810b966bf9adb08c524a4cf30aa
Author: Connor Clark <cjamcl@chromium.org>
Date:   Fri Oct 23 22:05:35 2026 +0000

    [Lantern] Fix multi-navigation URL inference in createGraph
    
    Fixes multi-navigation and client-side redirect edge cases when building
    the Lantern dependency graph and navigation context from a trace:
    
    - In LanternComputationData.createGraph (when url is omitted), throw a
      LanternError if requests is empty instead of throwing a TypeError on
      requests[0].url, and infer requestedUrl / mainDocumentUrl from the
      first and last main-frame Document request chains rather than assuming
      requests[0] is the navigation's Document request (which fails with
      mainDocumentRequest not found when an unload beacon or late subresource
      from the previous page fires right after navigationStart).
    - In Processor.#createLanternContext, call createProcessedNavigation
      before filtering events and building the network requests and graph so
      aborted navigations without FCP fail fast with an expected LanternError.
    - In MetricTestUtils.getComputationDataFromFixture, select
      mainFrameNavigations.at(-1) instead of mainFrameNavigations[0].
    
    https://github.com/GoogleChrome/lighthouse/pull/17433
    
    Bug: None
    Test: npm run test -- front_end/models/trace/Processor.test.ts front_end/models/trace/lantern/metrics/FirstContentfulPaint.test.ts
    Change-Id: I68c6a0a191ac5a55e7f6b25f5564894cddcbf02b
    Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/8646212
    Auto-Submit: Connor Clark <cjamcl@chromium.org>
    Commit-Queue: Connor Clark <cjamcl@chromium.org>
    Presubmit-Verified: devtools-frontend-scoped@luci-project-accounts.iam.gserviceaccount.com <devtools-frontend-scoped@luci-project-accounts.iam.gserviceaccount.com>
    Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>

commit a6b0ce84ea54047908ea5455b1ab2eedc1360378
Author: Simon Zünd <szuend@chromium.org>
Date:   Thu Oct 29 12:31:36 2026 +0000

    [test] Assert DevToolsLocale in TraceLoader and add setupLocaleHooks
    
    `TraceLoader.traceEngine` and `executeTraceEngineOnFileContents` parse
    traces with all handlers and insights enabled and cache the parsed
    trace across test files. Insight models localize strings via
    `i18n.DevToolsLocale.DevToolsLocale.instance()`.
    
    Assert that a `DevToolsLocale` instance is initialized when calling
    `TraceLoader` and add `setupLocaleHooks()` (using `beforeEach` rather
    than `before` where needed so the locale hook runs first) to tests that
    were missing it.
    
    Bug: 563186270, 563186272
    Change-Id: I165389ee182d597eb6d943ec2045e13aea6fd0a6
    Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/8676349
    Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
    Commit-Queue: Simon Zünd <szuend@chromium.org>

commit 5e6a54e7ba701774cedcf0915e5af3d986d3b342
Author: Paul Irish <paulirish@chromium.org>
Date:   Sun Oct 25 16:57:52 2026 -0700

    trace: scope InitiatorsHandler IDs by process and execution context
    
    Blink allocates timerId, RequestIdleCallback id, WebSocket identifier,
    and SchedulePostTaskCallback taskId per ExecutionContext (starting at 1
    in each frame or worker), not globally across the trace.
    
    InitiatorsHandler tracked those four event types in separate Maps keyed
    by bare numeric ID. When two frames schedule id=1 concurrently (like
    RequestIdleCallback in web-dev-animation-frames.json.gz), the second
    frame overwrites the first, attributing frame A's callback to frame B's
    install event (and producing negative "Pending for" durations when
    frame A fires before frame B's install).
    
    Collapse those four Maps into a single Map keyed by event kind, pid,
    frame/workerId (falling back to tid), and numeric ID.
    
    Bug: 578485062
    Change-Id: Icac3619022d67e296d226111b2aa12fd29ef0912
    Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/8654418
    Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
    Presubmit-Verified: devtools-frontend-scoped@luci-project-accounts.iam.gserviceaccount.com <devtools-frontend-scoped@luci-project-accounts.iam.gserviceaccount.com>
    Commit-Queue: Paul Irish <paulirish@chromium.org>

commit 5bca92f45dbeecd97d73aa76f69decd749ba636a
Author: Paul Irish <paulirish@chromium.org>
Date:   Tue Oct 27 08:34:02 2026 -0700

    trace: round CPU profile sample bounds to integer microseconds
    
    SamplesHandler converted millisecond sample timestamps and durations
    independently via milliToMicro() without rounding. In IEEE-754 float,
    ts + dur can overshoot an adjacent sample's ts or parent end by 1 ULP,
    and accumulated float selfTimeMs can diverge from dur - childrenDur
    (e.g. selfTime=85.9ms > totalTime=69.5ms in large-profile.cpuprofile.gz
    and overlapping sibling calls in node-fibonacci-website.cpuprofile.gz).
    
    Round open/close sample timestamps to integer microseconds and derive
    dur = endTime - ts and selfTime = dur - childrenDur from those integer
    bounds.
    
    Bug: none
    Change-Id: I2338019a7662dcd9198d4cd66fa3d4b7b682e1b5
    Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/8654598
    Commit-Queue: Paul Irish <paulirish@chromium.org>
    Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>

commit 8e0d50d50e2d7f1f23feb7cec8afed7a0cd6e7ed
Author: Paul Irish <paulirish@chromium.org>
Date:   Sun Oct 25 16:57:26 2026 -0700

    trace: derive LayoutShift cluster.dur from clusterWindow
    
    LayoutShiftsHandler builds each cluster's clipped session window in
    cluster.clusterWindow (capped at MAX_CLUSTER_DURATION,
    MAX_SHIFT_TIME_DELTA, the next navigation, and traceBounds.max), then
    overwrote cluster.dur at the end of finalize() with
    (lastShift.endTime - firstShift.ts) + MAX_SHIFT_TIME_DELTA.
    
    When a cluster closed due to the 5s max session duration, a navigation,
    or trace end, that unconditional +1s pushed cluster.dur past 5s and
    across adjacent clusters (e.g. 5603.9ms in cls-multiple-frames.json.gz,
    forcing clusters onto a second flamechart row on top of the Main
    track).
    
    Set cluster.ts and cluster.dur directly from cluster.clusterWindow.
    
    Bug: none
    Change-Id: I4cbb1fbba9dfa07ff1d39b734b694c57283d8783
    Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/8653009
    Commit-Queue: Paul Irish <paulirish@chromium.org>
    Presubmit-Verified: devtools-frontend-scoped@luci-project-accounts.iam.gserviceaccount.com <devtools-frontend-scoped@luci-project-accounts.iam.gserviceaccount.com>
    Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>

commit a3a5ec1f0b6af332d51f778c156b3707e9f34dc4
Author: Connor Clark <cjamcl@chromium.org>
Date:   Fri Oct 23 21:13:06 2026 +0000

    [Lantern] Strip #hash fragments from trace request URLs
    
    ResourceSendRequest URLs in the trace (request.args.data.url and
    request.args.data.redirects) retain #hash fragments, whereas CDP
    Network.requestWillBeSent, Page.frameNavigated, initiator.url,
    documentURL, and V8 script trace events strip #hash fragments.
    
    NetworkAnalyzer.findResourceForUrl and
    NetworkAnalyzer.findLastDocumentForUrl require request.url not to have a
    fragment, and linkInitiators matches request.url against fragment-free
    initiator.url values. Strip #hash fragments from request and redirect
    URLs in LanternComputationData.
    
    https://github.com/GoogleChrome/lighthouse/pull/17431
    
    Bug: None
    Test: npm run test -- front_end/models/trace/lantern/core/NetworkAnalyzer.test.ts
    Change-Id: I613466b7428b593e737d96fa874ff6ee541e3d4f
    Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/8646989
    Auto-Submit: Connor Clark <cjamcl@chromium.org>
    Presubmit-Verified: devtools-frontend-scoped@luci-project-accounts.iam.gserviceaccount.com <devtools-frontend-scoped@luci-project-accounts.iam.gserviceaccount.com>
    Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
    Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>

commit 747acd30ad0262dc82cf8ac5dcc892a5622f3c21
Author: Jack Franklin <jacktfranklin@google.com>
Date:   Tue Oct 27 11:28:27 2026 +0000

    Performance: Memoize cache-hit request IDs in BottomUpRootNode
    
    Previously, BottomUpRootNode#ungroupedTopNodes() scanned the entire
    trace events array on every tree rebuild (even when transfer size
    calculation was disabled) to index ResourceReceiveResponse cache hits
    before iterating over the active [startTime, endTime] window.
    
    - Memoize the Set of cache-hit requestIds per events array in a
      module-level WeakMap.
    - Look up the cache-hit set lazily inside sumTransferSizeOfInstantEvent
      only when calculateTransferSize is enabled and a ResourceReceivedData
      or zero-length ResourceFinish event is encountered in the window.
    - On a 100k-event trace across 50 sliding 200ms window updates, this
      reduces BottomUpRootNode rebuild time by 2.3x (5.96ms to 2.58ms per
      update).
    
    Bug: 576311136
    Change-Id: Id476aa52a0cf29a04befafbb700da701588a84ff
    Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/8669460
    Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
    Presubmit-Verified: devtools-frontend-scoped@luci-project-accounts.iam.gserviceaccount.com <devtools-frontend-scoped@luci-project-accounts.iam.gserviceaccount.com>
    Commit-Queue: Paul Irish <paulirish@chromium.org>
    Reviewed-by: Paul Irish <paulirish@chromium.org>

commit e5e60a9df8b83d236f7715ff75c5bf087fda8f00
Author: Jack Franklin <jacktfranklin@google.com>
Date:   Mon Oct 26 13:46:15 2026 +0000

    Trace: Key FlowsHandler bindings by a small-integer timestamp key
    
    FlowsHandler#finalize looks up every non-flow event in a Map of flow
    bindings keyed by the event's timestamp. Trace timestamps are
    microseconds and too large to be V8 small integers, so each lookup
    hashed a heap number. Each bound timestamp also created three nested
    Maps (pid, tid, category).
    
    Instead, key the bindings by the low 30 bits of the timestamp, which is
    always a small integer, and tell bindings that share a key apart by
    comparing the full (ts, pid, tid, category) tuple in findBinding().
    Also stop allocating an unused Map for every flow start.
    
    Parsed output is identical across 140 trace fixtures. Flows finalize,
    median of 5 runs, build order alternated:
    - 1.05M-event trace (4+4 processes): 364 -> 228 ms (-37%).
    - 10 repo fixtures (2+2 processes): -13% to -37%. Largest:
      non-composited-animation-shift 489 -> 320 ms, loading-dt1
      506 -> 334 ms.
    
    Bug: 569885392
    Change-Id: I840d690db4807ba69738855ef772779b334d0b61
    Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/8654282
    Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
    Reviewed-by: Paul Irish <paulirish@chromium.org>
    Presubmit-Verified: devtools-frontend-scoped@luci-project-accounts.iam.gserviceaccount.com <devtools-frontend-scoped@luci-project-accounts.iam.gserviceaccount.com>
    Commit-Queue: Paul Irish <paulirish@chromium.org>

commit 2b86c5871e6750b507df67bf565df53b9d83ef4c
Author: Jack Franklin <jacktfranklin@google.com>
Date:   Fri Oct 16 16:48:18 2026 +0000

    Trace: Key synthetic events by raw event instead of raw index
    
    SyntheticEventsManager stored synthetic events in an array indexed by
    the raw event's position in the trace. To find that position, the
    first registration built a Map of every raw event to its index, which
    replaced a per-registration indexOf() in 262ef5fed0.
    
    The index is only needed when loading a serialized synthetic event
    key, and at that point the raw event is rawTraceEvents[index]. So:
    - Key synthetic events by their raw event in a WeakMap, one entry per
      synthetic event, and resolve the index through the raw events array
      on lookup.
    - Remove the map of every raw event, clearRegistrationIndex() and
      getSyntheticTraces(), whose only caller filled an unused
      ModificationsManager field.
    - Registering an event whose raw source is not in the trace no longer
      throws inside the manager; the static registerSyntheticEvent()
      already swallowed that error.
    
    On a 1.05M-event trace this removes ~59 MB of heap held during parsing
    (measured in Node; less in Chrome, which compresses pointers) and the
    ~113 ms spent building the map. On 10 repo fixtures the map took
    3-61 ms. Parsed output is identical across 140 trace fixtures.
    
    Bug: 569885392
    Change-Id: I53e0bb74f48050270a8409d01d4ffac848481056
    Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/8529493
    Reviewed-by: Paul Irish <paulirish@chromium.org>
    Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>

commit 3bc7a3d624c9a46360e118ad47fd0c15b190d0f7
Author: Connor Clark <cjamcl@chromium.org>
Date:   Sat Oct 24 00:24:25 2026 +0000

    [Lantern] Expose queuedTime on Simulation.NodeTiming
    
    LCPBreakdown and other Lantern consumers need queuedTime from
    nodeTimings to know when a network node was queued in the simulation
    (matching ResourceSendRequest semantics) rather than when it acquired a
    connection (startTime).
    
    Bug: none
    Change-Id: I4f583b1bfe083ecdc376818fe221b550df890e4c
    Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/8646214
    Auto-Submit: Connor Clark <cjamcl@chromium.org>
    Presubmit-Verified: devtools-frontend-scoped@luci-project-accounts.iam.gserviceaccount.com <devtools-frontend-scoped@luci-project-accounts.iam.gserviceaccount.com>
    Commit-Queue: Connor Clark <cjamcl@chromium.org>
    Reviewed-by: Paul Irish <paulirish@chromium.org>

commit 0a3a988e6eaabde86016a212fe0da0f1f7bbefd2
Author: Connor Clark <cjamcl@chromium.org>
Date:   Sat Oct 24 01:09:11 2026 +0000

    [Lantern] Reset H2 overflow bytes for sequential requests
    
    Lantern models H2 multiplexing with a single TCPConnection per origin
    and uses h2OverflowBytesDownloaded so requests queued concurrently can
    share leftover congestion-window bytes from the round trip in which the
    previous request completed. However, if queuedTime === totalElapsedTime
    when a request starts, the request was only queued after all prior
    requests on that connection had already finished, so it could not have
    shared the previous request's round trip and must not consume its
    h2OverflowBytesDownloaded.
    
    On the Lighthouse Lantern golden traces dataset, this improves p50 error
    across all simulated metrics:
    
    - FCP p50 error: 39.1% -> 35.9% (-3.1%)
    - LCP p50 error: 40.1% -> 37.1% (-3.0%)
    - LCP Load Duration p50 error: 49.9% -> 45.0% (-4.9%)
    - TTI p50 error: 27.8% -> 26.6% (-1.2%)
    - SI p50 error: 37.8% -> 37.1% (-0.7%)
    - Overall p50 error: 36.5% -> 35.8% (-0.7%), Good buckets +6, Bad buckets -7
    
    Bug: 570004155
    Change-Id: Ib598c9a6d54869fb2c4430b1b03ce059d691fb51
    Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/8638201
    Commit-Queue: Paul Irish <paulirish@chromium.org>
    Reviewed-by: Paul Irish <paulirish@chromium.org>
    Auto-Submit: Connor Clark <cjamcl@chromium.org>
    Presubmit-Verified: devtools-frontend-scoped@luci-project-accounts.iam.gserviceaccount.com <devtools-frontend-scoped@luci-project-accounts.iam.gserviceaccount.com>

commit 38d2de628c738c98f17ccdf25a1caf35b1946fff
Author: Connor Clark <cjamcl@chromium.org>
Date:   Thu Oct 22 22:40:17 2026 +0000

    [trace] Defer to X-ProtocolIsH2 for request protocol in Lightrider
    
    In Lightrider, responses are provided by the WRS fetcher rather than a
    direct network socket, so ResourceReceiveResponse trace events always
    report protocol as 'http/1.1' and pass 'X-ProtocolIsH2' in the response
    headers when HTTP/2 was used.
    
    Check for 'X-ProtocolIsH2' in NetworkRequestsHandler when isLightrider
    is set so ModernHTTP and Lantern see the accurate protocol.
    
    https://github.com/GoogleChrome/lighthouse/issues/7326
    
    Bug: b/157076979
    Change-Id: I897aeb753b69a67dcc1b46629c90f33320adee77
    Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/8633258
    Auto-Submit: Connor Clark <cjamcl@chromium.org>
    Commit-Queue: Connor Clark <cjamcl@chromium.org>
    Reviewed-by: Paul Irish <paulirish@chromium.org>