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.
What this means
Request count tallies every fetch a page makes: the document, sub-resources, and runtime calls. Each shows up as a PerformanceResourceTiming entry, so counting and categorising those entries reveals how chatty a page is and which origins it talks to.
Why the raw number is not the point
HTTP/2 and HTTP/3 multiplex many requests over one connection, so a high count is less damaging than it once was. What matters is the critical path: render-blocking CSS and JavaScript, and slow third-party calls, gate paint regardless of total count. A page with fewer but blocking requests can be slower than one with many lazy ones.
- Each request is a PerformanceResourceTiming entry
- HTTP/2 & HTTP/3 multiplex over one connection
- Critical-path and third-party requests gate paint
Why it misleads
Counting requests rewards bundling everything into one file, which can hurt caching and delay first paint. And third-party requests outside your control can dominate. Read request count with the critical path and connection view, not as a target to minimise blindly.
How it appears in analytics and logs
A high request count signals many resources or chatty third parties — the risk is not the number itself but render-blocking or connection-contended requests delaying first paint.
Diagnostic use case
Use request count to spot pages that fan out into many small fetches, then focus on the render-blocking and third-party requests on the critical path rather than the raw total.
What WebmasterID can help detect
WebmasterID can summarise resource-timing entries first-party so request patterns are read against human-classified sessions, not crawler fetch storms.
Common mistakes
- Bundling aggressively to cut count and hurting cacheability.
- Treating all requests as equal when only some block rendering.
- Ignoring third-party requests in the total.
Privacy and accuracy notes
Request count is a tally of resource fetches, not personal data. This material is educational, not legal advice.
Related pages
- 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.
- 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.
- First Contentful Paint (FCP)
First Contentful Paint (FCP) measures the time from navigation start to when the browser first renders any DOM content — text, an image, a non-white canvas, or SVG. The Paint Timing API exposes it as the first-contentful-paint entry, and web.dev treats it as the moment a visitor first sees that something is happening. It precedes Largest Contentful Paint, which marks the largest element, so the two answer different questions about perceived load.
- Website observability
Resource request patterns 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.