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 our large assets. This feature is enabled by default and is available out of the box for our integrators.
We use browser’s Cache Storage, which 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.
In browsers, this type of storage is persisted per domain - so on a different domain, it would be re-downloaded per browser profile (the work/personal profile picture used to sync bookmarks and similar items)
| There might be different cache controls implemented in custom browsers or operating systems, however our expectation is that our integrators would not experience frequent downloads for the largest assets. |
Choosing appropriate CDN
The SDK parameters provide anylinePath parameter which allows integrators to choose the best option for hosting the assets. It could be a public or corporate CDN, or on-premise hosting when bypassing firewall restrictions would speed up the fetching.
Preloading
In low-network conditions the initial loading of assets, before saving to browser cache, will still need the amount of time that is noticeable for the user. For such cases, the library provides preload() function which can be called in advance. The preload() function needs preload: true to be passed to initialization parameters.
Make sure to call preload() early enough in the flow. This implies that the scanner element also needs to be in the dom, with visibility: hidden (not display:none or opacity:0)
|
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 pause(). You can then simply call resume() function once the scanner is displayed to the user.
User will get prompted to give camera permission, and the camera will be activated, though due to pause() call, scanning will not start
|