大多数免费的在线图像工具的工作方式相同：你将文件上传到他们的服务器，服务器处理它，然后你下载结果。这种模式构建简单，但带有隐藏成本——你的隐私、他们的服务器账单，以及文件大小和吞吐量的限制。
ToolBox Image 采用了不同的方法。整个应用程序——解码、编码、压缩、调整大小、格式转换——都在你的浏览器中运行。没有需要上传的服务器。你的图像永远不会离开你的设备。这种架构是一个深思熟虑的选择，它塑造了我们对产品做出的每一个决定。
为什么采用浏览器优先的方法？
显而易见的替代方案是传统的服务器端架构。你上传一张图片，服务器通过 ImageMagick 或 Sharp 等工具处理它，然后发回结果。这很有效，但它带来了一系列难以解决的问题：
- 隐私。用户必须相信你不会存储、分析或泄露他们的图像。对于敏感文件——医学图像、设计稿、个人照片——这种信任很难赢得。
- 成本。每次压缩都在你的基础设施上运行。你越成功，支付的就越多。这带来了限制文件大小、添加队列或引入付费层的压力。
- 延迟。通过慢速连接上传 100 MB 的文件需要几分钟才能开始处理。对于连接性差地区的用户，该工具实际上无法使用。
- 扩展。单个服务器可以处理数十个并发压缩。但如果是数千个呢？你需要自动扩展组、负载均衡器、CDN 上传端点——所有这些都增加了复杂性和成本。
浏览器优先模型一次性解决了所有这些问题。处理是免费的（用户的 CPU 周期）、私密的（没有数据离开设备）并且无限可扩展（每个用户自带硬件）。
实现方式：WebAssembly 和 Web Workers
十年前，在浏览器中运行图像编解码器是不可能的。今天，WebAssembly 让我们可以将 C 和 Rust 库直接编译成浏览器可以以接近原生速度执行的格式。我们将 Mozilla 的 mozJPEG、Google 的 libwebp 和 libaom AVIF 编码器——全部用 C 编写——编译成 WebAssembly。浏览器运行它们的效率就像它们原生安装一样。
但单线程编码对于大批量处理来说很慢。这就是 Web Workers 发挥作用的地方。每个 Worker 在独立的 CPU 核心上运行，我们根据设备的核心数量生成相应数量的 Worker。在具有 8 个核心的现代笔记本电脑上，这意味着 8 张图片同时压缩。在单线程上需要几分钟的 200 张照片批次在几秒钟内完成。
我们放弃的东西
浏览器优先的方法并非没有代价。最重要的权衡是内存。浏览器标签页可以访问设备的 RAM，但一个标签页因为图像超出可用内存而崩溃是一种糟糕的体验。我们将单个文件限制在 100 MB，批次大小限制在 200 个文件，以保持在安全范围内。
我们还放弃了服务器端功能，如持久存储、电子邮件投递和分析。没有压缩图像的数据库，没有电子邮件通讯，没有跟踪用户偏好哪种格式。这在哲学上与我们的隐私立场一致，但意味着我们不能提供"最近压缩"或"会话间保存预设"等功能。
下一步计划
浏览器正在成为性能敏感型应用的合法运行环境。随着 WebAssembly 获得垃圾回收、多线程和 SIMD 支持，更多的应用程序堆栈可以转移到客户端。我们正在探索 WebGPU 以实现更快的像素处理，以及文件系统访问 API 以实现无缝的文件夹集成。
目前，压缩器已上线并每天处理数千张图像——所有这些图像都留在它们该在的地方。