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.
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.
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.
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.
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.
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.
Największym problemem w tej dyskusji nie jest interpretacja, tylko jakość pomiaru. Widzę cztery błędy, które powtarzają się niemal zawsze.
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.
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.
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.
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 |