Jak działa kompresja plików po stronie klienta (i dlaczego jest bardziej prywatna)

Gdy kompresujesz zdjęcie lub zmniejszasz plik PDF na większości stron internetowych, Twój plik odbywa podróż w obie strony: zostaje przesłany na serwer, przetworzony w jakimś centrum danych, a mniejsza wersja wraca do Ciebie. Działa to, ale oznacza, że kopia Twojego prywatnego pliku przez chwilę żyje na komputerze, którego nie kontrolujesz. FileShrinking podchodzi do tego inaczej — każdy bajt kompresji odbywa się wewnątrz karty Twojej własnej przeglądarki, a Twoje pliki nigdy nie opuszczają Twojego urządzenia. Ten artykuł wyjaśnia dokładnie, jak to możliwe, jakie technologie przeglądarki za tym stoją i z jakimi uczciwymi kompromisami się to wiąże.

Dwa sposoby kompresji pliku w sieci

Tradycyjny model działa po stronie serwera. Twoja przeglądarka wysyła oryginalny plik przez sieć; backend uruchamiający narzędzie takie jak ImageMagick lub FFmpeg wykonuje ciężką pracę; wynik jest przesyłany z powrotem. Maszyna użytkownika ledwie się wysila, a serwer może być ogromnie wydajny. Kosztem są prywatność i zaufanie: Twoje dane są przesyłane, leżą (choćby tymczasowo) na dysku kogoś innego, a Ty musisz wierzyć temu komuś na słowo co do tego, co dzieje się z nimi później.

Nowszy model działa po stronie klienta. Te same algorytmy kompresji uruchamiają się bezpośrednio na Twoim urządzeniu, w przeglądarce, bez żadnego etapu przesyłania. Przez lata było to niepraktyczne — sam JavaScript był zbyt wolny, aby uruchomić poważny kodek obrazu lub wideo z użyteczną prędkością. Zmieniło się to, gdy przeglądarki zyskały zdolność uruchamiania skompilowanego, niemal natywnego kodu w sieci. Dziś nowoczesny laptop lub telefon może wykonać pracę, która kiedyś wymagała serwera, a FileShrinking jest zbudowany w całości na tym modelu.

WebAssembly: prawdziwe kodeki działające w przeglądarce

Technologią, która sprawia, że kompresja po stronie klienta jest wykonalna, jest WebAssembly (często skracane do Wasm). To kompaktowy, niskopoziomowy format instrukcji binarnych, który przeglądarki mogą wykonywać z prędkością zbliżoną do kodu natywnego. Co kluczowe, pozwala on programistom wziąć kodeki napisane w C, C++ lub Rust (i udoskonalane przez dziesięciolecia) oraz skompilować je tak, aby działały w sieci bez przepisywania ich w JavaScript.

Tak właśnie te same sprawdzone w boju silniki kompresji, które znalazłbyś w profesjonalnym oprogramowaniu desktopowym, trafiają do karty przeglądarki:

MozJPEG do wysokiej jakości kodowania JPEG, które wyciska więcej z każdego kilobajta.
OxiPNG do bezstratnej optymalizacji PNG.
libwebp oraz kodery AVIF dla nowoczesnych formatów WebP i AVIF.
FFmpeg, skompilowany do WebAssembly, do transkodowania i zmniejszania wideo.

Aby uzyskać głębszy materiał techniczny, dokumentacja WebAssembly w MDN jest kanonicznym źródłem informacji o tym, jak działa ten format i dlaczego jest szybki.

Web Workers: utrzymywanie responsywności strony

Kompresja jest obliczeniowo wymagająca. Gdybyś uruchomił transkodowanie wideo w głównym wątku przeglądarki, cała strona zamarłaby — przyciski przestałyby reagować, przewijanie by się zacinało, a paski postępu by się blokowały. Aby tego uniknąć, FileShrinking wykonuje pracę w osobnym wątku za pomocą Web Workers.

Web Worker to działający w tle kontekst JavaScript, który uruchamia się równolegle z interfejsem użytkownika. Główny wątek przekazuje plik (i kodek Wasm) do workera, worker przemiela kompresję i odsyła gotowy wynik, gdy skończy. W międzyczasie interfejs pozostaje płynny i może pokazywać postęp w czasie rzeczywistym. Przewodnik MDN po używaniu Web Workers szczegółowo omawia model przekazywania wiadomości. Duże dane binarne można efektywnie przenosić między wątkami za pomocą obiektów przekazywalnych, więc plik nie musi być kopiowany bajt po bajcie tylko po to, by przekroczyć granicę wątku.

Odczytywanie i dekodowanie plików bez sieci

Zanim cokolwiek będzie można skompresować, przeglądarka musi wczytać Twój plik do pamięci i go zdekodować. Opiera się to na niewielkiej rodzinie standardowych interfejsów API sieci, z których żaden nie wymaga serwera:

Interfejsy API File i Blob reprezentują plik, który wybierasz lub przeciągasz. Udostępniają surowe bajty jako ArrayBuffer, na którym kodeki mogą pracować bezpośrednio — wszystko w pamięci.
createImageBitmap efektywnie dekoduje obraz do postaci gotowej do przetwarzania i może to robić poza głównym wątkiem.
OffscreenCanvas pozwala przeglądarce rysować, zmieniać rozmiar i ponownie kodować dane obrazu wewnątrz workera, nigdy nie dotykając widocznej strony.

Razem cały potok wygląda tak: upuszczasz plik, przeglądarka odczytuje jego bajty lokalnie, worker go dekoduje, kodek Wasm koduje go ponownie z wybraną przez Ciebie jakością, a nowy Blob zostaje zwrócony, abyś mógł go pobrać. W żadnym momencie plik nigdzie nie podróżuje. Jeśli ciekawią Cię decyzje dotyczące jakości na tym etapie ponownego kodowania, nasz przewodnik o kompresji stratnej a bezstratnej wyjaśnia, co tak naprawdę jest odrzucane i dlaczego.

Dlaczego jest to naprawdę bardziej prywatne

Korzyść związana z prywatnością w modelu po stronie klienta nie jest marketingowym sloganem — to bezpośrednia konsekwencja architektury. Ponieważ Twój plik jest jedynie wczytywany do pamięci lokalnej i ponownie kodowany na Twoim urządzeniu:

Nic nie jest przesyłane. Nie ma przesyłania, więc nie ma kopii Twojego pliku w tranzycie, którą można by przechwycić, ani kopii spoczywającej na serwerze, którą można by naruszyć, sprzedać lub uzyskać na mocy wezwania sądowego.
Działa offline. Gdy strona i jej kodeki Wasm już się załadują, możesz całkowicie odłączyć się od internetu, a narzędzia nadal będą działać. To najprostszy dowód na to, że nie zachodzi żadne przesyłanie — możesz sam to sprawdzić w karcie sieci swojej przeglądarki.
Nie ma czego przechowywać. Gdy zamykasz kartę, dane pliku znikają z pamięci. Nie ma logów serwera łączących Twoje dokumenty z Twoją tożsamością.

A ponieważ FileShrinking jest w pełni otwartoźródłowy na licencji MIT, nie musisz przyjmować tych zapewnień na wiarę. Każdy może przeczytać kod, potwierdzić, że nie istnieje żadna ścieżka przesyłania, i zweryfikować dokładnie, jak zachowuje się potok kompresji. Audytowalna prywatność jest najsilniejszym rodzajem prywatności.

Uczciwe kompromisy

Kompresja po stronie klienta nie jest magią i warto otwarcie powiedzieć, gdzie model serwerowy nadal ma przewagę:

Szybkość przy bardzo dużych zadaniach. Centrum danych może przeznaczyć na długie wideo znacznie więcej rdzeni, niż ma Twój laptop. W przypadku większości obrazów i krótkich klipów różnica jest niezauważalna, ale pełnometrażowe wideo będzie wolniejsze w przeglądarce niż na farmie serwerów.
Ograniczenia pamięci. Wszystko dzieje się w pamięci RAM Twojego urządzenia. Niezwykle duże pliki — powiedzmy kilkugigabajtowe wideo na telefonie z małą ilością pamięci — mogą natrafić na limity pamięci przeglądarki, których serwer by nie miał.
Koszt pierwszego ładowania. Kodeki Wasm muszą zostać pobrane przy pierwszym użyciu narzędzia. Później są zapisywane w pamięci podręcznej, więc kolejne wizyty są błyskawiczne, ale samo pierwsze uruchomienie wiąże się z jednorazowym pobraniem.

W przypadku przeważającej większości codziennych zadań — optymalizacji zdjęć na potrzeby sieci, zmniejszenia pliku PDF do rozmiaru pozwalającego wysłać go mailem, zredukowania nagrania ekranu — te kompromisy z łatwością są tego warte, a prywatność dostajesz za darmo.

Przekonaj się sam

Najlepszym sposobem na zrozumienie kompresji po stronie klienta jest jej użycie. Wypróbuj kompresor obrazów, kompresor wideo lub kompresor PDF — a następnie otwórz narzędzia deweloperskie swojej przeglądarki, obserwuj kartę sieci i potwierdź, że nic nie jest przesyłane, gdy Twój plik się zmniejsza. Wszystko działa lokalnie, kod jest otwarty, aby każdy mógł go sprawdzić, a Twoje pliki pozostają dokładnie tam, gdzie ich miejsce: u Ciebie.