🤖 Created by Gemini 4 Argon.

Chromium Runtime & CPU Overhead When Running Lighthouse (https://www.cnn.com/)

Executive Summary

To isolate and quantify the Chromium runtime overhead introduced exclusively when Lighthouse and Perfetto/DevTools tracing are active, we profiled a Release build with symbols of Chromium 157.0.8088.0 (is_debug = false, dcheck_always_on = false, symbol_level = 1) loading https://www.cnn.com/ under three controlled configurations using a custom LD_PRELOAD per-thread CPU-time stack sampling profiler (lhprof.cc, CLOCK_THREAD_CPUTIME_ID at 500 Hz / 2.0 ms per sample across all browser, renderer, GPU, and utility processes):

1. baseline: Standard Chromium navigation to https://www.cnn.com/ via Lighthouse's Driver with no tracing or Lighthouse gatherers active.
2. tracing_only: Identical navigation with only Lighthouse's default Tracing.start categories enabled during navigation and Tracing.end drained afterward.
3. full_lh: Full Lighthouse navigation run (navigation-runner.js) with all 28 default gatherers (prepare, startInstrumentation, startSensitiveInstrumentation, navigation, stopSensitiveInstrumentation, stopInstrumentation, and getArtifact).

1. Methodology & 4-Phase Architecture

All runs used a local Release-with-symbols Chromium build (commit 0a167bc56d56d, is_debug = false, dcheck_always_on = false, symbol_level = 1) with the custom stack profiler liblhprof.so (lhprof.cc) preloaded into the root browser process and inherited across all child processes (renderer, gpu-process, utility:tracing, utility:network, utility:storage).

Each run is partitioned into four synchronized phases via shared memory (control.bin):

flowchart LR
    P1["Phase 1: Setup & Prepare<br/>(Target/Network/Page/DOM/Debugger enable,<br/>startInstrumentation)"] --> P2["Phase 2: Navigation<br/>(Tracing.start + gotoURL<br/>https://www.cnn.com/)"]
    P2 --> P3["Phase 3: Stop & Drain<br/>(Tracing.end + dataCollected,<br/>takePreciseCoverage)"]
    P3 --> P4["Phase 4: Post-Navigation<br/>(28 Gatherers getArtifact:<br/>CSSUsage, Stylesheets, ImageElements,<br/>Accessibility, TraceElements, etc.)"]

2. Process & Thread CPU Breakdown Across Configurations (Release Build)

2.1 CPU Time by Process Type (ms)

2.2 Top Threads by Total & Direct-Instrumentation CPU Time

3. Direct Instrumentation CPU Attribution by Subsystem (Release Build)

By classifying every symbolized stack frame against Chromium's tracing, Perfetto, and DevTools Inspector subsystems (analyze_profile.py), 7,208 ms (37.6% of total Chromium CPU) in full_lh occurs directly inside tracing/DevTools C++ stack frames:

(Note: In baseline, the 514 ms in Phase 1 is prepareTargetForNavigationMode evaluating user-agent/emulation setup via Runtime.evaluate, and the remaining 486 ms in Phase 2 is baseline Network.enable, Page.enable, and Debugger.enable probes used by Lighthouse's Driver to monitor page load.)

4. Deep-Dive Ranked C++ Hotspots (Release Build)

Hotspot #1: Trace Export, Redundant JSON -> CBOR -> JSON Conversion, and Byte-by-Byte WebSocket Framing (1,852 ms Trace Export + 542 ms CBOR->JSON & WebSocket Copy in Phase 3)

When NavigationRunner finishes Phase 2 navigation and calls Trace.stopSensitiveInstrumentation (Tracing.end), Chromium spends 3.51 seconds of wall-clock time and 2.39 seconds of CPU time across three threads (utility:tracing::chrome, browser::chrome, and browser::Chrome_DevTools) just to export and deliver the 80,749-event trace to Lighthouse:

sequenceDiagram
    participant U as utility:tracing::chrome<br/>(908 ms CPU)
    participant B as browser::chrome (CrBrowserMain)<br/>(1,270 ms CPU)
    participant D as browser::Chrome_DevTools<br/>(196 ms CPU)
    participant L as Lighthouse (Node.js)

    U->>U: TracingServiceImpl::ReadBuffersIntoConsumer (908 ms)<br/>1. ProtoTraceParser / TrackEventEventImporter (164 ms)<br/>2. ExportJson -> JsonExporter::ExportSlices (586 ms)
    U->>B: Mojo IPC: ConsumerHost::OnTraceData (JSON chunks)
    B->>B: TracingHandler::OnTraceDataCollected (948 ms)<br/>1. UpdateTraceDataBuffer scans braces/strings (226 ms)<br/>2. TracingNotification::AppendSerialized:<br/>   ConvertJSONToCBOR parses JSON -> CBOR (790 ms)<br/>3. DevToolsSession::DispatchProtocolMessageToClient:<br/>   ConvertCBORToJSON converts CBOR -> JSON (348 ms)
    B->>D: PostTask to Chrome_DevTools I/O thread
    D->>L: ServerWrapper::SendOverWebSocket<br/>EncodeFrameHybi17 -> base::Extend copies payload<br/>byte-by-byte via std::back_inserter (194 ms)

Call Stacks & Symbolized CPU Breakdown (Phase 3 of full_lh)

1. utility:tracing Process (908 ms CPU in Trace Export):

   • perfetto::tracing_service::TracingServiceImpl::ReadBuffersIntoConsumer (908 ms incl)
   • tracing::ConsumerHost::TracingSession::OnTraceData (836 ms incl)
   • Step 1A — Protobuf Trace Ingestion & Sorting (164 ms incl):
     • perfetto::trace_processor::TraceProcessorStorageImpl::NotifyEndOfFile (164 ms incl) -> TraceSorter::ExtractEventsForced (160 ms incl) -> ProtoTraceParserImpl::ParseTrackEvent (138 ms incl) -> TrackEventEventImporter::Import (128 ms incl).
   • Step 1B — JSON Serialization in utility:tracing (586 ms incl):
     • tracing::ConsumerHost::TracingSession::ExportJson (586 ms incl) -> perfetto::trace_processor::json::ExportJson (586 ms incl) -> JsonExporter::ExportSlices (376 ms incl) -> TraceFormatWriter::DoWriteEvent (244 ms incl) -> JsonSerializer::AppendEscapedString (130 ms incl, 122 ms self).

2. browser::chrome (CrBrowserMain, 948 ms in OnTraceDataCollected + 322 ms in DispatchProtocolMessageToClient):

   • Because Lighthouse's Trace gatherer calls Tracing.start without transferMode: 'ReturnAsStream', Chromium uses DevToolsTraceEndpointProxy to emit Tracing.dataCollected protocol notifications.
   • TracingHandler::OnTraceDataCollected (948 ms incl):
     • Calls TracingHandler::UpdateTraceDataBuffer (226 ms incl, 78 ms self), scanning every byte of the JSON string to find balanced {...} object boundaries.
     • Wraps each JSON slice in TracingNotification, whose AppendSerialized calls crdtp::json::ConvertJSONToCBOR (790 ms incl) -> JsonParser::ParseValue (788 ms incl, 250 ms in DecodeString, 82 ms self in ParseToken) to parse the JSON string into binary CBOR!
     • Immediately afterward, DevToolsSession::DispatchProtocolMessageToClient (322 ms incl) calls crdtp::json::ConvertCBORToJSON (348 ms incl) to serialize the CBOR right back into JSON for the WebSocket client.

3. browser::Chrome_DevTools (196 ms CPU in EncodeTextFrame):

   • ServerWrapper::SendOverWebSocket -> net::WebSocket::Send -> net::WebSocketEncoder::EncodeTextFrame (196 ms incl) -> EncodeFrameHybi17 (194 ms incl, 156 ms self) calls base::Extend(frame, message).
   • Because frame is std::vector<char> and message is std::string_view (const char vs char), it hits the generic base::Extend overload at base/containers/extend.h:33 which runs std::ranges::transform(..., std::back_inserter(dst), ...) — copying the WebSocket payload byte-by-byte instead of memcpy.

Hotspot #2: InspectorCSSAgent & InspectorAnimationAgent Overhead During Both Navigation and Post-Navigation (1,658 ms Direct CPU)

2A. Unintended Stylesheet Re-Parsing on CrRendererMain During Navigation (110 ms CPU in Phase 2)

Before navigation starts, TraceElements.startInstrumentation sends Animation.enable. During Phase 2 page load on CNN.com:

• blink::probe::AnimationUpdatedImpl (110 ms incl) invokes InspectorAnimationAgent::AnimationUpdated (108 ms incl).
• AnimationUpdated calls BuildObjectForAnimation (82 ms) -> InspectorAnimationAgent::CreateCSSId (82 ms).
• CreateCSSId calls InspectorCSSAgent::StyleSheetId (60 ms) -> InspectorCSSAgent::BindStyleSheet -> InspectorStyleSheet::ParseText -> CSSParser::ParseSheetForInspector.
• This synchronously re-parses the page's CSS stylesheets on CrRendererMain in the middle of the traced navigation, perturbing main-thread responsiveness even though CSS.enable was never called in Phase 2.

2B. Linear $O(N)$ Rule Scans in startRuleUsageTracking, Quadratic $O(M \times N)$ Rule Mapping in SourceDataForRule, & Triple CSS.enable / CSS.disable Thrashing in Phase 4 (1,650 ms CPU)

In Phase 4, blink::protocol::CSS::DomainDispatcherImpl::Dispatch consumes 1,650 ms of CPU time on CrRendererMain:

Three compounding issues make Phase 4 CSS gathering so expensive:

1. Linear $O(N)$ CSSOM scans during startRuleUsageTracking (666 ms CPU): When StyleRuleUsageTracker is active during the forced full-document style recalculation, ElementRuleCollector::SortAndTransferMatchedRules calls FindStyleSheet (616 ms incl) -> FindStyleRule<CSSStyleSheet> (604 ms incl) and FindStyleRule<CSSRuleList> (402 ms incl, 128 ms self), linearly iterating through every CSSOM rule in every stylesheet (LiveCSSRuleList::length, CSSStyleSheet::item) to locate the parent CSSStyleSheet of each matched StyleRule.
2. Quadratic $O(M \times N)$ CSSOM traversal inside InspectorStyleSheet::SourceDataForRule (446 ms CPU):
   • For every used CSS rule in takeCoverageDelta and every matched rule in getMatchedStylesForNode, SourceDataForRule(rule) calls RemapSourceDataToCSSOMIfNecessary() (588 ms total) and cssom_flat_rules_.Find(rule).
   • RemapSourceDataToCSSOMIfNecessary() unconditionally creates a fresh CSSRuleVector and walks the entire stylesheet's CSSOM tree via CollectFlatRules(page_style_sheet_.Get(), &cssom_rules) on every single rule lookup, spending 300 ms self time in LiveCSSRuleList<CSSStyleRule>::length(), 42 ms self time in LiveCSSRuleList<CSSGroupingRule>::length(), and 116 ms (96 ms self) in CSSStyleSheet::item.
3. Repeated CSS.disable resets: CSSUsage, Stylesheets, and ImageElements each call CSS.enable followed by CSS.disable. InspectorCSSAgent::disable calls Reset(), destroying all InspectorStyleSheet objects so the next gatherer must re-parse every stylesheet on the page (BindStyleSheet -> ParseText: 198 ms) and re-run MapSourceDataToCSSOM (318 ms).

Hotspot #3: Post-Navigation Gatherers (Runtime.evaluate, Network.getResponseBody, DOM, Accessibility, BFCacheFailures) in Phase 4

During Phase 4 (getArtifact), full_lh spends 6,394 ms of CPU time (10.75 s wall time). Outside of InspectorCSSAgent (1,548 ms in Phase 4, covered in Hotspot #2), the remaining Phase 4 CPU time is driven by:

1. Injected DOM & Layout Inspection Scripts via Runtime.evaluate / Runtime.callFunctionOn (1,316 ms direct CDP in Phase 4 + Induced Blink Style/Layout):
   • V8RuntimeAgentImpl::evaluate (1,198 ms total: 512 ms in Phase 1 setup + 686 ms in Phase 4) and V8RuntimeAgentImpl::callFunctionOn (58 ms in Phase 4) execute Lighthouse's pageFunctions.getElementsInDocument, getComputedStyle, and getBoundingClientRect across Accessibility, ImageElements, TraceElements, AnchorElements, MetaElements, and LinkElements.
   • Across full_lh, blink::Document::UpdateStyleAndLayoutTreeForThisDocument (2,392 ms total vs 728 ms in baseline, +1,664 ms) and blink::StyleResolver::ResolveStyle (2,096 ms total vs 624 ms in baseline, +1,472 ms) account for a 3.3x increase in Blink style resolution.
2. Network.getResponseBody & InspectorNetworkAgent (220 ms direct CPU):
   • Phase 2 network event recording (DidFinishLoading 56 ms, DidReceiveData 26 ms, and NetworkServiceDevToolsObserver 40 ms): 128 ms CPU.
   • Phase 4 InspectorNetworkAgent::getResponseBody (74 ms incl, called by MainDocumentContent / Scripts): 92 ms CPU.
3. BFCacheFailures Gatherer Navigation in Phase 4:
   • BFCacheFailures.getArtifact (~1.89 s wall time) navigates away to about:blank and back to https://www.cnn.com/ at the end of Phase 4, triggering an additional round of page lifecycle/compositor work when the page is not BFCache-eligible.

Hotspot #4: Perfetto TrackEvent Emission During Navigation (528 ms Direct CPU in Release)

During Phase 2 navigation (412 ms) and Phase 3 flush (94 ms), emitting trace events across all threads accounts for 528 ms of direct CPU time in the Release build:

1. Task & Scheduler Trace Lambdas (126 ms CPU):
   • base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl emits ThreadControllerImpl::RunTask / DoWork trace events on every task dispatch across all threads.
2. V8 & Blink Trace Event Serialization (140 ms CPU):
   • v8::tracing::EscapeAndAppendString (54 ms), v8::internal::Script::TraceScriptRundownSources (26 ms), cc::frame_viewer_instrumentation::ScopedRasterTask (20 ms), and cc::CompositorFrameReporter::ReportCompositorLatencyTraceEvents (18 ms).
3. V8 Debugger & Async Call Stacks (230 ms CPU):
   • Enabled in prepare.js (Debugger.enable + Debugger.setAsyncCallStackDepth({maxDepth: 8})). Costs 196 ms during Phase 2 navigation (primarily v8::internal::Debug::ProcessCompileEvent at 104 ms) and 28 ms in Phase 4.

Hotspot #5: DevTools Trace Screenshots (disabled-by-default-devtools.screenshot, 424 ms Direct CPU + +1,168 ms GPU Process CPU in Phase 2)

Enabling disabled-by-default-devtools.screenshot in Trace._defaultTraceCategories activates continuous frame capture from the GPU compositor into the Browser UI thread during Phase 2 navigation:

1. GPU Process (VizCompositorThread, 64 ms direct DidCopyFrame CPU + +1,168 ms induced GPU compositing/readback in Phase 2):
   • viz::FrameSinkVideoCapturerImpl::DidCopyFrame (64 ms) reads back compositor surfaces and converts pixel formats (ReadI420Planes, I422ToARGBRow_AVX2), driving total gpu-process Phase 2 CPU from 272 ms (baseline) to 1,404 ms (tracing_only) and 1,440 ms (full_lh).
2. Browser Process (CrBrowserMain, 354 ms direct CPU):
   • content::DevToolsVideoConsumer::OnFrameCaptured (354 ms) delivers each captured media::VideoFrame to TracingHandler::OnFrameFromVideoConsumer (350 ms).
   • OnFrameFromVideoConsumer emits a TRACE_EVENT_INSTANT with a DevToolsTraceableScreenshot, which Perfetto serializes synchronously on CrBrowserMain via DevToolsTraceableScreenshot::AppendAsTraceFormat (274 ms) -> gfx::JPEGCodec::Encode (274 ms incl, 118 ms self in encode_mcu_gather) and base::Base64EncodeAppend.

5. Actionable Optimization Recommendations & Validation Results

In Lighthouse (GoogleChrome/lighthouse)

1. Stream Trace Collection via transferMode: 'ReturnAsStream' in Trace — Opened as PR #17407:
   • Passing transferMode: 'ReturnAsStream' to Tracing.start and incrementally parsing chunks via IO.read after Tracing.tracingComplete eliminates TracingHandler::OnTraceDataCollected (948 ms -> 0 ms), UpdateTraceDataBuffer (226 ms -> 0 ms), and the entire ConvertJSONToCBOR trace round-trip (790 ms -> 0 ms).
2. Keep DOM and CSS Domains Enabled Across Phase 4 Gatherers Instead of Toggling CSS.enable / CSS.disable 3 Times — Opened as PR #17408:
   • Keeping DOM and CSS enabled across CSSUsage, Stylesheets, and ImageElements avoids calling InspectorCSSAgent::Reset() three times and reduces RemapSourceDataToCSSOMIfNecessary by 25% (588 ms -> 440 ms).
   • Additionally, remove the redundant window.getComputedStyle(document.body) evaluation in CSSUsage and Stylesheets (as InspectorCSSAgent::startRuleUsageTracking already forces a full UpdateStyleAndLayoutTree()).
3. Avoid Animation.enable During Navigation in TraceElements:
   • Animation.enable is only used to resolve animation names for TraceElements, yet it causes InspectorAnimationAgent::AnimationUpdated to synchronously bind and re-parse CSS stylesheets on CrRendererMain during Phase 2 page load (110 ms Release CPU).

Validated Impact of PR #17407 + PR #17408 on Chromium Release Build

In Chromium (chromium/chromium)

1. Eliminate Linear $O(N)$ FindStyleSheet/FindStyleRule Scans in ElementRuleCollector::SortAndTransferMatchedRules (616 ms Release CPU) and Quadratic $O(M \times N)$ CSSOM Re-Traversal in InspectorStyleSheet::SourceDataForRule (446 ms Release CPU):
   • Cache the StyleRule -> CSSStyleSheet mapping during startRuleUsageTracking instead of scanning every stylesheet's CSSRuleList linearly in FindStyleSheet/FindStyleRule (616 ms CPU).
   • Track a dirty bit or mutation counter on CSSStyleSheet so RemapSourceDataToCSSOMIfNecessary() is a no-op when the CSSOM has not mutated, and replace the linear cssom_flat_rules_.Find(rule) with a hash map lookup (446 ms CPU).
2. Avoid ConvertJSONToCBOR + ConvertCBORToJSON in TracingNotification:
   • TracingHandler::OnTraceDataCollected already holds valid JSON from Perfetto's ExportJson; when the client session uses JSON over WebSocket, pass pre-serialized JSON directly instead of round-tripping through CBOR (~1,138 ms Release CPU across ConvertJSONToCBOR + ConvertCBORToJSON).
3. Fix Byte-by-Byte std::back_inserter in net::WebSocketEncoder::EncodeFrameHybi17:
   • Replace base::Extend(frame, message) (which falls back to std::ranges::transform with std::back_inserter because frame is std::vector<char> and message is std::string_view, i.e., const char) with frame.insert(frame.end(), message.begin(), message.end()) (194 ms Release CPU).
4. Offload Screenshot JPEG + Base64 Encoding From CrBrowserMain in TracingHandler::OnFrameFromVideoConsumer:
   • Move DevToolsVideoConsumer::GetSkBitmapFromFrame and gfx::JPEGCodec::Encode onto a base::ThreadPool worker task before emitting the trace event (354 ms Release CPU removed from the Browser UI thread).