Analytics via Cloudflare Zaraz
GA4 and the Meta Pixel are not in the front-end bundle. They are configured in the Cloudflare dashboard and executed in a Worker at the edge, so the phone never downloads, parses, or runs the vendor SDKs.
Nothing in this repo injects them. front-end/vite.config.ts used to do it via vite-plugin-radar; that plugin has been removed.
Why
A Safari HAR captured on a real iPhone against production (2026-08-17) measured the landing page. Every app JS chunk in that trace came from memory cache — the network was idle from 212 ms onward — yet the app's first query didn't fire until 3707 ms. That 3.5 s gap was main-thread time, not bandwidth.
What was on the critical path, decompressed:
| Script | Raw | Brotli |
|---|---|---|
googletagmanager.com/gtag/js | 498 KB | 170 KB |
connect.facebook.net/en_US/fbevents.js | 410 KB | 110 KB |
connect.facebook.net/signals/config/<pixel-id> | 287 KB | 68 KB |
| Analytics subtotal | 1.19 MB | 348 KB |
| Landing route app chunks (15 files) | 466 KB | — |
72% of the JavaScript the device had to execute before first paint belonged to the two analytics tags. The gtag tag was async, but the inline fbq(...) bootstrap ran synchronously in <head> and started the whole Meta chain immediately.
IDs
| Tool | ID |
|---|---|
| Google Analytics 4 | G-WQQT9HXW0N |
| Meta Pixel | 1332503762092630 |
Dashboard setup
Zaraz is per-zone, and ai-mee.uk must be proxied through Cloudflare (orange cloud) for it to inject anything.
- Cloudflare dashboard → the
ai-mee.ukzone → Zaraz → Tools. - Add tool → Google Analytics 4. Measurement ID
G-WQQT9HXW0N. Keep the default automatic Pageview trigger. - Add tool → Facebook Pixel. Pixel ID
1332503762092630. Keep the default Pageview trigger so it matches thefbq('track', 'PageView')the inline snippet used to fire. - Leave Zaraz → Settings → Load Zaraz script on the default. Zaraz still ships a small first-party loader (
/cdn-cgi/zaraz/i.js); the point is that the ~1.19 MB of vendor SDK stays on the edge.
Verifying
Zaraz only runs on Cloudflare's edge — it does not run under vite dev or vite preview, so a local build legitimately shows no analytics at all. It is also zone-scoped (see Dashboard setup above): a *.pages.dev preview subdomain belongs to Cloudflare's own pages.dev zone, not ai-mee.uk, so Zaraz never injects there and checking that URL would pass for the wrong reason regardless of whether the dashboard is configured correctly. Verify against a hostname that's actually on the ai-mee.uk zone — production, or a preview mapped to a custom domain on that zone:
# Should return the Zaraz loader, not a 404
curl -sI https://ai-mee.uk/cdn-cgi/zaraz/i.js | head -1
# Prints the match count for the vendor SDKs — should print 0, since they
# must not be in the HTML any more now that Zaraz replaces the in-repo tag
curl -s https://ai-mee.uk/ | grep -cE 'googletagmanager|fbevents'
Then confirm data still arrives: GA4 Realtime should show the session, and Meta Events Manager → Test Events should show the PageView.
Tracking-parity caveats
- Timing. Zaraz fires the Pageview from the edge on request, not from the page. Session stitching and attribution are equivalent, but per-event client timestamps shift slightly.
window.fbq/window.gtagno longer exist. Nothing infront-end/srcreferenced them at the time of this change (verified by grep). Any future custom event must go throughzaraz.track(), notfbq()/gtag().- Consent. If a cookie banner is added later, wire it to Zaraz's consent API rather than conditionally injecting tags.