eBay recently reported a positive business outcome by using WebAssembly to deliver a barcode scanning feature to its mobile web users. The Draft Completion Rate for sellers’ listings increased by 30% by porting the in-house C++ scanning library to WebAssembly, and using it concurrently with two competing solutions.
eBay decided to experiment with WebAssembly to offer its mobile users the ability to automatically fill in data required in its selling flow, by scanning a product UPC barcode. The productivity improvement resulting from eschewing the overhead linked to manual data entry is important in e-commerce, as it may translate into an improved bottom-line. In a blog post, eBay explains:
Though there are many use cases and applications that would benefit from WebAssembly, the scope of the technology within ecommerce is still primitive.
At eBay, when we evaluate new technologies, the first question we ask is: What potential value does this add to our customers?
(…) we just did not have the right use case. Well, that changed […].
While the barcode scanning feature was already available in both Android and iOS as part of a native app, the feature was not enabled for eBay mobile web users. As eBay describes:
We already have a well-optimized selling flow for the mobile web, except that the barcode scanner was not available […], thus adding […] friction.
eBay ported its in-house C++ barcode scanning library with WebAssembly by compiling the library using Emscripten. The solution involved a Worker thread which imports the generated JavaScript glue code generated by Emscripten and instantiates the generated .wasm file. The main thread sends a camera snapshot to the worker, which calls the wasm API and returns a response. The response can either be the UPC string (passed to a backend service which, in turn, fills out the listing) or an empty string if no barcode is detected. If no barcode is detected, the procedure is repeated until either a barcode is eventually detected or a configurable timeout expires. If a timeout occurs, it may result either from the user not focusing on a valid barcode, or from a lack of accuracy of the barcode scanner.
While the WebAssembly port resulted in significantly faster processing than the two-year old BarcodeReader in-house JavaScript implementation used as a benchmark, the accuracy was disappointing. As eBay details:
In our testing, the WebAssembly implementation performed at an astonishing 50 FPS on an average. However, it worked only 60% of the time with the current timeout threshold. […] the JavaScript implementation that we tried earlier performed only at 1 FPS.
After multiple investigations, eBay eventually reached a final implementation which reaches near perfect accuracy, by running in parallel in three worker threads its 50 FPS WebAssembly port, its slower 1FPS BarcodeReader library, and a 15 FPS WebAssembly port of the open source barcode reader ZBar. Observations revealed that what any two libraries failed to decipher, was successfully recognized by the third library.
Final tests reported a 30% increase in the Draft Completion Rate for the listing flows with a barcode scanner enabled. The ZBar port contributed to 53% of successful scans, the in-house C++ port to 34%, and the BarcodeReader JavaScript library to 13%.
eBay concludes:
The whole WebAssembly journey was a great learning experience for us. Engineers get pretty excited about new technologies and immediately want to try them out. Every day we hear new things getting launched. But only a few make a difference to customers, and WebAssembly is one of them. Our biggest learning from this exercise — “Saying “No” to 99 things and “Yes” to the one thing that really matters to our customers.”
Senthil Padmanabhan, from eBay, mentions the possibility that eBay would open source the resulting barcode scanning library.
A reddit user asked whether an alternative WebAssembly-free implementation, which consists of running directly on Chrome’s V8 the Emscripten JavaScript compiled code, was investigated. Padmanabhan answers that a significant factor behind choosing WebAssembly was its being a standard supported by all browsers.
The full blog post contains additional details on eBay experimentation with WebAssembly, the process followed through the port, and the architecture retained for the final implementation.
