> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Request Count, Website Performance (PageSpeed + CrUX)
> Request Count for Website Performance (PageSpeed + CrUX) stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it.
**Metrics type:** [Supporting Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Website Performance](/nerve-centre/connectors#connectors-by-type)
## 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** |
What the request count is telling us:
1. **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.
2. **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.**
3. **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.
4. **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.
5. **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.
6. **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**.
7. **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.
8. **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.
The diagnostic flow:
1. **Compare total against ecommerce typical.** Above 150 is worth attention; above 200 is critical.
2. **Decompose by type** to identify which bucket dominates.
3. **Apply bucket-specific consolidation patterns** (sprites, bundles, GTM SS, font subsetting).
4. **Re-audit** to confirm count drops.
Rapid-response playbook:
| 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`](/nerve-centre/kpi-cards/website-performance/total-page-weight) | Total page weight; complements request count. |
| [`psi_weight_by_type`](/nerve-centre/kpi-cards/website-performance/weight-by-resource-type) | Weight per type; complements requests per type. |
| [`psi_third_party_cost`](/nerve-centre/kpi-cards/website-performance/third-party-cost) | Third-party request cost; identifies external request inflation. |
| [`psi_render_blocking`](/nerve-centre/kpi-cards/website-performance/render-blocking-resources) | Render-blocking resources; subset of total requests with critical impact. |
| [`psi_unused_js`](/nerve-centre/kpi-cards/website-performance/unused-javascript) | JS-specific opportunities. |
| [`psi_unused_css`](/nerve-centre/kpi-cards/website-performance/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.
**Why the Vortex IQ count may differ from manual checks:**
| 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. |
**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 the `crux_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. `` and `` 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).
***
### Tracked live in Vortex IQ Nerve Centre
*Request Count* is one of hundreds of KPI pulses Vortex IQ tracks across Website Performance (PageSpeed + CrUX) and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English.
[Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.