Optimizing performance

For mobile SDKs, scan engine and models are bundled in the application. This naturally is not possible on the web, which means that assets are downloaded on-demand over the network.

We already have separation and caching in place for the assets, and this page explains their working mechanism, along with further functionality and design guidelines for use cases and devices where additional optimizations are necessary.

Solutions

Caching

In version 53.4.0, we introduced caching for large assets. This feature is enabled by default and is available out of the box for our integrators.

We use the browser’s Cache Storage, which typically persists across browser restart, system reboot, and session storage/local storage change.

We only invalidate the cache if the version of Anyline SDK changes, or the custom anylinePath parameter is changed. This means that if the user is manually or automatically signed out on a website, and the same or a different user signs in, by default Chrome functionality, the cache would still be available. The cache is skipped for the advanced barcode engine because those assets are encrypted and delivered dynamically.

In browsers, this type of storage is persisted:

Per origin (different domains require a fresh download)
Per browser profile (work/personal profiles keep separate caches)

Advanced barcode engine assets are not cached. Cache eviction is also controlled by the browser, so users can still lose cached assets due to storage pressure or manual site-data clears.

If you need to disable caching, set enableCaching: false in the initialization parameters.

Choosing appropriate CDN

The SDK parameters provide anylinePath, which allows integrators to choose the best option for hosting the assets. It can be a public CDN, a corporate CDN, or on-premise hosting when bypassing firewall restrictions speeds up fetching.

Preloading

In low-network conditions the initial loading of assets, before saving to browser cache, will still be noticeable to the user. For such cases, the library provides preload() which can be called in advance. The preload() function requires preload: true in the initialization parameters.

Make sure to call preload() early enough in the flow. The scanner element must be present in the DOM and have layout size. Hiding it with visibility: hidden or moving it off-screen keeps it measurable; display: none collapses it to zero size and should be avoided.

Low-performance devices

In cases when initialization of the scanner after preloading needs to be sped up, a workaround is to start scanning in advance, a few seconds before your application is supposed to open the scanner, and immediately call pauseScanning(). You can then simply call resumeScanning() function once the scanner is displayed to the user.

The browser will request camera permission and activate the stream during the warm-up phase. Because scanning is paused right away, frames are not processed until you resume.