The JavaScript/WebAssembly code in this library weighs just under 8 KB if served with Brotli compression. It's tested on current versions of Firefox, Chrome, Edge, and Safari. This should work on any moderately recent browser. For example, new xzwasm.XzReadableStream(compressedResponse.body). Note: If you're using a tag to reference xzwasm, you probably need to prefix XzReadableStream with xzwasm. The API is designed to be as JavaScript-standard as possible, so XzReadableStream is a ReadableStream instance, which in turn means you can feed it into a Response, and in turn get a blob, an ArrayBuffer, JSON data, or anything else that you browser can do with a Response. arrayBuffer(): const text = await decompressedResponse. body ) ) // We now have a regular Response object, so can use standard APIs to parse its body data, // such as. Installation Option 1: As an NPM packageĬonst compressedResponse = await fetch ( 'somefile.xz' ) const decompressedResponse = new Response ( new XzReadableStream ( compressedResponse. It's also a good demonstration of how a technology like WebAssembly can effectively extend the capabilities of a browser. But it would be nice if browsers supported XZ natively. In most applications the added complexity of XZ via a custom decompressor library won't be worth the small bandwidth saving. XZ can be 5-10x faster to compress than Brotli, especially at the highest compression level. Or, if you care a lot about compression (not decompression) speed.Or, if you're serving very large bundles of bytecode.If the best available alternative is Gzip.So, you would only benefit from using XZ: wasm file from above takes my browser 21ms to decompress if served as Brotli, or 69ms if served as XZ and decompressed with xzwasm. In part that's because of the overhead of WebAssembly vs pure native code, but in part is inherent to the algorithms. Decompressing XZ content takes more CPU time than decompressing Brotli.Using this xzwasm library adds slightly under 8KB to your site (assuming it's served minified and Brotli-compressed). You have to bundle your own decompressor.The main drawbacks to using XZ in the browser are: dll files) better than BrotliĮxample, in each case using the highest available compression level: Scenario XZ (or rather, the underlying LZMA2 algorithm) is not so oriented around text content and - in my experiments - usually compresses bitcode (e.g., WebAssembly.Brotli is based around a large dictionary of web-related text snippets, and usually outperforms XZ for text-based content (e.g., HTML, JS, CSS, WOFF, etc.).Skip to: Installation or How to use Why would anyone do this?Īlthough Brotli is an excellent general-purpose compression algorithm, there are some kinds of data for which XZ gives better compression ratios. It's an alternative to Gzip or Brotli compression for HTTP responses. You can use this if you want your web server to return XZ-encoded content and have your JavaScript code see the uncompressed data. This is a browser-compatible NPM package that can decompress XZ streams. Xzwasm - XZ decompression for the browser
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |