How Many HTTP Requests Does Your Analytics Tool Make? We Counted.
Every HTTP request your analytics tool makes competes with your content for bandwidth and connection slots. Browsers limit concurrent connections per domain — Chrome caps at 6. When your analytics fires 4 requests across 3 domains, it is consuming resources your product pages, images, and checkout flows need.
We wanted to know exactly how many requests each tool makes, how many external domains it contacts, and how many bytes it transfers. So we set up a controlled test and counted.
What we measured
We loaded the same test page once per tool on a clean Chrome profile with no extensions. We filtered the Network tab to analytics-related domains and recorded three numbers: total requests, unique domains contacted, and total bytes transferred. No warm caches. No service workers. No ad blockers.
The results
| Tool | Requests | Domains | Transfer (KB) | What it loads |
|---|---|---|---|---|
| SealMetrics | 2 | 1 | 2.7 | Script (2.5 KB) + beacon to first-party endpoint |
| Plausible | 2 | 1 | 1.5 | Script (1.3 KB) + beacon |
| Fathom | 2 | 1 | 2.2 | Script (2.0 KB) + beacon |
| Simple Analytics | 2 | 1 | 4.2 | Script + beacon |
| Piwik PRO | 3 | 2 | 38 | Container + tracker + beacon |
| Mixpanel | 3 | 2 | 32 | SDK + config + beacon |
| PostHog | 4 | 2 | 59 | SDK + config + session recording init + beacon |
| Google Analytics 4 | 4 | 3 | 134 | gtag.js + analytics.js + config + collect |
| Adobe Analytics | 6 | 4 | 158 | AppMeasurement + visitor ID + config + beacon + ID sync + audience mgr |
Adobe Analytics fires 6 requests across 4 domains and transfers 158 KB. SealMetrics fires 2 requests to 1 domain and transfers 2.7 KB. That is a 59x difference in bytes transferred.
Why request count matters
Each HTTP request carries overhead that goes beyond the bytes transferred. The browser must resolve DNS, negotiate a TLS handshake, and wait for the server response before the payload even begins downloading. On a mobile connection with 80ms round-trip latency, a single request adds 240ms or more before the first byte arrives.
Chrome limits concurrent connections to 6 per domain. When analytics consumes 4 of those slots, your product images, fonts, and JavaScript bundles queue behind them. This is not a theoretical concern — it is measurable in Core Web Vitals. Largest Contentful Paint increases when the browser is busy negotiating connections for analytics scripts instead of rendering your page.
The domain problem
Each external domain your analytics contacts requires its own DNS lookup and TLS handshake. DNS resolution typically costs 50-100ms. A TLS 1.3 handshake adds another 50-100ms. For tools that contact multiple domains, these costs stack.
GA4 contacts google-analytics.com, googletagmanager.com, and sometimes doubleclick.net. That is 3 DNS lookups + 3 TLS handshakes = 300-600ms of overhead before analytics data even begins to move. Adobe Analytics contacts 4 domains — adding up to 400-800ms.
SealMetrics uses cookieless first-party tracking through a single first-party endpoint. One domain. One DNS lookup. One TLS handshake. Two requests. Zero third-party connections.
The payload gap
The 158 KB that Adobe Analytics transfers on a single pageview includes AppMeasurement code, a visitor ID service, configuration data, the tracking beacon itself, a cross-domain ID sync, and an audience manager call. Most of that payload supports cross-domain tracking, visitor stitching across sites, and remarketing data collection — features that are either illegal under GDPR without explicit consent or already blocked by modern browsers.
GA4's 134 KB follows a similar pattern: gtag.js bootstraps analytics.js, which fetches a configuration payload, then fires the collection call. The configuration includes logic for Google Signals, cross-device tracking, and ad remarketing. If you have disabled those features for compliance, the bytes are still downloaded and parsed — you pay the performance cost for functionality you cannot use.
SealMetrics' 2.7 KB total — a 2.5 KB script and a small beacon — goes to a single first-party endpoint. No visitor IDs to sync. No cross-domain stitching. No remarketing payloads. Cookieless analytics does not need any of that infrastructure — and your visitors do not need to pay for it.
How we measured
We tested each tool on an identical HTML page with a single analytics snippet. The steps were reproducible:
- Created a fresh Chrome profile with no extensions, no saved data
- Loaded the test page with DevTools open, Network tab recording
- Waited for the page to fully load and all analytics requests to complete
- Filtered the Network tab by analytics-related domains
- Recorded request count, unique domains, and total bytes transferred
- Repeated the test 3 times per tool and averaged the results
We tested default installations — no custom configurations, no tag manager optimizations, no deferred loading. The numbers reflect what most sites actually deploy.
The bottom line
Your analytics tool should measure your site, not slow it down. Two requests totaling 2.7 KB to one first-party domain captures 100% of traffic through cookieless first-party collection. No third-party domains. No connection overhead. No wasted bytes on features your visitors never agreed to.
See how SealMetrics works under the hood, or calculate how much data your current setup is losing.