Web tag performance

If you're reviewing the tag before allowing it on a storefront, this page is the answer sheet: what it weighs, how many requests it makes, when it makes them, and what stops it from getting worse. It also says plainly what we have not measured.

The commitments come first because they're the part that stays true. The current measurement comes second, dated, because it moves with every release.

The budget we commit toCopy Anchor Link

These are absolute figures, not "current size plus a margin". Crossing one fails our build: the check runs inside the tag build itself, so there is no build of iAdvize anywhere that ships a tag over budget.

Current measurementCopy Anchor Link

Measured 2026-09-21, from a production build of the tag:

On top of that, the snippet you paste is about 390 bytes of inline HTML, no request of its own.

So a page carries roughly 9.6 KB of transferred script whether or not the shopper ever opens the chat.

The bundle figure is measured against the production app origin. That origin is baked into the bundle as a literal, so a build for a preview environment weighs a few bytes more or less purely because its hostname is a different length; the number we publish, and the number the budget check enforces, is the production one.

What loads, and whenCopy Anchor Link

Two more network behaviours, so they don't surprise you in a waterfall:

• Hovering one of your data-iadvize-open triggers adds a <link rel="preconnect"> to the iAdvize app origin. That warms up the TLS connection so the conversation opens faster; it downloads nothing.
• Batched page telemetry is sent once, when the tab is hidden or the page unloads (visibilitychange / pagehide), never during your page's render.

Caching. The content-hashed bundle is served public, max-age=31536000, immutable, so a repeat visitor pays nothing for it. The loader, whose URL is stable, is public, max-age=300, must-revalidate: a 5-minute revalidation window that bounds how long a bad tag deploy can stick around.

Zero layout shiftCopy Anchor Link

Outside a mount point you declare, the tag adds nothing to your document flow. The panel and its optional backdrop are position: fixed, appended to <body>, and they animate with transform and opacity only: compositor-only properties that don't affect layout, so the slide-in cannot move your content. A chat bubble and a question bar are fixed too.

An inline button is the exception, because being in your content flow is what it's for. There the commitment is per mount mode, and it's worth reading before you pick one:

The selector mode inserts the button next to an element we don't own, so there is no box to reserve. On our own fixture the content below an unreserved mount point moved by 72 px, scoring a 0.0325 layout shift. That's a property of the mode, not a defect we're working on. The way to avoid it is to reserve the space, which only the two element modes allow. See Reserve the space.

Two honest limits even on the reservable modes: a custom element the browser hasn't upgraded yet is laid out as display: inline and has no box, so a min-height needs a display beside it; and we can't compute the reserved box for you, because the button's width follows a label that is per-language and rendered in your own font. Zero shift is a claim we make for a fixed geometry you reserve, not for any configuration.

Opening and closing the panel moves nothing either way: a button or a Starters widget stays exactly where it is while the panel is open.

Being fixed isn't enough on its own, and one case genuinely touches your page's layout. When the panel locks background scroll (a narrow screen where the panel fills the viewport, or the dimmed backdrop), the tag sets overflow: hidden on <html> and <body>. On Windows and Linux desktop, that removes a classic scrollbar and widens the layout viewport by around 15 px, which moves every horizontally centred element on your page. Here's what the tag does about it:

• It measures the scrollbar's width before locking and adds exactly that much padding-right to <html>, so the layout viewport width doesn't change. Your original value is restored on close.
• That padding is added to whatever padding-right your own stylesheet computes, never substituted for it: overwriting your 24 px with 15 px would itself be a layout change.
• Where the scrollbar takes no space (overlay scrollbars: macOS, mobile), nothing is added. The compensation is inert exactly where the problem can't occur.
• The lock is applied before the panel and iframe are created, and released only after the 280 ms close animation ends, so our own fixed elements are laid out once, in their final viewport, instead of moving mid-animation.

We measure this on our own fixture: zero shift with no inline widget and with a button in a reserved mount point, and the real measured figure for an unreserved button and for a Starters widget in either resolved state. That isolates what the tag itself adds to layout, at load and across an open/close cycle. It's not a CLS score for your storefront as a whole. For that, launch a real measurement from the site's Performance tab. See Measure it on your own storefront.

Listeners on your pageCopy Anchor Link

The tag registers nine listeners on your document and window, and no more:

Page-wide listeners are the tag's main interaction cost and they're invisible in the DOM, so the set is pinned by a test: adding one fails that test with a printed diff, which makes a new listener a reviewed decision rather than a silent cost.

pointerover is registered as passive, so it can't delay scrolling. resize and orientationchange only do work while the panel is open, and are coalesced to at most one evaluation per animation frame.

What we enforce, and what we only measureCopy Anchor Link

The split is by measurement stability, not by importance.

Enforced (a violation fails a check):

• both size ceilings (gzip and uncompressed) for both files;
• the exact set of requests made before any interaction;
• zero sub-document, stylesheet, font, image or media request before the panel opens;
• a reference element's position on the host page, unchanged across an open → close cycle with the scroll lock engaged;
• zero raw layout-shift entries, on load and across an open → close cycle, and with a button mounted into a reserved mount point (Starters is reported, not gated, on this check; see Zero layout shift);
• the pinned listener inventory;
• a sensitivity check that applies an uncompensated scroll lock and requires that a shift is detected, so the checks above can't quietly lose the ability to fail.

Measured and reported, never gated: script evaluation time, long tasks, the browser's own per-request byte figures, the shift an unreserved button mount point produces, and the shift a Starters widget produces in either resolved state (chip stack present or absent). Those are reported rather than asserted at a figure on purpose: an unreserved button's shift scales with your own type scale, and Starters' with whatever your starter-question library resolves. A threshold on either would be a threshold on your page or your content, not on the tag. What is asserted for both is that the transition between states is real and detectable. Otherwise a zero-shift claim elsewhere on this page would mean nothing.

That last split is deliberate and worth stating rather than glossing over. CI machines share CPU with no isolation, so any millisecond threshold flakes; a flaky gate gets loosened or skipped, and you're left with a green check that means nothing, worse than no check. So timing is a trend we record and read, not a guarantee we make.

On the layout-shift checks, one detail matters: they read raw layout-shift entries and deliberately ignore the hadRecentInput flag. Cumulative Layout Shift excludes anything within 500 ms of a user input, and our panel opens from a click, so a CLS-based check would score 0 even with the scroll-lock shift above still present, and would certify the tag as safe while it wasn't. That's why the check asserts the stronger property: the tag shifts nothing, ever, whether or not a click preceded it.

Where the checks run. The size budget is part of the tag build, so it runs in every build. The browser measurements run as their own job on every pull request, with the footprint report kept as an artifact. That browser job reports today; it isn't yet a hard block on merging.

These figures come from a fixture, not from your storefrontCopy Anchor Link

Stated plainly, because it changes how you should read everything above.

Every measurement on this page is taken on a controlled test page we host in our own repository: a centred content container, a hero image with explicit dimensions, no web font, all assets inlined, and the same install snippet the dashboard gives you, driven in Chromium at a desktop (1280×720) and a mobile (390×844) viewport.

That makes it a floor test: it proves the tag cannot get worse than a known baseline without a check going red. It is not a before/after comparison on a real storefront, not field data from real shoppers, and not a Core Web Vitals score. The test page also uses a placeholder site key, so the conversation iframe stays inert: the measurement covers what the tag costs your page, not what the conversation UI costs once a shopper opens it.

Measure it on your own storefrontCopy Anchor Link

Everything above comes from our own fixture. To see what the tag costs your storefront (and how the page performs for real shoppers), open the site's Settings → Performance tab.

Launch a runCopy Anchor Link

The URL field is pre-filled from the site's own registered URL, editable per run. Measure now checks that URL's origin against the site's own registered origin allowlist (Settings → Public access), rejected outright if it isn't listed, no exception, and re-checks it again when the background job actually runs, in case the allowlist changed in the meantime.

A launched run moves pending → running → completed (or failed, if something broke outside the comparison itself: a Google API error, an unreachable URL). The page refreshes on its own while a run is in flight. The tab is split in three: Most recent run (the lab delta below), Real-world field data (CrUX), and History: the site's full run history, one row per run, with a Score (off → on) column whose value you can hover for the full per-metric breakdown. Launching a new run never jumps you back to Most recent run if you were looking at Field data or History.

The causal lab deltaCopy Anchor Link

Once a run completes, you get a same-instant, same-page comparison, driven by Google PageSpeed Insights: the storefront URL measured once with the tag running, and once with the tag's own kill switch (?iadvize_disable=1) turned on: the same page, the tag itself the only difference between the two. Each side is measured 5 times and reduced to its median, to smooth out normal PSI run-to-run noise; the 5 raw runs per side stay visible behind a "based on N tag-on and N tag-off runs" toggle rather than disappearing into the median.

The delta covers Performance score, LCP (largest contentful paint), CLS, TBT (total blocking time), and FCP (first contentful paint): tag-off, tag-on, and the difference, side by side.

A run can come back not comparable, in which case no delta is shown and you get a message explaining why, instead of a number to second-guess:

• Google's own measurement came back incomplete. PSI/Lighthouse occasionally fails to resolve a metric like LCP on an otherwise ordinary page, a known Lighthouse limitation, not something about your storefront specifically. One retry absorbs this before the run gives up on that side.
• The tag-on/tag-off pairing itself looks broken: the tag-on side shows no evidence of the tag's own requests, the tag-off side still shows them (the kill switch didn't suppress it), the two sides returned different HTTP statuses, or their total page weight differs by more than about 10%. Any of these means the two runs weren't measuring equivalent pages, so the comparison is discarded rather than published.

Real-world field data (CrUX)Copy Anchor Link

Separately from the lab delta (its own tab, shown even when the lab delta wasn't comparable), the same run also pulls the storefront origin's history from Google's Chrome UX Report (CrUX): real Chrome users' own LCP, CLS, INP, and TTFB, reported as 75th-percentile ("p75") weekly figures (a percentile, not an average, and not isolated to the tag's effect): this is your whole page's real-world experience with the tag included, not a delta. The most recent week's four figures are highlighted first, followed by a table of every available week, most recent first. If your storefront doesn't have enough real Chrome traffic yet for Google to report on, you'll see "No field data available for this URL yet" instead of a guess. The field-data half of a run is best-effort and never fails the run itself.

Reproduce it on your own pageCopy Anchor Link

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log(entry.value, entry.hadRecentInput, entry.sources)
  }
}).observe({ type: 'layout-shift', buffered: true })

iadvize('set', { backdrop: true })