Pixel Test Harness — V1 vs V2
Standalone testImage-based pixel→Research probe · no API callsWebRTC IP vs header IP→Every scenario below loads the current pixel (V1) and the proposed fix (V2) side by side in identical conditions, so you can see exactly how each one behaves. The list is ordered by importance — the situations where V1 fails today come first.
- account
79, property6a2111320c2dee2dc5548935 - V1 — the pixel currently in production. It waits for the page to finish loading before firing (
window.load), which is exactly the source of the bug. - V2 — pixel
6a211df10c2dee2dc5548936. Fires the moment the script executes, with no wait. Also refires on in-app navigation and bfcache restore.
Where V1 fails today — the cases V2 fixes
These are the situations where the current pixel silently misses fires — slow networks, performance optimizers, tag managers, and cookie-consent banners. If you have ever seen V1 undercounting in production, the cause is almost certainly in here. Start with these.
- Slow connection (3-second delay)compare V1 ↔ V2The clearest reproduction of the V1 bug. wire.js delivery is artificially delayed, forcing V1 to lose the race every time.
- Cookie consent + in-app navigationcompare V1 ↔ V2The most realistic real-world edge case: a site behind a consent banner that also has single-page-app navigation.
- Cookie consent bannercompare V1 ↔ V2A site behind a OneTrust/Cookiebot-style banner. Interactive Accept / Decline / Accept-after-delay controls.
- Performance optimizer (NitroPack)compare V1 ↔ V2Mirrors how NitroPack and similar tools delay scripts past window.load to make pages "feel faster".
- Google Tag Managercompare V1 ↔ V2How GTM-installed pixels arrive ~800ms late by the time the container loads and fires its tags.
What V2 newly enables — capabilities V1 lacks
These scenarios demonstrate behaviour that V2 supports and V1 cannot: tracking in-app navigation in single-page sites, refiring when the browser restores a page from cache, and behaving predictably when the script is installed more than once. These are net-new features, not just bug fixes.
- In-app navigation tracking (manual)compare V1 ↔ V2V2 refires the pixel every time the URL changes inside a single-page app — pushState, replaceState, hashchange, back/forward. Manual button-driven test.
- Duplicate install + wrapper chaincompare V1 ↔ V2What happens when wire.js is installed more than once (theme + tag manager). Verifies V2 chains correctly under N installs.
- Back / forward cache restorecompare V1 ↔ V2When the browser restores a previous page from cache instead of reloading, V2 refires the pixel — V1 doesn’t.
- In-app navigation (auto-triggered)compare V1 ↔ V2Same as the manual SPA test, but the navigation fires automatically 2 seconds in — no clicks required.
Standard install methods — baseline reference
How wire.js behaves under each of the common install patterns. Useful as a baseline: these confirm V2 still works in the same situations where V1 already works fine, with no regression.
- <script async> in <head>compare V1 ↔ V2The recommended install. Reliable on heavy pages, but race-prone on lightweight ones.
- <script defer> in <head>compare V1 ↔ V2The "safest" V1-compatible install — defer guarantees execution before window.load.
- <script async> in <body>compare V1 ↔ V2Injected client-side after the page hydrates. Common when scripts come from a tag manager.
- next/script afterInteractivecompare V1 ↔ V2Next.js default. Loads after React hydrates. Mirrors lektik.com/campaign.
- next/script beforeInteractivecompare V1 ↔ V2Next.js high-priority strategy — defer-equivalent. V1 always passes here.
- next/script lazyOnloadcompare V1 ↔ V2Next.js opt-in lazy loading. Worst case for V1 — script arrives after browser idle.
Framework-specific quirks — edge cases
The same race condition observed outside Next.js. Light frameworks (plain React) and heavy traditional pages (WordPress-style) sit at opposite ends of the spectrum — useful for understanding why some real customer sites fail while others happen to pass.
- Plain React (no Next.js)compare V1 ↔ V2Lightweight React app — page is so quick that V1 reliably loses the race. Closest to legacy amli.com setup.
- Heavy WordPress-style pagecompare V1 ↔ V2jQuery + Bootstrap + busy-wait. Heavy pages give V1 enough time to arrive before window.load — V1 usually passes here.
How to read each comparison
- window.load — the moment the iframe finishes loading everything on the page. This is the event V1 listens for.
- wire.js — when the wire.js script finishes downloading. If this happens later than
window.load, V1 has already missed its chance — it cannot fire. V2 doesn’t care about timing. - pixel — the actual tracking hit. This is the success signal: if you see a number, the pixel fired. A
×Nsuffix means it fired multiple times (relevant for SPA tests, duplicate installs, and bfcache restores). - Both iframes load independently inside the same page, so any difference in outcome comes from the wire.js logic itself — not from the surrounding test setup.