Obrazki w sklepie: WebP, AVIF, rozmiary, leniwe ładowanie
Zdjęcia to zwykle ponad połowa wagi strony sklepu. Jakie formaty wybrać, jak dobrać rozmiary pod ekrany, kiedy ładować leniwie i jak przerobić istniejące tysiące zdjęć bez zatrzymywania sprzedaży.
Zrobimy to za Ciebie. Opisz problem, a odpowiemy w ciągu 24 godzin roboczych.
Opisz projektNa typowej stronie kategorii sklepu obrazki ważą więcej niż cały kod, style i skrypty razem. Jeśli masz zrobić jedną rzecz dla szybkości sklepu, zrób porządek ze zdjęciami. To zmiana o najlepszym stosunku efektu do ryzyka: nie dotyka logiki sklepu, nie psuje koszyka, a potrafi zmniejszyć wagę strony o kilkadziesiąt procent.
W skrócie
- Format: WebP jako podstawa, AVIF tam, gdzie się da, JPEG jako zapas dla starych przeglądarek. PNG tylko dla grafik z przezroczystością.
- Rozmiar: przeglądarka powinna dostać obrazek tylko trochę większy niż miejsce, w którym go pokazuje. Do tego służy srcset.
- Leniwe ładowanie dla zdjęć poniżej pierwszego ekranu, nigdy dla głównego zdjęcia produktu.
- Istniejące zdjęcia konwertujesz hurtowo w tle, z oryginałami zachowanymi, partiami, poza godzinami szczytu.
Dlaczego zdjęcia ważą tyle
Zdjęcie produktu wgrane prosto z aparatu albo od producenta ma często 3000 do 5000 pikseli szerokości i kilka megabajtów. Na liście kategorii wyświetla się w ramce 300 pikseli. PrestaShop generuje miniatury w zdefiniowanych rozmiarach, ale domyślnie w JPEG o stałej jakości, a motywy często proszą o większą miniaturę, niż potrzebują, „na zapas”. Do tego dochodzą banery na stronie głównej wgrywane przez marketing w pełnej rozdzielczości, ikony w PNG zamiast SVG i obrazki w opisach produktów wklejane z edytora bez żadnej obróbki.
Efekt: strona kategorii z 24 produktami pobiera kilka megabajtów samych zdjęć. Na telefonie z przeciętnym zasięgiem to kilka sekund, zanim klient zobaczy produkty. To wprost przekłada się na LCP i na porzucenia.
Formaty: WebP, AVIF, JPEG, PNG, SVG
| Format | Do czego | Oszczędność względem JPEG | Wsparcie przeglądarek |
|---|---|---|---|
| JPEG | zdjęcia, zapas dla starych przeglądarek | punkt odniesienia | wszystkie |
| WebP | zdjęcia i grafiki, podstawowy format dziś | zwykle kilkadziesiąt procent przy podobnej jakości | wszystkie aktualne |
| AVIF | zdjęcia, najmniejsze pliki | większa niż WebP, kosztem dłuższej konwersji | aktualne, ale sprawdź starsze urządzenia |
| PNG | grafiki z przezroczystością, zrzuty ekranu | większe pliki niż JPEG przy zdjęciach | wszystkie |
| SVG | logo, ikony, proste grafiki | kilka kilobajtów, skalowalne bez strat | wszystkie |
W praktyce ustawiasz WebP jako format podstawowy, bo daje dużą oszczędność bez ryzyka. AVIF dokładasz, jeśli serwer ma moc na konwersję, bo generuje się wolniej, a różnica wobec WebP jest mniejsza niż WebP wobec JPEG. JPEG zostawiasz jako zapas. Przeglądarka sama wybiera, co obsługuje, jeśli użyjesz elementu picture z kilkoma źródłami. PrestaShop 8 i 9 mają wbudowaną obsługę WebP i AVIF w ustawieniach obrazów, trzeba ją włączyć i wygenerować miniatury ponownie.
Uwaga
Nie zamieniaj plików PNG z przezroczystością na JPEG, bo stracisz przezroczystość i dostaniesz czarne tło. Zamień je na WebP, który przezroczystość obsługuje. Ikony i logo zamień na SVG, jeśli masz źródła wektorowe.
Jakość kompresji: ile można ścisnąć
Jakość 100 to prawie bezstratnie i bardzo duże pliki. Jakość 60 to już widoczne artefakty na gładkich przejściach. Dla zdjęć produktów na białym tle zwykle dobrze działa przedział 75 do 85 dla WebP i 60 do 75 dla AVIF. Nie ma jednej liczby dla wszystkich, bo ubrania z fakturą, biżuteria z błyskami i elektronika na jednolitym tle kompresują się inaczej. Zrób test: wygeneruj to samo zdjęcie w trzech jakościach, obejrzyj na telefonie w powiększeniu i wybierz najniższą, przy której nie widzisz różnicy. Następnie ustaw tę wartość globalnie w panelu.
Osobnym tematem są metadane w plikach: informacje o aparacie, profil kolorów, miniatury osadzone w pliku. Potrafią ważyć kilkadziesiąt kilobajtów na zdjęcie. Konwersja na WebP zwykle je usuwa, ale przy JPEG jako zapasie warto je wyczyścić narzędziem do optymalizacji.
Rozmiary i srcset: właściwy obrazek na właściwy ekran
Telefon o szerokości ekranu 390 pikseli i gęstości 3x potrzebuje obrazka 1170 pikseli, żeby był ostry. Laptop z ekranem 1440 pikseli pokazujący ten sam produkt w kolumnie 400 pikseli potrzebuje 800 pikseli przy gęstości 2x. Jeden rozmiar nie pasuje do obu. Atrybut srcset na elemencie img podaje przeglądarce kilka wersji tego samego obrazka z ich szerokościami, a atrybut sizes mówi, ile miejsca obrazek zajmie na ekranie. Przeglądarka sama wybiera najmniejszy wystarczający plik.
W PrestaShop definiujesz rozmiary obrazków w ustawieniach obrazów: miniatura do listy, średni do karty, duży do powiększenia. Dobry motyw używa ich w srcset. Motywy z marketplace’u często tego nie robią i ładują wszędzie jeden rozmiar, zwykle za duży. To da się poprawić w szablonie bez zmiany motywu na nowy.
Wymiary w HTML, żeby strona nie skakała
Każdy obrazek powinien mieć w HTML atrybuty width i height albo ustalone proporcje w CSS. Dzięki temu przeglądarka rezerwuje miejsce, zanim pobierze plik, i treść nie przeskakuje po załadowaniu. To bezpośrednio poprawia CLS i jest jedną z najprostszych napraw w szablonie.
Leniwe ładowanie: co i kiedy
Leniwe ładowanie (atrybut loading=”lazy”) sprawia, że przeglądarka pobiera obrazek dopiero, gdy użytkownik zbliża się do niego przewijaniem. Dla listy 24 produktów oznacza to pobranie na start sześciu, ośmiu zdjęć zamiast wszystkich. Zasady są proste. Zdjęcia poniżej pierwszego ekranu: lazy. Główne zdjęcie produktu na karcie i pierwsze zdjęcia na liście: ładowane od razu, najlepiej z atrybutem fetchpriority=”high”, bo to one są LCP. Baner na stronie głównej: od razu, chyba że jest poniżej pierwszego ekranu.
Częsty błąd to leniwe ładowanie na wszystkim, łącznie z głównym zdjęciem produktu, bo tak ustawił moduł optymalizacji. Wtedy LCP rośnie, bo przeglądarka czeka ze zdjęciem, aż wykona skrypt, który zdecyduje o ładowaniu. Drugi błąd to galerie na karcie produktu, które ładują wszystkie zdjęcia w pełnym rozmiarze na start, choć klient widzi jedno.
Jak przerobić istniejące zdjęcia bez zatrzymywania sklepu
Sklep z 10 tysiącami produktów ma 30 do 50 tysięcy plików zdjęć w kilku rozmiarach każdy. Ponowne wygenerowanie miniatur z panelu PrestaShop przy takim katalogu kończy się przekroczeniem limitu czasu wykonania skryptu. Trzeba to zrobić inaczej.
Krok po kroku
- Zrób kopię katalogu ze zdjęciami. Oryginały zostają. Konwersja jest stratna, więc gdy zmienisz zdanie co do jakości, musisz mieć z czego wrócić.
- Ustaw formaty i jakość w panelu. Włącz WebP (i AVIF, jeśli serwer ma moc), ustaw jakość po testach, przejrzyj listę rozmiarów i usuń te, których motyw nie używa.
- Uruchom konwersję z linii poleceń w partiach. Skrypt przechodzi katalog po katalogu, generuje nowe miniatury i loguje postęp. Przy dużym sklepie trwa to godziny, więc puszczamy to nocą albo z ograniczeniem obciążenia procesora.
- Przełącz szablon na nowe formaty. Element picture ze źródłami AVIF, WebP i JPEG, srcset z rozmiarami, width i height, lazy poniżej pierwszego ekranu.
- Sprawdź i zmierz. Kategoria, karta produktu, strona główna na telefonie w PageSpeed Insights, przed i po. Przejrzyj kilka losowych produktów, czy zdjęcia wyglądają poprawnie i czy powiększenie działa.
- Ustaw konwersję dla nowych zdjęć. Każde zdjęcie wgrane od teraz, przez panel albo import, ma od razu dostać nowe formaty i rozmiary. Inaczej za rok problem wróci.
Z naszej praktyki
Sklep z odzieżą roboczą, około 6 tysięcy produktów z kilkoma zdjęciami każdy, strona kategorii na telefonie ważyła ponad 8 MB. Zdjęcia były w JPEG o jakości 100, miniatura do listy miała 800 pikseli przy wyświetlaniu w 250. Po konwersji na WebP w jakości 80, dodaniu srcset i leniwym ładowaniu poniżej pierwszego ekranu strona kategorii zeszła poniżej 1 MB, a LCP na telefonie skrócił się z ponad 5 sekund do około 2. Konwersja całego katalogu trwała jedną noc i nie wymagała wyłączania sklepu.
Klient nie widzi, że zdjęcie ma 4000 pikseli. Widzi, że sklep się ładuje.
Zdjęcia w opisach i banery: dziura, o której się zapomina
Zdjęcia produktów przechodzą przez mechanizm miniatur PrestaShop. Obrazki wklejone do opisu produktu w edytorze i banery wgrane przez moduły stron głównych nie. Trafiają na serwer w takim rozmiarze, w jakim je wgrano. Przejrzyj je osobno: wszystko w katalogu z plikami z edytora i w katalogach modułów bannerów. Zasada jest ta sama: WebP, rozmiar zbliżony do wyświetlanego, wymiary w HTML. Przy marketingu wgrywającym banery co tydzień ustaw automatyczną konwersję przy wgraniu albo ogranicz maksymalny rozmiar pliku w edytorze.
Pytania, które słyszymy najczęściej
Czy moduł do optymalizacji obrazków wystarczy?
Dobry moduł załatwi konwersję i leniwe ładowanie. Rzadko poprawia srcset w szablonie i rozmiary miniatur, a to często połowa zysku. Traktuj moduł jako jeden z kroków.
Czy WebP szkodzi SEO obrazków w Google?
Nie. Google indeksuje WebP i AVIF. Zadbaj o atrybut alt z nazwą produktu i o to, żeby adres obrazka był stabilny, bo zmiana adresów wszystkich zdjęć resetuje ich historię w Google Obrazy.
Co z CDN dla obrazków?
CDN przyspiesza dostarczanie, ale nie zmniejsza wagi. Najpierw formaty i rozmiary, potem CDN. Część CDN potrafi konwertować w locie na WebP i AVIF, co upraszcza krok z konwersją istniejących zdjęć.
Jak bardzo mogę zmniejszyć wagę strony?
Zależy od stanu wyjściowego. Przy zdjęciach w JPEG o wysokiej jakości i bez srcset oszczędność rzędu kilkudziesięciu procent wagi strony jest typowa. Przy sklepie, który już ma WebP, zysk z samych formatów będzie mały i trzeba szukać w rozmiarach i leniwym ładowaniu.
W audycie wydajności mierzymy, ile Twoje zdjęcia ważą na każdym typie strony, i dajemy plan konwersji z ustawieniami jakości i rozmiarów dopasowanymi do motywu. Zobacz, co zawiera audyt.