Pierwszy ekran dłużej niż 3 sekundy
Połowa odwiedzających z telefonu odchodzi, nie doczekawszy się. Płacisz za ten ruch reklamą, ale nie widzisz go w zapytaniach.
Znajdujemy, co dokładnie spowalnia, i usuwamy to. Z pomiarami przed i po, widocznymi w Google PageSpeed i w Search Console.
Połowa odwiedzających z telefonu odchodzi, nie doczekawszy się. Płacisz za ten ruch reklamą, ale nie widzisz go w zapytaniach.
W raporcie Core Web Vitals strony są oznaczone jako „wymagają poprawy” lub „słabe”. To bezpośredni czynnik rankingowy.
Na urządzeniu mobilnym wynik w czerwonej strefie. Zwykle to ciężkie obrazy, tuzin wtyczek i zewnętrzne skrypty.
Treść się przesuwa, człowiek nie trafia w przycisk. Google liczy to jako CLS i obniża ocenę strony.
Google Ads obniża wynik jakości za wolną stronę docelową — płacisz za kliknięcie więcej niż konkurenci z tą samą ofertą.
Strona z filtrami myśli po kilka sekund przy każdym kliknięciu i człowiek odchodzi, nie docierając do produktu.
Szybkość ładowania wpływa na biznes dwiema drogami jednocześnie. Pierwsza jest oczywista: człowiek z telefonem nie czeka — według różnych pomiarów około połowy odwiedzających opuszcza stronę, która ładuje się dłużej niż trzy sekundy. Jeśli sprowadzasz ten ruch reklamą, płacisz za każdego z nich.
Druga droga jest mniej widoczna. Google od 2021 roku uwzględnia Core Web Vitals — trzy wskaźniki opisujące doświadczenie prawdziwego użytkownika: LCP (kiedy pojawiła się główna treść), CLS (jak bardzo skakał układ) i INP (jak szybko strona reaguje na działania). Te dane są zbierane od prawdziwych odwiedzających twoją stronę, a nie z testu laboratoryjnego, i wpływają na pozycje w wynikach.
Osobno — reklama. Google Ads liczy wynik jakości strony docelowej, a szybkość wchodzi w jego skład. Wolna strona oznacza wyższą cenę kliknięcia za tę samą ofertę. Czyli płacisz dwa razy: tracisz część odwiedzających i przepłacasz za tych, którzy dotarli.
Zdjęcie z aparatu na 4 MB tam, gdzie wystarczy 150 KB w WebP. Najczęstsza przyczyna i najtańsza w naprawie.
Każda ciągnie swój CSS i JS na wszystkie strony, nawet tam, gdzie nie jest używana.
Czaty, piksele, widgety opinii — ładują się synchronicznie i blokują wyświetlenie strony.
Serwer za każdym razem składa tę samą stronę od zera.
Czas odpowiedzi serwera powyżej sekundy — dalsza optymalizacja nie ma sensu, dopóki nie nastąpi przeprowadzka.
Kilka odmian z zewnętrznego źródła, przez które tekst pojawia się z opóźnieniem.
Oglądamy stronę w PageSpeed, w Search Console i ręcznie. Mówimy, co dokładnie spowalnia i o ile realnie da się przyspieszyć. W dniu zgłoszenia.
Ustalamy docelowe liczby przed rozpoczęciem pracy: jaki wynik na urządzeniu mobilnym i jakie Core Web Vitals mamy osiągnąć.
Obrazy, skrypty, cache, fonty, zapytania do bazy — po kolei, z pomiarem po każdym kroku. 3–10 dni.
Pokazujemy nie tylko wynik PageSpeed, ale i realny czas do pierwszego ekranu. Raport ze zrzutami ekranu.
Core Web Vitals są zbierane od prawdziwych użytkowników i nie aktualizują się od razu. Przez miesiąc pilnujemy, żeby liczby w Search Console zrobiły się zielone.
Cena zależy od tego, co dokładnie spowalnia stronę. Pomiar jest bezpłatny — po nim podajemy dokładną kwotę.
Kiedy spowalnia jedna oczywista rzecz: obrazy, cache, fonty.
Najczęstszy format: analizujemy wszystkie przyczyny i dochodzimy do zielonej strefy.
Katalogi z filtrami, tysiącami produktów i ciężkimi stronami.
Jeśli po pomiarze okaże się, że główną przyczyną jest hosting, powiemy to jako pierwsi. Optymalizowanie kodu na serwerze z dwusekundowym czasem odpowiedzi to praca na marne: najpierw przeprowadzka, potem optymalizacja.
Pakiet szybki — $150 za 2–3 dni, jeśli spowalnia jedna oczywista rzecz. Pełna optymalizacja — od $400, termin 3–10 dni. Sklepy z katalogiem — od $900. Dokładną kwotę podajemy po bezpłatnym pomiarze.
Docelowe liczby ustalamy przed rozpoczęciem pracy, po pomiarze — gdy już widać, co dokładnie spowalnia. Jeśli uzgodnionego wyniku nie osiągniemy, zwracamy pieniądze. Obiecywanie 90+ przed obejrzeniem strony byłoby nieuczciwe: w niektórych systemach sufit jest niżej.
Pracujemy na kopii, każdy krok sprawdzamy osobno. Przed wdrożeniem na działającą stronę robimy kopię zapasową. Jeśli coś przestało działać — przywracamy stan poprzedni i szukamy innej drogi.
Tak, i to najczęstszy przypadek. Sprawdzamy, które wtyczki są naprawdę używane, które się dublują, a które bez potrzeby ciągną swoje skrypty na wszystkie strony. Często połowę można usunąć bez utraty funkcji.
Powiemy od razu po pomiarze. Jeśli czas odpowiedzi serwera przekracza sekundę, optymalizacja kodu nie ma sensu — najpierw przeprowadzka. Przeniesienie możemy zrobić sami, to osobna praca.
PageSpeed pokazuje dwa różne zestawy danych: test laboratoryjny (uruchamiany za każdym razem od nowa, dlatego skacze) i dane terenowe od prawdziwych użytkowników z 28 dni (aktualizowane powoli). Kierujemy się terenowymi — właśnie je uwzględnia Google.
Core Web Vitals liczone są z 28 dni prawdziwego ruchu, więc po naprawach liczby w Search Console nie zmieniają się od razu. Zwykle pierwsze zmiany widać po dwóch-trzech tygodniach, pełny obraz — po miesiącu-półtora.
Zmierz moją stronę
Rozpocznij projekt