The Squid ID SDK is built to be invisible to your visitors and to your page speed. It loads without blocking, runs its work off your page’s main thread, and keeps its data footprint small. This page covers why it stays out of the way.
If you’re coming from RB2B
A script that runs in the page context competes with your own JavaScript for the main thread. Squid ID moves that work into an isolated iframe.
| RB2B | Squid ID |
|---|
| Load behavior | Async script | Async, never blocks rendering |
| Where work runs | The page’s main thread | An isolated iframe, off your main thread |
| How data moves | Tracking-pixel HTTP fires | A persistent real-time WebSocket stream |
| Data footprint | Varies | Compact signals, not a chatty API client |
| Visible UI | None | None, no layout shift |
Why this matters. Anything you add to a page can slow it down. Squid ID does its work in a separate context and sends little data, so it doesn’t compete with your page for the main thread or the network, and your visitors don’t feel it.
Loads asynchronously
The snippet loads the SDK asynchronously, so it never blocks your page from rendering. Your content paints first, and Squid ID initializes in the background. There is no render-blocking script and nothing for a visitor to wait on.
Runs off the main thread
The actual identification work happens inside the SDK’s isolated iframe, which is a separate execution context from your page. Because that work isn’t running on your page’s main thread, it doesn’t compete with your own JavaScript, so scrolling, clicks, and interactions stay smooth. The iframe talks to your page only through a small postMessage channel, which is cheap.
Light on bandwidth
Squid ID does not run a chatty API client on your page. It sends compact behavioral signals, and the heavier work (matching, enrichment, verification) happens on our servers, not over a stream of requests from the browser. That keeps the data the SDK moves small, which matters most on mobile and slow connections.
Streaming, not a tracking pixel
Most visitor tools work like a tracking pixel: the page fires off a separate request for each event and forgets about it. It is simple, but it means no live view, a steady stream of one-off requests, and all of that happening in your page.
Squid ID opens a single persistent, real-time WebSocket connection from its iframe and streams over it. That one connection is what powers live presence, the green online dots, and watching a session unfold as it happens. It is far more capable than a pixel fire, and because it runs in the isolated iframe off your main thread, it is also gentler on your page than a steady drip of pixel requests would be. The sophistication sits on our side of the connection, not on your page.
The SDK renders nothing on your page. There is no widget, no banner, and no injected UI, so there is no layout shift and nothing that changes how your site looks or behaves for a visitor.
