The average analytics script loads 45 kilobytes of JavaScript, sets 8 first-party cookies, fires 3 third-party requests, and blocks the page’s load event by 200 milliseconds. It also gets blocked by 74% of ad-blocker users — the exact audience most likely to care about privacy.

Glinto’s tracking pixel is 2 kilobytes. It makes one request. It sets zero cookies. And it has never appeared on a blocklist.

Here’s how we built it, and what it says about the state of web analytics in 2026.

First: Why So Small?

When we reduced the tracking script from its initial 8KB to a final 2KB, we weren’t chasing a vanity metric. We were chasing three concrete outcomes:

Load time. A script that’s 2KB compressed (around 3.5KB uncompressed) loads in under 5 milliseconds from any Cloudflare edge location in Europe. That’s faster than DNS resolution for most sites. Your visitors never see a loading spinner, never experience a render-blocking pause, and never wonder why your Lighthouse score tanked when you installed analytics.

Ad-blocker evasion. Most ad-blockers work by matching request URLs against community-maintained blocklists. The EasyPrivacy list — one of the most popular — blocks requests to domains like google-analytics.com, analytics.tiktok.com, and hundreds of other tracking endpoints. Our tracking domain (*.glinto.eu) is a generic analytics service, not an advertising technology provider. The blocklist maintainers have no reason to target us because we don’t serve ads, don’t create user profiles, and don’t share data with third parties.

Reduced attack surface. Every line of JavaScript you ship is a potential vector for XSS, prototype pollution, or supply-chain compromise. Our script is small enough to audit in 60 seconds. There’s no minified bundle, no dependency tree, no eval, and no dynamic code loading.

What the Script Actually Does

The entire logic fits in a screen of code:

  1. Construct a URL with query parameters for the current page, the referrer, the screen width (for device category — mobile/tablet/desktop), and optionally a page title.
  2. Create a <noscript> fallback in case JavaScript is disabled — a simple <img> tag that sends the same data.
  3. Fire a fetch to our ingestion endpoint, which responds with a 204 No Content and takes no further action.
  4. That’s it. There’s no session management, no event queuing, no retry logic, no local storage, no cookie read/write. The script is stateless because all state lives on our servers, not in the user’s browser.

The noscript fallback is important. Around 1–2% of web users browse with JavaScript disabled, and they’re disproportionately technical people whose opinions matter. If you can’t count them, you’re missing the most influential segment of your audience.

Why Ad-Blockers Leave Us Alone

There’s a common misconception that ad-blockers block everything that “tracks” you. In reality, blocklists are maintained by humans who apply specific criteria:

  1. Does the domain serve ads? If yes, it goes on the advertising blocklist.
  2. Does the domain collect cross-site browsing data for profiling? If yes, it goes on the tracking protection list.
  3. Does the domain fingerprint browsers? If yes, it goes on the fingerprinting list.

Glinto fails all three tests. We don’t serve ads. We don’t build cross-site profiles. We don’t fingerprint browsers. The blocklist maintainers — who are pragmatic about the difference between surveillance and measurement — see no reason to block us.

This isn’t a hack or an exploit. It’s the intended behavior of the ad-blocking ecosystem: block surveillance, allow measurement. The problem is that most analytics tools are indistinguishable from surveillance tools. We just built one that isn’t.

The Technical Details

For those who want to understand the pixel format itself:

GET /pixel.gif?d=example.com&p=/blog/post&r=https://google.com&w=1440&t=The+2KB+Pixel HTTP/1.1
Host: t.glinto.eu

Parameters:

  • d: the hostname of the tracked site (required — identifies which Glinto account owns this pageview)
  • p: the URL path (required)
  • r: the referrer (optional — we store it if present)
  • w: screen width in pixels (optional — for device bucketing)
  • t: page title (optional — makes the dashboard more readable)

The endpoint responds 204 No Content. No set-cookie header, no tracking ID in the response, no redirect. Your browser makes one opaque request and moves on.

On the server side, the Worker:

  1. Extracts the origin IP for geo-lookup (country-level only)
  2. Pulls the site’s account from D1 based on the d parameter
  3. Increments the per-minute counter in a Durable Object
  4. Writes the pageview record to D1 (without IP, without user agent hash if daily salt has rotated)
  5. Returns 204 in under 3ms

The Privacy Implications of Being Tracked by Nobody

There’s something philosophically satisfying about building an analytics tool that doesn’t know who your visitors are. We can tell you that 342 people visited your site yesterday — 40% from Germany, 30% from France, with an average of 2.1 pages per session. We cannot tell you that a specific person clicked from LinkedIn to your pricing page to your documentation to your signup form.

That’s not a technical limitation; it’s a design goal. Glinto was built during the era when “privacy-first” meant “we store less data than Google does.” We went further: we never had the data in the first place.

The result is an analytics platform that works without consent banners, without cookie notices, without complex data processing agreements, and without the nagging feeling that your analytics tool is monetising your visitors behind your back.

A 2-kilobyte pixel. One request. No cookies. No consent required. That’s the whole story.