Optymalizacja zdjęć na stronę WWW — szybkość i Core Web Vitals

Strona ładuje się wolno, a pierwsze podejrzenie zwykle pada na hosting albo na „ciężki” motyw. Tymczasem w większości przypadków winowajca jest banalny: zdjęcia. Pojedyncza fotografia prosto z aparatu potrafi ważyć tyle, co cały kod strony razem wzięty, a wystarczy kilka takich na stronie głównej, żeby odwiedzający czekał kilka sekund na coś, co powinno pojawić się od razu.

To nie jest problem czysto kosmetyczny. Waga zdjęć przekłada się wprost na Core Web Vitals — zestaw wskaźników, którymi Google mierzy realne wrażenia z korzystania ze strony. A te wskaźniki mają wpływ na pozycje w wyszukiwarce i, co jeszcze bardziej namacalne, na to, czy odwiedzający w ogóle zostanie. Przyjrzyjmy się, dlaczego zdjęcia ciążą najbardziej i jak je odchudzić bez psucia wyglądu.

Dlaczego to właśnie zdjęcia spowalniają stronę

Przeciętna strona to dziś w dużej mierze obrazy. Kod HTML, arkusze stylów i nawet skrypty liczą się zwykle w kilobajtach, podczas gdy pojedyncze zdjęcie z telefonu bije w megabajty. Proporcje bywają dramatyczne: tekst i układ strony to 200 KB, a galeria pod spodem — osiem megabajtów.

Dochodzi do tego druga rzecz: obrazy często blokują to, co użytkownik widzi jako pierwsze. Duże zdjęcie w nagłówku, baner czy fotografia produktu na górze strony to zwykle największy element, jaki przeglądarka musi pobrać i narysować, zanim strona zacznie wyglądać na gotową. Dopóki ten plik się ściąga, odwiedzający patrzy na pustkę albo na rozjeżdżający się szkielet.

I wreszcie — zdjęć zwykle jest dużo. Jeden ciężki plik to problem, ale dwadzieścia miniatur produktów, z których każda waży po pół megabajta, to już dziesięć megabajtów do pobrania, zanim klient zobaczy ofertę.

LCP, czyli jak zdjęcia psują Core Web Vitals

Najważniejszy wskaźnik, na który wpływają zdjęcia, to LCP (Largest Contentful Paint) — czas, po którym na ekranie pojawia się największy widoczny element. W ogromnej większości stron tym elementem jest właśnie obraz: zdjęcie w nagłówku, główny baner, pierwsza fotografia wpisu.

Mechanizm jest prosty. Im cięższy ten kluczowy obraz, tym dłużej trwa jego pobranie i wyświetlenie, a tym samym tym później strona „zaskakuje”. Google traktuje LCP poniżej 2,5 sekundy jako dobre, między 2,5 a 4 sekundami jako wymagające poprawy, a powyżej 4 sekund jako słabe. Wystarczy jeden niezoptymalizowany baner ważący kilka megabajtów, żeby wskoczyć w czerwoną strefę nawet na szybkim łączu — a na telefonie w terenie tym bardziej.

Zdjęcia potrafią też pogorszyć CLS (Cumulative Layout Shift) — wskaźnik mierzący, jak bardzo treść skacze podczas ładowania. Gdy obraz nie ma z góry zarezerwowanego miejsca, tekst najpierw się układa, a po wczytaniu zdjęcia gwałtownie przeskakuje w dół. To irytujące i punktowane na minus. Tu lekarstwo nie jest po stronie wagi, lecz layoutu, ale warto o tym pamiętać, bo oba problemy lubią chodzić w parze.

Waga zdjęć kontra pozycje w Google i konwersja

Szybkość strony jest jednym z czynników, które Google bierze pod uwagę przy ustalaniu kolejności wyników, a Core Web Vitals to konkretne, mierzalne sygnały tej szybkości. Nie jest to magiczny przełącznik, który sam wyniesie stronę na szczyt — treść i dopasowanie do zapytania liczą się bardziej — ale przy zbliżonej jakości to wydajność potrafi przechylić szalę. Wolna, ciężka od zdjęć strona startuje z gorszej pozycji.

Druga, często niedoceniana strona medalu to konwersja. Tu liczby mówią same za siebie: każda dodatkowa sekunda ładowania zauważalnie zwiększa odsetek osób, które rezygnują, zanim cokolwiek zobaczą. Na telefonie, na słabszym zasięgu, cierpliwość kończy się jeszcze szybciej. Sklep, który pokazuje produkt po pięciu sekundach, traci klientów na rzecz tego, który robi to po jednej — niezależnie od ceny.

Z naszych obserwacji: odchudzenie zdjęć to zwykle najtańsza optymalizacja wydajności, jaką da się zrobić. Nie wymaga przepisywania kodu ani zmiany hostingu, a efekt na wskaźnikach widać od ręki.

Trzy filary optymalizacji zdjęć

Cała sztuka sprowadza się do trzech ruchów, wykonanych w odpowiedniej kolejności. Każdy z nich tnie wagę, a razem potrafią ściąć ją o 80–90 procent bez widocznej różnicy na ekranie.

Filar 1: właściwe wymiary pod layout

Najczęstszy błąd to wgrywanie zdjęć w wymiarach prosto z aparatu — 4000, 6000 pikseli szerokości — w miejsce, które na stronie ma najwyżej 800 czy 1200 pikseli. Przeglądarka ściśnie taki obraz w locie, ale użytkownik i tak pobierze pełną, gigantyczną wersję. To czysta strata transferu.

Zasada jest prosta: zdjęcie powinno mieć tyle pikseli, ile realnie zajmuje na ekranie (z zapasem na ekrany o dużej gęstości — zwykle wystarczy razy dwa). Zdjęcie w treści wpisu rzadko potrzebuje więcej niż 1600 px po dłuższym boku, miniatura produktu 600–800 px, a tło pełnoekranowe około 1920 px. Samo zejście z 4000 do 1600 px potrafi ściąć wagę o dwie trzecie, zanim w ogóle dotkniemy kompresji. Gdy zdjęć jest dużo, najwygodniej zrobić to hurtem — masowa zmiana rozmiaru przepuszcza całą paczkę za jednym razem.

Filar 2: nowoczesny format — WebP albo AVIF

Format decyduje o tym, jak sprytnie te same piksele zostaną zakodowane. JPG to wciąż solidny wybór, ale WebP przy tej samej jakości waży zwykle o 25–35 procent mniej, a AVIF schodzi jeszcze niżej. Oba są dziś obsługiwane przez wszystkie liczące się przeglądarki.

W praktyce dla większości stron przejście z JPG na WebP daje największy zysk przy najmniejszym wysiłku. Jeśli galeria leży w JPG, sama konwersja do WebP potrafi zmniejszyć łączną wagę o jedną trzecią. Warto tylko zachować wariant zapasowy w JPG dla nielicznych miejsc, które WebP nie otworzą — a gdy trzeba odwrócić kierunek, pomaga szybka konwersja WebP na JPG. Więcej o różnicach między formatami opisuje osobny poradnik: JPG, PNG, WebP czy AVIF.

Filar 3: sensowna kompresja

Na końcu wchodzi kompresja, czyli świadome poświęcenie szczegółów, których oko i tak nie wyłapuje. Sztuka polega na trafieniu w punkt, w którym plik jest mały, a strat nie widać. Dla zdjęć jakość na poziomie 75–85 procent to złoty środek — niżej zaczynają być widoczne „kwadraty” przy krawędziach i artefakty na gładkich powierzchniach.

Gdy zależy na konkretnej, przewidywalnej wadze, wygodniej niż żonglować suwakiem jakości jest podać docelowy rozmiar i pozwolić narzędziu dobrać resztę. Tak działa kompresja do 200 KB — sensowny pułap dla większych zdjęć w treści; dla miniatur i mniejszych grafik sięga się po wariant do 100 KB. Cały proces odbywa się w przeglądarce, więc zdjęcia nie opuszczają urządzenia.

Serwuj zdjęcie w rozmiarze, w jakim się wyświetla

To zasada warta osobnego akapitu, bo łamana jest najczęściej. Nie ma sensu wgrywać obrazu większego, niż przewiduje go układ strony. Jeśli zdjęcie produktu pokazuje się w kafelku szerokim na 400 pikseli, plik 3000 px to dziesięciokrotny nadmiar danych, które ktoś musi pobrać i które przeglądarka i tak wyrzuci.

Praktycznie oznacza to dopasowanie wymiarów pliku do realnego miejsca w layoucie, a nie do tego, co wypluł aparat. Zdjęcie tła, hero na górze, miniatura w siatce i fotografia w treści to cztery różne rozmiary — i każdy z nich powinien dostać własną, dopasowaną wersję, a nie jeden wielki plik na wszystkie zastosowania.

Lazy-loading, czyli wczytuj to, co widać

Kolejny tani zysk to odroczone wczytywanie. Przeglądarki potrafią ładować zdjęcia dopiero wtedy, gdy użytkownik dociera do nich przewijaniem, zamiast pobierać od razu całą długą stronę. Wystarczy dodać atrybut loading="lazy" do obrazów poniżej pierwszego ekranu.

Jest jeden wyjątek wart zapamiętania: głównego obrazu na samej górze (tego od LCP) nie należy odraczać — przeciwnie, to on ma się załadować jak najwcześniej. Lazy-loading zostawiamy dla galerii i zdjęć w dalszej części strony.

Mini-audyt zdjęć na stronie

Zanim ruszysz z optymalizacją, warto wiedzieć, gdzie naprawdę uciekają megabajty. Taki mini-audyt zajmuje kilka minut:

1. Otwórz stronę i zważ ją. W przeglądarce wystarczy panel narzędzi deweloperskich (zakładka „Network”): pokazuje łączną wagę strony i to, ile z niej to obrazy. Najczęściej zdjęcia odpowiadają za grubo ponad połowę.
2. Wskaż największe pliki. Posortuj zasoby po rozmiarze. Zwykle wyłania się garstka winowajców — kilka ciężkich zdjęć, które same robią różnicę.
3. Sprawdź wymiary kontra wyświetlanie. Dla każdego dużego obrazu porównaj jego wymiary z miejscem, jakie zajmuje na ekranie. Jeśli plik ma 4000 px, a kafelek 400 — masz pierwszego kandydata do zmniejszenia.
4. Zajrzyj w format. Pliki z rozszerzeniem .png przy zwykłych fotografiach to sygnał ostrzegawczy — PNG do zdjęć potrafi ważyć kilka razy za dużo.
5. Zmierz LCP. Darmowe narzędzia od Google pokazują, który element jest tym największym i ile zajmuje jego wyświetlenie. To podpowiada, którym zdjęciem zająć się w pierwszej kolejności.

Po takim przeglądzie zwykle okazuje się, że za 80 procent problemu odpowiada kilka plików. Ich odchudzenie daje największy skok i od niego warto zacząć.

Docelowa waga zdjęć na stronę

Trudno o jedną świętą liczbę, ale rozsądne punkty odniesienia istnieją. Pojedyncze zdjęcie w treści powinno mieścić się w 100–300 KB, większy baner czy hero do 400–500 KB, a miniatura w siatce poniżej 100 KB. Jeśli którykolwiek plik przekracza megabajt, prawie zawsze da się go bezpiecznie odchudzić.

Na poziomie całej strony dobrym celem jest łączna waga obrazów poniżej jednego, najwyżej dwóch megabajtów — i to wliczając wszystko, co widać po wejściu. Brzmi restrykcyjnie, ale po przejściu przez trzy filary okazuje się całkiem osiągalne, a różnicę w szybkości widać gołym okiem.

Na koniec drobna, lecz miła uwaga: skoro całą obróbkę — zmianę wymiarów, konwersję i kompresję — można wykonać w przeglądarce, zdjęcia produktów, materiały firmowe czy zdjęcia klientów nie muszą lądować na cudzym serwerze tylko po to, by je odchudzić. Szczegóły opisuje polityka prywatności.

FAQ

Dlaczego moja strona ładuje się wolno, choć kod jest lekki?

W większości przypadków to zdjęcia. Pojedyncza fotografia prosto z aparatu potrafi ważyć więcej niż cały kod strony, a kilka takich na górze to już kilka megabajtów do pobrania, zanim cokolwiek się pokaże. Zważ stronę w narzędziach deweloperskich — zwykle obrazy odpowiadają za grubo ponad połowę wagi.

Jak zdjęcia wpływają na Core Web Vitals?

Najmocniej na LCP, czyli czas pojawienia się największego elementu — a tym jest zwykle główny obraz. Im cięższy, tym później strona wygląda na gotową. Zdjęcia bez zarezerwowanego miejsca pogarszają też CLS, czyli skakanie treści podczas ładowania.

Ile powinny ważyć zdjęcia na stronie?

Pojedyncze zdjęcie w treści najlepiej w 100–300 KB, baner do 400–500 KB, miniatura poniżej 100 KB. Łączna waga obrazów widocznych po wejściu powinna mieścić się w jednym, najwyżej dwóch megabajtach.

Czy WebP naprawdę robi różnicę względem JPG?

Tak. Przy tej samej jakości WebP waży zwykle o 25–35 procent mniej, a wszystkie aktualne przeglądarki go obsługują. Dla większości stron przejście z JPG na WebP daje największy zysk przy najmniejszym wysiłku.

Czy muszę optymalizować zdjęcia po kolei, jedno po drugim?

Nie. Najwygodniej przepuścić całą paczkę przez masową zmianę rozmiaru i kompresję za jednym razem, a wynik pobrać jako ZIP. Cała obróbka odbywa się w przeglądarce, więc pliki nie są nigdzie wysyłane.