How Browser-Based Campaigns Drive Engagement With Web AR Face Tracking

[navigation]

Key takeaways

• Banuba Face AR SDK's web build runs in any browser with WebGL 2.0, so one campaign URL covers iOS and Android with no app store step.
• The heaviest Banuba web asset, BanubaSDK.wasm, is 12 Mb uncompressed and 3.5 Mb gzipped or 2.5 Mb with Brotli, which sets how fast the page becomes interactive.
• Banuba's background separation holds a stable 30 FPS on high-end Android and on iOS, so virtual backgrounds stay usable on the phones people scan QR codes with.

Why do browser-based campaigns lose people before the effect loads?

A campaign that asks for an app install loses most of its audience at the store page. The browser removes that step but moves the cost: the page now has to download a computer vision runtime, get camera permission, and start tracking a face before the visitor gives up.

That is what Web AR face tracking is built for: tracking runs in WebAssembly on the visitor's own device, the effect renders through WebGL, and no frame makes a round trip to a server.

Banuba's face tracking example

How does Web AR face tracking solve it?

Browser reach without a build per platform. Banuba Web SDK supports any browser with WebGL 2.0 or higher, on mobile and desktop Chrome, Firefox, and Safari. One campaign page, one URL in the QR code, the same effect on an iPhone and a mid-range Android handset.

Predictable page weight. BanubaSDK.wasm is 12 Mb original, 3.5 Mb gzipped, and 2.5 Mb with Brotli; the SIMD variant is 13, 3.8, and 2.7 Mb. The SDK is tree-shakable, so importing only the modules a campaign uses keeps the JavaScript bundle down too, and the faster SIMD binary loads automatically where supported.

Effects that hold their frame rate. Banuba's background separation runs at a stable 30 FPS on high-end Android and on iOS, and web-side effects such as lip coloring measure 30 FPS in Chrome and 26 FPS in Safari. Lab figures rather than a guarantee for every device, but published.

Processing stays on the device: frames are never uploaded, which is the question Banuba gets most often from teams evaluating a browser experience.

What does the integration look like?

The web build ships as the @banuba/webar npm package. A campaign page creates a Player, attaches a Webcam, loads an Effect, and renders into a Dom target. Bundler config is the step teams miss: the SDK expects BanubaSDK.data and BanubaSDK.wasm at the app root unless locateFile says otherwise.

The Web AR SDK documentation covers requirements and setup, and Banuba publishes runnable starters for vanilla JavaScript, React, Angular, and Vue. For teams weighing a browser build against a native one, this developer's guide to face-based AR works through the same decision from the engineering side.

What did a browser campaign look like in production?

Loncolor, a Romanian hair dye and hair care producer, wanted customers to see a shade on themselves before buying. Scorpion Technology, a Bucharest software company, built the experience on Banuba Face AR SDK rather than its own computer vision code, to ship faster.

The flow is as plain as a browser campaign gets: a customer scans a QR code on the dye package, a page opens in their browser, and once their face is in frame, it shows the chosen color on their hair. That puts try-on into every store carrying the product, with no in-store hardware and no app. The virtual try-on for a Romanian hair color brand write-up covers why the agency picked Banuba: recoloring that affects hair only and holds up across lighting conditions, per-feature licensing, and documentation good enough to integrate against directly. It rolled out in 2025, and usage has grown since; Banuba publishes no conversion figure for this deployment.

Start with a working page, not a spec

The fastest way to size a browser campaign is to run a quickstart against your own creative and time how long the page takes to reach a tracked face on a mid-range phone. Start a free trial of Banuba's Web AR SDK and measure it.