Conversation
Enhanced clarity and corrected minor inaccuracies in the text. It is not finalized yet.
Updated date filters and added new metrics for WebAssembly requests.
Super-linter summary
Super-linter detected linting errors For more information, see the GitHub Actions workflow run Powered by Super-linter EDITORCONFIG |
Super-linter summary
All files and directories linted successfully For more information, see the GitHub Actions workflow run Powered by Super-linter |
Super-linter summary
All files and directories linted successfully For more information, see the GitHub Actions workflow run Powered by Super-linter |
Super-linter summary
All files and directories linted successfully For more information, see the GitHub Actions workflow run Powered by Super-linter |
Super-linter summary
All files and directories linted successfully For more information, see the GitHub Actions workflow run Powered by Super-linter |
src/content/en/2025/webassembly.md
Outdated
| }} | ||
|
|
||
| These WebAssembly modules differ considerably in size, with the smallest being just a few kilobytes, and the largest one is 228.102 MB in desktop's client and 166.415 MB for mobile client. | ||
| When examining uncompressed sizes, we observe that while the median module remains lightweight at approximately 30 KB on both platforms, the largest binaries at the 90th percentile are significantly heavier on desktop (897 KB) than on mobile (756 KB). |
There was a problem hiding this comment.
Is Wasm not typically binary? What compression does it use? Gzip? Brotli? I thought those only really worked on text resources (maybe explaining the relatively low different between these two charts?) and they shouldn't be further compressed for sending on the wire?
There was a problem hiding this comment.
Barry, The Wasm is fundamentally a binary instruction format, not typically a text format. the format sent over the wire is the compact binary format (wasm).
It has built in compression.
It is observed that applying Gzip or Brotli to an already highly optimized binary file yields minimal additional size savings (often less than 10%, sometimes even negligible), Because of the minimal benefit of compression, Barry the Wasm files are typically served with an identity encoding, meaning no further general purpose compression is applied
There was a problem hiding this comment.
Is it worth commenting on this?
At the moment we show raw (which I think should be renamed "compress" as per other conversation to make it more obvious) and uncompressed, but never really explain that it's not really expected for them to be compressed. And that that explains why the charts aren't that different. By presenting both, it's almost like the opposite and we think it is something to be looked at, almost like we expect there to be interesting insights here?
So I went back to the 2021 chapter that we seem to be basing this on and it has this to say:
"...one of the benefits of Wasm bytecode is that it’s highly compressible, and size over the wire is what matters for download speed and billing reasons. Let’s check sizes of raw response bodies as sent by servers instead:"
That's a good narrative for why they included both.
But the 2025 chapter doesn't seem to have a similar narrative and just says "here's the raw bytes, here's the compressed bytes" and I'm not sure what the readers's supposed to take away from that.
Additionally it contradicts what you say about compression (and what I believed too).
Again, as a reader I'm confused as to what to take away from this section?
There was a problem hiding this comment.
Hi Nurullah and Barry,
It seems to resolve this concern and to make it easy to understand,
It would be good to have the compression method chart along with its details.
What do you say, guys ?
There was a problem hiding this comment.
I'm not sure what you mean by that? I'm still very confused here..
There was a problem hiding this comment.
lets talk on slack tomorrow afternoon about this.
Co-authored-by: Barry Pollard <barrypollard@google.com>
Removed redundant sentence from introduction
Super-linter summary
All files and directories linted successfully For more information, see the GitHub Actions workflow run Powered by Super-linter |
Super-linter summary
All files and directories linted successfully For more information, see the GitHub Actions workflow run Powered by Super-linter |
Super-linter summary
All files and directories linted successfully For more information, see the GitHub Actions workflow run Powered by Super-linter |
Updated the data collection section to reflect the identification of WebAssembly modules on sites analyzed.
Super-linter summary
All files and directories linted successfully For more information, see the GitHub Actions workflow run Powered by Super-linter |
please, have the link almanac-wasm-stats Later on We would be raising pull request and will merge the stack under HTTPArchive and enable in the pipeline with the help of Patrick and Barry. |
Super-linter summary
All files and directories linted successfully For more information, see the GitHub Actions workflow run Powered by Super-linter |
tunetheweb
left a comment
There was a problem hiding this comment.
I'm still very confused and not sure this PR make this text any less confusing. Can we address the comments I've raised @nrllh and @nimeshgit ?
src/content/en/2025/webassembly.md
Outdated
|
|
||
| WebAssembly module sizes vary drastically based on their specific use cases. We observed that the bottom 50% of modules are quite small, ranging between 2 KB and 14 KB. These are typically "micro-utilities" like Base64 encoders or checksum calculators, often written in AssemblyScript or Rust to handle performance-critical tasks where JavaScript lacks precision. | ||
|
|
||
| Conversely, at the 90th percentile, sizes increase significantly to 381 KB on desktop and 316 KB on mobile. These larger binaries usually represent full desktop-grade applications ported to the web—such as Adobe Photoshop or Google Earth—compiled from heavier languages like C++ or C# to handle complex 3D rendering and logic. |
There was a problem hiding this comment.
Can we add something like this to the text?
src/content/en/2025/webassembly.md
Outdated
| }} | ||
|
|
||
| These WebAssembly modules differ considerably in size, with the smallest being just a few kilobytes, and the largest one is 228.102 MB in desktop's client and 166.415 MB for mobile client. | ||
| When examining uncompressed sizes, we observe that while the median module remains lightweight at approximately 30 KB on both platforms, the largest binaries at the 90th percentile are significantly heavier on desktop (897 KB) than on mobile (756 KB). |
There was a problem hiding this comment.
I'm not sure what you mean by that? I'm still very confused here..
Removed mention of Microsoft's dominance in WebAssembly ecosystem.
As per the pull request (#4401), enhanced compression methods, data collection and analysis methods, revised statistics on WebAssembly module sizes and usage. Improved clarity on language usage and library dominance in WebAssembly + other minor edits as suggested.
revise language usage that counts duplicates in percentage
we have updated compression methods for both clients desktop and mobile + updated language usage chart with duplicate records counts percentage stats.
|
Images automagically compressed by Calibre's image-actions ✨ Compression reduced images by 80.2%, saving 777.4 KB.
|
|
Barry, we have merged @nrllh updates plus your suggetions and compression methods for desktop and mobile clients along with couple of edits. |
|
Images automagically compressed by Calibre's image-actions ✨ Compression reduced images by 19%, saving 26.4 KB.
1 image did not require optimisation. |
|
Images automagically compressed by Calibre's image-actions ✨ Compression reduced images by 43%, saving 23.8 KB.
2 images did not require optimisation. |
|
Images automagically compressed by Calibre's image-actions ✨ Compression reduced images by 25.9%, saving 16.5 KB.
|
tunetheweb
left a comment
There was a problem hiding this comment.
OK let's merge this.
Thanks for improving the text!
|
Images automagically compressed by Calibre's image-actions ✨ Compression reduced images by 26%, saving 5.8 KB.
3 images did not require optimisation. |
…parchive.org into webassembly-pass
I have edited the chapter. Could you folks please take a look at it and take further adjustments?
@nimeshgit : we still need the tool "almanac-wasm". Can you please provide it to us?