Page weight (total transfer size)
Page weight is the total number of bytes transferred to load a page — the sum of the compressed transfer sizes of the document and every sub-resource it pulls in. The Resource Timing API exposes transferSize per resource, which differs from the uncompressed decodedBodySize. Page weight correlates with load cost on slow or metered connections, and breaking it down by resource type shows whether images, scripts, fonts, or media dominate.
What this means
Page weight is the total bytes that crossed the network to render a page: the HTML document plus CSS, JavaScript, images, fonts, and media. The Resource Timing API reports each resource's transferSize, and summing them gives the page's transferred weight.
Transfer size vs resource size
transferSize is the compressed bytes actually sent over the wire, including response headers; decodedBodySize is the larger uncompressed size the browser works with. A cached resource can report a transferSize near zero. Because of this, page weight measured as transfer size reflects network cost, while decoded size reflects memory and parse cost.
- transferSize = compressed bytes on the wire (+ headers)
- decodedBodySize = uncompressed resource size
- Cached resources transfer little but still parse
Why it misleads
A low total does not guarantee speed if a few critical resources block rendering, and a high total can be fine if most bytes load lazily after the main content. Read page weight alongside the critical path and paint metrics rather than as a quality score on its own.
How it appears in analytics and logs
A heavy page means many or large bytes had to transfer — often unoptimised images, large JavaScript bundles, or autoplay media — which slows load most on constrained connections.
Diagnostic use case
Use page weight to quantify how much data a visit costs and to spot the resource type — usually images or JavaScript — that should be optimised first on slow or metered networks.
What WebmasterID can help detect
WebmasterID can record resource-timing summaries first-party so page weight is observed against human-classified traffic rather than crawler fetches.
Common mistakes
- Confusing transfer size with uncompressed resource size.
- Treating total bytes as the same thing as load speed.
- Ignoring that cached resources report near-zero transfer.
Privacy and accuracy notes
Page weight is a byte total for resources, not personal data. This page is educational, not legal advice.
Related pages
- Request count (number of requests)
Request count is the number of network requests a page issues to load — every HTML document, stylesheet, script, image, font, and API call. The Resource Timing API lists each as a PerformanceResourceTiming entry. The raw count matters less than which requests sit on the critical rendering path and how they contend for connections, since modern protocols multiplex but third-party and render-blocking requests still gate the experience.
- Largest Contentful Paint (LCP)
Largest Contentful Paint (LCP) reports the render time of the largest image or text block visible in the viewport, measured from when the page starts loading. It is one of Google's Core Web Vitals, exposed through the Largest Contentful Paint API, and the candidate element can change as larger content paints — the final value is taken at the last candidate before user interaction. web.dev breaks LCP into TTFB, resource load delay, load duration, and render delay to localise the bottleneck.
- Time to first byte (TTFB)
Time to first byte (TTFB) measures the interval between the browser starting a navigation request and receiving the first byte of the server's response. The Performance Timeline derives it from responseStart minus the request's start time, so it folds in redirect, DNS, connection, TLS, and server processing time. Because nothing can render before bytes arrive, a slow TTFB delays every downstream metric, which is why web.dev treats it as a diagnostic for First Contentful Paint and Largest Contentful Paint.
- Website observability
Resource-timing signals beside traffic.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.