Optymalizuj czas do pierwszego bajtu

Dowiedz się, jak optymalizować dane dotyczące czasu do pierwszego bajtu.

Jeremy Wagner

Barry Pollard

Czas do pierwszego bajta (TTFB) to podstawowy wskaźnik wydajności strony, który poprzedza wszystkie inne istotne wskaźniki dotyczące jakości korzystania z witryny, 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 pozostałych danych.

Zalecamy, aby serwer odpowiadał na żądania nawigacyjne na tyle szybko, aby w 75. percentilu użytkowników wartość FCP mieściła się w wartościach mieszczących się w „dobrym” progu. W przybliżeniu czas TTFB powinien wynosić 0, 8 sekundy lub mniej.

Jak mierzyć TTFB

Zanim zoptymalizujesz czas oczekiwania na odpowiedź serwera, musisz sprawdzić, jak wpływa on na użytkowników Twojej witryny. Jako podstawowe źródło informacji o TTFB należy używać danych z pola, ponieważ jest ono podatne na wpływ przekierowań, podczas gdy narzędzia laboratoryjne często używają do pomiarów końcowego adresu URL, przez co nie uwzględniają tego dodatkowego opóźnienia.

PageSpeed Insights to jedno z narzędzi, które pozwala uzyskać informacje z pól i laboratorium dotyczące publicznych stron internetowych, dostępne w Raporcie na temat użytkowania Chrome.

Czas oczekiwania na odpowiedź dla rzeczywistych użytkowników jest widoczny w sekcji Dowiedz się, jakie są wrażenia użytkowników:

Podzbiór TTFB jest widoczny w kontroli czasu reakcji serwera:

Więcej informacji o metodach pomiaru czasu TTFB w warunkach rzeczywistych i w laboratorium znajdziesz na stronie wskaźnika TTFB.

Debugowanie wysokiego TTFB w polu za pomocą Server-Timing

Nagłówek odpowiedzi Server-Timing można wykorzystać w backendzie aplikacji do pomiaru procesów backendowych, które mogą przyczyniać się do wysokiej wartości opóźnienia. Struktura wartości nagłówka jest elastyczna i przyjmuje co najmniej zdefiniowany przez Ciebie alias. Opcjonalne wartości obejmują wartość czasu trwania (za pomocą dur) oraz opcjonalny opis zrozumiały dla człowieka (za pomocą desc).

Serving-Timing można używać do pomiaru wielu procesów aplikacji na zapleczu, ale są też takie, na które warto zwrócić szczególną uwagę:

• Zapytania do bazy danych
• Czas renderowania po stronie serwera (jeśli dotyczy)
• Przewijanie dysku
• trafienia/brak trafień w pamięci podręcznej serwera brzegowego (jeśli korzystasz z CDN),

Wszystkie części wpisu Server-Timing są rozdzielane dwukropkiem, a poszczególne wpisy można rozdzielać przecinkami:

// 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ć w wybranym języku na zapleczu aplikacji. W 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 polu.

W polu każda strona z ustawionym nagłówkiem odpowiedzi Server-Timing wypełnia w interfejsie API Czas trwania nawigacji właściwość serverTiming:

// 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 laboratorium dane z nagłówka odpowiedzi Server-Timing będą wizualizowane w panelu Czasy trwania na karcie Sieć w Narzędziach deweloperskich w Chrome:

Nagłówki odpowiedzi Server-Timing zwizualizowane na karcie Sieć w Narzędziach deweloperskich w Chrome. W tym przypadku Server-Timing służy do pomiaru, czy żądanie zasobu dotarło do pamięci podręcznej CDN i jak długo zajęło mu dotarcie do serwera brzegowego CDN, a następnie do źródła.

Po zbadaniu dostępnych danych i ustalenia, że masz problem z czasem TTFB, możesz przejść do jego rozwiązania.

Sposoby optymalizacji wartości TTFB

Największym wyzwaniem w optymalizacji czasu oczekiwania na odpowiedź jest to, że choć interfejs front-end zawsze składa się z HTML, CSS i JavaScriptu, komponenty back-end mogą się znacznie różnić. Istnieją liczne rozwiązania backendowe i bazy danych, z których każde ma własne techniki optymalizacji. Dlatego w tym przewodniku skupimy się na rozwiązaniach, które są odpowiednie dla większości architektur, a nie tylko na wskazówkach dotyczących konkretnych pakietów.

Wskazówki dotyczące poszczególnych platform

Platforma, której używasz do obsługi witryny, może mieć duży wpływ na czas TTFB. Na przykład wydajność WordPressa zależy od liczby i jakości wtyczek oraz używanych motywów. Inne platformy są również dotknięte tym problemem, gdy są one dostosowywane. Aby uzyskać porady dotyczące konkretnego dostawcy, zapoznaj się z dokumentacją platformy. Dopełniają one ogólne wskazówki dotyczące skuteczności podane w tym poście. Weryfikacja Lighthouse dotycząca skracania czasu odpowiedzi serwera zawiera też ograniczone wskazówki dotyczące konkretnego pakietu technologii.

Hosting, hosting, hosting

Zanim zaczniesz rozważać inne metody optymalizacji, zastanów się nad hostingiem. Nie możemy podać żadnych konkretnych wskazówek, ale ogólnie zalecamy, aby hosting witryny był w stanie obsłużyć ruch, który do niej kierujesz.

Hosting współdzielony jest zazwyczaj wolniejszy. Jeśli masz małą witrynę osobistą, która udostępnia głównie pliki statyczne, prawdopodobnie nie ma to większego znaczenia. Niektóre z opisanych poniżej technik optymalizacji pomogą Ci zminimalizować czas oczekiwania na odpowiedź.

Jeśli jednak korzystasz z większej aplikacji z dużą liczbą użytkowników, która wymaga personalizacji, zapytań do bazy danych i innych intensywnych operacji po stronie serwera, wybór hostingu staje się kluczowy dla obniżenia wartości TTFB.

Wybierając dostawcę usług hostingowych, zwróć uwagę na te kwestie:

• Ile pamięci jest przydzielane instancji aplikacji? Jeśli aplikacja ma za mało pamięci, będzie się męczyć i nie będzie w stanie wyświetlać stron tak szybko, jak to możliwe.
• Czy Twój dostawca hostingu aktualizuje oprogramowanie backendowe? Wraz z wydaniem nowych wersji języków backendu aplikacji, implementacji HTTP i oprogramowania bazy danych ich wydajność będzie się z czasem poprawiać. Kluczowe jest nawiązanie współpracy z dostawcą usług hostingowych, który traktuje tego typu istotne działania konserwacyjne priorytetowo.
• Jeśli masz bardzo konkretne wymagania dotyczące aplikacji i chcesz uzyskać dostęp do plików konfiguracji serwera na najniższym poziomie, zapytaj, czy warto dostosować backend własnej instancji aplikacji.

Wiele firm hostingowych zadba o to za Ciebie, ale jeśli zauważysz długi czas TTFB nawet w przypadku dedykowanych usług hostingowych, może to oznaczać, że musisz ponownie ocenić możliwości swojego obecnego dostawcy usług hostingowych, aby zapewnić użytkownikom jak najlepsze wrażenia.

Korzystanie z sieci dostarczania treści (CDN)

Temat korzystania z CDN jest dobrze znany, ale nie bez powodu: możesz mieć bardzo dobrze zoptymalizowane zaplecze aplikacji, ale użytkownicy znajdujący się daleko od serwera źródłowego mogą nadal mieć wysoki czas TTFB.

Sieci CDN rozwiązują problem odległości użytkowników od serwera źródłowego, korzystając z rozproszonej sieci serwerów, które przechowują w pamięci podręcznej zasoby na serwerach fizycznie bliżej użytkowników. Takie serwery nazywamy serwerami peryferyjnymi.

Dostawcy usług CDN mogą oferować też inne korzyści niż serwery peryferyjne:

• Dostawcy CDN zwykle oferują bardzo szybkie czasy rozpoznawania nazw DNS.
• Usługa CDN będzie wyświetlać treści z serwerów peryferyjnych przy użyciu nowoczesnych protokołów, takich jak HTTP/2 lub HTTP/3.
• HTTP/3 rozwiązuje problem blokowania na linii, który występuje w TCP (z którego korzysta HTTP/2), dzięki użyciu protokołu UDP.
• Usługa CDN prawdopodobnie udostępnia też nowe wersje TLS, co zmniejsza opóźnienie związane z czasem negocjacji TLS. Protokół TLS 1.3 został zaprojektowany tak, aby negocjacje TLS były jak najkrótsze.
• Niektórzy dostawcy CDN udostępniają funkcję, która często nazywana jest „workerem na krawędzi”, i która korzysta z interfejsu API podobnego do interfejsu Service Worker API, aby przechwytywać żądania, zarządzać odpowiedziami w pamięci podręcznej na krawędzi lub całkowicie je przepisywać.
• Dostawcy sieci CDN bardzo dobrze optymalizują kompresję. Kompresję trudno jest zastosować samodzielnie, a w niektórych przypadkach może ona prowadzić do wydłużenia czasu odpowiedzi w przypadku dynamicznie generowanego znacznika, który musi być kompresowany na bieżąco.
• Dostawcy CDN będą też automatycznie umieszczać w pamięci podręcznej skompresowane odpowiedzi dla zasobów statycznych, co zapewni najlepszy stosunek współczynnika kompresji do czasu odpowiedzi.

Wdrożenie CDN wymaga od Ciebie od nieznacznej do znacznej ilości wysiłku, ale jeśli Twoja witryna jeszcze z niego nie korzysta, powinnaś/powinieneś dążyć do optymalizacji czasu oczekiwania na odpowiedź serwera (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 peryferyjnych, które są fizycznie bliżej użytkowników, pod warunkiem że treści są skonfigurowane z odpowiednimi nagłówkami Cache-Control HTTP. Nie jest to odpowiednie w przypadku treści spersonalizowanych, ponieważ wymaganie powrotu do źródła może zniweczyć większość zalet CDN.

W przypadku witryn, w których treści są często aktualizowane, nawet krótki czas przechowywania w pamięci podręcznej może przynieść zauważalne korzyści w zakresie wydajności, ponieważ tylko pierwszy użytkownik w tym czasie odczuwa pełne opóźnienie związane z połączeniem z serwerem źródłowym, podczas gdy wszyscy inni użytkownicy mogą ponownie użyć zasobu z pamięci podręcznej na serwerze brzegowym. Niektóre sieci CDN umożliwiają unieważnienie pamięci podręcznej w przypadku wersji witryny, co pozwala uzyskać najlepsze rozwiązania z obu światów: długi czas przechowywania w pamięci podręcznej i błyskawiczne aktualizacje w razie potrzeby.

Nawet wtedy, gdy buforowanie jest prawidłowo skonfigurowane, można je zignorować, używając unikalnych parametrów ciągu zapytania do pomiaru w Analytics. Mogą one wyglądać jak inne treści dla CDN, mimo że są takie same, więc wersja w pamięci podręcznej nie zostanie użyta.

Starsze lub rzadziej odwiedzane treści mogą też nie być przechowywane w pamięci podręcznej, co może powodować wyższe wartości TTFB na niektórych stronach niż na innych. Wydłużenie czasu przechowywania w pamięci podręcznej może zmniejszyć wpływ tego problemu, ale pamiętaj, że wraz z wydłużeniem czasu przechowywania w pamięci podręcznej wzrasta prawdopodobieństwo wyświetlania treści, które mogą być nieaktualne.

Treści przechowywane w pamięci podręcznej nie wpływają tylko na użytkowników korzystających z CDN. Gdy nie można ponownie użyć treści z pamięci podręcznej, infrastruktura serwera może potrzebować generowania treści z drogich wyszukiwań w bazie danych. Dane, do których użytkownicy sięgają częściej, lub strony z domyślnie z pamięci podręcznej często działają lepiej.

Unikaj wielokrotnych przekierowań

Jednym z częstych czynników wpływających na wysoką wartość TTFB są przekierowania. Przekierowania występują, gdy żądanie nawigacji dotyczące dokumentu otrzymuje odpowiedź, która informuje przeglądarkę, że zasób znajduje się w innej lokalizacji. Jedno przekierowanie może wydłużyć czas oczekiwania na żądanie nawigacyjne, ale może być jeszcze gorzej, jeśli przekierowuje ono do innego zasobu, który z kolei powoduje jeszcze jedno przekierowanie, i tak dalej. Może to mieć szczególny wpływ na witryny, które otrzymują dużą liczbę wizyt z reklam lub newsletterów, ponieważ często przekierowują użytkowników przez usługi analityczne w celu pomiarów. Wyeliminowanie przekierowań, które możesz kontrolować bezpośrednio, może pomóc w osiągnięciu dobrego czasu TTFB.

Istnieją 2 rodzaje przekierowań:

• Przekierowania w ramach tego samego źródła, gdy przekierowanie odbywa się wyłącznie w Twojej witrynie.
• Przekierowania między domenami, w których przekierowanie następuje początkowo w innej domenie, np. w usłudze skracania adresów URL w mediach społecznościowych, zanim nastąpi przekierowanie do Twojej witryny.

Skup się na wyeliminowaniu przekierowań w ramach tej samej domeny, ponieważ masz nad nimi bezpośrednią kontrolę. Polega to na sprawdzeniu linków w witrynie pod kątem kodu odpowiedzi 302 lub 301. Często jest to spowodowane brakiem schematu https:// (ponieważ przeglądarki domyślnie używają schematu http://, który następnie przekierowuje) lub nieprawidłowym uwzględnieniem lub wykluczeniem ukośników w adresie URL.

Przekierowania między domenami są bardziej skomplikowane, ponieważ często nie masz nad nimi kontroli. Staraj się jednak, jeśli to możliwe, unikać wielokrotnych przekierowań, na przykład używając wielu skrótów linków podczas udostępniania linków. Sprawdź, czy adres URL podany reklamodawcom lub subskrybentom newslettera 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 ograniczenia jest użycie nagłówka Strict-Transport-Security (HSTS), który wymusza HTTPS przy pierwszej wizycie w źródle, a potem informuje przeglądarkę, aby w przyszłości natychmiast uzyskiwać dostęp do źródła za pomocą schematu HTTPS.

Gdy już wdrożysz odpowiednią zasadę HSTS, możesz przyspieszyć proces podczas pierwszej wizyty w źródle poprzez dodanie witryny do listy wstępnego wczytywania HSTS.

Przesyłanie znaczników do przeglądarki

Przeglądarki są zoptymalizowane pod kątem wydajnego przetwarzania znaczników podczas ich przesyłania strumieniowego, co oznacza, że znaczniki są przetwarzane w porcjach w miarę ich otrzymywania z serwera. Jest to bardzo ważne w przypadku dużych ładunków znaczników, ponieważ oznacza to, że przeglądarka może analizować kolejne fragmenty znaczników, zamiast czekać na całą odpowiedź, zanim rozpocznie analizowanie.

Chociaż przeglądarki świetnie radzą sobie z obsługą znaczników streamingu, ważne jest, aby zrobić wszystko, co możliwe, aby strumień był ciągły i aby początkowe bity znaczników były wysyłane jak najszybciej. Jeśli problem leży po stronie backendu, to jest problem. Ze względu na dużą liczbę pakietów oprogramowania backendowego nie sposób w ramach tego przewodnika omówić wszystkich z nich i problemów, które mogą się w nich pojawić.

React i inne platformy, które mogą renderować znaczniki po stronie serwera na żądanie, stosują synchroniczne podejście do renderowania po stronie serwera. Nowsze wersje Reacta mają jednak zaimplementowane metody serwera do przesyłania strumieniowego znaczników podczas ich renderowania. Oznacza to, że nie musisz czekać, aż metoda interfejsu API serwera React zakończy renderowanie całej odpowiedzi.

Innym sposobem na szybkie przesyłanie znaczników do przeglądarki jest korzystanie z renderowania statycznego, które generuje pliki HTML podczas kompilacji. Ponieważ pełny plik jest dostępny od razu, serwery WWW mogą zacząć wysyłać plik natychmiast, a właściwa natura protokołu HTTP spowoduje, że znaczniki będą przesyłane strumieniowo. Chociaż takie podejście nie jest odpowiednie dla każdej strony w każdej witrynie (np. dla stron, które wymagają dynamicznej odpowiedzi w ramach wrażeń użytkownika), może być przydatne w przypadku stron, które nie wymagają personalizacji znaczników pod kątem konkretnego użytkownika.

Używanie serwisu workera

Interfejs Service Worker API może mieć duży wpływ na czas TTFB zarówno dokumentów, jak i zasobów, które wczytują. Dzieje się tak, ponieważ usługa robocza działa jako serwer pośredniczący między przeglądarką a serwerem. Jednak to, czy ma to wpływ na TTFB witryny, zależy od tego, jak skonfigurujesz usługę roboczą i czy jej konfiguracja jest zgodna z wymaganiami aplikacji.

• Stosuj w przypadku zasobów strategię sprawdzania ważności zasobów po upływie określonego czasu. Jeśli zasób znajduje się w pamięci podręcznej skryptu service worker (czy to dokument, czy zasób wymagany przez dokument), strategia sprawdzania poprawności zasobów nieaktualnych najpierw użyje tego zasobu z pamięci podręcznej , a potem pobierze zasób w tle i będzie go udostępniać z pamięci podręcznej w przyszłych interakcjach.
  • Jeśli masz zasoby dokumentów, które nie zmieniają się zbyt często, użycie strategii sprawdzania poprawności w przypadku nieaktualnych dokumentów może sprawić, że czas TTFB strony będzie niemal natychmiastowy. Nie działa to jednak tak dobrze, jeśli Twoja witryna wysyła znaczniki wygenerowane dynamicznie, 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 zasoby niekrytyczne, które zmieniają się z pewną częstotliwością, ale pobranie nieaktualnego zasobu nie wpłynie znacząco na komfort użytkownika (np. wybrane obrazy lub inne zasoby, które nie są krytyczne), czas oczekiwania na odpowiedź dla tych zasobów można znacznie skrócić, stosując strategię sprawdzania poprawności w czasie pobierania.
• W przypadku aplikacji renderowanych po stronie klienta użyj modelu powłoki aplikacji. Ten model najlepiej sprawdza się w przypadku aplikacji SPA, w których przypadku „szkielet” strony może być dostarczany natychmiast z pamięci podręcznej skryptu service worker, a dynamiczne treści strony są wypełniane i renderowane później w cyklu życia strony.

Użyj 103 Early Hints do zasobów krytycznych dla renderowania.

Niezależnie od tego, jak dobrze zoptymalizowano backend aplikacji, serwer może potrzebować sporo czasu na przygotowanie odpowiedzi, w tym na kosztowne (choć konieczne) operacje na bazie danych, które opóźniają wysłanie odpowiedzi nawigacyjnej. Może to spowodować opóźnienie niektórych zasobów krytycznych dla renderowania, takich jak CSS lub – w niektórych przypadkach – JavaScript, który renderuje znaczniki na kliencie.

Nagłówek 103 Early Hints to wstępny kod odpowiedzi, który serwer może wysłać do przeglądarki, gdy backend przygotowuje znaczniki. Ten nagłówek może służyć do wskazywania przeglądarce zasobów, które są kluczowe dla renderowania i powinny zostać pobrane, gdy przygotowywany jest znacznik. W obsługiwanych przeglądarkach może to oznaczać szybsze renderowanie dokumentu (CSS) i szybszą dostępność podstawowej funkcjonalności strony (JavaScript).

Podsumowanie

Ze względu na wiele kombinacji pakietów aplikacji zaplecza nie ma jednego artykułu, który opisuje wszystko, co możesz zrobić, aby skrócić czas oczekiwania na odpowiedź (TTFB) witryny. Poniżej znajdziesz jednak kilka opcji, które mogą pomóc w przyspieszeniu działania na serwerze.

W przypadku optymalizacji każdego rodzaju danych podejście jest w dużej mierzę podobne: zmierz czas TTFB w polu, użyj narzędzi laboratoryjnych, aby zidentyfikować przyczyny, a następnie zastosuj optymalizacje tam, gdzie jest to możliwe. Nie każda z tych metod może być odpowiednia w Twoim przypadku, ale niektóre z nich mogą się sprawdzić. Jak zawsze musisz uważnie obserwować dane z pola i w razie potrzeby wprowadzać zmiany, aby zapewnić użytkownikom jak najszybsze działanie.

Baner powitalny autorstwa Taylor Vick, pochodzący z Unsplash.