Reference

The trace.

“The scrape took 4.2 seconds” tells you nothing you can act on. Every response carries a per-stage breakdown instead, so you can see which part was slow and decide what to do about it.

trace, from a real response

"trace": {
  "stages": [
    { "name": "fetch",    "elapsed_ms": 22.2 },
    { "name": "parse",    "elapsed_ms": 1.3 },
    { "name": "content",  "elapsed_ms": 185.8 },
    { "name": "metadata", "elapsed_ms": 10.0 },
    { "name": "links",    "elapsed_ms": 0.1 },
    { "name": "media",    "elapsed_ms": 0.0 },
    { "name": "records",  "elapsed_ms": 0.1 },
    { "name": "combine",  "elapsed_ms": 0.0 }
  ],
  "cache_hit": false,
  "rendered": false,
  "redirects": [],
  "warnings": []
}

Stages

Stages appear in the order they ran. Not every stage appears on every request, render only shows up when rendering actually happened.

Stage	What it covers
fetch	Cache lookup, robots check, politeness delay, the request itself, and any redirects. Network-bound. This is where a slow site shows up.
render	Only present when the page turned out to be a JavaScript shell. Usually the largest number in the trace when it appears at all.
parse	Building the document tree. Roughly proportional to page size.
content	Both extraction passes, precision and density. Usually the largest CPU cost on a static page.
metadata	JSON-LD, OpenGraph, meta tags, and the date and author heuristics.
links	Collecting, canonicalizing and classifying every link.
media	Images, with alt text and lazy-load attributes resolved.
records	Detecting repeated structures, product cards, search results.
combine	The deterministic merge. Effectively free; it is bookkeeping, not work.

The other fields

Field	Meaning
cache_hit	The response came from the HTTP cache. Expect `fetch` to be near zero.
rendered	A headless browser was used. The page was a JavaScript shell.
redirects	Every hop, in order. A long chain is worth noticing.
warnings	Things that degraded the result without failing it, a JS page that could not be rendered, a binary body that was not extracted.

There is no total_ms field, sum the stages. That keeps the trace a record of what happened rather than a summary that can drift out of step with it.

Reading it

fetch dominates, the target site is slow, or politeness delays are throttling you. Not something faster hardware fixes.

render dominates, the page is a JavaScript shell. If a domain is actually static, its pages will not trigger rendering at all; if you see rendering on a site you expected to be static, the markup is probably client-assembled.

content dominates, a large or deeply nested page. This is CPU, so it scales with page size rather than network conditions.

Everything is small but the total is large. You are being rate limited or queued. Check rate limits.

Watch it happen

The playground renders this trace as a bar chart on its Trace tab. Paste a URL and compare a static page against a JavaScript-heavy one, the difference is the clearest explanation of the pipeline there is.