How Glinto's Analytics Pixel Stays Under 2KB
The engineering techniques behind the world’s smallest production analytics script: preconnect hints, beacon API, and zero dependencies.
Web performance is a zero-sum game. Every kilobyte of JavaScript you add to a page is a kilobyte that delays interactivity, consumes battery on mobile devices, and competes with your actual content for network bandwidth. The average analytics script from a mainstream provider is now over 50 KB compressed. Some exceed 100 KB when you include the consent management wrapper. For a tool whose sole purpose is to count page views, that is absurd.
The Glinto analytics pixel is 1.8 KB, including the inline loader and the event payload. It loads in a single request, executes in under 5 ms on a mid-range phone, and has zero external dependencies. Here is how we got there.
One File, One Purpose
Most analytics scripts are modular. They load a core library, then dynamically import plugins for heatmaps, session replay, conversion tracking, A/B testing, and advertising integrations. Each plugin adds weight, and the loading strategy itself — usually a chain of document.createElement('script') calls — introduces latency and failure points.
Glinto does one thing: it sends an event to our edge collector. There are no plugins, no extensions, no optional modules. The entire script is a single inline function that constructs a payload and fires it via the Beacon API. If you want heatmaps or funnel analysis, you use a different tool. We are comfortable with that trade-off because it keeps the pixel tiny and predictable.
The Beacon API Over Fetch
Modern analytics scripts often use fetch() with keepalive: true to send data. That works, but it requires constructing a Request object, handling promise resolution, and sometimes polyfilling for older browsers. The Beacon API — navigator.sendBeacon() — is purpose-built for fire-and-forget analytics. It runs asynchronously, does not block the unload event, and is supported by every browser released since 2016.
Our pixel uses Beacon exclusively. The call is a single line: navigator.sendBeacon(url, payload). No headers to configure, no CORS preflight to worry about, no promise chain to manage. The payload is a tiny JSON blob — typically under 200 bytes — containing the page URL, referrer, and a few coarse-grained environment flags.
Preconnect and DNS-Prefetch Hints
Even a 1.8 KB script can feel slow if the browser has to resolve a new domain and establish a TLS connection before downloading it. We recommend that customers add two link tags to their HTML <head>:
<link rel="dns-prefetch" href="//p.glinto.eu">
<link rel="preconnect" href="//p.glinto.eu" crossorigin>
These hints tell the browser to resolve our pixel domain and warm up the TLS handshake before the script is even referenced. In practice, this reduces the effective load time of the pixel to the network round-trip plus the script execution — usually under 20 ms on a decent connection.
No Frameworks, No Build Step for the Pixel
The pixel is written in plain JavaScript. There is no TypeScript, no bundler, no minifier pipeline beyond a single pass with Terser. We do not transpile for IE11. We do not ship polyfills. The code is simple enough that we can verify its correctness by reading it.
This is a deliberate cultural choice. In an industry obsessed with developer ergonomics, we optimise for user ergonomics. The developer’s comfort is irrelevant if the user pays the cost in milliseconds and megabytes.
Compression and Caching
The 1.8 KB figure is the Brotli-compressed size delivered over the wire. Cloudflare’s edge automatically applies Brotli or gzip depending on the client’s Accept-Encoding header. The script is served with a far-future cache header — Cache-Control: public, max-age=31536000, immutable — because the URL includes a content hash. Once downloaded, the pixel never needs to be fetched again for that visitor.
Measuring the Impact
We run synthetic performance tests on the top 1,000 Glinto customer sites every day. The median Total Blocking Time contribution from the Glinto pixel is 0 ms. The median Largest Contentful Paint delta compared to a control without the pixel is indistinguishable from noise. On slow 3G connections, the pixel adds less than 50 ms to the page load timeline. These are not marketing claims — they are reproducible measurements, and we publish the methodology in our public performance repository.
Small is not just a feature. It is a philosophy. Every byte we refuse to ship is a byte that belongs to our customers’ content. That is the respect we think analytics owes the web.