Dowiedz się, jak zoptymalizować czas do pierwszego bajtu.
Data publikacji: 19 stycznia 2023 r., ostatnia aktualizacja: 28 listopada 2025 r.
Czas do pierwszego bajtu (TTFB) to podstawowy wskaźnik skuteczności witryny, który poprzedza wszystkie inne istotne wskaźniki wrażeń użytkownika, takie jak pierwsze wyrenderowanie treści (FCP) i największe wyrenderowanie treści (LCP). Oznacza to, że wysokie wartości TTFB wydłużają czas wskaźników, które po nim następują.
Zalecamy, aby serwer odpowiadał na żądania nawigacji wystarczająco szybko, aby 75% użytkowników doświadczało FCP w zakresie „dobry”. W większości witryn wskaźnik TTFB powinien wynosić 0, 8 sekundy lub mniej.
Jak mierzyć TTFB
Zanim zoptymalizujesz TTFB, musisz sprawdzić, jak wpływa on na użytkowników witryny. Jako główne źródło obserwacji TTFB należy wykorzystywać dane zgromadzone, ponieważ wpływają na nie przekierowania, podczas gdy narzędzia laboratoryjne często mierzą czas na podstawie końcowego adresu URL, przez co nie uwzględniają tego dodatkowego opóźnienia.
PageSpeed Insights to jeden ze sposobów na uzyskanie informacji z pól i laboratorium dotyczących publicznych witryn, które są dostępne w Raporcie na temat użytkowania Chrome.
Wskaźnik TTFB dla rzeczywistych użytkowników jest widoczny w górnej sekcji Sprawdź, jakie są wrażenia rzeczywistych użytkowników:
W przypadku danych laboratoryjnych problemy z TTFB są widoczne w statystykach Czas oczekiwania w przypadku żądania dokumentu:
Więcej informacji o sposobach pomiaru TTFB w środowisku i w laboratorium znajdziesz na stronie ze wskaźnikiem TTFB.
Różnice między wartościami TTFB w środowisku produkcyjnym i laboratoryjnym
Wskaźnik TTFB może się różnić w przypadku danych laboratoryjnych i danych z testów w terenie z wielu powodów. Gdy tak się dzieje, ważne jest, aby zrozumieć, dlaczego tak jest, aby móc skutecznie wykorzystywać dane laboratoryjne do poprawy wrażeń użytkowników.
Jeśli laboratoryjny TTFB jest znacznie większy niż TTFB w środowisku produkcyjnym, oznacza to, że środowisko laboratoryjne jest bardziej ograniczone niż typowe środowisko użytkownika. Nie musi to być problemem, ponieważ wyniki i rekomendacje z laboratorium są nadal prawidłowe, ale mogą wyolbrzymiać wpływ i poprawę.
Jeśli wskaźnik TTFB w terenie jest znacznie większy niż w laboratorium, oznacza to, że występują problemy, które nie są widoczne w laboratorium, takie jak użycie buforowania po stronie serwera, przekierowania lub różnice w sieci. W takim przypadku wyniki i rekomendacje modułu mogą być mniej przydatne, ponieważ nie uwzględniają jednego z głównych problemów.
Aby sprawdzić, czy buforowanie po stronie serwera wpływa na TTFB w laboratorium, przetestuj mniej popularne strony lub użyj innych parametrów adresu URL, aby uzyskać niebuforowane treści i sprawdzić, czy TTFB jest bardziej zbliżony do TTFB w środowisku produkcyjnym. Przydatna może być też możliwość pominięcia pamięci podręcznej po stronie serwera za pomocą określonego parametru adresu URL. Zobacz sekcję dotyczącą treści z pamięci podręcznej.
W przypadku przekierowań i różnic w sieciach analiza sposobu, w jaki ruch trafia do naszej witryny, oraz jego źródeł może być przydatna do zdiagnozowania potencjalnych problemów.
Debugowanie wysokiego wskaźnika TTFB w terenie za pomocą Server-Timing
Nagłówek odpowiedzi Server-Timing może być używany w backendzie aplikacji do pomiaru różnych procesów backendu, które mogą przyczyniać się do wysokiego czasu oczekiwania. Struktura wartości nagłówka jest elastyczna i akceptuje co najmniej zdefiniowany przez Ciebie uchwyt. Opcjonalne wartości obejmują wartość czasu trwania (za pomocą dur) oraz opcjonalny opis zrozumiały dla człowieka (za pomocą desc).
Serving-Timing może służyć do pomiaru wielu procesów backendu aplikacji, ale na niektóre z nich warto zwrócić szczególną uwagę:
- Zapytania do bazy danych
- Czas renderowania po stronie serwera (jeśli dotyczy)
- Liczba wyszukań na dysku
- trafienia lub chybienia w pamięci podręcznej serwera brzegowego (jeśli używasz sieci CDN);
Wszystkie części wpisu Server-Timing są oddzielone dwukropkiem, a poszczególne wpisy można oddzielić przecinkiem:
// Two metrics with descriptions and values
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2
Nagłówek można ustawić za pomocą wybranego języka backendu aplikacji. W języku PHP możesz na przykład ustawić nagłówek w ten sposób:
<?php
// Get a high-resolution timestamp before
// the database query is performed:
$dbReadStartTime = hrtime(true);
// Perform a database query and get results...
// ...
// Get a high-resolution timestamp after
// the database query is performed:
$dbReadEndTime = hrtime(true);
// Get the total time, converting nanoseconds to
// milliseconds (or whatever granularity you need):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStartTime) / 1e+6;
// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>
Gdy ten nagłówek jest ustawiony, wyświetla informacje, których możesz używać zarówno w laboratorium, jak i w terenie.
W terenie każda strona z ustawionym nagłówkiem odpowiedzi Server-Timing wypełnia właściwość serverTiming w interfejsie Navigation Timing API:
// Get the serverTiming entry for the first navigation request:
performance.getEntries('navigation')[0].serverTiming.forEach(entry => {
// Log the server timing data:
console.log(entry.name, entry.description, entry.duration);
});
W module dane z nagłówka odpowiedzi Server-Timing są wizualizowane w panelu Czasy na karcie Sieć w Narzędziach deweloperskich w Chrome:
W tym przypadku Server-Timing służy do pomiaru, czy żądanie zasobu trafiło do pamięci podręcznej CDN oraz ile czasu zajmuje żądaniu dotarcie do serwera brzegowego CDN, a następnie do źródła.
Czasy serwera są też widoczne na ścieżce Sieć w panelu Wydajność w Narzędziach deweloperskich w Chrome:
Gdy po przeanalizowaniu dostępnych danych stwierdzisz, że masz problem z TTFB, możesz przystąpić do jego rozwiązania.
Sposoby optymalizacji TTFB
Najtrudniejszym aspektem optymalizacji TTFB jest to, że chociaż stos frontendu sieci zawsze składa się z HTML, CSS i JavaScriptu, stosy backendu mogą się znacznie różnić. Istnieje wiele stosów backendu i usług baz danych, z których każda ma własne techniki optymalizacji. Dlatego ten przewodnik skupia się na tym, co dotyczy większości architektur, a nie tylko na wskazówkach dotyczących konkretnego stosu.
Wskazówki dotyczące poszczególnych platform
Platforma, której używasz do obsługi witryny, może mieć duży wpływ na TTFB. Na przykład na wydajność WordPressa wpływa liczba i jakość wtyczek oraz używane motywy. Inne platformy są podobnie dotknięte, gdy platforma jest dostosowywana. Więcej informacji znajdziesz w dokumentacji platformy, gdzie znajdziesz porady dotyczące konkretnego dostawcy, które uzupełniają ogólne porady dotyczące wydajności zawarte w tym poście. Statystyki Lighthouse zawierają też pewne ograniczone wskazówki dotyczące stosu.
Hosting, hosting, hosting
Zanim rozważysz inne metody optymalizacji, najpierw pomyśl o hostingu. Nie możemy udzielić Ci konkretnych wskazówek, ale ogólna zasada jest taka, że host witryny musi być w stanie obsłużyć ruch, który do niego wysyłasz.
Hosting współdzielony jest zwykle wolniejszy. Jeśli prowadzisz małą osobistą witrynę, która obsługuje głównie pliki statyczne, prawdopodobnie nie będzie to problemem. Aby jak najbardziej skrócić TTFB, zastosuj niektóre z poniższych technik optymalizacji.
Jeśli jednak prowadzisz większą aplikację z wieloma użytkownikami, która obejmuje personalizację, zapytania do bazy danych i inne intensywne operacje po stronie serwera, wybór hostingu staje się kluczowy dla obniżenia TTFB w terenie.
Przy wyborze dostawcy usług hostingowych zwróć uwagę na te kwestie:
- Ile pamięci przydzielono instancji aplikacji? Jeśli aplikacja nie ma wystarczającej ilości pamięci, będzie działać wolno i nie będzie w stanie wyświetlać stron tak szybko, jak to możliwe.
- Czy dostawca usług hostingowych dba o aktualność stosu backendu? W miarę wydawania nowych wersji języków backendu aplikacji, implementacji HTTP i oprogramowania baz danych wydajność tego oprogramowania z czasem się poprawia. Ważne jest, aby współpracować z dostawcą usług hostingowych, który traktuje priorytetowo tego rodzaju kluczowe czynności konserwacyjne.
- Jeśli masz bardzo konkretne wymagania dotyczące aplikacji i chcesz mieć dostęp do plików konfiguracji serwera na najniższym poziomie, zapytaj, czy warto dostosować backend instancji aplikacji.
Jest wielu dostawców usług hostingowych, którzy zajmują się tymi kwestiami, ale jeśli zaczniesz obserwować długie wartości TTFB nawet u dedykowanych dostawców usług hostingowych, może to oznaczać, że musisz ponownie ocenić możliwości obecnego dostawcy usług hostingowych, aby zapewnić użytkownikom jak najlepsze wrażenia.
Używanie sieci dostarczania treści (CDN)
Temat korzystania z sieci CDN jest dobrze znany, ale nie bez powodu: możesz mieć bardzo dobrze zoptymalizowany backend aplikacji, ale użytkownicy znajdujący się daleko od serwera pierwotnego mogą nadal doświadczać wysokiego TTFB w praktyce.
Sieci CDN rozwiązują problem odległości użytkownika od serwera pierwotnego, korzystając z rozproszonej sieci serwerów, które przechowują zasoby w pamięci podręcznej na serwerach znajdujących się fizycznie bliżej użytkowników. Te serwery są nazywane serwerami brzegowymi.
Dostawcy sieci CDN mogą też oferować korzyści wykraczające poza serwery brzegowe:
- Dostawcy CDN zwykle oferują bardzo szybkie rozpoznawanie nazw DNS.
- Sieć CDN prawdopodobnie udostępnia treści z serwerów brzegowych przy użyciu nowoczesnych protokołów, takich jak HTTP/2 lub HTTP/3.
- HTTP/3 rozwiązuje problem blokowania początku kolejki, który występuje w TCP (na którym opiera się HTTP/2), dzięki użyciu protokołu UDP.
- Sieć CDN prawdopodobnie udostępnia nowoczesne wersje protokołu TLS, co zmniejsza opóźnienia związane z czasem negocjacji TLS. TLS 1.3 został zaprojektowany tak, aby negocjacje TLS były jak najkrótsze.
- Niektórzy dostawcy sieci CDN udostępniają funkcję często nazywaną „edge worker”, która używa interfejsu API podobnego do interfejsu skryptu service worker API do przechwytywania żądań, zautomatyzowanego zarządzania odpowiedziami w tymczasowym przechowywaniu danych na serwerach brzegowych lub całkowitego przepisywania odpowiedzi.
- Dostawcy sieci CDN są bardzo dobrzy w optymalizacji kompresji. Samodzielne skonfigurowanie kompresji jest trudne i w niektórych przypadkach może prowadzić do dłuższego czasu odpowiedzi, gdy znaczniki są generowane dynamicznie i muszą być kompresowane na bieżąco.
- Dostawcy CDN automatycznie zapisują też w pamięci podręcznej skompresowane odpowiedzi dotyczące zasobów statycznych, co pozwala uzyskać najlepszy współczynnik kompresji i czas odpowiedzi.
Wdrożenie sieci CDN może wymagać różnego nakładu pracy – od niewielkiego do znacznego. Jeśli jednak Twoja witryna nie korzysta jeszcze z takiej sieci, powinno to być priorytetem w optymalizacji wskaźnika TTFB.
W miarę możliwości używaj treści z pamięci podręcznej.
Sieci CDN umożliwiają przechowywanie treści w pamięci podręcznej na serwerach brzegowych, które znajdują się fizycznie bliżej użytkowników, pod warunkiem że treści są skonfigurowane z odpowiednimi nagłówkami HTTP Cache-Control. Chociaż nie jest to odpowiednie w przypadku treści spersonalizowanych, konieczność powrotu do punktu początkowego może zniweczyć dużą część korzyści płynących z używania sieci CDN.
W przypadku witryn, które często aktualizują swoje treści, nawet krótki czas przechowywania w pamięci podręcznej może przynieść zauważalny wzrost wydajności, ponieważ tylko pierwszy użytkownik w tym czasie doświadcza pełnego opóźnienia w powrocie do serwera pierwotnego, podczas gdy wszyscy pozostali użytkownicy mogą ponownie użyć zasobu z pamięci podręcznej z serwera brzegowego. Niektóre sieci CDN umożliwiają unieważnienie pamięci podręcznej podczas publikowania witryny, co pozwala na korzystanie z obu tych rozwiązań – długiego czasu przechowywania w pamięci podręcznej, ale natychmiastowych aktualizacji w razie potrzeby.
Nawet jeśli buforowanie jest prawidłowo skonfigurowane, można je zignorować, używając unikalnych parametrów ciągu zapytania do pomiarów analitycznych. Dla sieci CDN mogą one wyglądać jak różne treści, mimo że są takie same, więc wersja z pamięci podręcznej nie zostanie użyta.
Starsze lub rzadziej odwiedzane treści mogą nie być zapisywane w pamięci podręcznej, co może powodować wyższe wartości TTFB na niektórych stronach. Wydłużenie czasu buforowania może zmniejszyć wpływ tego problemu, ale pamiętaj, że im dłuższy czas buforowania, tym większe prawdopodobieństwo wyświetlania potencjalnie nieaktualnych treści.
Wpływ treści przechowywanych w pamięci podręcznej nie dotyczy tylko tych, którzy korzystają z sieci CDN. Infrastruktura serwera może wymagać generowania treści z kosztownych wyszukiwań w bazie danych, gdy nie można ponownie użyć treści z pamięci podręcznej. Częściej używane dane lub strony zapisane we wstępnej pamięci podręcznej mogą często działać lepiej.
Unikaj wielokrotnych przekierowań
Jedną z częstych przyczyn wysokiego wskaźnika TTFB są przekierowania. Przekierowania występują, gdy żądanie nawigacji dotyczące dokumentu otrzymuje odpowiedź informującą przeglądarkę, że zasób znajduje się w innym miejscu. Jedno przekierowanie może z pewnością zwiększyć niepożądane opóźnienie żądania nawigacji, ale może być jeszcze gorzej, jeśli to przekierowanie wskazuje na inny zasób, który powoduje kolejne przekierowanie itd. Może to mieć wpływ zwłaszcza na witryny, które odwiedza wielu użytkowników z reklam lub newsletterów, ponieważ często przekierowują one użytkowników przez usługi analityczne w celach pomiarowych. W uzyskaniu dobrego wyniku TTFB może pomóc wyeliminowanie przekierowań, które są pod Twoją bezpośrednią kontrolą.
Istnieją 2 rodzaje przekierowań:
- Przekierowania w ramach tej samej domeny, w przypadku których przekierowanie następuje całkowicie w Twojej witrynie.
- Przekierowania między domenami, w przypadku których przekierowanie następuje najpierw w innej domenie (np. z usługi skracania adresów URL w mediach społecznościowych), zanim użytkownik trafi do Twojej witryny.
Skup się na eliminowaniu przekierowań w tej samej domenie, ponieważ masz nad nimi bezpośrednią kontrolę. Obejmuje to sprawdzenie linków w witrynie, aby zobaczyć, czy któryś z nich nie zwraca kodu odpowiedzi 302 lub 301. Często może to być spowodowane brakiem schematu https:// (więc przeglądarki domyślnie używają http://, który następnie przekierowuje) lub brakiem odpowiedniego uwzględnienia lub wykluczenia ukośników na końcu adresu URL.
Przekierowania między domenami są trudniejsze, ponieważ często nie masz nad nimi kontroli, ale staraj się unikać wielokrotnych przekierowań, gdy jest to możliwe – na przykład przez używanie wielu skracaczy linków podczas udostępniania linków. Upewnij się, że adres URL podany reklamodawcom lub w newsletterach jest prawidłowym końcowym adresem URL, aby nie dodawać kolejnego przekierowania do tych, które są używane przez te usługi.
Innym ważnym źródłem czasu przekierowania mogą być przekierowania z HTTP na HTTPS. Jednym ze sposobów na obejście tego problemu jest użycie nagłówka Strict-Transport-Security (HSTS), który wymusza użycie protokołu HTTPS podczas pierwszej wizyty w źródle, a następnie informuje przeglądarkę, aby podczas kolejnych wizyt natychmiast uzyskiwała dostęp do źródła za pomocą protokołu HTTPS.
Gdy masz już odpowiednie zasady HSTS, możesz przyspieszyć pierwszą wizytę w źródle, dodając witrynę do listy wstępnego wczytywania HSTS.
Przesyłanie znaczników do przeglądarki
Przeglądarki są zoptymalizowane pod kątem wydajnego przetwarzania znaczników, gdy są one przesyłane strumieniowo, co oznacza, że znaczniki są przetwarzane we fragmentach, gdy docierają z serwera. Jest to kluczowe w przypadku dużych ładunków znaczników, ponieważ oznacza, że przeglądarka może analizować fragmenty znaczników przyrostowo, zamiast czekać na całą odpowiedź, zanim będzie mogła rozpocząć analizę.
Chociaż przeglądarki świetnie radzą sobie z obsługą znaczników strumieniowych, ważne jest, aby zrobić wszystko, co możliwe, aby utrzymać ten strumień, tak aby te początkowe fragmenty znaczników były jak najszybciej przesyłane. Jeśli backend powoduje opóźnienia, jest to problem. Ponieważ stosów backendu jest wiele, omówienie każdego z nich i problemów, które mogą się w nich pojawić, wykracza poza zakres tego przewodnika.
React i inne platformy, które mogą renderować znaczniki na żądanie na serwerze, stosują synchroniczne podejście do renderowania po stronie serwera. Nowsze wersje Reacta mają jednak zaimplementowane metody serwerowe do przesyłania strumieniowego znaczników podczas ich renderowania. Oznacza to, że nie musisz czekać, aż metoda interfejsu API serwera React wyrenderuje całą odpowiedź, zanim zostanie ona wysłana.
Innym sposobem na szybkie przesyłanie znaczników do przeglądarki jest korzystanie z renderowania statycznego, które generuje pliki HTML podczas kompilacji. Gdy cały plik jest od razu dostępny, serwery WWW mogą natychmiast rozpocząć jego wysyłanie, a wrodzona natura protokołu HTTP powoduje, że znaczniki są przesyłane strumieniowo. To podejście nie jest odpowiednie dla każdej strony w każdej witrynie – np. dla stron, które wymagają dynamicznej odpowiedzi w ramach wygody użytkownika – ale może być korzystne w przypadku stron, które nie wymagają personalizacji znaczników pod kątem konkretnego użytkownika.
Używanie skryptu service worker
Interfejs Service Worker API może mieć duży wpływ na TTFB zarówno w przypadku dokumentów, jak i zasobów, które są przez nie wczytywane. Dzieje się tak, ponieważ skrypt service worker działa jako serwer proxy między przeglądarką a serwerem. To, czy ma on wpływ na TTFB witryny, zależy od sposobu jego skonfigurowania i od tego, czy konfiguracja jest zgodna z wymaganiami aplikacji.
- Używaj strategii stale-while-revalidate w przypadku zasobów. Jeśli zasób znajduje się w pamięci podręcznej skryptu service worker, niezależnie od tego, czy jest to dokument, czy zasób wymagany przez dokument, strategia stale-while-revalidate obsługuje ten zasób z pamięci podręcznej najpierw, a następnie pobiera go w tle i obsługuje z pamięci podręcznej na potrzeby przyszłych interakcji.
- Jeśli masz zasoby dokumentów, które nie zmieniają się zbyt często, użycie strategii stale-while-revalidate może sprawić, że TTFB strony będzie niemal natychmiastowy. Nie działa to jednak zbyt dobrze, jeśli witryna wysyła dynamicznie generowane znaczniki, np. znaczniki, które zmieniają się w zależności od tego, czy użytkownik jest uwierzytelniony. W takich przypadkach zawsze warto najpierw sprawdzić sieć, aby dokument był jak najbardziej aktualny.
- Jeśli dokument wczytuje niekrytyczne zasoby, które zmieniają się z pewną częstotliwością, ale pobranie nieaktualnego zasobu nie wpłynie znacząco na wrażenia użytkownika (np. wybrane obrazy lub inne zasoby, które nie są krytyczne), TTFB tych zasobów można znacznie skrócić, stosując strategię stale-while-revalidate.
- W przypadku aplikacji renderowanych po stronie klienta używaj modelu powłoki aplikacji. Ten model najlepiej sprawdza się w przypadku aplikacji jednostronicowych, w których „powłoka” strony może być dostarczana natychmiast z pamięci podręcznej skryptu service worker, a zawartość dynamiczna strony jest wypełniana i renderowana później w cyklu życia strony.
Używaj 103 Early Hints w przypadku zasobów o kluczowym znaczeniu dla renderowania
Niezależnie od tego, jak dobrze zoptymalizowany jest backend aplikacji, serwer może nadal mieć dużo pracy, aby przygotować odpowiedź, w tym kosztowne (ale konieczne) operacje na bazie danych, które opóźniają nadejście odpowiedzi nawigacyjnej. Może to spowodować opóźnienie niektórych kolejnych zasobów krytycznych dla renderowania, takich jak CSS lub (w niektórych przypadkach) JavaScript, który renderuje znaczniki po stronie klienta.
Nagłówek 103 Early Hints to kod wczesnej odpowiedzi, który serwer może wysłać do przeglądarki, gdy backend jest zajęty przygotowywaniem znaczników. Ten nagłówek może służyć do informowania przeglądarki, że istnieją zasoby o kluczowym znaczeniu dla renderowania, które strona powinna zacząć pobierać podczas przygotowywania znaczników. W przypadku obsługiwanych przeglądarek może to przyspieszyć renderowanie dokumentów (CSS) i wczytywanie stron.
Jedną z wad 103 Early Hints jest to, że podobnie jak buforowanie mogą maskować „rzeczywisty” TTFB witryny. Jeśli infrastruktura serwera jest powolna (ponieważ jest zbyt słaba lub kod wymaga optymalizacji), może to być mniej oczywiste, gdy używane są wskazówki 103 Early Hints, ponieważ TTFB wydaje się szybki. Witryny korzystające z kodów 103 Early Hints powinny rozważyć pomiar rzeczywistego czasu serwera (za pomocą Server-Timing lub finalResponseHeadersStart w interfejsie PerformanceNavigationTiming API).
Podsumowanie
Istnieje wiele kombinacji stosów aplikacji backendowych, dlatego nie ma jednego artykułu, który zawierałby wszystkie informacje o tym, co można zrobić, aby obniżyć TTFB witryny. Możesz jednak wypróbować kilka opcji, aby nieco przyspieszyć działanie po stronie serwera.
Podobnie jak w przypadku optymalizacji wszystkich danych, podejście jest w dużej mierze podobne: zmierz TTFB w terenie, użyj narzędzi laboratoryjnych, aby zbadać przyczyny, a następnie zastosuj optymalizacje tam, gdzie to możliwe. Niektóre techniki mogą nie być odpowiednie w Twojej sytuacji, ale inne prawdopodobnie tak. Jak zawsze musisz uważnie obserwować dane z testów w terenie i wprowadzać odpowiednie zmiany, aby zapewnić użytkownikom jak najszybsze działanie.