Dlaczego przeglądarki co rok stają się cięższe

Izolacja wszystko pomnożyła

Od wzmocnień epoki Spectre Chromium uruchamia każdą witrynę we własnym procesie, a Firefox poszedł śladem z własnym podziałem per witryna. Sesja z piętnastoma kartami i kilkoma rozszerzeniami to bez trudu dwadzieścia pięć procesów i licząc — przeglądarka, proces GPU, usługa sieciowa i jeden renderer na witrynę. Izolacja witryn to naprawdę solidna ochrona: przejęty renderer nie sięgnie po dane innej strony. Ale każdy proces płaci pełną cenę za stos renderujący, więc te same piętnaście kart, które w 2014 roku dzieliły jeden proces, dziś piętnaście razy płaci wstęp.

Rozszerzenia to też procesy. Od Manifestu V3 działają jako sterowane zdarzeniami service workery: budzą się, gdy ich reguły tego wymagają, i trzymają skrypty zawartości wstrzykiwane do każdej otwieranej strony. Tuzin „małych” rozszerzeń waży w pamięci jak kilka dodatkowych kart, a jedno rozwydrzone potrafi zjeść więcej niż wszystkie razem. Wbudowany menedżer zadań Chrome (Shift+Esc) pokazuje koszt każdej karty i każdego rozszerzenia z nazwami — pięć minut tam bije każdą ogólną poradę.

Platforma potrafi tylko rosnąć

Przeglądarka wysyła każdemu ten sam plik binarny i niesie wszystko, co potrafi współczesny web: WebGPU, WebAssembly, WebRTC, WebCodecs, service workery, instalowalne aplikacje. Usuwanie funkcji jest praktycznie niewykonalne — gdzieś jakiś bank albo intranet wciąż zależy od API z 2013 roku — więc silnik wyłącznie się rozrasta. Każda wersja aktualizuje też w tle swoje komponenty: kodeki, stos sieciowy, listy bezpiecznego przeglądania; przeglądarka, której wczoraj nie zrestartowałeś, wypatchowała się trzy razy sama z siebie.

Same strony przybrały na wadze w równie szybkim tempie. Przeciętna strona wysyła megabajty JavaScriptu, zanim pokaże się treść, reklamy i analityka jadą na gapę, a „lekki” serwis informacyjny bez trudu ładuje sto skryptów. Przeglądarka nie ukrywa, czyj ciężar niesie — otwórz wbudowany menedżer zadań i porównaj stronę dokumentacji ze sklepem internetowym. Silnik rzeczywiście stawał się cięższy, ale ładunek rósł szybciej.

• Pełny silnik JavaScript z JIT — kompilator kosztuje każdy proces, nie tylko strony pełne skryptów
• Kompozycja GPU i kodeki — każdy renderer niesie swoją część graficznego potoku
• Service workery — witryny trzymają logikę działającą w tle, bez widocznej karty
• Instalowalne PWA — aplikacja webowa dostaje własne środowisko, nieodróżnialne od małej przeglądarki
• Rozszerzenia — po procesie na sztukę, plus skrypty zawartości wstrzykiwane do każdej strony

Co realnie obniża rachunek

Uczciwy pierwszy krok to usypianie kart — i jest wbudowane: uśpione karty Edge zamrażają karty w tle według timera, którym sterujesz sam, a Memory Saver w Chrome wyładowuje nieaktywne karty i przywraca je kliknięciem. Oba mechanizmy odzyskują realną pamięć i oba pozwalają przypiąć wyjątki dla witryn, które mają być zawsze żywe. Drugi krok to audyt rozszerzeń: usuń te, których nie rozpoznajesz, wyłącz te, z których korzystasz raz na tydzień zamiast co godzinę, i porównaj liczby w menedżerze zadań przed i po.

Co nie działa: polowanie na „lekkie” przeglądarki. Wszystko, co jeździ na tym samym silniku, niesie tę samą architekturę wieloprocesową i ten sam ciężar platformy — wymieniasz kompatybilność albo aktualizacje bezpieczeństwa na błąd zaokrąglenia. Stare forki na porzuconych silnikach są gorsze niż ciężkie: to niełatajana powierzchnia ataku. Więcej RAM-u to nieszlachetna naprawa, ale jako jedyna trzyma się linii trendu — przeglądarka to system operacyjny dla sieci, a nikt nie jeździ systemem operacyjnym na minimalnej specyfikacji.

Pytania i odpowiedzi

Przeczytaj także