Як працює стиснення файлів на боці клієнта
Як FileShrinking стискає зображення, відео та PDF у вашому браузері через WebAssembly та Web Workers — і чому файли лишаються приватними.
Коли ви стискаєте фото або зменшуєте PDF на більшості вебсайтів, ваш файл здійснює подорож туди й назад: він завантажується на сервер, обробляється в якомусь центрі обробки даних, і вам надсилається менша версія. Це працює, але означає, що копія вашого приватного файлу на мить опиняється на комп’ютері, який ви не контролюєте. FileShrinking використовує інший підхід — кожен байт стиснення відбувається всередині вкладки вашого власного браузера, і ваші файли ніколи не залишають ваш пристрій. Ця стаття пояснює, як саме це можливо, які технології браузера це забезпечують, а також чесні компроміси, що з цим пов’язані.
Два способи стиснути файл у вебі
Традиційна модель — це на боці сервера. Ваш браузер надсилає оригінальний файл через мережу; бекенд, що запускає інструмент на кшталт ImageMagick або FFmpeg, виконує важку роботу; результат передається назад. Машина користувача майже не напружується, а сервер може бути надзвичайно потужним. Ціною є приватність і довіра: ваші дані передаються, вони залишаються (навіть тимчасово) на чужому диску, і вам доводиться вірити на слово щодо того, що з ними станеться згодом.
Новіша модель — це на боці клієнта. Ті самі алгоритми стиснення виконуються безпосередньо на вашому пристрої, у браузері, без жодного етапу завантаження. Роками це було непрактично — самого JavaScript було надто повільно, щоб запускати серйозний кодек зображень чи відео з прийнятною швидкістю. Це змінилося, коли браузери отримали здатність виконувати скомпільований, майже нативний код у вебі. Сьогодні сучасний ноутбук чи телефон може робити роботу, яка раніше вимагала сервера, і FileShrinking повністю побудований на цій моделі.
WebAssembly: справжні кодеки, що працюють у браузері
Технологія, яка робить стиснення на боці клієнта життєздатним, — це WebAssembly (часто скорочується до Wasm). Це компактний двійковий формат інструкцій низького рівня, який браузери можуть виконувати зі швидкістю, наближеною до нативного коду. Що важливо, він дозволяє розробникам брати кодеки, написані мовами C, C++ чи Rust (і вдосконалювані десятиліттями), та компілювати їх для роботи у вебі без переписування їх на JavaScript.
Саме так ті самі перевірені часом рушії стиснення, які ви знайшли б у професійному настільному програмному забезпеченні, опиняються у вкладці браузера:
- MozJPEG для високоякісного кодування JPEG, що вичавлює більше з кожного кілобайта.
- OxiPNG для оптимізації PNG без втрат.
- libwebp та кодувальники AVIF для сучасних форматів WebP та AVIF.
- FFmpeg, скомпільований у WebAssembly, для перекодування та зменшення відео.
Для глибшого технічного довідника документація WebAssembly від MDN є канонічним джерелом щодо того, як працює формат і чому він швидкий.
Web Workers: підтримання чутливості сторінки
Стиснення обчислювально важке. Якби ви запустили перекодування відео в головному потоці браузера, уся сторінка б зависла — кнопки перестали б реагувати, прокручування б смикалося, а смуги прогресу зависли б. Щоб цього уникнути, FileShrinking виконує роботу в окремому потоці за допомогою Web Workers.
Web Worker — це фоновий контекст JavaScript, що виконується паралельно з інтерфейсом користувача. Головний потік передає файл (і кодек Wasm) воркеру, воркер опрацьовує стиснення і відправляє готовий результат назад, коли завершує. Тим часом інтерфейс залишається плавним і може показувати прогрес у реальному часі. Посібник MDN з використання Web Workers детально розглядає модель передавання повідомлень. Великі двійкові дані можна ефективно переміщувати між потоками за допомогою переданих об’єктів, тож файлу не доводиться копіюватися байт за байтом лише для того, щоб перетнути межу між потоками.
Читання та декодування файлів без мережі
Перш ніж щось можна стиснути, браузер має зчитати ваш файл у пам’ять і декодувати його. Це спирається на невелику родину стандартних вебових API, жодне з яких не передбачає сервера:
- API File та Blob представляють файл, який ви обираєте чи перетягуєте. Вони надають необроблені байти як
ArrayBuffer, над яким кодеки можуть працювати безпосередньо — усе в пам’яті. - createImageBitmap ефективно декодує зображення у форму, готову до обробки, і може робити це поза головним потоком.
- OffscreenCanvas дозволяє браузеру малювати, змінювати розмір та перекодовувати дані зображення всередині воркера, жодного разу не торкаючись видимої сторінки.
У сукупності конвеєр виглядає так: ви кидаєте файл, браузер зчитує його байти локально, воркер декодує його, кодек Wasm перекодовує його з обраною вами якістю, і вам повертається новий Blob для завантаження. Файл нікуди не подорожує в жоден момент. Якщо вам цікаві рішення щодо якості на цьому етапі перекодування, наш посібник про стиснення з втратами проти стиснення без втрат пояснює, що насправді відкидається і чому.
Чому це справді приватніше
Перевага приватності моделі на боці клієнта — це не маркетинговий слоган, а пряме наслідок архітектури. Оскільки ваш файл лише зчитується в локальну пам’ять і перекодовується на вашому пристрої:
- Нічого не передається. Завантаження немає, тож немає ані копії вашого файлу під час передавання, яку можна перехопити, ані копії, що зберігається на сервері, яку можна зламати, продати чи витребувати за судовим рішенням.
- Це працює офлайн.Щойно сторінка та її кодеки Wasm завантажилися, ви можете повністю від’єднатися від інтернету, і інструменти продовжуватимуть працювати. Це найпростіший доказ того, що жодного завантаження не відбувається — ви можете переконатися в цьому самі у вкладці мережі вашого браузера.
- Немає чого зберігати.Коли ви закриваєте вкладку, дані файлу зникають з пам’яті. Немає серверних журналів, які пов’язували б ваші документи з вашою особистістю.
А оскільки FileShrinking повністю з відкритим кодом за ліцензією MIT, вам не доводиться сприймати ці твердження на віру. Будь-хто може прочитати код, підтвердити, що немає шляху для завантаження, і перевірити, як саме поводиться конвеєр стиснення. Приватність, яку можна перевірити, — найнадійніша.
Чесні компроміси
Стиснення на боці клієнта — не магія, і чесно бути відвертими щодо того, де серверна модель усе ще має переваги:
- Швидкість на дуже великих завданнях. Центр обробки даних може кинути на довге відео значно більше ядер, ніж є у вашого ноутбука. Для більшості зображень та коротких кліпів різниця непомітна, але повнометражне відео стискатиметься в браузері повільніше, ніж на серверній фермі.
- Обмеження пам’яті.Усе відбувається в оперативній пам’яті вашого пристрою. Надзвичайно великі файли — скажімо, відео на кілька гігабайтів на телефоні з малою кількістю пам’яті — можуть упертися в стелю пам’яті браузера, чого не сталося б на сервері.
- Вартість першого завантаження. Кодеки Wasm потрібно завантажити, коли ви вперше використовуєте інструмент. Після цього вони кешуються, тож наступні відвідування миттєві, але саме перший запуск сплачує одноразове завантаження.
Для переважної більшості повсякденних завдань — оптимізації фото для вебу, обрізання PDF до розміру для електронної пошти, зменшення запису екрана — ці компроміси легко того варті, і ви отримуєте приватність безкоштовно.
Переконайтеся самі
Найкращий спосіб зрозуміти стиснення на боці клієнта — це скористатися ним. Спробуйте компресор зображень, компресор відео чи компресор PDF — а потім відкрийте інструменти розробника вашого браузера, понаблюдайте за вкладкою мережі й переконайтеся, що нічого не завантажується, поки ваш файл зменшується. Усе виконується локально, код відкритий для будь-кого, хто захоче його перевірити, а ваші файли залишаються саме там, де їм і місце: з вами.