- Patryk Marek
- Baza wiedzy
- 0 polubienia
- 71 wyświetlenia
- 0 komentarze
- zdjęcia, wydajność, WebP
Włączona konwersja WebP nie przesądza o tym, jaki obraz pobiera przeglądarka. Sprawdź rzeczywiste żądanie w karcie Network: wybrany URL, nagłówek Content-Type, wymiary i rozmiar odpowiedzi. Dopiero wtedy ustalisz, czy problemem jest brak właściwego wariantu, reguła serwera, cache czy zbyt duże zdjęcie.

Ten poradnik jest dla właścicieli sklepów PrestaShop, którzy mają już WebP, ale nadal widzą ciężkie obrazy lub słaby wynik wydajności. Zawiera rzeczywistą, kontrolowaną próbę trzech ilustracji oraz sposób oddzielenia konwersji pliku od dostarczania go klientowi.
1. Zacznij od zdjęcia widocznego na konkretnej stronie
Wybierz jeden obraz na karcie produktu albo liście produktów. Nie zaczynaj od przypadkowego pliku w katalogu serwera: motyw może używać innej miniatury, wariantu dla ekranu o większej gęstości pikseli lub adresu z CDN. WebP oryginału nie zastępuje automatycznie wszystkich potrzebnych rozmiarów.
Otwórz narzędzia deweloperskie, przejdź do Network, wyłącz cache na czas próby i odśwież stronę. Wybierz filtr obrazów. Dla zdjęć ładowanych leniwie przewiń do badanego miejsca. Zapisz URL, typ odpowiedzi, rozmiar i informację, czy dane rzeczywiście pobrano z sieci. Opcje te opisuje dokumentacja Network w Chrome DevTools.
Nie porównuj pełnego pobrania JPEG z wierszem WebP oznaczonym jako memory cache. Taki wynik opisuje inne warunki. Podobnie mały transfer przy odpowiedzi 304 nie oznacza, że sam plik graficzny nagle ma kilka bajtów.
2. Adres .jpg może zwracać WebP
W źródłach WebP Pro 2.1.3 dostarczanie obrazu może działać przez reguły Apache: żądanie JPG lub PNG jest przepisywane na istniejący wariant WebP, jeżeli przeglądarka deklaruje jego obsługę. Adres widoczny w HTML może więc nadal kończyć się na .jpg, a odpowiedź mieć typ image/webp.
Dlatego sam podgląd kodu strony nie wystarcza do wniosku „WebP nie działa”. Sprawdź format otrzymanej odpowiedzi. Z drugiej strony napis .webp w ustawieniach czy istnienie pliku na dysku nie dowodzą, że odpowiednia reguła jest wykonywana na serwerze obsługującym sklep.
| Obserwacja | Możliwy wniosek | Następny krok |
|---|---|---|
| URL .jpg, Content-Type image/webp | Serwer dostarczył WebP mimo zachowania adresu źródłowego. | Sprawdź wymiary i bajty tego wariantu. |
| URL .jpg, Content-Type image/jpeg | W tej próbie dostarczono JPEG. | Sprawdź obecność dokładnego wariantu WebP, reguły serwera i cache. |
| WebP istnieje, ale dotyczy innego rozmiaru | Konwersja nie odpowiada plikowi wybranemu przez motyw. | Uzupełnij potrzebny typ miniatury lub właściwy zakres kolejki. |
| Obraz pochodzi z CDN | Odpowiedzi nie dostarcza bezpośrednio reguła głównego serwera sklepu. | Zweryfikuj format, klucz cache i odświeżenie po stronie CDN. |
| WebP ma dużą rozdzielczość | Format może być prawidłowy, lecz wybrany obraz nadal zbyt duży. | Porównaj naturalne wymiary z rozmiarem wyświetlania. |
3. Sprawdź srcset, picture i wybrany wariant
Przy obrazach responsywnych przeglądarka wybiera zasób z uwzględnieniem warunków strony i urządzenia. Sprawdź element img, ewentualne srcset i sizes, a przy picture także elementy source. Właściwość currentSrc pomaga wskazać faktycznie wybrany adres, zamiast sugerować się pierwszym wpisem w kodzie.
Element picture pozwala dostarczać alternatywne źródła, na przykład według formatu lub warunku media; reguły wyboru przedstawia dokumentacja elementu picture. Nie każdy motyw wykorzystuje ten mechanizm i nie każdy sklep potrzebuje zmiany HTML, jeśli poprawnie działa negocjacja formatu po stronie serwera.
Powtórz próbę dla telefonu. Zdjęcie o szerokości 2000 px użyte w małej miniaturze pozostaje niepotrzebnym obciążeniem, nawet po konwersji. Dobór rozmiaru i wybór formatu to dwa osobne ustawienia.
4. Własny pomiar: trzy ilustracje JPEG i WebP
Do kontrolowanej próby użyliśmy trzech istniejących ilustracji blogowych w rozmiarze 700 × 400 px. Każdy JPEG przekonwertowaliśmy przez PHP 8.1.34 i GD 2.3.3 do WebP z parametrem jakości 80. Nie zmienialiśmy wymiarów ani kadru. Chromium pobrał sześć plików z lokalnego serwera HTTP z wyłączonym cache i bez CDN.
Źródłem miniatur była lokalna kopia PrestaShop 8.2.8 z Warehouse 4.7.2. Sam pomiar odbył się na osobnej stronie porównawczej, więc nie mierzy czasu otwierania karty produktu ani efektu wdrożenia modułu. Podajemy bajty treści otrzymanych odpowiedzi, bez nagłówków transportowych. Wszystkie sześć żądań zakończyło się HTTP 200 i poprawnym typem obrazu.
| Ilustracja, 700 × 400 px | JPEG, image/jpeg | WebP, image/webp | Pliki do porównania |
|---|---|---|---|
| Częściowy zwrot | 64 824 B | 35 040 B | JPEG / WebP |
| Merchant Center | 61 499 B | 29 286 B | JPEG / WebP |
| Checkout | 60 485 B | 30 742 B | JPEG / WebP |
| Razem | 186 808 B | 95 068 B | Różnica: 91 740 B w tej próbie. |
Wynik pokazuje rozmiary konkretnych plików. Nie dowodzi, że każdy WebP będzie mniejszy o tę samą wartość ani że oba kodowania mają identyczną jakość wizualną. Parametry jakości różnych formatów nie są wspólną skalą. Obejrzyj zdjęcia w rzeczywistym rozmiarze użycia, zwracając uwagę na napisy, drobne faktury i ostre krawędzie.
5. Sprawdź kolejkę, a dopiero potem ponawiaj konwersję
W WebP Pro 2.1.3 zapis lub przeskalowanie obrazu może dodać zadanie do kolejki. Gotowy wariant powstaje po jej wykonaniu. Przy diagnozie sprawdź, czy wybrano właściwy zakres, czy zadanie zostało obsłużone i czy nie zakończyło się błędem. Samo zapisanie harmonogramu nie uruchamia automatycznie zadania systemowego CRON.
Zmiana jakości również nie musi od razu zmienić istniejących plików. W przejrzanym kodzie świeży WebP może zostać pominięty poza trybem nadpisywania. Jeśli świadomie zmieniasz jakość, zaplanuj ponowne wygenerowanie potrzebnego zakresu, a potem zweryfikuj wynik. Nie uruchamiaj pełnej regeneracji całego sklepu przy każdej drobnej rozbieżności.
Jeżeli potrzebujesz instrukcji samego procesu tworzenia miniatur, przeczytaj poradnik o generowaniu i regenerowaniu zdjęć. Tutaj punktem odbioru jest obraz otrzymany przez klienta.
6. Cache, CDN i LCP sprawdzaj osobno
Przy negocjowaniu formatu ważne jest, aby warstwa pośrednia odróżniała warianty odpowiedzi. Reguły WebP Pro przewidują Vary: Accept przy dostępnym module nagłówków Apache. Nie oznacza to jednak automatycznej konfiguracji dowolnego CDN lub Nginx. Sprawdź rzeczywistą odpowiedź z miejsca, z którego pobiera ją przeglądarka.
Po zmianie obrazu odśwież właściwy cache i powtórz identyczną próbę. Zapisz wybrane urządzenie, stan cache, URL i wymiary. Bez tych danych porównanie „przed i po” łatwo miesza różne zdjęcia albo różne warunki.
Mniejszy plik może ograniczyć czas pobierania, ale LCP obejmuje również inne etapy, w tym oczekiwanie na serwer, odkrycie zasobu i jego wyświetlenie. Poradnik Google o optymalizacji LCP pokazuje, dlaczego sama kompresja nie rozwiązuje każdego opóźnienia. Nie obiecuj wyniku PageSpeed 100 na podstawie samego formatu.
Następny krok: jeśli brakuje generowania lub dostarczania właściwych wariantów, sprawdź WebP Pro dla PrestaShop. Gdy obrazy są poprawne, a strona nadal wolna, przygotuj wyniki Network i zleć diagnozę wydajności sklepu.
Sprawdzono 13.09.2026. Mechanizmy modułu: kod WebP Pro 2.1.3. Pomiar ilustracji: osobna kontrolowana próba HTTP; nie jest pomiarem szybkości produkcyjnego sklepu.
Komentarze (0)