ToolBox Image — Почему мы создали ToolBox Image для работы полностью в вашем браузере
Обзор архитектуры, лежащей в основе набора инструментов для работы с изображениями, ориентированного на конфиденциальность — и почему браузер оказался правильным выбором.
Большинство бесплатных онлайн-инструментов для работы с изображениями работают одинаково: вы загружаете файл на их сервер, сервер обрабатывает его, и вы скачиваете результат. Эту модель просто создать, но у неё есть скрытые затраты — ваша конфиденциальность, счета за сервер и ограничения на размер файлов и пропускную способность.
ToolBox Image использует другой подход. Всё приложение — декодирование, кодирование, сжатие, изменение размера, конвертация форматов — работает в вашем браузере. Нет сервера для загрузки. Ваши изображения никогда не покидают ваше устройство. Эта архитектура была осознанным выбором и повлияла на каждое решение, которое мы приняли о продукте.
Почему подход с优先тетом браузера?
Очевидная альтернатива — традиционная серверная архитектура. Вы загружаете изображение, сервер обрабатывает его с помощью инструмента вроде ImageMagick или Sharp и отправляет результат обратно. Это работает, но создаёт ряд проблем, которые трудно решить:
- Конфиденциальность. Пользователи должны доверять, что вы не будете хранить, анализировать или разглашать их изображения. Для конфиденциальных документов — медицинских снимков, дизайн-макетов, личных фото — это доверие трудно заслужить.
- Стоимость. Каждое сжатие выполняется на вашей инфраструктуре. Чем больше у вас успех, тем больше вы платите. Это создаёт давление, чтобы ограничивать размеры файлов, добавлять очереди или вводить платные тарифы.
- Задержка. Загрузка файла размером 100 МБ через медленное соединение занимает минуты до того, как начнётся обработка. Для пользователей в регионах с плохим подключением инструмент практически непригоден.
- Масштабирование. Один сервер может обрабатывать десятки одновременных сжатий. Но что насчёт тысяч? Вам нужны группы авто scaling, балансировщики нагрузки, конечные точки CDN — всё это добавляет сложность и стоимость.
Модель с优先тетом браузера решает всё это сразу. Обработка бесплатна (циклы CPU пользователя), конфиденциальна (никакие данные не покидают устройство) и бесконечно масштабируема (каждый пользователь приносит своё оборудование).
Как это работает: WebAssembly и Web Workers
Десять лет назад запуск кодеков изображений в браузере был невозможен. Сегодня WebAssembly позволяет нам компилировать библиотеки C и Rust напрямую в формат, который браузер может выполнять с почти нативной скоростью. Мы компилируем mozJPEG от Mozilla, libwebp от Google и кодировщик AVIF libaom — все написанные на C — в WebAssembly. Браузер выполняет их так же эффективно, как если бы они были установлены нативно.
Но однопоточное кодирование медленно для больших пакетов. Здесь на помощь приходят Web Workers. Каждый worker работает на отдельном ядре CPU, и мы создаём столько workers, сколько ядер у устройства. На современном ноутбуке с 8 ядрами это означает 8 изображений, сжимающихся одновременно. Пакет из 200 фотографий, который на одном потоке занял бы минуты, завершается за секунды.
От чего мы отказались
Подход с приоритетом браузера не бесплатен. Самая значительная жертва — память. Вкладка браузера имеет доступ к RAM устройства, но одна вкладка, вылетающая из-за того, что изображение превысило доступную память, — это плохой опыт. Мы ограничиваем отдельные файлы до 100 МБ, а размеры пакетов до 200 файлов, чтобы оставаться в безопасных пределах.
Мы также отказались от серверных функций, таких как постоянное хранение, доставка электронной почты и аналитика. Нет базы данных сжатых изображений, нет новостной рассылки, нет отслеживания того, какие форматы предпочитают пользователи. Это философски согласуется с нашей позицией по конфиденциальности, но означает, что мы не можем предлагать такие функции, как «последние сжатия» или «сохранённые настройки между сессиями».
Что дальше
Браузер становится законной средой выполнения для приложений, чувствительных к производительности. По мере того как WebAssembly получает сборку мусора, многопоточность и поддержку SIMD, всё больше частей стека приложений может перейти на сторону клиента. Мы изучаем WebGPU для ещё более быстрой обработки пикселей и File System Access API для бесшовной интеграции с папками.
Компрессор уже работает и обрабатывает тысячи изображений в день — все они остаются там, где им и место.