At a glance
Total number of network requests fired to render the page, counts every HTTP/HTTPS resource the browser fetches: images, scripts, stylesheets, fonts, XHR/fetch calls, beacons, prefetches. High request count is a separate problem from high page weight: a 2MB page with 250 requests is harder on mobile networks than a 4MB page with 60 requests, because each request adds connection overhead (DNS, TLS, latency) and contention on slow networks. Reducing request count via bundling, image sprites, font subsetting, and third-party consolidation often produces noticeable mobile speed wins independent of byte savings.
Calculation
Calculated automatically from your Website Performance (PageSpeed + CrUX) data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A UK-based BigCommerce fashion store, mobile homepage audit, Wednesday 15 May 26.
What the request count is telling us:
- Total request count is 223, almost double the ecommerce typical for a homepage. On a 4G connection with 80ms RTT, the cumulative latency cost of 223 requests is 5-9 seconds depending on multiplexing efficiency. This explains why the page feels slow on mobile even when individual resource weights aren’t extreme.
- Image request count is the largest contributor (84 requests). Likely caused by (a) no image sprite for icons (each social/payment icon is a separate file), (b) product thumbnails on the homepage carousel served as 12 separate images instead of a single sprite, (c) tracking pixels firing as image requests. A single sprite-sheet refactor on icons typically removes 20-30 image requests.
- Script request count at 62 is high. Each third-party widget loads multiple JS files: GTM container loads → fires 30 tags, each tag loads its own script → 30+ third-party requests. Consolidate via GTM tag audit + GTM Server-Side Container (which moves the request burden to your server). Saves 20-40 requests on a typical merchant.
- Stylesheet request count at 18. Theme is likely loading separate CSS files per page section (header.css, footer.css, hero.css, grid.css, modal.css). Bundle into one critical-path CSS file + defer non-critical styles. Reduces from 18 to 4-6 requests.
- Fonts at 14 requests is excessive. Three font families × multiple weights × multiple subsets × multiple formats (woff + woff2 + eot fallback). Drop legacy formats, subset to Latin only, preload only the critical weight. Reduces to 4-6 requests.
- XHR/fetch at 22 requests is suspiciously high for a homepage. Investigate which JS makes XHR calls on page load, common culprits: live-inventory updates, cart-state polls, tracking SDKs reporting page metadata, A/B test platforms. Many of these can be deferred until user interaction.
- Beacons/pixels at 16 requests. Tracking infrastructure: Meta pixel, Google Ads pixel, GA4 pixel, TikTok pixel, Pinterest pixel, plus retargeting. Each fires 1-2 beacons. Consolidate via server-side tagging (Meta CAPI, GA4 Measurement Protocol, GTM SS) to move these off the browser request budget.
-
Recommended ship sequence:
- Week 1: Image sprite for icons + product thumbnail sprite. Saves 20-30 requests.
- Week 2: CSS bundle consolidation. Saves 12-14 requests.
- Week 3: GTM tag audit + GTM SS migration. Saves 30-40 requests.
- Week 4: Font format/subset cleanup. Saves 8-10 requests.
- Week 5: XHR/fetch defer review. Saves 10-15 requests.
- Result after 5 weeks: 223 → 100-130 request count. Mobile time-to-interactive improvement of 1.5-3 seconds typical.
- Compare total against ecommerce typical. Above 150 is worth attention; above 200 is critical.
- Decompose by type to identify which bucket dominates.
- Apply bucket-specific consolidation patterns (sprites, bundles, GTM SS, font subsetting).
- Re-audit to confirm count drops.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look:- Chrome DevTools → Network panel, the count at the bottom of the panel (“X requests”) is the canonical reconciliation source. Refresh with cold cache (Ctrl+F5 + Disable Cache) and scroll to bottom.
- Lighthouse audit JSON →
network-requests, array of every request captured during the audit; length is the request count. - WebPageTest → Waterfall view, total request count appears in the summary panel.
Cross-connector reconciliation: primarily internal (with
psi_total_weight, psi_weight_by_type, psi_third_party_cost).
Quick rule for support tickets: when a merchant disputes the request count, capture a fresh DevTools network panel cold-cache with full page scroll and compare numbers directly. Disagreements typically resolve to caching or scroll-depth differences.
Known limitations / merchant FAQs
Q: We have 180 requests and the page is fast. Should we still try to reduce? Depends on the audience. If your traffic is mostly desktop on home/office WiFi, the request count overhead is small and you may not feel a problem. If 60%+ of traffic is mobile on cellular networks (which describes most consumer ecommerce), 180 requests adds noticeable latency on 3G/4G connections. Look at thecrux_ttfb_p75 and crux_lcp_p75 field-data values for actual user experience before deciding effort allocation.
Q: HTTP/2 multiplexes requests, does request count still matter?
Yes, but less than under HTTP/1.1. HTTP/2 amortises the connection setup cost and parallelises transfer, but each request still incurs server-side processing and head-of-line-blocking on the same connection. Reducing requests still helps, just less dramatically than the 5-10× improvement HTTP/2 vs HTTP/1.1 gave at the connection layer. HTTP/3 (QUIC) helps further but doesn’t eliminate the cost.
Q: Our request count went up after a release. What broke?
Likely a new third-party widget added (review, chat, A/B test, retargeting), a new GTM tag deployed, or a code change that loaded resources serially instead of bundled. Check psi_third_party_cost to see if a new third-party domain appeared, then check the GTM container changelog and recent theme deploys.
Q: Does prefetching count as requests?
Yes. <link rel="prefetch"> and <link rel="preload"> directives fire actual network requests; they appear in the count. Prefetching is generally healthy (warming cache for next-page navigation), but excessive prefetching wastes user bandwidth. Audit prefetch declarations periodically, a stale prefetch list can fire 20+ unused requests per page.
Q: Beacons fire-and-forget, do they slow the page down?
Beacons themselves don’t block rendering, but the JavaScript that fires them (analytics SDKs, conversion tracking) typically does block. Reducing beacon count via server-side tagging removes both the request and the originating script weight, double benefit.
Q: Should we use a request-count budget in CI?
Yes, establish a budget per template (e.g. homepage <120, PDP <150, collection <180) and fail CI when exceeded. Coupled with weight budgets, this prevents performance regressions from sneaking in via well-intended feature ships. Lighthouse CI supports this directly.
Q: How does this card differ from psi_total_weight?
psi_total_weight measures bytes transferred. This card measures requests fired. Both are needed because they have different remediation patterns and different impact profiles. Bytes hurt slow connections; requests hurt high-latency connections. A page with 5MB / 60 requests is a different fix than a page with 2MB / 200 requests, the first needs image/script optimisation, the second needs request consolidation (sprites, bundles, GTM SS).