Tracker Performance Report: Sealmetrics vs GA4
The current Sealmetrics tracker weighs 1.1 KB on the wire — 12× less than the legacy Sealmetrics v1 tracker and roughly 155× less than GA4's gtag.js. That weight, combined with a single-step dispatch chain and an ingestion pipeline rebuilt from scratch (Go → RabbitMQ → ClickHouse), translates into more hits captured: dual-tagged sites (running both Sealmetrics trackers in parallel) measure 25–30% more traffic on average with the current tracker than with v1, with the gain concentrated in mobile traffic and in visitors geographically far from our Dublin servers.
Key numbers at a glance:
| vs legacy v1 | vs GA4 | |
|---|---|---|
| Wire weight advantage | 12× lighter | ~155× lighter |
| Measured traffic difference | +25–30% (dual-tag average) | +25–45% (EU markets, estimate) |
Methodology
The weight and latency figures in this report come from direct measurements taken in July 2026 against production scripts, downloaded exactly as a real browser receives them (Accept-Encoding: gzip, 3 samples per measurement, fiber connection from Spain):
- Sealmetrics (current):
t.sealmetrics.com/t.js— the production script. - Sealmetrics v1 (legacy):
app.sealmetrics.com/tag/v3/tracker(versionsm 16.x). - GA4:
googletagmanager.com/gtag/jswith the ID of a real GA4 property in production.
Script URLs and tag configurations were extracted from the real Google Tag Manager container of a European e-commerce site that runs both Sealmetrics trackers in parallel alongside GA4. To preserve the site's anonymity, the GA4 figures and latency values have been rounded and lightly adjusted; orders of magnitude and ratios between systems are preserved. The Sealmetrics tracker weights are exact — they are product scripts, identical for every customer.
What is measured and what is modeled
- Measured: script weights (exact bytes, compressed and uncompressed), HTTP protocol and headers, the latency table below (median of 3 samples from a single location), IP addresses, and GTM configuration. Absolute latency values depend on the origin network; the relative differences between systems hold.
- Modeled: the four network scenarios (round-trip, bandwidth, and CPU arithmetic built on top of the measurements) and the per-device parse costs. These are always labeled as estimates.
- Business data: the +25–30% traffic difference vs v1 comes from Sealmetrics accounts running both trackers in parallel on the same site (dual-tagging). The +25–45% vs GA4 is a reasoned estimate, not a measurement of any single site.
How consent is treated
Every GA4 measurement and model in this report represents its technical chain once the tag fires — that is, GA4's best case (a visitor who has already granted consent). The cost of the consent banner is quantified separately, as volume loss, in the traffic impact section. Sealmetrics trackers have no such wait: they are consentless measurement by design (no cookies, no personal identifiers).
Script weight
What travels over the network determines when the first hit can fire. The legacy v1 tracker is also served uncompressed, so its wire weight is its raw weight.
| Sealmetrics (current) | Sealmetrics v1 (legacy) | GA4 (gtag.js) | |
|---|---|---|---|
| Transferred over the network | 1.1 KB (gzip) | 13.7 KB (no gzip) | ~171 KB (gzip) |
| Uncompressed (what the CPU parses) | 2.0 KB | 13.7 KB | ~512 KB |
| Relative wire weight | 1× | 12× | ~155× |
The TCP detail that matters: the current tracker's 1.1 KB fits in a single packet and arrives in the first round-trip. The v1 tracker's 13.7 KB uncompressed sits right at the edge of TCP's initial congestion window (~14.6 KB), and GA4's ~171 KB needs 4–5 slow-start round-trips. When the visitor is far from the server, every extra round-trip multiplies latency.
Delivery protocol and infrastructure
| Sealmetrics (current) | Sealmetrics v1 (legacy) | GA4 | |
|---|---|---|---|
| Protocol | HTTP/2 | HTTP/1.1 | HTTP/2 + HTTP/3 |
| Compression | gzip (1.1 KB) | none | gzip |
| Origin | Dedicated Go service (Dublin) | nginx (Dublin) | Google global anycast CDN |
| Requests until first hit | 1 script → immediate beacon | loader + script + hit (2 steps) | gtag ~171 KB + collect on a 2nd domain |
| Hit transport | sendBeacon — survives page close | standard request after tracker loads | beacon/fetch after evaluating ~512 KB |
| Data pipeline | Go → RabbitMQ → ClickHouse (columnar, real time) | legacy monolithic stack | batch processing; reports lag 24–48 h with thresholds |
Measured latency (fiber, Spain)
Median of 3 samples with warm DNS. Even in the best possible network scenario, the current tracker completes its download in roughly half the time of v1 and GA4.
| Phase | Sealmetrics (current) | Sealmetrics v1 | GA4 |
|---|---|---|---|
| TCP connect (≈ RTT) | ~34 ms | ~48 ms | ~19 ms (local edge) |
| TLS established | ~80 ms | ~95–100 ms | ~55–70 ms |
| Time to first byte | ~110 ms | ~190–280 ms | ~110–140 ms |
| Script fully downloaded | ~110 ms | ~190–340 ms | ~210–290 ms |
GA4 wins on network proximity (a Google edge in every city) but loses it all on volume: even with a better RTT, downloading ~171 KB takes twice as long as downloading 1.1 KB from Dublin — and after that, ~512 KB of JavaScript still has to be parsed on the visitor's device.
Time to first hit: four network scenarios
The tables below break the full pageview path into four phases: connection (DNS + TCP + TLS — driven by distance to the server), download (driven by script weight), CPU (parsing and executing the JavaScript — driven by uncompressed weight and device), and hit dispatch (v1 needs an extra round-trip; GA4 connects to a second domain; in the current tracker the beacon fires inside the execution phase). These are modeled estimates built on the measurements above. This is the time from tag fire until the pageview leaves the device — the window during which an abandonment is a lost hit.
They model the technical chain from the moment the tag fires — a visitor with consent already granted. For a new EU visitor, GA4 additionally requires prior banner acceptance: an extra delay of seconds (or forever, if they never accept) that does not appear in these numbers.
Fiber / fast 4G · Spain (RTT ~30 ms to Dublin, ~15 ms to Google edge, fast CPU):
| Connection | Download | CPU | Hit dispatch | Total | |
|---|---|---|---|---|---|
| Sealmetrics (current) | ~80 ms | ~30 ms | ~2 ms | included | ~0.1 s |
| Sealmetrics v1 | ~95 ms | ~145 ms | ~15 ms | ~45 ms | ~0.2–0.3 s |
| GA4 | ~60 ms | ~170 ms | ~180 ms | ~60 ms | ~0.5–0.7 s |
GA4's connection phase is the shortest of the three — its edge is 15 ms away. It still finishes last: download and CPU consume the advantage twenty times over.
Mid 4G · mobile (RTT ~80 ms to Dublin, ~50 ms to edge, 8 Mbps, mid-range CPU):
| Connection | Download | CPU | Hit dispatch | Total | |
|---|---|---|---|---|---|
| Sealmetrics (current) | ~180 ms | ~90 ms | ~5 ms | included | ~0.3 s |
| Sealmetrics v1 | ~260 ms | ~250 ms | ~35 ms | ~80 ms | ~0.6–0.9 s |
| GA4 | ~120 ms | ~380 ms | ~400 ms | ~100 ms | ~1.0–1.5 s |
On a mid-range phone, CPU becomes GA4's largest phase: parsing ~512 KB costs more than the current tracker's entire chain.
3G / weak signal (RTT ~200 ms, 1.5 Mbps, slow CPU):
| Connection | Download | CPU | Hit dispatch | Total | |
|---|---|---|---|---|---|
| Sealmetrics (current) | ~430 ms | ~220 ms | ~10 ms | included | ~0.7 s |
| Sealmetrics v1 | ~650 ms | ~800 ms | ~100 ms | ~250 ms | ~1.6–2.2 s |
| GA4 | ~350 ms | ~1.8 s | ~1.6 s | ~400 ms | ~3.5–5 s |
At 1.5 Mbps, GA4 spends ~3.4 s just downloading and parsing. The current tracker has had the hit delivered for 3 seconds by the time gtag is still downloading.
Remote visitor · e.g. LATAM → Dublin (RTT ~220 ms to Dublin, ~30 ms to local Google edge, 10 Mbps):
| Connection | Download | CPU | Hit dispatch | Total | |
|---|---|---|---|---|---|
| Sealmetrics (current) | ~460 ms | ~280 ms | ~10 ms | included | ~0.7–0.9 s |
| Sealmetrics v1 | ~680 ms | ~500 ms | ~40 ms | ~250 ms | ~1.4–1.9 s |
| GA4 | ~80 ms | ~330 ms | ~450 ms | ~140 ms | ~0.9–1.4 s |
The most illustrative case: GA4 has its best connection here (an edge in the visitor's own city) and Sealmetrics its worst (2 round-trips of ~220 ms to Dublin). Even with that network disadvantage, the current tracker delivers the hit first: its download and CPU phases are so small that distance is the only thing it pays for. GA4 wins the connection and loses the race on volume and CPU.
Round-trips and bytes
| Sealmetrics (current) | Sealmetrics v1 | GA4 | |
|---|---|---|---|
| TLS connections needed | 1 | 1 | 2 (gtag + collect) |
| Round-trips until the hit | ~3 | ~5–6 | ~7–9 |
| Bytes over the network | 1.1 KB | 13.7 KB | ~170 KB |
| JavaScript to parse | 2.0 KB | 13.7 KB | ~510 KB |
The hidden cost: parsing JavaScript has no CDN
A global edge brings bytes closer, but parsing always happens on the visitor's device. Estimated parse + execution cost by device class:
| Device | Sealmetrics · 2 KB | v1 · 13.7 KB | GA4 · ~510 KB |
|---|---|---|---|
| Laptop / high-end | under 1 ms | ~5 ms | ~120–250 ms |
| Mid-range phone | ~2 ms | ~15 ms | ~300–500 ms |
| Low-end phone | ~5 ms | ~40 ms | ~800–1,500 ms |
This is the structural reason GA4 cannot compensate for its weight with infrastructure: Google can put an edge in every city, but it cannot put a faster CPU in every visitor's pocket. The current tracker attacks the problem from the other side — making sure there is almost nothing to download or parse.
Why the current tracker captures hits the others lose
Every visit that abandons the page before the pixel fires is invisible traffic. The current tracker's vulnerability window is ~0.1–0.9 s depending on network; v1's is 2–3× larger — and v1 can also lose the hit to a race condition even when the visitor stays.
Legacy v1 chain — two steps with a race:
- An inline loader snippet creates the
sealmetrics.qqueue. - The 13.7 KB tracker downloads (HTTP/1.1, no gzip).
- The script parses and executes; tags call
window.sm. - If the tracker has not loaded yet:
"sm2 plugin is not available"— hit lost, no retry. - The hit request fires (an additional round-trip).
Current tracker chain — one step:
t.jsdownloads: 1.1 KB, HTTP/2, one packet.- The pageview fires from inside the script itself via
sendBeacon— no dependencies, no race. - The beacon survives even if the visitor closes or navigates away: the browser delivers it anyway.
- The Go ingestion service acknowledges in milliseconds → RabbitMQ → ClickHouse.
The hit's life insurance: sendBeacon
There is a transport difference that multiplies everything above. A classic request (XMLHttpRequest, fetch) is tied to the page's lifetime: if the visitor closes the tab or navigates to another URL while the request is in flight, the browser cancels it and the hit is lost. navigator.sendBeacon() inverts the model: the page hands the packet to the browser and steps aside — the browser queues it internally and delivers it even after the page no longer exists. It is the API browsers themselves designed for telemetry.
Verified against the production scripts: the current tracker uses sendBeacon (with fetch keepalive as fallback, which has the same property), while the legacy v1 tracker does not use it at all — it sends via a cancelable XMLHttpRequest. In practice: as soon as the current tracker executes (~0.1–0.3 s), the hit already belongs to the browser and closing the page cannot lose it; v1 additionally needs to complete the round-trip to the server with the page still alive.
The band of visits lasting between ~0.3 s and ~1.5–2 s — instant bounces from paid traffic, accidental taps on mobile, abandonments due to slowness — is captured systematically by the current tracker and lost systematically by v1. It is one of the clearest signatures of the dual-tag gap: segmented by visit duration, the current tracker's surplus should concentrate in the shortest visits.
| Hit transport | Sealmetrics (current) | Sealmetrics v1 | GA4 |
|---|---|---|---|
| Mechanism | sendBeacon + fetch keepalive | XMLHttpRequest | sendBeacon/fetch keepalive |
| Survives page close? | Yes | No — canceled | Yes |
| Moment the hit is secured | ~0.1–0.3 s | ~0.5–2 s (when the XHR completes) | ~0.5–1.5 s (after parsing gtag, and only with consent) |
GA4 also uses beacon-style transport — its problem is not the transport but that it reaches the dispatch point much later (weight + CPU) and only after consent. And sendBeacon is best effort: if the browser crashes or the OS kills the process, the beacon can be lost — practical reliability is very high, but not literally 100%. The current tracker also cannot measure a visitor who leaves before t.js executes; loading it through GTM widens that window, which is one more reason to install the snippet directly in the <head>.
Impact on measured traffic
| Comparison | Traffic difference | Where it comes from |
|---|---|---|
| Current vs legacy v1 | +25–30% on average | Observed on dual-tagged accounts (both trackers in parallel on the same site). Gain concentrated in mobile traffic, slow connections, and visitors far from Dublin: earlier fire, race-free chain, sendBeacon, HTTP/2, and compression. |
| Current vs GA4 (EU markets) | +25–45% (estimate) | Three GA4 losses the Sealmetrics tracker does not have: consent banner rejection/ignoring (~20–35% of visitors), blocking of Google domains by browsers and filter lists (~10–15%, partially overlapping), and abandonment before gtag fires (~2–5% on mobile). |
Session window change ("Rejoined Traffic"): 6 h → 2 h
There is also a definitional factor that pushes the current tracker's numbers up, worth keeping in mind when reading the gap: the session re-entry window. In v1, if a visitor clicked through to the site again within 6 hours of their entrance, that visit was classified as Rejoined — it did not open a new entrance. In the current tracker that window is 2 hours.
Example: a user with 2 clicks 5 hours apart — v1 counted 1 entrance + 1 pageview (the second click became Rejoined); the current tracker counts 2 entrances + 2 pageviews. Same user behavior, more entrances and pageviews recorded.
This effect is more granular measurement, not newly captured traffic: it adds to the real capture gains (timing, sendBeacon, race-free chain) in the total v1-vs-current difference. To isolate it in your own data, look at the segment of re-entries between 2 and 6 hours — that is exactly the band where the two definitions diverge.
Deployment recommendations
- Do not gate Sealmetrics tags behind consent in GTM. A frequent misconfiguration: if Sealmetrics tags sit behind the CMP's consent state, you give up their main advantage — Sealmetrics can measure without consent by design (no cookies, no personal identifiers). Fire them on Consent Initialization or with no consent condition.
- Install the snippet directly in the
<head>, outside GTM. Loaded through GTM, the tracker inherits the container's latency (typically 100–250 KB): if GTM is slow, blocked, or the visitor leaves before it loads, the tracker cannot measure either. With the snippet directly in the<head>you capture the full advantage shown above. - Compare v1 and the current tracker with homogeneous metrics. When evaluating a dual-tag, compare pageviews with pageviews and entrances with entrances — and account for the different session windows (Rejoined at 6 h in v1 vs 2 h in the current tracker, see above): mixing metrics or ignoring the window inflates or hides differences.
- Keep the dual-tag for a validation period. Running both trackers in parallel lets you quantify the capture difference with your own data, segmented by device and geography, before retiring v1.
Limitations and honest notes
- Latencies were measured from a single location (fiber, Spain) in July 2026; the four network scenarios are models, not field measurements, and should be cited as such.
- The GA4 timings above are its best case: they exclude the consent wait, which for new EU visitors adds seconds or prevents measurement entirely.
- The +25–30% vs v1 is an average across dual-tagged accounts; each site will have its own figure depending on its device, network, and geography mix. The GA4 range depends critically on each site's CMP acceptance rate.
- Part of the entrance increase vs v1 is definitional, not capture: the Rejoined session window changed from 6 h (v1) to 2 h (current tracker).
- EasyPrivacy includes the rule
||sealmetrics.com^$third-party: visitors with uBlock/AdGuard block both Sealmetrics tracker versions equally. The advantage over GA4 lies in consent and timing, not in ad blockers. - To preserve the anonymity of the reference site, GA4 figures and latencies are rounded and lightly adjusted (see methodology); Sealmetrics tracker weights are exact.