Optymalizacja zdjęć i grafiki na potrzeby strony www

Większość audytów technicznych, które robimy, zaczyna się od jednego wniosku: strona jest wolna, bo zdjęcia są za duże. Nie kod, nie hosting, nie skrypty analityczne. Same obrazy. To zaskakuje właścicieli firm, bo grafika wydaje się sprawą estetyki, nie techniki. W praktyce to jeden z najbardziej mierzalnych elementów SEO na stronie.

Poniżej rozkładam ten temat na konkretne decyzje: jaki format, jaka kompresja, jakie wymiary, jak nazwać plik i jak opisać go dla Google. Bez teorii, którą trudno przełożyć na działanie.

Dlaczego zdjęcia decydują o szybkości strony

Przeglądarka musi ściągnąć każdy plik, zanim go wyświetli. Tekst i kod HTML ważą kilobajty. Jedno nieskompresowane zdjęcie z aparatu albo telefonu waży kilka megabajtów. Jeśli na stronie głównej wisi dziesięć takich zdjęć, użytkownik czeka, a Google zapisuje ten czas jako wynik testu wydajności.

Największe zdjęcie widoczne od razu po wczytaniu strony to najczęściej element, który odpowiada za wskaźnik LCP, czyli czas wyrenderowania największej treści w widoku. To jeden z sygnałów, które Google bierze pod uwagę przy ocenie jakości strony. Wolna strona nie jest karana wprost jednym przełącznikiem, ale wolniejsze ładowanie oznacza więcej odbić, krótszy czas na stronie i gorsze sygnały użytkownika, które algorytm i tak zbiera.

Jest jeszcze druga strona medalu: zdjęcia same są źródłem ruchu. Google Grafika generuje realne wejścia na stronę, szczególnie w branżach, gdzie wygląd produktu ma znaczenie: meble, moda, wnętrza, gastronomia. Zdjęcie bez opisu i bez sensownej nazwy pliku jest dla wyszukiwarki niewidzialne, nawet jeśli wygląda świetnie dla człowieka.

Format pliku: co realnie ma znaczenie

Format decyduje o tym, ile waży plik przy tej samej jakości wizualnej. To pierwsza decyzja, zanim zajmiesz się czymkolwiek innym.

• JPG - dobry dla zdjęć z dużą ilością kolorów i szczegółów: produkty, ludzie, wnętrza. Kompresja stratna, ale przy rozsądnych ustawieniach różnica wizualna jest niezauważalna.
• PNG - potrzebny tam, gdzie liczy się przezroczystość: logotypy, ikony, grafiki z płaskim tłem. Dla zdjęć produktowych to zły wybór, bo plik wychodzi kilka razy większy niż JPG bez żadnej korzyści.
• WebP - następca JPG i PNG w jednym formacie. Przy tej samej jakości wizualnej daje wyraźnie mniejszy plik. Obsługują go wszystkie aktualne przeglądarki, więc nie ma już powodu, żeby z niego nie korzystać.
• AVIF - jeszcze nowszy format, potrafi zejść z wagą plików niżej niż WebP przy porównywalnej jakości. Wymaga trochę więcej mocy obliczeniowej przy generowaniu, ale wsparcie przeglądarek jest już wystarczające do produkcyjnego użycia.
• SVG - format wektorowy dla logotypów, ikon i prostych ilustracji. Skaluje się bez utraty jakości i zwykle waży bardzo mało, bo to nie jest siatka pikseli, a zapis matematyczny kształtów.

W praktyce dobra strona serwuje jeden plik źródłowy w kilku formatach naraz i pozwala przeglądarce wybrać ten, który obsługuje najlepiej. Przeglądarka dostaje AVIF, jeśli umie go odczytać, WebP jako opcję zapasową, a JPG jako ostatnią linię obrony dla najstarszych urządzeń. To nie wymaga trzymania trzech wersji ręcznie - mechanizm konwersji powinien działać automatycznie po stronie serwera albo CMS-a.

Kompresja: gdzie jest granica

Kompresja stratna zmniejsza wagę pliku, usuwając część informacji o obrazie w sposób niezauważalny dla oka. Kompresja bezstratna pakuje dane szczelniej, bez usuwania niczego, ale efekt jest znacznie mniejszy.

Dla zdjęć produktowych i tła stron sensowny poziom kompresji JPG czy WebP to zwykle 60-80% jakości oryginału. Wyżej nie widać różnicy gołym okiem, a plik rośnie bez potrzeby. Niżej zaczynają się artefakty: rozmyte krawędzie, plamy koloru na gradientach, ziarnistość w cieniach.

Częsty błąd: eksport zdjęcia z programu graficznego bez ustawienia kompresji, prosto na serwer. Plik wychodzi kilka megabajtów, bo program domyślnie zapisuje w najwyższej jakości. Druga skrajność: automatyczne narzędzia kompresujące wszystko na jeden poziom, bez rozróżnienia zdjęcia produktowego od baneru z dużą płaską powierzchnią koloru, gdzie mocniejsza kompresja jest niewidoczna.

Sensowny proces wygląda tak: zdjęcie robocze w wysokiej rozdzielczości trzymasz w archiwum, a na stronę trafia wersja przygotowana pod konkretne miejsce wyświetlenia, z kompresją dobraną do typu grafiki.

Wymiary: dlaczego jedno zdjęcie w kilku rozmiarach

Zdjęcie w rozdzielczości 3000x2000 pikseli na telefonie z ekranem 400 pikseli szerokości to marnotrawstwo. Przeglądarka i tak musi ściągnąć cały plik, żeby go zmniejszyć wizualnie, a to oznacza niepotrzebny transfer danych.

Poprawne rozwiązanie to generowanie kilku wersji tego samego zdjęcia w różnych szerokościach i pozwolenie przeglądarce na wybór właściwej w zależności od ekranu i gęstości pikseli. Mechanizm nazywa się srcset i jest częścią standardu HTML, nie żadnym dodatkiem. Przeglądarka sama liczy, jaki plik potrzebuje, i ściąga tylko go.

Druga sprawa to lazy loading, czyli leniwe wczytywanie. Zdjęcia poniżej pierwszego ekranu nie muszą się ładować od razu. Przeglądarka wczytuje je w momencie, gdy użytkownik przewija stronę w ich kierunku. To odciąża pierwsze sekundy wczytywania strony i poprawia wynik LCP, bo przeglądarka nie musi konkurować o transfer między zdjęciem widocznym od razu i tym na dole strony.

Wyjątek: zdjęcie w pierwszym widoku, to samo, które liczy się do LCP, nie powinno być leniwie wczytywane. Tam chcesz priorytetu, nie odkładania na później.

Nazwa pliku i adres URL grafiki

Plik prosto z aparatu albo telefonu ma nazwę typu IMG_2041.jpg. Dla człowieka to nic nie mówi, dla wyszukiwarki też. Google indeksuje obrazy częściowo na podstawie nazwy pliku i ścieżki, w której się znajduje, bo to jeden z niewielu sygnałów tekstowych, jakie ma przy analizie grafiki.

Zasada jest prosta: nazwa pliku powinna opisywać to, co jest na zdjęciu, w formie zrozumiałej i krótkiej. Słowa oddzielone dywizami, małe litery, bez polskich znaków diakrytycznych, bez losowych numerów seryjnych aparatu. Nazwa fotel-obrotowy-szary.jpg mówi więcej niż DSC00231.jpg, i to widać w statystykach ruchu z wyszukiwania grafiki.

To samo dotyczy folderu, w którym leży plik. Adres w stylu /media/uploads/2024/03/ nie jest błędem krytycznym, ale nic nie dodaje. Struktura, która odzwierciedla kategorię produktu czy temat artykułu, ułatwia też porządek w samym systemie zarządzania treścią, nie tylko SEO.

Atrybut alt: nie dla robota, dla sytuacji awaryjnej

Atrybut alt bywa traktowany jako pole do wklejenia słowa kluczowego. To błędne podejście. Alt ma dwa realne zadania: opisuje obraz osobie korzystającej z czytnika ekranu i zastępuje obraz tekstem, gdy plik się nie wczyta z jakiegoś powodu - błąd serwera, wolne połączenie, zablokowane wyświetlanie grafik.

Dobry alt jest konkretny i krótki. Opisuje to, co faktycznie widać, bez wymuszonego powtarzania frazy kluczowej cztery razy w jednym opisie. Fotel biurowy obrotowy w kolorze szarym, widok z boku - to działa. Fotel biurowy, fotele biurowe, fotel obrotowy szary tanio - to psuje doświadczenie osoby korzystającej z czytnika i wygląda podejrzanie dla algorytmu oceniającego jakość treści.

Praktyczna zasada: każde zdjęcie na stronie ma inny alt, dopasowany do kontekstu, w którym się znajduje. To samo zdjęcie produktu użyte na stronie kategorii i na karcie produktu może mieć inny opis, bo inny jest kontekst wokół niego.

Title obrazu - kiedy ma sens

Atrybut title wyświetla się jako podpowiedź po najechaniu kursorem na obraz. Ma marginalne znaczenie dla SEO i bywa ignorowany przez czytniki ekranu. Sensowne jest jego użycie tam, gdzie dodatkowy opis faktycznie pomaga użytkownikowi, na przykład w galerii ze szczegółami technicznymi produktu. Nie ma sensu duplikować w nim treści z alt jeden do jednego.

Zdjęcia produktowe: osobna kategoria problemów

W sklepach internetowych zdjęcie produktu robi więcej pracy niż opis. Klient nie może dotknąć towaru, więc zdjęcie musi pokazać go z każdej istotnej strony: przód, tył, detal, kontekst użycia. To jednak oznacza więcej plików na jedną kartę produktu, a więcej plików to więcej wagi do przeniesienia przy każdym wejściu na stronę.

Tu optymalizacja techniczna staje się jeszcze ważniejsza niż na stronie firmowej z kilkoma zdjęciami. Galeria produktowa z sześcioma zdjęciami w wysokiej rozdzielczości bez kompresji i bez leniwego wczytywania potrafi samodzielnie zjeść większość budżetu wydajności strony. Rozwiązanie jest zawsze to samo: jeden plik źródłowy w wysokiej jakości do archiwum, automatyczna generacja mniejszych wersji do wyświetlania, format WebP albo AVIF jako domyślny, lazy loading dla wszystkiego poza pierwszym zdjęciem w galerii.

Jak to wygląda technicznie na Payload CMS i Next.js

Nasze strony budujemy na Payload CMS z frontendem w Next.js. To ma znaczenie praktyczne dla tego tematu, bo obsługa obrazów jest wbudowana w architekturę, nie doklejana wtyczką.

Media w Payload trzymane są jako osobna kolekcja. Każde przesłane zdjęcie generuje automatycznie zestaw wersji w różnych szerokościach, zgodnie z konfiguracją rozmiarów ustawioną dla danego projektu. Nie trzeba ręcznie przygotowywać trzech plików dla trzech breakpointów - system robi to przy uploadzie.

Next.js dodaje do tego mechanizm renderowania obrazów, który automatycznie wybiera format zgodny z przeglądarką odwiedzającego, ustawia leniwe wczytywanie dla zdjęć poza pierwszym ekranem i pozwala oznaczyć priorytetowo obraz liczący się do LCP. Dzięki temu decyzje, które opisałem wyżej - format, wymiary, kolejność wczytywania - dzieją się na poziomie frameworka, a nie ręcznej pracy przy każdym zdjęciu wgranym do CMS-a.

To nie znaczy, że można olać przygotowanie plików wejściowych. Framework poprawi wagę i format, ale nie wymyśli sensownej nazwy pliku i nie napisze alt za Ciebie. Automatyzacja odciąża technikę, redakcja treści zostaje po stronie człowieka.

Kiedy ten temat nie ma sensu forsować

Jeśli strona ma pięć zdjęć na całą witrynę i ruch liczony w kilkudziesięciu wejściach miesięcznie, głęboka optymalizacja obrazów nie zmieni wyniku biznesowego. Ważniejsze będzie wtedy uzupełnienie treści albo poprawa samej oferty. Optymalizacja grafiki daje realny efekt tam, gdzie zdjęć jest dużo: sklepy z rozbudowanym katalogiem, strony z galeriami realizacji, blogi z regularnymi wpisami ilustrowanymi zdjęciami. Tam różnica w czasie wczytywania i w ruchu z wyszukiwania grafiki jest wymierna.

Budżet na ten temat zależy od skali. Uporządkowanie procesu przy nowej stronie - ustawienie formatów, kompresji, automatycznych rozmiarów - to jednorazowa praca techniczna wliczona w budowę serwisu. Uporządkowanie istniejącej bazy kilku tysięcy zdjęć w starym sklepie to już projekt osobny, wymagający czasu na przetworzenie plików i aktualizację opisów. Nie ma sensu robić tego ręcznie, plik po pliku, przy dużej skali - to praca dla automatyzacji, nie dla jednej osoby klikającej w panelu.

FAQ

Czy WebP zawsze jest lepszy niż JPG?

Przy tej samej jakości wizualnej WebP prawie zawsze waży mniej. Jedyny powód, żeby trzymać się JPG, to bardzo stare urządzenia lub systemy, które nie obsługują nowszego formatu, a to dziś rzadkość. Rozsądne rozwiązanie to serwowanie WebP z automatycznym fallbackiem do JPG, nie wybieranie jednego formatu na zawsze.

Czy trzeba kompresować zdjęcia ręcznie przed wgraniem na stronę?

Jeśli zdjęcia ważą dużo, warto wgrywać plik źródłowy w rozsądnej rozdzielczości, nie w maksymalnej z aparatu. Reszta pracy - dopasowanie do formatów i rozmiarów wyświetlania - powinna się dziać automatycznie po stronie systemu zarządzania treścią. Ręczna kompresja każdego pliku ma sens tylko przy bardzo małej liczbie zdjęć.

Czy alt obrazu wpływa na pozycję strony w Google?

Bezpośrednio niewiele, ale pomaga w indeksacji grafiki i w dostępności strony. Przy dużej liczbie zdjęć poprawnie opisanych efekt widać w ruchu z wyszukiwania obrazów, rzadziej w samych pozycjach tekstowych.

Ile zdjęć na stronie to za dużo?

Nie ma sztywnej liczby. Problem zaczyna się, gdy suma wagi wszystkich zdjęć widocznych na pierwszym ekranie przekracza sensowny limit dla wolniejszego połączenia mobilnego. Lepiej mierzyć czas wczytywania konkretnej podstrony niż liczbę plików.