Local-first browser tools: where should caching stop?

I’m part of the team building Pixlane Media, so this is a transparent product and architecture discussion, not an independent recommendation.

We are building browser-based image, PDF, OCR and AI-assisted tools around a local-first principle: when a task can run on the device, the user’s file should not need to be uploaded to our servers.

That principle sounds simple until performance enters the conversation.

The trade-off

Loading every WebAssembly module and model up front makes later interactions feel fast, but it turns the first visit into a large download. Loading everything on demand keeps the landing page light, yet the first real action can feel unexpectedly slow.

Caching helps, but it creates another set of questions:

• How long should a processing module remain cached?
• Should a model be retained after a single use on a shared device?
• Is a “clear local data” control enough, or should caches expire automatically?
• Should recent tool choices be remembered without keeping any source or output files?

Our current direction is a layered approach:

1. Keep navigation and lightweight utilities ready.
2. Load heavier WASM modules or AI models only after a tool is selected.
3. Cache reusable code locally, but never silently retain the user’s source files.
4. Make local state visible and easy to clear.

The implementation is only half of the problem. The interface also needs to explain what is happening. A two-second delay with a clear “loading the local engine” state feels very different from a frozen button, even if the elapsed time is identical.

What would you expect?

I would genuinely value feedback from people who build or regularly use browser utilities:

• Would you prefer the fastest possible first page or the fastest first tool run?
• Should the site display the download size before loading a large module or model?
• Would a local cache inspector be useful, or is one clear reset button enough?
• Which tasks deserve preloading: compression, PDF merge, OCR, background removal, or none?

If you test the current site, the most useful feedback is the exact point where an interaction feels slower or less private than you expected. We are using those observations to decide what should be preloaded, cached, or removed from the first screen.