Analytics runs on every page you have, so its weight is a fair question and one you should not have to take on trust. This page gives the number and the method, so you can repeat it.

The number

11.7 KB gzipped, from 33.8 KB of JavaScript, measured against the bundle served for a live site.

To repeat it: fetch the script with Accept-Encoding: identity and gzip the result locally at level 9. That is the number below, and it is what a browser downloads once and then caches.

curl -s -H "Accept-Encoding: identity" \
  "https://t.skomi.com/s/YOUR-SITE-ID.js" | gzip -9 | wc -c

Your bundle may differ from ours, and that is the design. The script is composed per site: it carries the settings that site actually uses, and the capture fragments its products need. A site with fewer things switched on gets a smaller file. Run the command above against your own site ID for your number rather than trusting this one.

What is in it

One file, doing the whole job:

  • The page view itself: path, referrer, campaign parameters, screen size.
  • Identity, derived without storage. Nothing is written to the visitor's device, so there is no cookie code, no consent plumbing, and no banner to load before measurement can start. That is a large part of why the file is one file.
  • Session and engagement: how long a page held attention, how far it was read.
  • Automatic capture: outbound clicks, downloads, form submissions and 404s, for the ones you have switched on.
  • The transport: batching, retry, and the page-hide path.

There is no framework in it, no polyfill bundle, and no second request for a "plugin". What arrives is what runs.

How it loads

The snippet is one line and it carries defer:

<script src="https://t.skomi.com/s/YOUR-SITE-ID.js" defer></script>

defer means the browser keeps parsing your page and runs the script after the document is ready. It is never on the critical path, it does not block the first paint, and moving it into <head> does not change that. The attribute does the work, not the position.

Nothing is injected into your layout. The script adds no elements, no styles and no fonts, so it cannot shift anything on the page. Whatever your Cumulative Layout Shift is, this is not in it.

How often it is fetched

Cache-Control: public, max-age=300, stale-while-revalidate=86400
ETag: W/"…"

Five minutes of fresh caching, then a day in which a stale copy is served immediately while a new one is fetched in the background. So a returning visitor almost never waits for it, and a repeat page view within the window costs nothing at all.

Five minutes is deliberately short, and it is the one number here that looks wrong at first glance. The bundle is composed from your settings, so turn on outbound-link tracking, change an exclusion or switch a product on and the file changes. A long cache would mean your change reaching real visitors hours later. stale-while-revalidate is what buys back the speed: the visitor gets the old copy instantly and the new one lands in the background.

The file is content-hashed, so when nothing has changed the response validates against the ETag and no bytes move.

What it costs while running

  • One request for the script, cached as above.
  • One small request per page view.
  • One sendBeacon when the page is hidden, which is how time on page is closed out. Beacons are queued by the browser and do not delay navigation. This is the only place the tracker uses one.

Durations are worked out on the server from those timestamps rather than by a timer running in the page, so there is no interval firing while somebody reads.

Being honest about the trend

The script was about 10 KB raw a few months ago and is 33.8 KB now. It grew because engagement, automatic capture and app support were added to it. That is a real trade and it is worth stating plainly rather than only quoting today's figure: a tool that does more arrives as more bytes.

If you want the smallest possible file, switch off the automatic captures you do not use. The bundle is composed from your settings, so what you turn off is not sent.

We do not publish anybody else's script size. A comparison needs both figures re-measured on the same day by the same method, and the half that belongs to somebody else cannot be checked automatically, which makes it exactly the number that goes stale while looking authoritative. Ours is checked against the built file on every test run. Measure theirs yourself, with the command above, on the day you need the answer.