Analiza wpływu szybkości odpowiedzi serwera (TTFB) na pozycje w organicznych wynikach wyszukiwania.

Wpływ realny, ale rzadko bezpośredni

Baner wejsciowyParallax

Analiza wpływu szybkości odpowiedzi serwera (TTFB) na pozycje w organicznych wynikach wyszukiwania.

Wpływ realny, ale rzadko bezpośredni

Autor nie posiada zdjęcia
Tomasz Piasecki
29 listopada 2024

Pytanie o TTFB wraca w każdej rozmowie o audycie technicznym i zwykle w formie, na którą nie da się odpowiedzieć jednym zdaniem: „czy jeśli przeniesiemy stronę na szybszy serwer, wskoczymy wyżej w Google”. Odpowiedź brzmi „to zależy, od czego wskakujemy i dlaczego jesteśmy nisko” — i właśnie dlatego warto to rozłożyć na części.

W tym tekście oddzielam trzy poziomy wpływu. Pierwszy to bezpośrednie użycie czasu odpowiedzi serwera jako czynnika rankingowego. Drugi to wpływ przez wskaźniki, które Google faktycznie mierzy i wykorzystuje. Trzeci to wpływ na indeksowanie, czyli na to, czy Twoje strony w ogóle trafiają do wyników.

Mieszanie tych trzech poziomów jest źródłem większości nieporozumień w tej sprawie, w tym oczekiwań, że migracja hostingu sama z siebie odbuduje ruch.

Czym jest TTFB i co się w nim mieści

TTFB to czas od rozpoczęcia żądania do momentu, w którym przeglądarka odbiera pierwszy bajt odpowiedzi. Nazwa sugeruje, że to pomiar serwera, ale w środku siedzi znacznie więcej rzeczy.

Składają się na niego kolejno: ewentualne przekierowania, czas rozwiązania nazwy domeny, zestawienie połączenia, negocjacja szyfrowania, wysłanie żądania, praca serwera nad odpowiedzią i oczekiwanie na jej pierwszy fragment. Jeśli adres, w który wchodzi użytkownik, przechodzi przez dwa przekierowania, cały ten łańcuch liczy się do wyniku — i bywa, że sam serwer jest szybki, a liczba i tak wychodzi zła.

To pierwsza praktyczna wskazówka z tego artykułu: zanim zaczniesz optymalizować bazę danych, sprawdź, ile przekierowań pokonuje typowy użytkownik po wpisaniu adresu bez ukośnika i bez przedrostka. Bardzo często to jest właśnie ta „awaria serwera”.

Jako punkt odniesienia dla oceny wyniku przyjmuje się mniej więcej ośmiuset milisekund dla dobrego rezultatu, przy czym liczy się to, co widzą realni użytkownicy, a nie pojedynczy pomiar z Twojego biura.

Co Google faktycznie mówi o szybkości serwera

W oficjalnej komunikacji Google nie ma czynnika rankingowego o nazwie „czas odpowiedzi serwera”. Sygnały związane z doświadczeniem strony opierają się na wskaźnikach Core Web Vitals, a TTFB do nich nie należy — jest opisywany jako wskaźnik diagnostyczny, pomocny w wyjaśnianiu, dlaczego inne wskaźniki wypadają słabo.

Z drugiej strony szybkość działania strony jest wymieniana jako czynnik od lat, począwszy od komunikatów sprzed ponad dekady, a narzędzia Google konsekwentnie ostrzegają przed zbyt długim czasem pierwszej odpowiedzi. Wypowiedzi przedstawicieli firmy sprowadzają się do tego samego: różnica między stroną szybką i bardzo szybką ma niewielkie znaczenie rankingowe, natomiast różnica między stroną akceptowalną i wyraźnie zbyt wolną ma znaczenie realne.

Tak to traktuję w praktyce. TTFB nie jest suwakiem, który podnosi pozycje proporcjonalnie do skrócenia czasu. Jest raczej progiem: powyżej pewnego poziomu zaczyna szkodzić na wielu poziomach jednocześnie, poniżej przestaje być tematem i wracamy do treści oraz linków.

Wpływ na indeksowanie i budżet indeksowania

To jest poziom, na którym wpływ szybkości serwera jest najlepiej udokumentowany i najbardziej bezpośredni, a jednocześnie najczęściej pomijany w rozmowach o pozycjach.

Robot Google reguluje tempo odwiedzin między innymi na podstawie tego, jak zachowuje się serwer. Wolne odpowiedzi, przeciążenia i błędy po stronie serwera powodują ograniczenie liczby żądań, żeby nie dokładać obciążenia. Efekt jest odwrotny do oczekiwanego: im mniej zasobów ma Twój serwer, tym rzadziej Google zagląda i tym dłużej trwa, aż zauważy nowe albo zmienione podstrony.

W małym serwisie firmowym o dwudziestu podstronach to nie ma większego znaczenia. W sklepie z kilkudziesięcioma tysiącami produktów, zmiennymi cenami i dostępnością — ma znaczenie ogromne. Tam różnica w czasie odpowiedzi przekłada się bezpośrednio na to, jak szybko aktualizacja oferty pojawia się w wynikach.

Dane do oceny tej sytuacji są w Search Console w raporcie o statystykach indeksowania: średni czas odpowiedzi, liczba żądań w czasie i rozkład kodów odpowiedzi. Jeśli na wykresie widać, że wzrost czasu odpowiedzi zbiega się ze spadkiem liczby żądań robota, masz swój dowód i nie potrzebujesz do tego żadnych badań korelacyjnych.

Korelacja czy przyczyna — jak czytać badania rynkowe

Co jakiś czas pojawiają się analizy pokazujące, że strony z pierwszej trójki wyników mają lepszy czas odpowiedzi niż strony z drugiej strony wyników. Takie wnioski warto czytać ostrożnie.

Serwisy, które zajmują czołowe pozycje w konkurencyjnych frazach, to zwykle większe organizacje z lepszym budżetem technicznym, lepszym hostingiem, zespołem utrzymania i profesjonalną warstwą pośredniczącą. Ich dobry TTFB jest raczej objawem posiadanych zasobów niż przyczyną pozycji. Odwrócenie tej zależności prowadzi do prostego, ale kosztownego błędu: wydania budżetu na infrastrukturę w serwisie, którego problemem jest brak treści odpowiadającej na zapytania.

Nie znaczy to, że takie zestawienia są bezwartościowe. Pokazują rozkład i pozwalają ocenić, gdzie jesteś względem konkurencji. Ale decyzję o kolejności prac opieram na czymś innym: na tym, czy da się wskazać mechanizm, przez który wolny serwer szkodzi konkretnie w tym serwisie. Jeżeli tym mechanizmem jest ograniczone indeksowanie albo systematycznie słabe wyniki wskaźnika renderowania na urządzeniach mobilnych, mam uzasadnienie. Jeżeli nie, to mam tylko liczbę, która komuś się nie podoba.

Jak mierzyć, żeby liczba coś znaczyła

Największym problemem w tej dyskusji nie jest interpretacja, tylko jakość pomiaru. Widzę cztery błędy, które powtarzają się niemal zawsze.

  • Pomiar z jednej lokalizacji i jednego łącza. Wynik z biura w tym samym mieście, w którym stoi serwer, nie mówi nic o użytkownikach z drugiego końca kraju ani o połączeniach komórkowych.
  • Mierzenie strony głównej i wyciąganie wniosków o całym serwisie. Strona główna jest zwykle najlepiej zbuforowana. Karta produktu z filtrami i wynik wyszukiwania w sklepie to zupełnie inna historia.
  • Pojedynczy pomiar zamiast rozkładu. Interesuje mnie mediana i wynik gorszy niż większość — najczęściej używa się do tego siedemdziesiątego piątego centyla, czyli poziomu, poniżej którego mieści się trzy czwarte wizyt.
  • Ignorowanie stanu bufora. Odpowiedź z pamięci podręcznej i odpowiedź generowana od zera to dwa różne pomiary. Jeśli nie wiesz, który masz przed sobą, nie wiesz nic.

Do oceny stanu faktycznego używam danych od realnych użytkowników — z publicznego zbioru danych o doświadczeniu w przeglądarce Chrome albo z własnego pomiaru wbudowanego w stronę. Narzędzia laboratoryjne służą mi do szukania przyczyn i weryfikowania poprawek, nie do oceny, czy problem istnieje.

Co realnie skraca czas odpowiedzi

Kolejność, w której to zwykle rozwiązuję, od najczęściej skutecznych działań do najbardziej kosztownych.

Najpierw łańcuchy przekierowań i konfiguracja domeny, bo to zwykle godzina pracy i natychmiastowy efekt. Potem pełne buforowanie strony po stronie serwera dla ruchu anonimowego — w typowym serwisie opartym o system zarządzania treścią to największy pojedynczy zysk, jaki da się osiągnąć. Następnie warstwa pośrednicząca rozproszona geograficznie, szczególnie jeśli sprzedajesz poza jednym krajem.

Dalej idą rzeczy po stronie aplikacji: aktualna wersja środowiska uruchomieniowego z włączonym buforowaniem kodu, indeksy w bazie danych, eliminacja zapytań wykonywanych w pętli i przegląd wtyczek, z których część odpytuje zewnętrzne usługi przy każdym wczytaniu strony. Ten ostatni punkt bywa w praktyce najbardziej dochodowy, bo koszt takiej wtyczki jest niewidoczny do momentu, gdy usługa zewnętrzna zwolni.

Na końcu zostają zmiany infrastrukturalne: mocniejsze zasoby, oddzielenie bazy danych, nowsza wersja protokołu przesyłania. Kolejność jest tu nieprzypadkowa — przeniesienie na droższy serwer aplikacji, która wykonuje trzysta zapytań na wczytanie strony, poprawi wynik jednorazowo i o niewiele.

Kiedy to nie jest Twój problem SEO

Zamknę tym, co mówię klientom najczęściej, bo pozwala zaoszczędzić pieniądze.

Jeżeli czas odpowiedzi mieści się w granicach uznawanych za dobre, robot indeksuje serwis bez ograniczeń, a wskaźniki doświadczenia użytkownika wypadają poprawnie, to dalsza optymalizacja serwera nie jest działaniem SEO. Może być uzasadniona kosztami infrastruktury albo współczynnikiem konwersji, ale nie oczekuj po niej ruchu z wyszukiwarki.

W takiej sytuacji brak pozycji ma niemal zawsze inne wytłumaczenie: treść, która nie odpowiada na intencję zapytania, słaba struktura serwisu, kanibalizacja podstron albo profil linków nieproporcjonalny do konkurencji. Serwer jest wtedy wygodnym tematem zastępczym, bo problem daje się zamknąć w liczbie i zlecić komuś innemu.

Odwrotny przypadek też się zdarza i wtedy nie ma dyskusji: strona odpowiadająca po trzech sekundach, z regularnymi błędami serwera w godzinach szczytu, ma problem techniczny, który trzeba naprawić przed jakąkolwiek pracą nad treścią. Nie dlatego, że Google karze za wolny serwer, ale dlatego, że reszta działań na takim fundamencie po prostu się nie zwróci.

Podziel się tym artykułem z innymi!

Twitter Facebook Linke.din
Autor nie posiada zdjęcia
Tomasz Piasecki
Specjalista Google Ads / SEM
Zajmuję się kampaniami Google Ads i widocznością stron w wyszukiwarce. Na blogu UDI Group piszę o tym, jak ustawienia kampanii i decyzje techniczne przekładają się na realne wyniki. Staram się tłumaczyć mechanizmy, a nie tylko podawać gotowe przepisy.