The 7 KB truth: how lightweight analytics trackers improve Core Web Vitals

Every kilobyte you ship to a visitor's browser is a tax — on their data plan, on their CPU, and on your Core Web Vitals. Most of the analytics scripts shipped in 2026 cost between 50 and 90 KB gzipped, run a tag manager that loads more scripts, and silently degrade your Largest Contentful Paint by half a second or more. Multiply that across a quarter and it's measurable revenue.

A lightweight tracker fixes this — but the trade-off is real and worth understanding before you swap one. This post breaks down what actually happens to your performance budget when you switch from a heavy analytics suite to a 7 KB script, and how the Core Web Vitals respond.

The Web Vitals you're really being graded on

Google's Core Web Vitals reduce performance to three numbers, each with a threshold for “good.” Pass them and you keep your search ranking, your conversion rate, and your sanity:

• LCP (Largest Contentful Paint):the time until the largest visible element renders. Good = < 2.5s.
• INP (Interaction to Next Paint):how responsive the page feels under interaction. Good = < 200ms.
• CLS (Cumulative Layout Shift):how much the layout jumps after first paint. Good = < 0.1.

A heavy analytics tracker hurts the first two directly. Long script execution blocks the main thread, delaying interactivity. Large bundles compete with your hero image for bandwidth, delaying LCP. The third — CLS — is mostly your fault, not your tracker's, but a slow-to-load tracker that injects an opt-in banner can wreck it too.

Why heavy trackers cost more than their bytes

Wire size is only the first hit. Once the script reaches the browser it has to be parsed and compiled by the JavaScript engine, and that work is roughly linear in script size. On a low-end Android phone — the device most of your visitors actually have — parsing 60 KB of analytics JavaScript takes longer than rendering your entire homepage.

What a 7 KB tracker actually contains

It's reasonable to wonder what a 7 KB script can do. The answer: almost everything you actually use. Page-view collection, event tracking, session stitching, referrer parsing, Core Web Vitals reporting, heartbeat pings for visitor presence, and a small queue for retrying failed beacons. The features you're losing — most of them — are the ones a heavy tracker uses for ad-network identity reconciliation, not product analytics.

// What's inside the 7 KB Produl tracker
export const tracker = {
  collect:    sendPageview,        // ~600 bytes
  ping:       heartbeat,           // ~200 bytes
  vitals:     reportCoreWebVitals, // ~1.4 KB
  events:     queueAndFlush,       // ~900 bytes
  session:    stitchVisitor,       // ~700 bytes
  referrer:   parseAndAttribute,   // ~500 bytes
  // total — gzipped, no deps:    ~7 KB
}

Every byte is measured. There's no jQuery, no Lodash, no shimmedPromise, no polyfill bundle. It runs in evergreen browsers with the platform APIs already sitting in memory.

How loading order changes everything

Even a small script can hurt LCP if it's loaded wrong. The two rules:

1. Use defer. Never async for analytics — async can run before LCP and steal the main thread at the worst possible moment.
2. Don't inline the tracker into the document. It bloats the critical HTML response and forces the browser to parse it before first paint.

<!-- Right -->
<script defer src="/tracker.min.js" data-site="ma_..."></script>

<!-- Wrong: blocks LCP -->
<script src="/tracker.min.js" data-site="ma_..."></script>

<!-- Wrong: can interrupt LCP rendering -->
<script async src="/tracker.min.js" data-site="ma_..."></script>

The numbers: a real-world swap

We benchmarked the same Next.js storefront with three configurations: GA4 only, GA4 plus a tag manager loading four extra tools, and Produl alone. All three were on the same Vercel deployment, served over the same CDN, on identical hardware. The median LCP delta from removing the heavy stack and adding Produl was 1.4 secondson a throttled Moto G4 profile. That moves the page from “Needs improvement” into “Good” territory by itself.

How to migrate without losing data

Don't cut your old tool the day you ship the new one. The cleanest migration is a two-week overlap:

1. Install Produl alongside your existing tracker.
2. Compare top-line metrics — pageviews, unique visitors, conversion — for two weeks. They should agree within ~3%.
3. Once you're confident, remove the old script in a single deploy.
4. Watch your Web Vitals dashboard. The improvement is usually visible the same day.

The takeaway

Analytics doesn't need to be heavy. The reason most trackers are big is historical, not technical — they accreted features for ad targeting, attribution modelling, and cross-site identity that your product team almost certainly doesn't use. Strip those out and you get a tracker that fits in 7 KB, respects your performance budget, and pays for itself in Core Web Vitals.

Your visitors won't notice anything has changed. Their phones will. So will Google.