Lekcja 17. Optymalizacja

Co eksporter wpycha do pliku i co wolno z tego wyciąć

Otwierasz SVG wyeksportowany z programu graficznego i widzisz trzysta linijek. Otwierasz go w przeglądarce i widzisz trzy kształty. Ta różnica to temat całej lekcji.

Nie chodzi tylko o wagę pliku, choć i o nią. Chodzi o to, że pliku, którego nie da się przeczytać, nie da się też poprawić — a poprawiać będziesz.

Zobacz różnicę

Typowy eksport. Spójrz na licznik bajtów nad edytorem.

Ten sam obrazek, co do piksela. Ponad tysiąc bajtów zeszło do dwustu czterdziestu — bez utraty czegokolwiek widocznego.

Prawie osiemdziesiąt procent tego pliku było balastem. I to jest wynik typowy, nie wyjątkowy.

Co konkretnie leci

Metadane i komentarze. Nazwa programu, wersja, bloki <metadata>, <sfw>, informacje o warstwach. Zero wpływu na obraz.

Atrybuty domyślne. version="1.1", x="0px", y="0px", enable-background, xml:space="preserve". Powtarzają to, co i tak jest domyślne, albo pochodzą ze starych wersji standardu.

Nadmiarowa precyzja. 20.00000000 to 20. Osiem miejsc po przecinku w każdej współrzędnej to zwykle największy pojedynczy zysk w całym pliku, bo współrzędnych są setki. Przy grafice wyświetlanej na ekranie jedno albo dwa miejsca wystarczają z nadmiarem.

Puste i zbędne grupy. <defs></defs> bez zawartości, <g> z translate(0,0), grupy zagnieżdżone w grupach bez żadnego powodu. Program tworzy je z warstw, przeglądarce są niepotrzebne.

Styl dublujący atrybut. fill="#E05C1A" style="fill:#E05C1A;" — dwa zapisy tego samego. Warto pamiętać z poprzedniej lekcji, że przy konflikcie wygra style, więc usuwając nieuważnie ten drugi, można zmienić wygląd.

Wygenerowane identyfikatory. id="Warstwa_1", id="g10", id="rect12". Nikt się do nich nie odwołuje.

Ukryte elementy. Warstwy wyłączone w programie graficznym potrafią wylądować w pliku z display="none". Niewidoczne, a ważą.

Czego nie ruszać

Tu kończy się sprzątanie, a zaczyna psucie.

viewBox — bez niego grafika przestaje się skalować. To najczęstsza szkoda wyrządzona przez automat, bo część konfiguracji usuwa go, gdy uzna za nadmiarowy wobec width i height.

Identyfikatory, do których coś się odwołuje. Gradienty, filtry, maski, <use>, <textPath>. Automatyczne skracanie id potrafi rozjechać te powiązania, zwłaszcza gdy odwołanie siedzi w CSS albo w skrypcie na stronie, a nie w samym pliku.

xmlns — bez niego plik przestaje być SVG-iem dla parsera XML. O tym była mowa przy budowie playgroundu: element bez przestrzeni nazw powstaje poprawnie i nie rysuje się w ogóle.

<title>, <desc> i atrybuty ARIA. To nie są metadane do wycięcia, tylko dostępność. Automat może je uznać za zbędne — nie są.

Grupy niosące transformację albo styl, oraz identyfikatory używane przez animacje.

SVGO

SVGO to standardowe narzędzie przeznaczone do tej roboty, dostępne jako pakiet npm, wtyczka do edytorów i kilka serwisów online ( https://svgo.dev ). Działa na wtyczkach, każdą można wyłączyć.

Cztery, przy których warto uważać:

• removeViewBox — najgroźniejsza. Sprawdź, czy jest wyłączona.
• cleanupIds — skraca i usuwa identyfikatory; przy sprite'ach i odwołaniach z zewnątrz potrafi zepsuć więcej niż pomóc.
• mergePaths — łączy ścieżki w jedną; oszczędza bajty, ale odbiera możliwość animowania fragmentów osobno i miesza fill-rule.
• convertShapeToPath — zamienia <circle> na <path>; mniejszy plik, ale mniej czytelny kod.

Najważniejsze ustawienie to jednak precyzja liczb. Zejście z domyślnych trzech miejsc do jednego albo dwóch zwykle daje więcej niż wszystkie pozostałe wtyczki razem.

Nie ma sensu robić tego ręcznie przy każdym pliku. To co ma sens to spojrzenie na wynik: otworzyć przed i po obok siebie i sprawdzić, czy nic nie zniknęło. Automat nie wie, że ten pusty prostokąt był obszarem klikalnym.

Jeszcze o wadze

Dwie rzeczy, o których warto pamiętać, zanim zaczniesz walczyć o ostatnie bajty.

SVG to tekst, więc kompresuje się znakomicie. Serwer wysyła go z gzip albo brotli, a te potrafią zredukować plik o siedemdziesiąt do dziewięćdziesięciu procent. Powtarzalna struktura pakuje się lepiej niż nieregularna, więc czasem plik z krótszym kodem jest po kompresji większy od dłuższego, ale bardziej regularnego. Jeśli mierzysz, mierz po kompresji.

Odchudzanie ma granicę sensu. Ikona ważąca 400 bajtów zamiast 600 nie zmieni niczego w szybkości strony. Warto optymalizować ilustracje, mapy i zestawy ikon — czyli miejsca, gdzie mówimy o dziesiątkach kilobajtów. Przy pojedynczej ikonce liczy się głównie czytelność kodu.

Jak to poukładać u siebie

Prosty przepływ, który się broni:

1. Eksport z programu graficznego do folderu roboczego.
2. SVGO z własną konfiguracją, z removeViewBox wyłączonym i precyzją ustawioną na 2.
3. Rzut oka na wynik w przeglądarce.
4. Plik zoptymalizowany idzie na stronę, źródłowy zostaje w repozytorium.

Ten ostatni punkt jest ważniejszy, niż się wydaje. Zoptymalizowany plik jest do wyświetlania, nie do edycji. Gdy trzeba coś poprawić, wracasz do źródła — inaczej po trzeciej poprawce zostaniesz z nieczytelnym ciągiem liczb, którego nikt nie chce dotykać.

Podsumowanie

• Typowy eksport zawiera 60–80% treści niepotrzebnej do wyświetlenia obrazu.
• Największy pojedynczy zysk daje ograniczenie liczby miejsc po przecinku.
• Nie wolno ruszać viewBox, xmlns, identyfikatorów używanych w odwołaniach ani <title> i <desc>.
• W SVGO uważaj na removeViewBox, cleanupIds, mergePaths i convertShapeToPath.
• SVG kompresuje się bardzo dobrze — mierz wagę po gzipie, nie przed.
• Trzymaj osobno plik źródłowy do edycji i zoptymalizowany do publikacji.

W następnej lekcji zajmiemy się tym, czego optymalizator nie powinien dotykać: dostępnością. Krótko i konkretnie — cztery atrybuty i dwie decyzje.

Do wypróbowania: otwórz zakładkę eksport · przed i sprzątaj ręcznie, obserwując licznik bajtów i podgląd. Zacznij od metadanych, potem usuń powtórzone style, na końcu skróć liczby. Cel: zejść poniżej 300 bajtów bez najmniejszej zmiany w obrazie.