Shipping WASM codecs without the bloat
A WebAssembly codec can weigh several megabytes. If we shipped every engine up front, a fast local converter would turn into a slow, heavy website before you even picked a file.
So Convertur treats each codec as something a task needs at run time. The server renders the page that explains the tool. Then the browser downloads only the code and engine for the job you actually start.
Load nothing until it's needed
The landing page ships no codecs at all. Each decoder lives in its own chunk that loads with a dynamic import. The browser fetches it only when you open a tool that uses it.
That keeps the most common visit, someone landing on the site, as light as a static page.
Trim the build
When we maintain a codec build for the browser, we can shrink it. Size-focused compiler settings help. So does removing debug info and turning off features we don't use. A task that only decodes doesn't need every encoder, command-line option or container the upstream project supports.
Prebuilt third-party modules give us less control. There, the tools we have are code splitting per route, reading the bundle output and avoiding two copies of the same library. Build reports show these costs even when we can't recompile a library ourselves.
Cache aggressively
Versioned engines and fingerprinted bundles can use long-lived immutable caching. When the content changes, its URL changes. When it doesn't, the browser reuses its local copy without checking with the server each visit.
Some larger engines load from a same-origin object store and are cached on purpose. Some tools also offer an optional offline cache. Neither one lasts forever. You can clear site storage, and browsers may evict it when space runs low.
Keep the server-rendered page useful
Lazy loading shouldn't turn the first page view into an empty spinner. Convertur renders the tool title, description, instructions, related tools and FAQ before the browser-only workspace loads. Search engines and people on slow devices can read the page without downloading a codec.
The interactive workspace shows a small placeholder while its module loads. That split also keeps browser-only APIs and large engine imports out of the Cloudflare Worker bundle that renders pages on the server.
Move heavy work off the main thread
Download size is only half of how fast a tool feels. Once a module arrives, decoding and encoding can hog the main thread. Then progress bars freeze and cancel buttons stop working. Web Workers move that work aside so the page can keep drawing and responding to input.
Workers have costs. Inputs may need to be copied or transferred. Progress messages add overhead. Stopping a worker throws away its memory. Workers pay off most for long codec jobs. Small native browser operations can be faster without them.
Measure the path a visitor takes
One homepage score can't describe every converter. We look at the first page bundle, the workspace chunk, the engine download, the time until a conversion can start and how responsive the page stays while a typical file is processed.
Those numbers change with the format, device, cache state and network. We test first visits and repeat visits separately. That shows whether a change helps first use, repeat use or both. It also stops a fast landing page from hiding a slow tool page.