The same page, two very different bills
A crawler that reads HTML and stops pays for one request. A browser pays for the fonts, the stylesheet, the images, and the script as well. This measures both, in real bytes, and shows exactly what sits in the gap.
Crawler Cost Meter
The gapPress measure to compare.
| Resource | Transferred | Decoded | Duration |
|---|---|---|---|
| No measurement yet. | |||
Byte counts come from the Resource Timing API, which reports the real compressed transfer size and decoded size for every subresource the browser actually fetched. The raw figure is a separate fetch of the HTML document on its own, which is exactly what a crawler that does not execute JavaScript pays for. Cached resources report a transfer size of zero, which is honest rather than broken: a repeat visitor genuinely pays nothing for them.
Two very different bills for the same page
A crawler that reads HTML and stops pays a fraction of what a browser pays. That asymmetry is why a page can be cheap to index and expensive to experience, and why optimising for one tells you almost nothing about the other.
Crawl budget is measured in requests
A crawler's cost is dominated by how many documents it fetches, not how heavy each one renders. Fewer, denser pages are cheaper to crawl than many thin ones saying the same thing.
The user pays the full bill
Fonts, images, and scripts are invisible to a non rendering crawler and entirely visible to the person on a train with two bars of signal. Only one of those two audiences is going to convert.
Compression ratio is a content signal
A very high ratio between decoded and transferred bytes usually means heavily templated markup. That is fine for delivery, and it is often a hint that the unique content per page is thinner than the page size suggests.