Modelowane listy odbiorców nie zawierają konkretnych osób, tylko prawdopodobieństwa. Wyjaśniam, jak powstają, gdzie ich szukać w panelu i jak czytać ich raporty.
Po kilku przesunięciach terminu Google zaczął w połowie czerwca wdrażać aktualizację powiązaną z doświadczeniem użytkownika na stronie. Wdrożenie ma być stopniowe i rozłożone na tygodnie, więc w chwili, gdy to piszę, jesteśmy w jego trakcie, a nie po nim.
To dobra wiadomość dla wszystkich, którzy nie zdążyli. Zmiana nie działa jak przełącznik i nie należy oczekiwać, że pozycje przestawią się w jednym dniu. Zła wiadomość jest inna: skoro wdrożenie jest rozciągnięte, nie da się jednoznacznie powiązać wahań pozycji z tą konkretną aktualizacją, bo w tym samym czasie dzieje się wiele innych rzeczy.
Poniżej opisuję, gdzie sprawdzam stan serwisu, jak czytam te dane i czego bym się po tej zmianie nie spodziewał.
Aktualizacja nie dotyczy jednego wskaźnika, ale zestawu sygnałów opisujących, jak strona zachowuje się z perspektywy odwiedzającego.
Trzon to trzy mierniki wydajności: czas wyświetlenia największego elementu treści, opóźnienie reakcji na pierwsze działanie użytkownika i stabilność wizualna układu. Każdy z nich ma progi określające, kiedy wynik jest dobry, wymagający poprawy albo słaby.
Do tego dochodzą sygnały, które istnieją od dawna i były już wcześniej brane pod uwagę: przystosowanie do urządzeń mobilnych, połączenie szyfrowane, brak natrętnych elementów zasłaniających treść oraz bezpieczne przeglądanie.
Warto zauważyć jedną rzecz: większość tych elementów to nie nowość. Nowością jest zestawienie ich w jeden opisany zestaw i dodanie mierników wydajności opartych na danych od rzeczywistych użytkowników.
Podstawowym miejscem jest Search Console. Znajduje się tam raport pokazujący adresy pogrupowane według oceny wraz z podziałem na urządzenia mobilne i komputery.
Raport ma dwie cechy, które trzeba znać, żeby nie wyciągać złych wniosków.
Po pierwsze, opiera się na danych od rzeczywistych użytkowników zbieranych w ruchomym okresie kilku tygodni. Poprawka wdrożona dziś nie zmieni raportu jutro — trzeba odczekać, aż nowe pomiary zaczną przeważać nad starymi.
Po drugie, grupuje adresy według podobieństwa. Jeden problem widoczny w grupie oznacza zwykle, że dotyczy on szablonu, a nie pojedynczej strony. To dobra wiadomość, bo poprawa szablonu naprawia setki adresów naraz.
Uzupełniająco korzystam z narzędzia do sprawdzania szybkości pojedynczego adresu, które pokazuje jednocześnie dane od użytkowników i wynik pomiaru laboratoryjnego, oraz z audytu w narzędziach przeglądarki, gdy potrzebuję zdiagnozować konkretną przyczynę.
To rozróżnienie jest źródłem większości nieporozumień w rozmowach o wydajności.
Pomiar laboratoryjny wykonuje się w kontrolowanych warunkach — symulowanym urządzeniu i symulowanej sieci. Jest powtarzalny i świetnie służy do diagnozowania: pokazuje, co konkretnie spowalnia stronę i ile można na tym zyskać.
Dane od użytkowników pochodzą z rzeczywistych wizyt: różnych telefonów, różnych sieci, różnych lokalizacji. To one są brane pod uwagę w ocenie i to one bywają rozczarowaniem, gdy pomiar laboratoryjny wyglądał świetnie.
Rozbieżność między nimi jest normalna i informacyjna. Jeśli laboratorium mówi „dobrze”, a rzeczywiści użytkownicy „słabo”, to zwykle znaczy, że twoja publiczność ma słabsze urządzenia albo gorsze połączenie niż warunki testu — albo że problem pojawia się na podstronach, których nie testowałeś.
Jest jeszcze jedno ograniczenie: strony o niewielkim ruchu mogą nie mieć wystarczająco danych, żeby raport cokolwiek pokazał. Wtedy pozostaje pomiar laboratoryjny i zdrowy rozsądek.
Kilka zasad, które porządkują interpretację.
Zaczynam zawsze od grup adresów o największym ruchu. Naprawianie szablonu, który obsługuje kilka procent wizyt, jest niewłaściwą kolejnością, choć bywa łatwiejsze technicznie.
Tu potrzebna jest szczera rozmowa, bo wokół tej aktualizacji narosły duże oczekiwania w obie strony.
Google od początku komunikował, że te sygnały nie przeważą nad jakością treści. Strona, która najlepiej odpowiada na zapytanie, będzie wyświetlana wysoko także wtedy, gdy ładuje się przeciętnie. Wydajność ma znaczenie przede wszystkim jako czynnik rozstrzygający między stronami porównywalnie dobrymi merytorycznie.
Nie spodziewałbym się więc skoku pozycji po samej optymalizacji technicznej. Widzę natomiast dwie rzeczy, które warto brać pod uwagę.
Pierwsza: w branżach, w których wszyscy mają podobną treść — a sklepy z tym samym asortymentem są tu wzorcowym przykładem — rola czynników rozstrzygających rośnie.
Druga i moim zdaniem ważniejsza: szybsza strona lepiej konwertuje niezależnie od wyszukiwarki. Praca nad wydajnością zwraca się przez sprzedaż, nawet gdy nie zwróci się przez pozycje. To argument, który zwykle przekonuje decydentów lepiej niż wykresy z Search Console.
Kolejność, którą proponuję klientom w tym momencie.
Najpierw ustalenie punktu wyjścia: zapisanie stanu raportu i pozycji najważniejszych fraz na dziś. Bez tego za dwa miesiące nikt nie odtworzy, czy coś się zmieniło.
Potem naprawa rzeczy oczywistych i tanich. Obrazy w nadmiarowych rozmiarach i formatach, brak wymiarów w kodzie powodujący przeskakiwanie układu, elementy wstawiane nad treścią po załadowaniu strony, nadmiar skryptów zewnętrznych — to zwykle większość problemu w typowym serwisie i naprawa nie wymaga przebudowy.
Następnie sprzątanie po narzędziach marketingowych. Widzę to na wielu stronach: kilka systemów analitycznych, dwa czaty, wtyczka opinii, pikselu trzech sieci reklamowych. Każdy z tych elementów kosztuje czas ładowania, a część nie jest używana od dawna. Ten przegląd potrafi dać więcej niż optymalizacja kodu szablonu.
Na koniec obserwacja przez kilka tygodni i dopiero potem decyzja o poważniejszych pracach. Jeśli po sprzątnięciu podstaw serwis wychodzi na dobre wyniki, przebudowa szablonu nie jest potrzebna — a to bywa kosztowna decyzja, którą łatwo podjąć pochopnie w atmosferze pośpiechu wokół aktualizacji.
Używamy plików cookies, aby ułatwić Ci nawigację oraz wykonywanie określonych funkcji. Szczegółowe informacje o wszystkich plikach cookies znajdziesz w każdej kategorii zgody poniżej.
Pliki cookies oznaczone jako "Niezbędne" są przechowywane w Twojej przeglądarce, ponieważ są one kluczowe dla zapewnienia podstawowych funkcji strony.
Używamy również plików cookies firm trzecich, które pomagają nam analizować, w jaki sposób korzystasz z tej strony, zapamiętują Twoje preferencje oraz dostarczają treści i reklamy odpowiednie dla Ciebie. Te pliki cookies będą przechowywane w Twojej przeglądarce tylko za Twoją uprzednią zgodą.
Możesz zdecydować, czy chcesz włączyć lub wyłączyć niektóre bądź wszystkie te pliki cookies, jednak wyłączenie niektórych z nich może wpłynąć na Twoje doświadczenia podczas przeglądania strony.
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __cf_bm | 13 minutes | Cloudflare bot management — distinguishes humans from bots. |
| rc::* | Persistent | Google reCAPTCHA — localStorage holding anti-bot challenge state. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| wpEmojiSettingsSupports | Session | WordPress — sessionStorage flag caching whether the browser can render emoji (feature detection). |
| ytidb* | Persistent | YouTube — IndexedDB storing playback/search state for embedded videos. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| _ga_* | 400 days | Google Analytics 4 — persists session state per property. |
| _ga | 400 days | Google Analytics — distinguishes unique users via a client id. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| NID | 183 days | Google — stores preferences for personalized ads. |
| fr | 90 days | Meta — encrypted Facebook id and browser id for ads. |
| _gcl_au | 90 days | Google AdSense/Ads — experiments with advertising efficiency (conversion linker). |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __Secure-YNID | 180 days | |
| YSC | Session | |
| __Secure-ROLLOUT_TOKEN | 180 days | |
| VISITOR_INFO1_LIVE | 180 days | |
| VISITOR_PRIVACY_METADATA | 180 days | |
| datr | 400 days | |
| sb | 400 days | |
| wd | 7 days |