How Big Is a Lightweight Analytics Script? Our Live 60-Request Test

A tracking script's file size and its download size can be very different. On 13 October 2026, we made 60 requests to LiteStats' public tracking script to measure that difference directly.

The JavaScript source was 19,106 bytes. When the server used gzip, the response body was 5,786 bytes, a 69.7% reduction. Requests offering both gzip and Brotli received gzip. Requests offering only Brotli received the uncompressed script.

Those results give us a precise answer to a small but useful question: how much JavaScript does this analytics script transfer under these compression settings?

Disclosure: this is a LiteStats-authored measurement of our own product. The experiment was run with a Node.js measurement script. It measures the script download; browser execution and real-user performance require separate tests. We have included the protocol, raw data, and reproduction script so readers can inspect the work.

Why measure analytics script size?

When you add analytics to a Next.js landing page or a small SaaS website, you add another resource to load. A useful starting point is to establish the size of that resource and how the server delivers it.

An editor shows you the decoded JavaScript. HTTP compression can reduce the bytes delivered over the network. The client's Accept-Encoding request header advertises supported compression formats, and the server's Content-Encoding response header identifies the format actually used. MDN explains this negotiation.

This distinction matters when evaluating claims such as “a 5 kB analytics script.” Ask what that number describes: source code, a locally compressed file, or the response served by the live endpoint. We wanted to measure the last of those.

How we ran the experiment

We requested the public endpoint:

https://getlitestats.com/track.js

Before running the test, we recorded a protocol with four request conditions:

We ran 15 rounds, with one request per condition in each round. We shuffled their order using a fixed seed, producing 60 sequential requests in total.

Each request used a fresh HTTP/1.1 connection. The client had no response cache and sent no conditional cache headers. We recorded the HTTP status, observed encoding, response-body byte count, decoded byte count, source hash, selected headers, and request timings.

The measurement script counted the compressed response body before decoding it. It then decoded the response and calculated a SHA-256 hash, allowing us to check that each request delivered the same JavaScript.

The test ran on one macOS machine using Node.js 20.19.0, between 19:40:10 and 19:40:18 Dublin time on 13 October 2026. It downloaded the script without executing it or calling analytics collection endpoints. One additional gzip download was used for independent Python decompression verification; it is excluded from the 60-request results below.

The live download results

All 60 requests returned HTTP 200. Every decoded response contained the same 19,106-byte JavaScript source and the same SHA-256 hash.

The byte count was identical across all 15 responses within each condition.

Gzip saved 13,320 response-body bytes per download compared with the uncompressed response:

1 - (5,786 / 19,106) = 69.7% reduction

Using decimal units, the gzip response was 5.79 kB. Using binary units, it was 5.65 KiB. These figures describe the response body; they exclude HTTP headers, connection overhead, and any requests the tracking script makes after it executes.

What happened when we requested Brotli?

The endpoint did not serve Brotli in this experiment. A request offering only br received the uncompressed response. Offering gzip alongside Brotli produced a gzip response.

Requesting a compression format does not establish that the server will use it. Inspect the response header and measure the body. HTTP negotiation can permit an uncompressed response when a requested compression format is unavailable. MDN documents that behaviour.

As a separate reference calculation, we compressed the captured source locally using Node's Brotli compressor at quality 11. That produced 4,915 bytes, approximately 15.1% smaller than the observed gzip response.

That local result identifies a possible optimisation to investigate. It is not a measurement of Brotli delivery from the live site, and compression cost and deployment configuration would need to be evaluated before adopting it.

Does a smaller download make the page faster?

The experiment established a reduction in response-body bytes. It also recorded request completion times from one machine: median completion was approximately 155 ms for identity requests and 123 ms for gzip requests.

Those timings include network conditions, connection setup, and server response behaviour. The short run used fresh HTTP/1.1 connections, so it does not represent every browser's connection reuse, protocol, caching, or network environment. The timing observations do not establish a causal page-speed improvement.

A full page-performance experiment would also measure JavaScript execution, rendering, and user interactions. Standard Lighthouse page-load testing reports lab metrics such as Largest Contentful Paint, Total Blocking Time, and Cumulative Layout Shift. Real-user Interaction to Next Paint requires interaction measurements. Google's Web Vitals guidance explains the distinction.

Download size is one piece of that investigation. This test provides a reproducible starting measurement.

How to reproduce the measurement

You can inspect a single gzip response with curl:

curl --fail --silent --show-error --max-time 20 \
  --http1.1 \
  --header 'Accept-Encoding: gzip' \
  --dump-header litestats-gzip-headers.txt \
  --output litestats-track.gzip \
  --write-out 'Downloaded response-body bytes: %{size_download}\n' \
  https://getlitestats.com/track.js

This command saves the raw response body. Check Content-Encoding in the saved headers to confirm the server actually used gzip. Change the request header to identity or br to examine the other conditions.

For the full experiment, copy the supplied measurement script into a new directory and run it:

node run-experiment.mjs

It writes raw CSV and JSON results, a summary, and the measured source file into that directory. A future run may produce different results as the script or hosting configuration changes.

The source measured in this experiment had this SHA-256 hash:

39fbfd4592169a4f41e5d76e3448d34a074e8ae8f1207fd3e82178bc8d111955

The supporting files are available here: raw CSV, raw JSON, summary, protocol, and measurement script.

What this means for a small SaaS website

For the LiteStats script tested on this date, 5,786 gzip-compressed response-body bytes is the measured download figure. The corresponding decoded JavaScript was 19,106 bytes. Keeping both numbers attached to a date and source hash makes the result easier to assess and repeat.

When evaluating analytics for your own website, begin with the delivered resource, then measure its behaviour on a representative page. Include subsequent tracking requests and real interactions in that next test. A useful benchmark should let another developer repeat the method and understand exactly what its numbers mean.

You can inspect LiteStats' tracking setup documentation and live demo to explore the implementation and dashboard.

Download the complete experiment files.