LCP poprawia się przez skrócenie czasu odpowiedzi serwera, odchudzenie i wcześniejsze załadowanie głównego zdjęcia oraz usunięcie plików, które blokują wyświetlenie pierwszego ekranu. Na większości stron firmowych i w sklepach elementem LCP jest zdjęcie w nagłówku, baner na stronie głównej albo pierwsze zdjęcie produktu.

Czas LCP składa się z kilku części: odpowiedzi serwera, odkrycia przez przeglądarkę, że trzeba pobrać dany obraz, samego pobierania i wyrenderowania. Dlatego samo zmniejszenie zdjęcia czasem nie wystarcza. Jeśli obraz jest ustawiony jako tło w CSS albo ładuje go skrypt slidera, przeglądarka dowiaduje się o nim późno. Częsty błąd to także lazy loading włączony dla zdjęcia na górze strony, przez co przeglądarka celowo odkłada jego pobranie.

W praktyce przy LCP robimy kilka rzeczy: ustawiamy wysoki priorytet pobierania dla głównego zdjęcia, wyłączamy dla niego lazy loading, przygotowujemy wersje w kilku rozmiarach pod różne ekrany, a slider na stronie głównej, jeśli nie jest potrzebny, zamieniamy na jedno statyczne zdjęcie. Po stronie serwera włączamy cache stron, żeby HTML nie był za każdym razem składany od nowa przez PHP i bazę danych.

INP poprawia się przez ograniczenie ilości JavaScriptu, który przeglądarka musi wykonać, zwłaszcza w momencie kliknięcia. Słaby INP widać jako menu, które otwiera się z opóźnieniem, filtry w sklepie, które „zamrażają” stronę, albo przycisk dodania do koszyka, który reaguje dopiero po chwili.

Najczęstsze źródła problemów to rozbudowane page buildery, kilka wtyczek robiących podobne rzeczy, skrypty reklamowe i analityczne uruchamiane od razu po wejściu, widżety czatu, pop-upy oraz bardzo duże strony z tysiącami elementów w kodzie. Każdy taki skrypt zajmuje główny wątek przeglądarki i kliknięcie musi czekać, aż ten się zwolni.

Przy INP sprawdzamy, które skrypty wykonują się najdłużej i co faktycznie jest potrzebne. Część usuwamy, część ładujemy dopiero po pierwszej interakcji lub po załadowaniu strony, a ciężkie elementy, takie jak mapy czy filmy, zastępujemy lekkim podglądem, który ładuje właściwą treść dopiero po kliknięciu. Na telefonach ten efekt jest największy, bo procesory w tańszych smartfonach są kilka razy słabsze niż w komputerach.

CLS poprawia się przez zarezerwowanie miejsca na każdy element, który pojawia się z opóźnieniem: zdjęcia, banery, reklamy, okienka zgody na cookies i fonty. Skaczący tekst to nie tylko gorszy wynik w Google, ale też przypadkowe kliknięcia w niewłaściwy przycisk, co w sklepie potrafi skończyć się porzuconym koszykiem.

Typowe przyczyny to obrazy bez podanych wymiarów, baner promocyjny wstawiany nad treścią po załadowaniu strony, pasek cookies, który przesuwa całą stronę, oraz fonty, które po pobraniu mają inną szerokość niż font zastępczy. W sklepach dochodzą jeszcze dynamicznie doładowywane bloki „polecane produkty” i ceny wczytywane osobnym zapytaniem.

Rozwiązania są zwykle proste technicznie: wymiary w kodzie każdego obrazu, stałe miejsce na baner, nakładka cookies zamiast paska, który przesuwa treść, i dopasowanie fontu zastępczego. Trudniejsze bywa znalezienie, który element przesuwa układ, bo na komputerze programisty strona często ładuje się na tyle szybko, że problemu nie widać.

Optymalizacja obrazów to zwykle pierwszy i najtańszy krok, bo na wielu stronach zdjęcia stanowią większość pobieranych danych. Zdjęcie z aparatu albo z banku zdjęć wgrane bez zmian potrafi ważyć kilka megabajtów, a wyświetla się w okienku o szerokości 400 pikseli na telefonie.

Przy obrazach pilnujemy pięciu rzeczy. Wymiary dopasowane do miejsca na stronie, z kilkoma wersjami dla różnych ekranów. Nowoczesne formaty WebP lub AVIF z odpowiednią kompresją. Lazy loading dla zdjęć poniżej pierwszego ekranu, ale nie dla głównego zdjęcia. Wymiary wpisane w kod, żeby nie było przesunięć układu. I osobne potraktowanie ikon i logo, które często lepiej działają jako SVG.

W WordPressie i sklepach dochodzi problem setek już wgranych plików. Zamiast ręcznie poprawiać każdy, ustawiamy automatyczną konwersję i generowanie miniatur, a stare, nieużywane rozmiary usuwamy. Wideo z YouTube czy Vimeo zastępujemy podglądem, który ładuje odtwarzacz dopiero po kliknięciu, bo jeden osadzony film potrafi dociągnąć więcej danych niż cała reszta strony.

Kod strony spowalnia ją na dwa sposoby: blokuje wyświetlenie pierwszego ekranu, dopóki przeglądarka nie pobierze i nie przetworzy plików CSS i JavaScript, oraz zajmuje procesor telefonu, przez co strona wolno reaguje. Minifikacja, czyli usuwanie zbędnych znaków z plików, pomaga, ale zwykle mniej niż usunięcie kodu, który na danej podstronie w ogóle nie jest potrzebny.

Tu pracujemy nad kilkoma obszarami. Ładujemy skrypty z atrybutami defer lub async albo dopiero po interakcji, jeśli nie są potrzebne od razu. Wydzielamy krytyczny CSS dla pierwszego ekranu, a resztę stylów ładujemy później. Wyłączamy pliki wtyczek na podstronach, na których z nich nie korzystają, na przykład skrypty formularza kontaktowego na każdej stronie bloga. Fonty pobieramy z własnego serwera, ograniczamy liczbę grubości i ustawiamy wyświetlanie tak, żeby tekst był widoczny od razu.

Osobny temat to skrypty zewnętrzne: Google Tag Manager z kilkunastoma tagami, piksele Meta i TikToka, czaty, widżety opinii, mapy Google i narzędzia do nagrywania sesji. Każdy z nich jest potrzebny komuś w firmie, więc nie usuwamy ich na ślepo. Ustalamy z Tobą, co musi działać od pierwszej sekundy, a co może poczekać kilka sekund lub do pierwszego ruchu użytkownika. Pomiar konwersji w GA4 zostaje bez zmian.

Cache przyspiesza stronę, bo serwer zamiast za każdym razem składać podstronę z PHP i bazy danych, wysyła gotowy plik HTML. Na stronach na WordPressie i w sklepach to często największa pojedyncza zmiana, jeśli chodzi o czas odpowiedzi serwera. Do tego dochodzi cache przeglądarki, dzięki któremu powracający użytkownik nie pobiera ponownie tych samych plików, oraz cache obiektów, na przykład Redis, który odciąża bazę danych.

W sklepach cache trzeba ustawić ostrożnie. Koszyk, konto klienta, ceny dla grup klientów i zamówienia nie mogą trafić do pamięci podręcznej, bo jeden klient zobaczyłby dane drugiego. Dlatego każdą regułę testujemy na kopii sklepu, a po wdrożeniu sprawdzamy proces zamówienia od dodania produktu do płatności.

CDN, czyli sieć serwerów rozsianych po świecie, ma sens przede wszystkim wtedy, gdy klienci są w różnych krajach albo strona serwuje dużo obrazów i plików. Dla firmy, która sprzedaje głównie w Polsce i ma dobry serwer w Polsce, CDN daje mniej, niż obiecują reklamy, choć często przydaje się do obrazów i ochrony przed atakami. Decyzję podejmujemy po pomiarze, a nie z góry.

Zmiana hostingu przyspiesza stronę wtedy, gdy wolna jest sama odpowiedź serwera, czyli TTFB jest wysoki nawet przy włączonym cache i na prostej podstronie. Jeśli serwer odpowiada szybko, a strona i tak ładuje się długo, problem leży w obrazach i kodzie, a przeprowadzka niewiele zmieni.

Na tanich pakietach hostingowych wiele stron dzieli te same zasoby, a limity procesora i pamięci szybko się kończą przy większym ruchu, na przykład w trakcie kampanii reklamowej. Sprawdzamy wersję PHP (nieaktualna potrafi wyraźnie spowalniać WordPressa i sklepy), dostępność cache po stronie serwera, obsługę HTTP/2 lub HTTP/3, lokalizację serwerowni i limity pakietu.

Strony, które budujemy i którymi się opiekujemy, stawiamy na hostingu Hostido. Jeśli po pomiarze okaże się, że obecny serwer jest wąskim gardłem, możemy przenieść tam stronę razem z pocztą i certyfikatem SSL. Przeniesienie wyceniamy indywidualnie, bo zależy od wielkości strony, liczby skrzynek i tego, czy po drodze trzeba zmieniać wersję PHP.

Przyspieszenie sklepu różni się od przyspieszenia strony firmowej tym, że najważniejsze są kategorie, karty produktów i koszyk, a nie strona główna. To na kategorie trafia ruch z Google, a wolny koszyk kosztuje porzucone zamówienia. Dlatego mierzymy osobno każdy typ podstrony i to na nich skupiamy pracę.

Typowe problemy sklepów to kategorie z kilkudziesięcioma produktami i pełnowymiarowymi zdjęciami, filtry przeładowujące całą stronę, moduły, które po latach działają w tle, mimo że nikt z nich nie korzysta, rozrośnięta baza danych z logami i porzuconymi koszykami oraz wolne wyszukiwanie. Do tego dochodzą skrypty porównywarek, systemów opinii i płatności ładowane na każdej podstronie.

Pracujemy na WooCommerce, PrestaShop, Shoperze i innych platformach, z tym że na platformach w abonamencie część rzeczy, takich jak serwer, zależy od dostawcy i możemy tylko zoptymalizować to, co jest po stronie sklepu: zdjęcia, skrypty, moduły i szablon. W sklepach na własnym serwerze mamy pełny dostęp, więc zakres jest szerszy. Jeśli sklep potrzebuje też pracy nad treściami kategorii i indeksacją, łączymy przyspieszenie z optymalizacją SEO.

• pomiar kategorii, karty produktu, koszyka i wyszukiwarki osobno
• cache z wyjątkami dla koszyka, konta i cen dla grup klientów
• zdjęcia produktów w kilku rozmiarach i nowoczesnych formatach
• przegląd modułów i czyszczenie bazy danych na kopii sklepu