How WebDive captures, computes, correlates, and interprets every value in a journey report.
Every result describes only the recorded journey, environment, cache state, viewport, account state, and Chrome version. “Unused” means unobserved during this capture—not safe to delete everywhere.
Start attaches chrome.debugger to the inspected tab and enables the Network, Debugger, Profiler, DOM, CSS, Page, Emulation, and Tracing domains. WebDive then records network lifecycle events, script and stylesheet metadata, precise coverage, and selected performance trace categories. Stop finalizes Tracing, snapshots coverage, reads source text and available source maps, normalizes URL-based correlations, saves details to IndexedDB, and returns a compact table report.
CPU and network throttling are applied through CDP only for the recording and restored during cleanup. Reloading after a manual Start remains manual because CDP cannot reconstruct requests completed before recording began.
Reload & auto-record completes instrumentation, waits 250 ms for the agents to settle, and reloads through chrome.devtools.inspectedWindow.reload. WebDive stops after the new document fires Page.loadEventFired and no Network-domain event has arrived for 1.5 seconds. It always waits at least 2 seconds and enforces a 60-second maximum for pages with continuous analytics, streaming, or background requests. Reload without cache uses the same algorithm with ignoreCache. The quiet window is a practical heuristic; it does not prove every asynchronous application request has finished.
Union of non-data: requests observed through Network.requestWillBeSent and JS/CSS URLs known through coverage. Redirects are separate request entries. Coverage-known code without a journey-time request is labelled Loaded before recording.
Impact: More requests can increase discovery, connection, scheduling, and server overhead, although pre-existing entries add no journey request and HTTP/2 or HTTP/3 multiplexing changes request cost.
Σ Network.loadingFinished.encodedDataLength. This is Chrome’s encoded byte count for completed journey-time requests. Cache hits and code loaded before recording can legitimately show zero even when the decoded source is large.
Impact: Transfer affects loading time and user data consumption. Compare cold and warm-cache recordings separately; do not interpret a pre-existing resource’s zero as its cold-load cost.
(loadingFinished.timestamp − requestWillBeSent.timestamp) × 1000. It includes the observed request lifetime, not only socket download time.
Impact: High values can reflect queuing, connection setup, server latency, throttling, streaming, or body transfer.
For JS and CSS, UTF-8 byte length of source retrieved from Debugger or CSS. For other resources, sum of Network.dataReceived.dataLength when available.
Impact: Decoded/source size better represents parse and memory exposure; it is not interchangeable with network transfer.
WebDive starts Profiler.startPreciseCoverage. Stable mode requests function-level coverage; Detailed requests block-level coverage and call counts. At Stop, nested V8 ranges are converted into effective used intervals: a positive-count parent is used except where a nested zero-count range overrides it. Intervals are merged, sliced from source text, and measured as UTF-8 bytes.
unused bytes = total source bytes − union(used source ranges)unused % = unused bytes ÷ total source bytes × 100Impact: Unused JS can still consume transfer, decompression, parsing, compilation, and memory. Coverage before instrumentation is absent, and code required by another route or state can appear unused.
WebDive uses CSS.startRuleUsageTracking and CSS.stopRuleUsageTracking. Chrome’s rendering engine reports used rule source ranges; WebDive does not search DOM class names. Used rule ranges are merged and byte-measured against the stylesheet.
A rule is journey-used when Chrome reports its selector as used. This is not declaration-level cascade analysis: a matched grouped rule may be counted as used even if one declaration is overridden. Rules for other routes, themes, media conditions, pseudo-states, permissions, or error states may appear unused.
Tracing ProfileChunk samples are mapped from profile-node IDs to the top call frame’s URL. Each sample receives its corresponding timeDelta ÷ 1000 milliseconds. Values are sampled self time, not exact wall-clock duration.
file sampled CPU ÷ all URL-attributed sampled CPU × 100. Browser-internal and anonymous frames without a URL are excluded from the denominator.
Number of V8 CPU samples whose top frame maps to the resource URL. More samples imply more observed self-time, but sampling can miss short work.
Count and summed duration of URL-attributed FunctionCall and EvaluateScript complete trace events. Nested events can overlap, so this total must not be added blindly to CPU time.
Count and summed duration of URL-attributed trace events matching V8 parse or compile activity. High values indicate code preparation cost before or during execution.
From the earliest start to latest end of complete events on the detected CrRendererMain thread. If the metadata is absent, WebDive selects the thread with the most RunTask events.
Σ renderer-main RunTask duration ÷ trace duration × 100. Overlap or incomplete trace data can affect interpretation.
Main-renderer RunTask complete events lasting at least 50 ms. Contributor URLs come from enclosed URL-bearing trace events.
For each long task: max(0, duration − 50 ms) ÷ contributor count, added to each contributing URL. This is a WebDive correlation heuristic, not Chrome’s Total Blocking Time implementation and not causal proof.
RunTask events containing a FunctionCall or UpdateLayoutTree child longer than 50 ms. P50/P90/P99 are nearest-rank values from those task durations. “Bottleneck” is the largest average category among JS, style, layout, paint, composite, and hit testing. It does not prove the task came from scrolling.
Heuristic count of repeated FunctionCall → Layout/UpdateLayoutTree alternations inside a task. Duration is the summed layout/style time in those detected alternations. It indicates layout-thrashing risk rather than definitive browser causality.
Count of UpdateLayoutTree events plus average and maximum elementCount exposed by trace arguments.
Average and maximum dirtyObjects from Layout begin data. Dirty ratio is the per-event dirtyObjects ÷ totalObjects × 100, averaged across Layout events.
Summed durations of MajorGC and MinorGC events on the renderer main thread. GC can interrupt application and rendering work, but collection is also normal runtime behavior.
A manual marker records elapsed wall-clock milliseconds from Start and begins a new named phase. The initial phase begins at zero; each phase ends at the next marker or Stop. CDP Network monotonic timestamps and trace microsecond timestamps share Chrome’s monotonic time domain, allowing requests, renderer tasks, URL-attributed JavaScript events, and long tasks to be placed within each phase.
Automatic markers come from supported EventDispatch trace events such as click, pointer, keyboard, touch, input, change, submit, and wheel. Each marker summarizes work until the next supported input, capped at one second. This is temporal correlation: a request or task inside that window is relevant evidence but is not proof that the input caused it. Chrome may omit an input type or its URL attribution, so manual phase boundaries are the reliable journey-level mechanism.
The priority score is a transparent ranking heuristic for JavaScript resources, expressed in mixed opportunity points:
score = blocking ms × 4 + sampled CPU ms + V8 ms × 2 + unused JS bytes ÷ 2048High ≥ 500 · Medium ≥ 100 · Low < 100The priority driver is whichever component contributes the most points. Scores help order investigation; they do not predict an exact user-visible improvement. In particular, cached files with zero transfer can still rank highly because source size, compilation, CPU, and memory remain relevant.
| Finding | Trigger | Meaning and likely action |
|---|---|---|
| CPU-heavy | At least 20% of URL-attributed sampled CPU | Inspect hot functions, repeated work, algorithms, and worker suitability. |
| Blocks main thread | Blocking heuristic above zero | Inspect contributing callbacks and split synchronous work into smaller tasks. |
| Mostly unused | At least 50% unused source bytes | Validate across journeys, then split routes, defer optional code, or remove dead dependencies. |
| High V8 compile/parse | At least 50 ms attributed V8 time | Ship less code, split bundles, and defer non-critical modules. |
For scripts declaring sourceMappingURL, WebDive asks Chrome to load the declared map with inspected-page credentials. Standard VLQ mappings associate generated segments with original source paths. Each generated segment extends to the next mapping on that line, and its overlap with generated used ranges is attributed to the mapped original source.
Module “mapped bytes” therefore represent generated bundle characters associated with an original source—not the original file’s byte size. Indexed/sectioned, malformed, missing, access-controlled, or incomplete maps are reported as unavailable. Source maps may contain proprietary source content; WebDive stores details locally and backups must be treated as sensitive.
Completed compact reports and per-file source details are stored in extension-local IndexedDB. Loading history does not contact a server. Delete removes both the report and its locally stored details. Backup export creates JSON containing the report, generated sources, coverage ranges, and source-map attribution; import restores these records.
There is no backend, analytics endpoint, remote code, or extension host permission. WebDive may request only source-map URLs declared by inspected scripts. Uninstalling the extension, clearing its site data, or deleting the Chrome profile removes local history—export important baselines.
External links open only when selected. The methodology page itself is bundled with the extension and works offline.