Performance
Request count
Request count is the number of HTTP requests a page makes to load. Each one can cost a round trip, a connection, and a slot in the browser's queue.
How it is measured
The DevTools Network footer shows 'N requests'. Lighthouse reports the total in its network audit, and a HAR export lists each entry. Count on a cold cache, and state whether you include data URIs, cache hits, and failed 404s.
Break the count down by host. Requests to your origin and to third parties cost differently, since each new host adds DNS and TLS. Over HTTP/2 and HTTP/3, requests share one connection, so the penalty per request is far smaller than under HTTP/1.1.
Worked example
A hotel booking page makes 187 requests: 41 to its own host and 146 to 23 third-party hosts, including two tag managers, three chat widgets, and a heatmap. Page weight is only 1.9 MB. On a throttled mobile run the main thread is busy for 4.1 s handling those responses and running their scripts.
Removing the heatmap, one chat widget, and a duplicate analytics tag brings requests to 119 and TBT from 1,100 ms to 480 ms, though page weight only falls by 0.4 MB.
How it differs
Request count is how many fetches; page weight is how many bytes. A page of 12 requests can weigh 9 MB because of one video, and one with 200 requests can weigh 700 KB. Count predicts connection and scheduling overhead, and weight predicts transfer time.
Common errors
Chasing a low count by bundling everything into one file that busts the cache on every change. Counting only first-party requests. Ignoring requests triggered after load, on scroll, or by a consent banner. Applying HTTP/1.1 advice like image sprites to an HTTP/2 site.
In practice
Export a HAR for your top page and group it by domain. Remove duplicate and dead requests first: old tags, 404s, libraries loaded twice. Then decide, host by host, whether each remaining third party earns its place.