I'm a bit of a noob when it comes to all this (Base64-encoded WASM especially). I was just curious about the actual size impact, or will it vary? Will there be any memory impact for lower-end devices?

I don't really know the impact, here is what Claude said which seemed sensible:

Base64 encoding has a fixed overhead of approximately 33% increase in size. This is because Base64 converts every 3 bytes of binary data into 4 ASCII characters (encoding 6 bits per character instead of 8 bits per byte).
So if your WASM binary is 1 MB, the Base64-encoded version will be roughly 1.33 MB.

For memory impact it said:

Memory Impact
This is where it gets more interesting for lower-end devices. When you load Base64-encoded WASM, you're looking at a memory sequence like:

• Base64 string in memory — the full 1.33x sized string
• Decoded ArrayBuffer — the original binary size (these briefly coexist during decoding)
• Compiled WebAssembly.Module — browser-optimized representation
• Instantiated module — runtime memory for the actual execution

Steps 1 and 2 create a brief spike where you're holding ~2.33x the original binary size in memory simultaneously before the string can be garbage collected.

A few other points worth considering:

• Client Side Media(CSM) processing is a relatively heavy operation that won't work well on low powered devices. Once we determine device capability requirements, we can skip CSM for those clients
• Should the device be underpowered (and not detected as sunch) and the processing times out, we can fall back to the server
• My hunch is the vast of desktop computers used to edit WordPress sites will have no trouble with the requirements, only lower end phones would fail (or maybe very low powered devices like Chromebooks)

Thanks for confirming @adamsilverstein

Once we determine device capability requirements, we can skip CSM for those clients
...
My hunch is the vast of desktop computers used to edit WordPress sites will have no trouble with the requirements

Sounds good 👍🏻