TTFB, czyli czas do pierwszego bajtu, pokazuje, jak długo przeglądarka czeka na początek odpowiedzi serwera po rozpoczęciu wczytywania strony. Jeśli ten etap trwa zbyt długo, opóźnia się wszystko, co następuje po nim: pierwszy widoczny tekst, główne zdjęcie i moment, w którym klient może zacząć korzystać z serwisu. Poniżej wyjaśniamy, co składa się na ten wynik, gdzie go odczytać, skąd biorą się rozbieżności między pomiarami i w jakiej kolejności usuwać przyczyny.
Co dokładnie mierzy TTFB
TTFB (z angielskiego Time to First Byte, czas do pierwszego bajtu) mierzy czas od chwili, gdy rozpoczyna się przejście na stronę, do chwili, gdy do przeglądarki zaczyna docierać odpowiedź. Serwis web.dev opisuje ten wskaźnik jako podstawową miarę czasu zestawiania połączenia i szybkości reakcji serwera. Potocznie mówi się o nim "czas odpowiedzi serwera", choć w rzeczywistości sam serwer odpowiada tylko za część tego wyniku.
Na TTFB składa się kilka następujących po sobie etapów. Najpierw czas przekierowań, jeśli wpisany lub kliknięty adres odsyła pod inny. Potem uruchomienie skryptu service worker (mechanizmu przeglądarki, który może pośredniczyć w żądaniach), o ile strona go używa. Następnie wyszukanie adresu serwera w systemie DNS, nawiązanie połączenia wraz z uzgodnieniem szyfrowania TLS, a na końcu samo żądanie, liczone do momentu nadejścia pierwszego bajtu odpowiedzi. W tym ostatnim etapie mieści się praca serwera: uruchomienie kodu strony, zapytania do bazy danych i złożenie dokumentu HTML.
Z tego podziału wynika ważny wniosek praktyczny. Długi TTFB nie zawsze oznacza "wolny serwer". Równie dobrze winne może być zbędne przekierowanie, powolny dostawca DNS albo to, że klient z Gdańska łączy się z maszyną stojącą na innym kontynencie. Dlatego przed jakąkolwiek zmianą hostingu warto ustalić, który etap zabiera najwięcej czasu.
TTFB a pozostałe wskaźniki szybkości
W przypadku wczytywania strony TTFB poprzedza każdy inny istotny wskaźnik ładowania. Przeglądarka nie narysuje nagłówka ani zdjęcia, dopóki nie otrzyma początku dokumentu. Każda chwila oczekiwania na serwer dolicza się więc do czasu pierwszego wyrenderowania treści (FCP) i do czasu wyświetlenia największego elementu, który omawiamy we wpisie o przyczynach wolnego LCP.
Jaki wynik TTFB jest uznawany za dobry
Za dobry wynik web.dev uznaje TTFB wynoszący 0,8 sekundy lub mniej. Przedział od 0,8 do 1,8 sekundy oznacza, że strona wymaga poprawy, a wynik powyżej 1,8 sekundy jest oceniany jako słaby. Te same progi podaje dokumentacja PageSpeed Insights, w której TTFB występuje jako wskaźnik eksperymentalny.
| Ocena | Wartość TTFB | Co to zwykle oznacza |
|---|---|---|
| Dobry | do 0,8 s włącznie | Serwer i połączenie nie hamują ładowania; uwagę można skierować na inne wskaźniki. |
| Wymaga poprawy | powyżej 0,8 s do 1,8 s | Któryś etap trwa za długo; warto ustalić, czy to przekierowania, połączenie, czy praca serwera. |
| Słaby | powyżej 1,8 s | Oczekiwanie na serwer jest prawdopodobnie główną przeszkodą dla szybkiego wczytywania strony. |
Ocena odnosi się do 75. percentyla, czyli do wyniku, w którym mieści się trzy czwarte wizyt. Chodzi o to, aby dobry czas miała zdecydowana większość odwiedzających, a nie tylko osoby z szybkim łączem i nowym telefonem. Pojedynczy udany pomiar na komputerze w biurze o niczym jeszcze nie przesądza.
Progi mają charakter orientacyjny
Autorzy web.dev zaznaczają, że 0,8 sekundy to przybliżona wskazówka, a TTFB nie jest wskaźnikiem Core Web Vitals. Strona nie musi bezwzględnie mieścić się w tym progu, jeżeli dobrze wypada w tych miarach, które faktycznie opisują odczucia użytkownika. Przykładem są serwisy renderowane po stronie serwera: mogą mieć nieco wyższy TTFB, bo dokument powstaje dłużej, a mimo to szybciej pokazują treść niż aplikacja, która błyskawicznie wysyła pusty szkielet i dopiero potem buduje stronę skryptami w przeglądarce. O trzech podstawowych wskaźnikach piszemy szerzej w tekście o tym, jak poprawić Core Web Vitals na stronie firmy.
Czy TTFB wpływa na widoczność w Google
TTFB nie jest samodzielnym wskaźnikiem ocenianym w ramach Core Web Vitals, ale wpływa na widoczność pośrednio - przez wskaźniki, które od niego zależą, oraz przez tempo, w jakim roboty Google mogą pobierać podstrony. Google w omówieniu jakości strony potwierdza, że jego systemy rankingowe korzystają z Core Web Vitals, a jednocześnie zastrzega, że dobre wyniki nie gwarantują wysokich pozycji. Wyszukiwarka stara się pokazywać najtrafniejsze treści, nawet gdy jakość strony odbiega od ideału; wygoda korzystania nabiera znaczenia tam, gdzie o tę samą frazę rywalizuje wiele równie przydatnych stron.
Drugi wątek dotyczy robotów. W dokumentacji o budżecie indeksowania Google wyjaśnia, że limit pobierania zależy od kondycji serwera. Jeśli serwer odpowiada stabilnie i szybko, a czas do pierwszego bajtu się nie pogarsza, limit z czasem rośnie. Gdy odpowiedzi zwalniają albo pojawiają się błędy serwera, robot ogranicza liczbę pobrań. Google zaznacza przy tym, że zagadnienie dotyczy głównie bardzo dużych lub często aktualizowanych serwisów. Dla strony kancelarii z Krakowa, która ma kilkadziesiąt podstron, budżet indeksowania nie jest zmartwieniem; inaczej bywa w sklepie z Poznania z dziesiątkami tysięcy produktów i filtrów.
Szybka odpowiedź serwera jest więc warunkiem, aby pozostałe prace nad serwisem, prowadzone w ramach SEO technicznego, mogły przynieść skutek.
Jak zmierzyć TTFB w PageSpeed Insights
Najszybciej TTFB można odczytać w PageSpeed Insights, narzędziu Google dostępnym bez opłat i bez logowania pod adresem pagespeed.web.dev. Wystarczy wpisać adres badanej podstrony w pole na środku ekranu i uruchomić analizę przyciskiem obok. Po kilkunastu sekundach pojawia się raport z osobnymi wynikami dla telefonów i komputerów.
Raport składa się z dwóch części i warto je rozróżniać. Górna prezentuje dane o zachowaniu rzeczywistych użytkowników. Pochodzą one z Raportu na temat użytkowania Chrome (Chrome UX Report, w skrócie CrUX) i obejmują poprzednie 28 dni. W tej części, obok LCP, INP, CLS i FCP, widać pozycję Time to First Byte (TTFB) z dopiskiem, że jest to wskaźnik eksperymentalny. Podana wartość to 75. percentyl, a kolorowy pasek pokazuje, jaka część wizyt mieściła się w ocenie dobrej, wymagającej poprawy i słabej.
Dolna część to diagnostyka laboratoryjna. Narzędzie Lighthouse wczytuje stronę jeden raz w symulowanym środowisku: dla telefonów naśladuje urządzenie średniej klasy w sieci komórkowej, dla komputerów - maszynę z połączeniem przewodowym. Czasu serwera należy tu szukać wśród wskazówek dotyczących wydajności. Jak podaje dokumentacja Chrome, od Lighthouse 13 dawny audyt skrócenia czasu odpowiedzi serwera został włączony do wskazówki o opóźnieniu żądania dokumentu (w wersji angielskiej Document request latency).
Gdy brakuje danych od użytkowników
Małe strony często nie mają wystarczającej liczby wizyt, aby CrUX mógł pokazać wynik dla konkretnego adresu. Dokumentacja PageSpeed Insights wyjaśnia, że narzędzie sięga wtedy po dane dla całego źródła, czyli wszystkich podstron serwisu łącznie. Jeśli i tych jest za mało, górna część raportu pozostaje pusta. Taka sytuacja jest typowa dla świeżo uruchomionej strony hydraulika z Łodzi czy gabinetu z Kielc. Pozostaje wówczas pomiar laboratoryjny i panel Sieć przeglądarki. Niezależnie od tego warto badać nie tylko stronę główną, lecz po jednym adresie każdego rodzaju: kartę usługi lub produktu, kategorię i wpis na blogu.
Jak sprawdzić TTFB w panelu Sieć przeglądarki
Panel Sieć w narzędziach dla programistów przeglądarki Chrome pokazuje TTFB dla pojedynczego wczytania strony i, co najcenniejsze, rozbija ten czas na etapy. Dzięki temu widać, czy opóźnienie powstaje przy wyszukiwaniu adresu, przy nawiązywaniu połączenia, czy podczas oczekiwania na serwer. Nazwy poniżej podajemy w brzmieniu angielskim z dokumentacji Chrome DevTools; w polskiej wersji przeglądarki są one przetłumaczone i mogą się nieznacznie różnić między wydaniami.
- Otwarcie narzędzi i panelu Sieć
Na badanej stronie należy nacisnąć klawisz F12 albo wybrać z menu przeglądarki narzędzia dla programistów, a następnie przejść do panelu Sieć (Network).
- Wyłączenie pamięci podręcznej przeglądarki
Zaznaczenie pola Disable cache u góry panelu sprawia, że przeglądarka zachowuje się jak u osoby odwiedzającej stronę po raz pierwszy.
- Ponowne wczytanie strony
Po odświeżeniu na liście pojawiają się wszystkie żądania. Interesuje nas pierwsze z nich, czyli dokument HTML - zwykle nosi nazwę adresu strony.
- Odczytanie karty Timing
Kliknięcie tego żądania w kolumnie Name i przejście do karty Timing pokazuje rozkład czasu. Ten sam podgląd wyświetla się po najechaniu kursorem na pasek w kolumnie Waterfall.
Na karcie Timing widać kolejno: DNS Lookup, czyli ustalanie adresu IP serwera, Initial connection, czyli nawiązywanie połączenia razem z uzgodnieniem szyfrowania, Request sent, czyli wysłanie żądania, oraz Waiting (TTFB) - oczekiwanie na pierwszy bajt odpowiedzi. Dokumentacja precyzuje, że ten ostatni etap obejmuje jedną podróż danych do serwera i z powrotem oraz czas, w którym serwer przygotowuje odpowiedź. Ostatnia pozycja, Content Download, to pobieranie treści i do TTFB już się nie wlicza.
Tu trzeba zwrócić uwagę na różnicę w nazewnictwie. Wiersz Waiting (TTFB) w panelu Sieć pokazuje samą fazę oczekiwania dla jednego żądania. Wskaźnik TTFB w rozumieniu web.dev jest szerszy, bo liczy się od początku nawigacji, a więc razem z przekierowaniami, DNS i połączeniem. Jeżeli wpisany adres przekierowuje pod inny, w panelu pojawią się dwa lub trzy żądania dokumentu jedno po drugim i ich czasy trzeba dodać.
Dlaczego wynik TTFB różni się między pomiarami
Wyniki różnią się, ponieważ każde narzędzie mierzy co innego: dane od użytkowników opisują wiele wizyt z różnych urządzeń, sieci i miejscowości w ciągu 28 dni, a pomiar laboratoryjny to jedno wczytanie w sztucznych, stałych warunkach. Dokumentacja PageSpeed Insights wprost uprzedza, że z tego powodu obie wartości mogą się nie zgadzać. Żaden z tych wyników nie jest błędny - odpowiadają na różne pytania.
Kierunek różnicy bywa cenną podpowiedzią. Według wskazówek web.dev o optymalizacji TTFB wyraźnie wyższy wynik laboratoryjny sugeruje, że środowisko testowe jest bardziej ograniczone niż warunki, w jakich stronę oglądają klienci. Wyraźnie wyższy wynik u rzeczywistych użytkowników wskazuje natomiast na pamięć podręczną po stronie serwera, przekierowania albo różnice w sieci. Narzędzia laboratoryjne często badają bowiem ostateczny adres i nie widzą opóźnienia, które powstaje wcześniej, na przykład gdy klient trafia na stronę z reklamy przez adres śledzący.
W codziennej pracy spotykamy też przyczyny bardziej przyziemne. Pierwsze otwarcie rzadko odwiedzanej podstrony bywa wolniejsze od kolejnych, bo serwer dopiero buduje jej kopię w pamięci podręcznej. Na hostingu współdzielonym wynik zależy od pory dnia i obciążenia sąsiednich kont. Bezpieczniej jest więc porównywać stronę samą ze sobą: tym samym narzędziem, w podobnych warunkach, przed zmianą i po niej.
Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl
Co wydłuża TTFB po stronie serwera
Po stronie serwera TTFB wydłużają najczęściej trzy rzeczy: zbyt słaby lub przeciążony hosting, powolne zapytania do bazy danych oraz brak pamięci podręcznej, przez co każda wizyta wymaga zbudowania strony od zera. Te przyczyny zwykle występują razem i wzajemnie się potęgują.
Hosting
Web.dev radzi, aby wybór hostingu rozstrzygnąć przed innymi optymalizacjami i upewnić się, że usługa udźwignie ruch serwisu. Hosting współdzielony, na którym jedna maszyna obsługuje wiele kont, jest na ogół wolniejszy. Dla małej, w większości statycznej strony wizytówkowej bywa to w pełni wystarczające. Inaczej wygląda sytuacja serwisów rozbudowanych, z treścią dopasowywaną do użytkownika i intensywną pracą bazy danych, takich jak sklep internetowy. Tam znaczenie ma ilość pamięci przydzielonej do usługi, aktualność oprogramowania serwera (wersja języka, protokołu HTTP, silnika bazy) oraz to, czy dostawca pozwala na zmianę konfiguracji.
Baza danych i kod strony
W systemach takich jak WordPress, WooCommerce czy PrestaShop każda niezapisana w pamięci podręcznej wizyta uruchamia kod aplikacji i serię zapytań do bazy danych. Dokumentacja Lighthouse wymienia optymalizację logiki aplikacji i zapytań do bazy wśród podstawowych sposobów skrócenia czasu odpowiedzi. Podręcznik administracji WordPressa dodaje konkretne zalecenia: usuwanie zbędnych wtyczek, wyłączanie ich po kolei w celu ustalenia, która spowalnia serwis, porządkowanie bazy, ograniczenie liczby przechowywanych wersji wpisów oraz pilnowanie rozmiaru opcji ładowanych automatycznie przy każdej odsłonie.
Najbardziej wrażliwe są podstrony, których nie da się łatwo zapisać w pamięci podręcznej: koszyk, wyniki wyszukiwania w sklepie, listy produktów z wieloma filtrami, panel klienta. Jeśli właśnie tam TTFB jest wyraźnie gorszy niż na stronie głównej, przyczyny należy szukać w zapytaniach do bazy, a nie w łączu.
Brak pamięci podręcznej
Pamięć podręczna (cache) polega na tym, że raz przygotowana odpowiedź jest zapisywana i podawana kolejnym odwiedzającym bez ponownego wykonywania całej pracy. Podręcznik WordPressa opisuje kilka jej warstw. Pamięć całych stron zapisuje gotowe wpisy i podstrony jako pliki statyczne, dzięki czemu serwer nie przetwarza każdego żądania od początku. Trwała pamięć obiektów ogranicza liczbę odwołań do bazy po dane takie jak ustawienia serwisu, co według podręcznika poprawia czas do pierwszego bajtu i pomaga przetrwać nagłe wzrosty ruchu; wymaga jednak, aby hosting udostępniał odpowiedni serwer pamięci. Trzecia warstwa to pamięć skompilowanego kodu PHP, która przyspiesza samo wykonywanie skryptów.
Jak przekierowania i odległość od serwera wpływają na TTFB
Przekierowania i odległość wydłużają TTFB jeszcze zanim serwer zacznie przygotowywać stronę: każde przekierowanie to dodatkowe żądanie i dodatkowe oczekiwanie, a im dalej od użytkownika stoi serwer, tym dłużej dane podróżują w obie strony. Żadna optymalizacja bazy tego nie naprawi.
Przekierowania
Web.dev wskazuje przekierowania jako częste źródło opóźnień, szczególnie gdy układają się w łańcuch. Przekierowania w obrębie własnej domeny są w pełni pod kontrolą właściciela. Najczęściej wynikają z linku bez przedrostka https albo z niespójnego stosowania ukośnika na końcu adresu. Typowy łańcuch wygląda tak: adres z http odsyła do https, ten do wersji z www, a ta dopiero do wersji z ukośnikiem. Klient czeka trzy razy, zanim serwer w ogóle zacznie budować właściwą stronę.
Przekierowania między domenami są trudniejsze do opanowania, bo należą do zewnętrznych usług: skracaczy linków, systemów śledzenia kliknięć w reklamach i wiadomościach e-mail. Web.dev zaleca, aby nie łączyć kilku takich pośredników oraz aby w reklamach i newsletterach podawać poprawny, ostateczny adres. To istotne przy kampaniach Google Ads: jeśli adres docelowy reklamy prowadzi do wersji strony, która dopiero przekierowuje dalej, klient czeka dłużej, zanim cokolwiek zobaczy.
Dla przejścia z http na https istnieje dodatkowe ułatwienie. Nagłówek Strict-Transport-Security (HSTS) informuje przeglądarkę, że przy kolejnych wizytach ma od razu łączyć się w sposób szyfrowany, bez pośredniego przekierowania. Wiele przekierowań pojawia się też po zmianie adresów lub domeny, dlatego porządkowanie ich warto wpisać w plan, który opisujemy w tekście o migracji strony bez utraty pozycji.
Odległość użytkownika od serwera
Zanim nadejdzie pierwszy bajt, dane muszą kilka razy pokonać drogę między urządzeniem a serwerem: przy wyszukiwaniu w DNS, przy nawiązywaniu połączenia, przy uzgadnianiu szyfrowania i przy samym żądaniu. Jeżeli sklep z Bydgoszczy sprzedaje wyłącznie w Polsce, a jego serwer stoi za oceanem, każda z tych podróży trwa dłużej, niż musi. Dla firmy działającej lokalnie najprostszym rozwiązaniem jest serwerownia w kraju lub w jego pobliżu.
Gdy klienci są rozsiani po wielu krajach, pomaga sieć dostarczania treści (CDN, Content Delivery Network), czyli sieć serwerów pośredniczących rozmieszczonych w wielu miejscach, które przechowują kopie treści bliżej odbiorcy. Web.dev wymienia także inne korzyści takich sieci: szybkie odpowiedzi DNS, obsługę nowszych protokołów HTTP/2 i HTTP/3, nowoczesne szyfrowanie TLS 1.3 zaprojektowane tak, aby uzgadnianie trwało krótko, oraz kompresję. Autorzy zalecają, aby wdrożenie CDN miało wysoki priorytet w serwisach, które jeszcze z niego nie korzystają. Ma to szczególne znaczenie przy pozycjonowaniu zagranicznym, gdy jeden serwis obsługuje odbiorców z kilku rynków.
| Objaw | Prawdopodobna przyczyna | Gdzie to potwierdzić |
|---|---|---|
| Kilka żądań dokumentu przed właściwą stroną | Łańcuch przekierowań | Panel Sieć: odpowiedzi 301 lub 302 na początku listy |
| Długie DNS Lookup lub Initial connection | Powolny DNS albo odległy serwer | Karta Timing pierwszego żądania |
| Długie Waiting (TTFB) na każdej podstronie | Przeciążony hosting lub brak pamięci podręcznej | Karta Timing, pomiary o różnych porach dnia |
| Długie Waiting (TTFB) tylko na wybranych podstronach | Ciężkie zapytania do bazy lub jedna z wtyczek | Porównanie rodzajów podstron, nagłówek Server-Timing |
| Pierwsze wejście wolne, kolejne szybkie | Podstrona nie ma kopii w pamięci podręcznej | Dwa pomiary tej samej podstrony jeden po drugim |
Jak skrócić TTFB i od czego zacząć
Prace nad TTFB warto zacząć od pomiaru i ustalenia, który etap trwa najdłużej, a dopiero potem sięgać po rozwiązania - od najprostszych i odwracalnych do najbardziej kosztownych. Web.dev opisuje ten sam porządek: zmierzyć TTFB u rzeczywistych użytkowników, narzędziami laboratoryjnymi znaleźć przyczynę, a następnie zastosować te usprawnienia, które pasują do danej strony. Nie ma jednego rozwiązania dobrego dla każdego serwisu.
W większości firmowych stron i sklepów rozsądna kolejność wygląda następująco. Najpierw przekierowania, bo ich uporządkowanie jest tanie i mało ryzykowne: linki wewnętrzne, mapa witryny, adresy w reklamach i w Profilu Firmy powinny prowadzić od razu do ostatecznej wersji adresu. Następnie pamięć podręczna całych stron, która w naszej praktyce zwykle daje największą różnicę przy najmniejszym nakładzie. Potem porządki w samym systemie: przegląd wtyczek, aktualizacja wersji PHP, czyszczenie bazy. Dalej pamięć obiektów i sieć CDN. Zmiana hostingu jest na końcu tej listy nie dlatego, że ma najmniejsze znaczenie, lecz dlatego, że warto ją podejmować ze świadomością, czego dokładnie brakuje obecnej usłudze. Dla stron na WordPressie dokumentacja Lighthouse podaje zbliżoną listę: lekki motyw blokowy, pamięć podręczna całych stron, mniejsza liczba wtyczek oraz hosting zarządzany lub dedykowany.
- Adres wpisany bez https i bez www trafia do wersji docelowej jednym przekierowaniem, a nie łańcuchem.
- Linki w menu, stopce, mapie witryny i reklamach wskazują ostateczne adresy.
- Działa pamięć podręczna całych stron dla niezalogowanych odwiedzających.
- Parametry dopisywane do adresów przez systemy reklamowe nie powodują pomijania pamięci podręcznej.
- Zbędne wtyczki i moduły są usunięte, a pozostałe aktualne.
- Serwer znajduje się blisko głównej grupy klientów albo serwis korzysta z CDN.
- Pomiar po każdej zmianie wykonano tym samym narzędziem i na tych samych podstronach.
Pamięć podręczna - na co uważać
Web.dev zwraca uwagę na kilka szczegółów, które decydują o skuteczności pamięci podręcznej. Nawet krótki czas przechowywania kopii pomaga ruchliwym serwisom, bo na serwer źródłowy czeka tylko pierwszy odwiedzający. Rzadziej otwierane podstrony mogą nie mieć kopii i wtedy ich TTFB jest wyższy; dłuższy czas przechowywania temu zaradza, ale zwiększa ryzyko pokazania nieaktualnej treści, na przykład starej ceny. Niepowtarzalne parametry w adresie, dopisywane przez narzędzia analityczne i reklamowe, mogą sprawiać, że identyczna strona jest za każdym razem budowana od nowa. Treści dopasowanych do konkretnej osoby, takich jak koszyk czy panel klienta, w ogóle nie należy zapisywać we wspólnej pamięci.
Nagłówek Server-Timing, czyli wgląd w pracę serwera
Gdy panel Sieć pokazuje długie oczekiwanie, ale nie wiadomo, co dokładnie zajmuje serwer, pomaga nagłówek Server-Timing. Programista może w nim przekazać, ile trwały poszczególne czynności: zapytania do bazy, składanie strony, odczyt z dysku, trafienie lub pudło w pamięci CDN. Wartości te wyświetlają się w panelu Sieć przy rozkładzie czasu żądania. Dla właściciela firmy to przede wszystkim informacja, o co poprosić wykonawcę: taki rozkład pozwala rozstrzygnąć, czy potrzebny jest mocniejszy serwer, czy poprawa kodu.
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2Typowe pomyłki przy ocenie TTFB i kiedy potrzebna jest pomoc
Najczęstszą pomyłką jest wyciąganie wniosków z jednego pomiaru jednej podstrony i podejmowanie na tej podstawie kosztownej decyzji, na przykład o zmianie hostingu. TTFB jest wskaźnikiem zmiennym, dlatego wiarygodny obraz daje dopiero kilka pomiarów różnych rodzajów podstron, zestawionych z danymi od rzeczywistych użytkowników.
Druga pomyłka to badanie strony po zalogowaniu do panelu administracyjnego. Zalogowany użytkownik zwykle omija pamięć podręczną, więc widzi wynik gorszy od tego, który mają klienci. Pomiar należy wykonać w oknie incognito albo w PageSpeed Insights. Trzecia to mylenie wiersza Waiting (TTFB) z pełnym wskaźnikiem i pomijanie przekierowań, które w panelu Sieć występują jako osobne żądania. Czwarta - porównywanie wyniku audytu Lighthouse z progiem 0,8 sekundy, choć oba mierzą inny zakres.
Zdarza się też odwrotna skrajność: poświęcanie tygodni na zbijanie TTFB, który już mieści się w dobrej ocenie, podczas gdy klientów zniechęca co innego, na przykład opóźniona reakcja strony na kliknięcie albo przeskakujący układ.
Pomoc specjalisty jest potrzebna wtedy, gdy przyczyna leży w kodzie lub konfiguracji serwera: długie oczekiwanie utrzymuje się mimo działającej pamięci podręcznej, wynik pogarsza się tylko na części podstron, serwis zwalnia przy większym ruchu albo planowana jest przeprowadzka. Zmiana serwera wymaga starannego przeniesienia plików, bazy, poczty i ustawień DNS, dlatego najlepiej połączyć ją z uporządkowaną migracją domeny i hostingu. Jeśli nie wiadomo, od czego zacząć, dobrym punktem wyjścia jest audyt SEO, który zestawia czas odpowiedzi serwera z pozostałymi problemami technicznymi i ustala ich kolejność.
Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl
Najczęstsze pytania
Czy TTFB jest czynnikiem rankingowym Google?
TTFB nie należy do Core Web Vitals, z których według dokumentacji Google korzystają systemy rankingowe. Poprzedza jednak pozostałe wskaźniki ładowania, w tym LCP, więc wpływa na nie bezpośrednio. Google zastrzega też, że dobre wyniki jakości strony nie gwarantują wysokich pozycji.
Ile powinien wynosić TTFB?
Web.dev za dobry uznaje wynik 0,8 sekundy lub mniej, liczony dla 75. percentyla wizyt. Wynik powyżej 1,8 sekundy jest oceniany jako słaby. To progi orientacyjne - ważniejsze jest, aby strona dobrze wypadała we wskaźnikach opisujących odczucia użytkownika.
Dlaczego PageSpeed Insights nie pokazuje TTFB dla strony firmy?
Część z danymi od rzeczywistych użytkowników pojawia się tylko wtedy, gdy Raport na temat użytkowania Chrome zebrał wystarczająco dużo wizyt. Przy małym ruchu narzędzie próbuje pokazać dane dla całego serwisu, a gdy i tych brakuje, część ta pozostaje pusta. Pozostaje wtedy pomiar laboratoryjny i panel Sieć przeglądarki.
Czy zmiana hostingu zawsze skraca TTFB?
Nie zawsze. Jeśli opóźnienie wynika z łańcucha przekierowań, braku pamięci podręcznej albo ciężkich zapytań do bazy, nowy serwer może przynieść niewielką poprawę. Dlatego przed przeprowadzką warto ustalić w panelu Sieć, który etap trwa najdłużej.
Czy sieć CDN jest potrzebna małej lokalnej firmie?
Jeśli klienci pochodzą z jednego kraju, a serwer stoi w nim lub w pobliżu, odległość rzadko jest głównym problemem. CDN może mimo to pomóc dzięki szybkim odpowiedziom DNS, nowszym protokołom i przechowywaniu kopii stron. Największą różnicę daje serwisom z odbiorcami w wielu krajach.
Czy pamięć podręczna może zaszkodzić stronie?
Źle ustawiona może pokazywać nieaktualne treści, na przykład starą cenę, albo zapisać stronę, która powinna być inna dla każdego klienta, jak koszyk. Dlatego podstrony z danymi osobistymi wyłącza się z zapisu, a po zmianach treści kopie należy odświeżać.
Źródła
- Time to First Byte (TTFB), web.dev
- Optimize Time to First Byte, web.dev
- O narzędziu PageSpeed Insights, Google for Developers
- Reduce server response times, Chrome for Developers
- Network features reference, Chrome for Developers
- Omówienie jakości strony z uwzględnieniem wymagań Google, Centrum wyszukiwarki Google
- Zarządzanie budżetem indeksowania, Google for Developers
- Optimization - Advanced Administration Handbook, Developer.WordPress.org
Funkcje wyszukiwarek i asystentów AI zmieniają się szybko, dlatego wpis aktualizujemy po większych zmianach.
