The lightest analytics script

Analytics is the only thing on most pages that is paid for entirely by the visitor and consumed entirely by the site owner. The bytes, the connection, the parse time and the main-thread work all land on somebody who gets nothing from it, on every page, forever.

That is a reasonable trade for a kilobyte. It is a less reasonable trade for forty, particularly on a content site where the reports are opened once a month.

What the spread actually looks like

The range across this market is close to two orders of magnitude, which is larger than most people assume.

At the light end: Cloudflare Web Analytics needs no client-side script at all on Cloudflare-proxied sites, because the edge already sees every request. Absolutely Analytics publishes 1,270 bytes gzipped. Plausible and Pirsch are around a kilobyte. Umami is about two, GoatCounter about three. Shynet works from a tracking pixel with no JavaScript whatsoever.

At the heavy end: Google Analytics 4 is tens of kilobytes and usually arrives through Google Tag Manager, which adds its own. PostHog, Mixpanel and Amplitude are tens of kilobytes each. Session replay libraries are heavier again, and their published figures often exclude the runtime fetches they make afterwards.

Compare gzipped transfer size, not raw, and check what the script fetches after it loads. A small loader that pulls a large payload is not a small script.

What weight costs in practice

Transfer size is the least of it. A third-party script costs a DNS lookup, a TCP connection and a TLS handshake before a byte of it arrives, and on a slow mobile connection that is most of the delay. Then it must be parsed and executed on the main thread, which competes directly with rendering.

The metrics it shows up in are Interaction to Next Paint, where main-thread work during load delays responsiveness, and Largest Contentful Paint, where connection contention delays your hero image. Cumulative Layout Shift is usually unaffected unless the tool injects visible elements, which is a reason to be wary of anything that renders a widget.

The practical rule: a one-kilobyte first-party-served script is effectively free. A forty-kilobyte third-party script on a slow connection is not, and you will see it in field data even when a lab test looks fine.

Measuring your own bill

Open DevTools, go to the Network panel, filter to JS, reload with cache disabled and sort by transfer size. Your analytics will be in there, and the number is usually bigger than the vendor's marketing figure because the marketing figure excludes whatever the script fetches afterwards.

Then run a Performance trace and look for long tasks during load. If an analytics script appears in one, it is competing with your rendering.

Finally, look at field data rather than lab data. Chrome's Core Web Vitals report and Cloudflare Web Analytics both give you real user measurements, which is where third-party script cost actually shows up. A lab test on a fast connection hides it almost completely, which is why so many sites carry more analytics weight than anybody realises.

Reducing it without losing the data

Pick a lighter tool. The most effective option and the least popular, because it means admitting most of the reports were never opened.

Serve it first-party. Several vendors document a proxy so the script comes from your own domain. This removes a connection and reduces ad-blocker loss, which improves your data as well as your performance.

Do not run two tools that do the same job. A cookieless analytics tool plus a separate heatmap tool means two scripts, two connections and two consent obligations. A tool that bundles both is one of each.

Measure at the edge where you can. If your site is behind Cloudflare, its analytics needs no script at all and is immune to ad blockers. It is shallow, but as a free baseline underneath a better tool it costs your visitors literally nothing.

The rest of the field

Common questions

Related guides