DISCOVER · DEPEND · DELIVER

Critical Request Chain Mapper

Follow the requests that wait on one another. Build a dependency map, expose broken links and compare a proposed loading plan before changing your code.

BASELINE · ONE CONTROLLING CHAIN

SCENARIO · THE BOTTLENECK CAN MOVE

READ THE LOADING STRUCTURE

Dependency map

On a controlling chainOther modeled requestUnresolved dependencyScroll or swipe to explore. Fit map shows the whole diagram.
INSPECT THE REQUEST · TEST AN IDEA

Request inspector

Measured / declared baseline

Every declared dependency must finish before this request starts in the model. Renaming an ID updates its references in both models.

What if…

Request ledger
RequestTypeDurationModeled start → finishSlack to goalWaits for

Preparing example…

A dependency model you can explain

  1. Declare the waits. Import a request list or build the map. Use the browser’s Initiator evidence to verify dependencies; timing order alone does not prove a link.
  2. Follow the chain. Inspect the baseline. Each request starts after its last finishing parent; independent branches run in ideal parallel. Fix missing parents and cycles.
  3. Test a proposal. Change a duration or discovery dependency. A different branch can become the bottleneck. Export your assumptions, implement a feasible change and measure again.
Supported files and limits

Open a JSON array, an object with requests/rows, or a version 2 saved project. CSV needs requestId,url,durationMs,dependsOn; separate parent IDs with |. Optional label, type, proposedMs, proposedParentsJSON and notes are supported. Up to 5,000 requests, 20,000 dependency links across both models and 8 MiB. Large maps display up to 80 requests; selecting a request focuses its neighborhood. The ledger and JSON report cover the complete graph.

This is a conceptual dependency model, not a browser performance trace or Lighthouse audit. It does not infer render-critical requests, crawl URLs, import HAR initiators, predict LCP, or simulate connection limits, discovery delays, bandwidth contention and CPU work. Supplied durations and hard finish-to-start dependencies are your assumptions. Public pages include advertising; see privacy information.

Reference: request chains and network dependencies · inspect browser initiators.

Using Critical Request Chain Mapper

Build an explicit request dependency graph, inspect controlling chains, diagnose missing links and cycles, and compare a proposed loading scenario.

  1. Try the product-page example. Its declared baseline completes in 700 ms; the proposal completes in 560 ms and moves the modeled bottleneck to the availability badge.
  2. Import a JSON request list, CSV or version 2 saved project. Confirm the page URL and choose all requests or a specific completion goal. Dependencies use request IDs and mean hard finish-to-start waits.
  3. Select a map node or use Jump to request. Edit baseline duration/dependencies, then test a proposed duration or parent list. Apply or discard edits before switching. Renaming IDs updates all references.
  4. Review both controlling chains, graph diagnostics and the request ledger. Save/reopen a project, export structured CSV or JSON analysis, or download a printable review brief. Measure the real browser after implementing a feasible change.

Example

The baseline follows document → css → theme → font, totaling 700 ms. Linking the theme directly from HTML and proposing a smaller font changes the font branch to 460 ms, but the document → app → inventory → badge branch still takes 560 ms. The modeled overall difference is 140 ms, not 240 ms.

Questions & answers

Does this predict my actual page-load time or LCP?

No. It computes an ideal dependency model from supplied durations. Independent branches run in parallel and a request waits until all declared parents finish. It does not model network limits, transfer contention, CPU, discovery delays or render-critical resource classification.

Where do dependencies come from?

You supply them as request IDs in an array or a pipe-separated dependsOn field. Verify them with browser initiator evidence; timing order alone does not prove a dependency. This tool does not infer dependencies from HAR or fetch the request URLs.

What happens with missing parents or cycles?

They remain visible as graph problems. Cyclic nodes and downstream blocked requests are distinguished. An unresolved chain cannot receive a trustworthy completion total. A selected valid goal can still be modeled when unrelated branches are unresolved.

Why does an improvement change the controlling chain?

A shorter branch can expose another bottleneck. The highlighted set includes tied controlling paths; the comparison shows one representative chain. Slack is modeled time by which a request could slip before affecting the selected completion goal under the same assumptions.

How do scenarios work?

Baseline values are preserved. An empty proposed duration inherits the baseline; zero is a valid proposal. Keep baseline dependencies inherits the original parent list. Uncheck it to supply a different list, or leave it empty to model an independent root. These are assumptions to verify in real code.

What files and graph sizes are supported?

JSON arrays, requests/rows objects, version 2 projects and CSV are supported, up to 5000 requests, 20000 links across both models and 8 MiB. Large diagrams show up to 80 requests around the selection; the ledger and report retain the full graph. CSV includes JSON-encoded text for exact round trips.

Can I remove a request or rename it safely?

Renaming an ID updates baseline and scenario references and the selected goal. Removing a request preserves references as missing-parent diagnostics, so dependencies are never silently discarded. Undo restores the last plan change.

KEEP YOUR WORKFLOW MOVING

A useful next step for your task.

Browse Developer & Data

Help improve this tool

Report a problem or suggest an improvement

Describe the issue without pasting private tool input. Feedback goes to our admin inbox.

Find another tool · Read practical guides