Plazer encrypts private conversations and groups with a Rust core shared with its native apps, shipped to the browser as WebAssembly. Encryption, voice, video effects and server settings add up to a lot of code, so each part arrives only when needed. The figures come from measuring the web version: a cold start in Chromium with the cache off, each file compressed on its own with gzip -9.
What the browser fetches, and when
| Part | Compressed | When |
|---|---|---|
| English sign-in screen, with its font | 105 kB in 24 files | on the first visit |
| Encryption core, start part | 536 kB | on every start after signing in |
| Encryption core, the rest | 239 kB | on password sign-in, registration, pairing a device, private groups and sending in encrypted conversations |
| Blurred or replaced camera background | 3.76 MB: the MediaPipe engine in WebAssembly, its model and the effect's code | when a background effect is first turned on |
The background effect alone weighs 36 times the sign-in screen, and whoever never uses it never downloads a byte.
A split the linker decides
Function names do not decide what moves to the rest. A split script reads the relocations rust-lld leaves with --emit-relocs: calls, function indices in tables and data addresses. A function moves only when no start path reaches it, so a start never runs into missing code. Binaryen's wasm-split then moves those functions, and wasm-opt optimises each part separately. An encrypted conversation's message box starts fetching the rest with the first word typed, so a send rarely waits, and an end-to-end test checks that a start alone never fetches it.
How Plazer was built is in its case study, and custom web apps are on our web apps and PWA page.
Was this post helpful?
