Follow

How can I optimize loading time?

In order for the end user to access scanning functionality, the Scandit library needs to be downloaded from the server and then initialized in the browser.  The speed with which this can happen is dependent on both the speed of the internet connection (for download of ~1MB library) and on the processing power of the device (for initialization).  

By default, the library is cached in the browser (browser and server permitting) and does not need to be redownloaded to the browser. 

The library is then compiled, cached and loaded into memory to be used.  The library must be loaded from cache on each page where it is to be used.  Depending on the device, the compilation and the loading processes can take some time.  

We recommend the following approaches to minimize perceived waiting time for the user.

Initial load

- Ensure the JavaScript assets and the `scandit-engine-sdk.min.js` and `scandit-engine-sdk.wasm` files are served compressed and with caching enabled by your web server.  (You should serve the files yourself instead of using CDN)

- Load and compile the library as soon as page with scanning functionality is loaded and ideally before the user has requested access to the scanner.   See example_background.html sample included with the npm download.

Hide and show / pause and resume

  - If possible, create a (hidden and paused) `BarcodePicker` in the background and simply resume scanning switching its visibility to "show" when needed instead of creating it on the fly to provide instant scanning capabilities.

- Re-use `BarcodePicker` objects whenever possible by hiding and showing them instead of destroying and recreating them: each object needs to load and initialize the external library on creation.

Distract and obfuscate 

- To avoid any perception of wait time, hide the UI for scanning until the scanner is ready.

- If above are not viable options, animate the loading indicator in an entertaining manner.

 

NOTE 1: these methods are shown in sample_background.html that's downloaded together with the library, as well as with the extended sample that's available on Github.  

NOTE 2: the load time on Firefox is a fraction of the time in Chrome and Firefox due to streaming compile of the library.  We expect that other browsers will eventually implement similar improvements.

NOTE 3: the folks at Chrome are working on Streaming Compile that will make the load time on Android significantly faster, and potentially on par with Firefox.  You can already test the current feature by enabling chrome://flags/#enable-webassembly-baseline.

NOTE 4: For single page webapps, the user experience will be better: after initial loading, the scanner will be readily available on different "pages" of the app, as it doesn't need to be retrieved from memory.

 

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request