Optimization tips
Most gdal3.js performance work is delivery, not computation: get the wasm to the user once, cheaply, and keep heavy work off the UI thread.
First-load budget
The full v3 build transfers roughly 14 MB gzipped on first use: ~11.5 MB wasm + ~2.2 MB driver/PROJ data. That is the cost of the complete driver registry with the new codecs. Two facts soften it: everything loads lazily at initCppJs() (your routes stay light), and it's a one-time cost per user (see caching).
- Serve with compression (brotli beats gzip here) and far-future cache headers: the files are content-addressed by your bundler.
- Initialise on first user intent (file drop), not on page load.
- A slimmer driver-subset build (
@gdal3.js/wasm-bundle-minimal) is in the works for size-capped platforms: the Cloudflare Pages limit of issue #85 is the canonical case.
Cache it once
After the first visit the wasm and data come from HTTP cache; with a service worker (PWA) they're available offline entirely. There are no runtime calls to any server. See the offline FAQ.
Runtime tips
- One init, many jobs.
initCppJs()is the expensive call: keep the module alive and reuse it. - useWorker for UX. Conversion throughput is the same; your frame rate isn't. Workers guide.
- mt build for big rasters where GDAL parallelises, requires cross-origin isolation headers.
- Batch proxy reads. With
useWorker, each property read crosses the worker boundary; cache descriptors once (the bundled converter caches all driver metadata at boot). - OPFS over /vsimem/ for big inputs: keeps file bytes out of wasm memory (memory guide).
- Close datasets, delete consumed outputs. Wasm memory doesn't shrink back.
Mobile: go native
On iOS and Android the wasm question disappears: gdal3.js runs as a native library over JSI. No 14 MB download (it ships in the app binary), no browser memory ceiling, native-speed execution. If your mobile-web users hit limits, that's the path (issue #96 → React Native support).