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.
| What it counts | The integer count of network requests captured during the Lighthouse audit run, including all sub-resources, third-party calls, beacons, and prefetches. Excludes service-worker-cached responses. |
| Sample type | Lab data from per-page Lighthouse network capture. |
| Why request count matters | Each request adds round-trip overhead. On a 4G connection with 80ms RTT, 100 sequential requests cost 8 seconds of pure latency even with zero bytes downloaded. HTTP/2 and HTTP/3 multiplexing reduce but don’t eliminate the cost. Tight, well-bundled pages feel fast on mobile; loose, unbundled pages with hundreds of requests feel slow regardless of total weight. |
| Reading the count | (1) Compare against ecommerce typical (homepage 60-120 requests, PDP 80-150, collection 100-180). (2) Anything above 200 is a red flag worth investigation. (3) Decompose via psi_weight_by_type to see which type contributes most requests. (4) Cross-reference psi_third_party_cost to see how many requests are first-party vs third-party. |
| Currency | integer (request count). |
| Time window | T/7D (per-audit). |
| Alert trigger | request count > 200 (page firing far above ecommerce typical). |
| Sentiment key | lower-is-better. |
| Roles | owner, operations |
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.| Resource type | Requests | Share | Ecommerce typical | Status |
|---|---|---|---|---|
| Images | 84 | 38% | 30-60 | High |
| Scripts | 62 | 28% | 25-45 | High |
| Stylesheets | 18 | 8% | 6-12 | High |
| Fonts | 14 | 6% | 4-8 | High |
| XHR / fetch | 22 | 10% | 5-15 | High |
| Beacons / pixels | 16 | 7% | 4-10 | High |
| Documents | 1 | <1% | 1 | Healthy |
| Other | 6 | 3% | 0-5 | Healthy |
| Total | 223 | 100% | 60-120 | Far above ecommerce typical |
- 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.
| Time horizon | Action |
|---|---|
| First 1 hour | Identify dominant bucket by request count (not weight). |
| First week | Apply highest-leverage consolidation (icons → sprite, CSS → bundle). |
| Day 14 | Audit GTM container, defer non-critical tags. |
| Re-audit | Confirm request count below 150. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
psi_total_weight | Total page weight; complements request count. |
psi_weight_by_type | Weight per type; complements requests per type. |
psi_third_party_cost | Third-party request cost; identifies external request inflation. |
psi_render_blocking | Render-blocking resources; subset of total requests with critical impact. |
psi_unused_js | JS-specific opportunities. |
psi_unused_css | CSS-specific opportunities. |
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.
| Reason | Direction | What to do |
|---|---|---|
| Browser cache. Manual checks with a warm cache show fewer requests; Vortex IQ audits cold. | Vortex IQ higher | Use cold-cache when reconciling. |
| Lazy-loaded resources. Vortex IQ scrolls during audit; a manual check that doesn’t scroll misses lazy-loaded images and below-the-fold scripts. | Vortex IQ higher | Scroll to bottom of page in DevTools before counting. |
| Service worker caching. Vortex IQ may bypass the service worker; the user’s actual browser may have a service worker satisfying many requests from cache. | Vortex IQ higher | Compare both states intentionally. |
| A/B tests / personalisation. Different test variants serve different scripts; counts may vary between audit runs. | Either direction | Use 7-day rolling. |
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).