Optymalizuj czas do pierwszego bajtu

Dowiedz się, jak optymalizować dane pod kątem wskaźnika Czas do pierwszego bajtu.

Czas do pierwszego bajtu (TTFB) to podstawowe dane dotyczące wydajności witryny, które poprzedzają wszystkie inne istotne dane o wrażeniach 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 analizowanych danych.

Zalecamy, aby serwer wystarczająco szybko odpowiadał na żądania nawigacji, aby w 75. percentylu użytkowników odnotowano FCP w ramach „dobrego” progu. Przybliżony czas wyświetlania powinien wynosić 0,8 sekundy do 0,8 sekundy w przypadku większości witryn.

Dobre wartości TTFB to 0,8 s lub mniej, niskie – powyżej 1,8 sekundy, a wszystkie pozostałe wymagają poprawy.

Pomiary TTFB

Zanim zaczniesz optymalizować witrynę TTFB, musisz sprawdzić, jak wpływa ona na użytkowników Twojej witryny. Główne źródło obserwacji formatu TTFB, na które mają wpływ przekierowania, powinno się odbywać na podstawie danych zgromadzonych. W przypadku narzędzi laboratoryjnych pomiar jest często przeprowadzany z wykorzystaniem końcowego adresu URL, co powoduje pominięcie dodatkowego opóźnienia.

Narzędzie PageSpeed Insights pozwala w prosty sposób uzyskać informacje dotyczące zarówno terenów, jak i laboratoriów dotyczących publicznych witryn dostępnych w Raporcie na temat użytkowania Chrome.

Wykres TTFB w przypadku prawdziwych użytkowników znajduje się u góry sekcji Poznaj wrażenia użytkowników:

Rzeczywiste dane użytkowników PageSpeed Insights

Część ustawień TTFB jest widoczna w kontroli czasu odpowiedzi serwera:

Kontrola czasu odpowiedzi serwera

Więcej informacji o sposobach pomiaru TTFB zarówno w polu, jak i w laboratorium znajdziesz na stronie z danymi dotyczącymi TTFB.

Interpretacja informacji o wysokim formacie TTFB w przypadku funkcji 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ą się wydłużać czasu oczekiwania. Struktura wartości nagłówka jest elastyczna i akceptuje co najmniej zdefiniowany przez Ciebie nick. Opcjonalne wartości obejmują wartość czasu trwania (przy użyciu elementu dur), a także opcjonalny zrozumiały dla człowieka opis (przy użyciu desc).

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

  • Zapytania do bazy danych
  • Czas renderowania po stronie serwera (w odpowiednich przypadkach)
  • Liczba wyszukiwań dysku
  • Trafienia lub braki w pamięci podręcznej serwera brzegowego (w przypadku korzystania z CDN)

Wszystkie części wpisu Server-Timing są rozdzielone dwukropkami, a poszczególne pozycje możesz oddzielić 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ć za pomocą wybranego języka backendu aplikacji. Na przykład w języku PHP możesz ustawić taki nagłówek:

<?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 - $dbReadStarTime) / 1e+6;

// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>

Gdy ten nagłówek jest ustawiony, pojawiają się informacje, których możesz użyć zarówno w laboratorium, jak i w polu.

Każda strona z ustawionym w tym polu nagłówkiem odpowiedzi Server-Timing będzie wypełniona właściwością 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 tym module dane z nagłówka odpowiedzi Server-Timing będą wizualizowane w panelu czasu na karcie Sieć w Narzędziach deweloperskich w Chrome:

Wizualizacja wartości nagłówka Server-Timing na karcie Network (Sieć) w Narzędziach deweloperskich w Chrome. W tym obrazie wartości nagłówka serwera-czasu mierzą, czy serwer brzegowy CDN napotkał w pamięci podręcznej lub nie, a także czas pobrania zasobu z brzegu i z serwera pierwotnego.

Nagłówki odpowiedzi Server-Timing widoczne na karcie sieci w Narzędziach deweloperskich w Chrome. Parametr Server-Timing służy tutaj do mierzenia, czy żądanie zasobu dotarło do pamięci podręcznej CDN oraz ile czasu potrzeba, aby żądanie dotarło do serwera brzegowego CDN, a następnie do punktu początkowego.

Gdy już na podstawie dostępnych danych ustalisz, że to problem, który może wystąpić, możesz zająć się jego rozwiązaniem.

Sposoby optymalizacji TTFB

Największym wyzwaniem podczas optymalizacji TTFB jest to, że choć stos frontendu internetowego zawsze będzie HTML, CSS i JavaScript, stosy backendu mogą się znacznie różnić. Istnieje wiele stosów backendu i usług bazodanowych, z których każdy ma własne techniki optymalizacji. Dlatego w tym przewodniku skupimy się na tym, co sprawdza się w przypadku większości architektur, a nie na wskazówkach dotyczących ich poszczególnych stosów.

Wskazówki dotyczące poszczególnych platform

Platforma, której używasz do tworzenia witryny, może mieć duży wpływ na TTFB. Na przykład na wydajność WordPressa ma wpływ liczba i jakość wtyczek lub używane motywy. Dostosowanie platformy ma podobny wpływ na inne platformy. Aby uzupełnić bardziej ogólne porady dotyczące skuteczności zawarte w tym poście, zapoznaj się z dokumentacją platformy, aby uzyskać porady do konkretnych dostawców. Audyt Lighthouse dotyczący skrócenia czasu odpowiedzi serwera obejmuje też ograniczone wytyczne dotyczące stosu.

Hosting, hosting i hosting

Zanim zaczniesz rozważać inne działania optymalizacyjne, warto rozważyć hosting. Nie możemy podać tu żadnych szczegółowych wskazówek, ale ogólną zasadą należy upewnić się, że host witryny jest w stanie obsługiwać kierowany do niej ruch.

Hostowanie współdzielone działa zwykle wolniej. Jeśli masz małą, osobistą witrynę, która obsługuje głównie pliki statyczne, jest to w porządku. Opisane tu techniki optymalizacji pomogą Ci w jak największym stopniu ograniczyć ilość TTFB.

Jeśli jednak używasz większej aplikacji z wieloma użytkownikami, która obejmuje personalizację, wysyłanie zapytań do bazy danych i inne intensywne operacje po stronie serwera, wybór hostingu staje się kluczowy, aby zmniejszyć liczbę TTFB w tym polu.

Oto kilka kwestii, które należy wziąć pod uwagę, wybierając dostawcę usług hostingowych:

  • Ile pamięci jest przydzielonej instancji aplikacji? Jeśli aplikacja ma niewystarczającą ilość pamięci, będzie niepotrzebnie zniekształcona i będzie mieć problemy z szybszym wyświetlaniem stron.
  • Czy Twój dostawca usług hostingowych dba o aktualność stosu backendu? W miarę pojawiania się nowych wersji języków backendu aplikacji, implementacji HTTP i oprogramowania bazy danych działanie tego oprogramowania będzie się z czasem poprawić. Kluczowe znaczenie ma współpraca z dostawcą usług hostingowych, który traktuje tę kluczową konserwację.
  • Jeśli masz bardzo szczególne wymagania dotyczące aplikacji i chcesz uzyskać dostęp do plików konfiguracyjnych serwera na najniższym poziomie, zapytaj, czy warto dostosować backend instancji swojej aplikacji.

Jest wielu dostawców usług hostingowych, którzy zajmują się tymi kwestiami. Jeśli jednak zauważysz długie wartości TTFB, nawet u usługodawców dedykowanych dostawców, może to oznaczać konieczność ponownej oceny możliwości oferowanego dostawcy usług w celu zapewnienia użytkownikom jak najlepszych wrażeń.

Korzystanie z sieci dystrybucji treści (CDN)

Temat Korzystanie z CDN jest popularny, ale z uzasadnionych przyczyn – możesz mieć bardzo dobrze zoptymalizowany backend aplikacji, a użytkownicy znajdujący się daleko od Twojego serwera pierwotnego nadal mogą zauważyć w nim wysoką wartość TTFB.

Sieci CDN rozwiązują problem odległości użytkowników od serwera pierwotnego, wykorzystując rozproszoną sieć serwerów, które buforują zasoby na serwerach znajdujących się fizycznie bliżej użytkowników. Są one nazywane serwerami brzegowymi.

Dostawcy CDN mogą też oferować korzyści poza serwerami brzegowymi:

  • Dostawcy CDN zwykle oferują bardzo krótki czas rozpoznawania nazw DNS.
  • CDN będzie prawdopodobnie wyświetlać Twoje treści z serwerów brzegowych przy użyciu nowoczesnych protokołów, takich jak HTTP/2 czy HTTP/3.
  • Protokół HTTP/3, w szczególności HTTP/3, rozwiązuje problem blokowania całego wiersza występujący w protokole TCP (na którym opiera się HTTP/2) przy użyciu protokołu UDP.
  • CDN będzie też prawdopodobnie udostępniać nowoczesne wersje protokołu TLS, które zmniejszają czas oczekiwania na negocjacje TLS. Zwłaszcza w standardzie TLS 1.3 negocjacje TLS są jak najkrótsze.
  • Niektórzy dostawcy CDN udostępniają funkcję często zwaną „instancją roboczą”, która używa interfejsu API podobnego do tego interfejsu Service Worker API, aby przechwytywać żądania, programowo zarządzać odpowiedziami w brzegowych pamięciach podręcznych lub całkowicie przepisywać odpowiedzi.
  • Dostawcy CDN są bardzo dobrymi w optymalizacji pod kątem kompresji. Samodzielne utworzenie kompresji nie jest łatwe. W niektórych przypadkach generowane dynamicznie znaczniki, które muszą być skompresowane na bieżąco, mogą się wydłużyć.
  • Dostawcy CDN będą też automatycznie zapisywać w pamięci podręcznej skompresowane odpowiedzi zasobów statycznych, co zapewni najlepsze połączenie współczynnika kompresji i czasu odpowiedzi.

Wdrożenie sieci CDN wymaga nakładu pracy: od banalnego po znaczny, jednak priorytetem jest jej optymalizacja, jeśli w Twojej witrynie jeszcze jej nie ma.

Używamy treści z pamięci podręcznej w miarę możliwości

Sieci CDN pozwalają na przechowywanie treści w pamięci podręcznej na serwerach brzegowych, które znajdują się fizycznie bliżej użytkowników, o ile treść jest skonfigurowana przy użyciu odpowiednich nagłówków HTTP Cache-Control. Chociaż nie jest to odpowiednie w przypadku treści spersonalizowanych, wymóg dotarcia z powrotem do punktu początkowego może to negatywnie wpłynąć na wartość sieci CDN.

W przypadku witryn, które często aktualizują treść, nawet krótki czas w pamięci podręcznej może spowodować zauważalny wzrost wydajności w przypadku zajętych witryn, ponieważ tylko pierwszy użytkownik w tym czasie doświadcza pełnego opóźnienia na serwerze pierwotnym, podczas gdy pozostali mogą ponownie wykorzystać zasób z pamięci podręcznej z serwera granicznego. Niektóre sieci CDN pozwalają na unieważnianie pamięci podręcznej w przypadku poszczególnych wersji witryny. Pozwala to korzystać z zalet obu tych rozwiązań – długie czasy buforowania i natychmiastowe aktualizacje w razie potrzeby.

Nawet wtedy, gdy pamięć podręczna jest prawidłowo skonfigurowana, można ją zignorować, stosując unikalne parametry ciągu zapytania na potrzeby pomiarów analitycznych. Chociaż sieć CDN może wyglądać inaczej, mogą one wyglądać jak inne treści, więc wersja z pamięci podręcznej nie będzie używana.

Starsze i rzadsze treści również mogą nie być zapisywane w pamięci podręcznej, co może skutkować wyższymi wartościami TTFB na niektórych stronach. Wydłużenie czasu buforowania może zmniejszyć wpływ tej sytuacji, ale pamiętaj, że dłuższy czas buforowania wiąże się z większym prawdopodobieństwem wyświetlania potencjalnie nieaktualnych treści.

Wpływ treści z pamięci podręcznej ma wpływ nie tylko na użytkowników korzystających z sieci CDN. Gdy nie można ponownie wykorzystać zawartości pamięci podręcznej, infrastruktura serwera może generować treści związane z kosztownymi wyszukiwaniami w bazie danych. Częściej używane dane lub strony w pamięci podręcznej często są skuteczniejsze.

Unikaj wielokrotnych przekierowań

Jednym z najczęstszych przyczyn wysokiego tętna jest przekierowania. Przekierowania występują, gdy żądanie nawigacji dotyczące dokumentu odbiera odpowiedź informującą przeglądarkę, że zasób znajduje się w innej lokalizacji. Jedno przekierowanie może z pewnością zwiększyć opóźnienie żądania nawigacji, ale z pewnością może się pogorszyć, jeśli przekierowanie będzie wskazywać inny zasób, który skutkuje kolejnym przekierowaniem itd. Może to mieć szczególne znaczenie w przypadku witryn często odwiedzanych przez użytkowników klikających reklamy lub newslettery, ponieważ w celu pomiaru skuteczności często są przekierowywani przez usługi analityczne. Wyeliminowanie przekierowań, które pozostają pod Twoją bezpośrednią kontrolą, może pomóc w osiągnięciu dobrego efektu w przypadku technologii TTFB.

Są 2 rodzaje przekierowań:

  • przekierowania z tej samej domeny, w przypadku których przekierowanie następuje w całości w Twojej witrynie;
  • Przekierowania między domenami, w których przekierowanie następuje początkowo w innym źródle, np. z serwisu skracającego adresy URL w mediach społecznościowych, zanim użytkownik wejdzie na Twoją stronę.

Musisz skupić się na eliminowaniu przekierowań z tej samej domeny, ponieważ będziesz nad tym mieć bezpośrednią kontrolę. Wiąże się to z sprawdzeniem, czy któryś z nich prowadzi do kodu odpowiedzi 302 lub 301. Często może to być spowodowane nieuwzględnieniem schematu https:// (w takim przypadku przeglądarki domyślnie wyświetlają adres http://, który następnie przekierowuje) lub końcowe ukośniki nie są prawidłowo uwzględnione w adresie URL lub wykluczone.

Przekierowania między domenami są trudniejsze, bo często są poza Twoją kontrolą, ale staraj się unikać wielokrotnych przekierowań, jeśli to możliwe, np. używając kilku metod skracania linków podczas udostępniania linków. Upewnij się, że URL podany reklamodawcom lub newsletterom jest poprawnym końcowym adresem URL, aby nie dodawać kolejnego przekierowania do adresów używanych w tych usługach.

Innym ważnym źródłem czasu przekierowania są przekierowania HTTP do HTTPS. Aby obejść ten problem, możesz użyć nagłówka Strict-Transport-Security (HSTS), który wymusza stosowanie protokołu HTTPS podczas pierwszej wizyty w witrynie źródła, a podczas kolejnych wizyt przekazuje przeglądarce informację o szybkim dostępie do źródła za pomocą schematu HTTPS.

Po ustaleniu zasad HSTS możesz przyspieszyć pierwsze wizyty w witrynie, dodając ją do listy wstępnego wczytywania HSTS.

Przesyłanie znaczników do przeglądarki

Przeglądarki są zoptymalizowane pod kątem efektywnego przetwarzania znaczników podczas przesyłania strumieniowego, co oznacza, że znaczniki są przetwarzane partiami w miarę przesyłania z serwera. Ma to kluczowe znaczenie w przypadku dużych ładunków znaczników, ponieważ oznacza to, że przeglądarka może analizować fragmenty znaczników stopniowo, zamiast czekać na nadejście całej odpowiedzi przed rozpoczęciem analizy.

Choć przeglądarki znakomicie obsługują znaczniki strumieniowania, ważne jest, aby zapewnić ciągłość strumienia, tak aby początkowe elementy były w drodze jak najszybciej. Jeśli backend się wstrzymuje, to jest problem. Ponieważ stosy backendu są bardzo liczne, ten przewodnik nie powinien obejmować każdego pojedynczego stosu i problemów, które mogą się pojawić w przypadku każdego z nich.

Na przykład w reakcji i innych platformach, które renderują znaczniki na żądanie na serwerze, stosowane jest podejście synchroniczne do renderowania po stronie serwera. W nowszych wersjach React stosowane są jednak metody serwera do strumieniowego przesyłania znaczników w trakcie ich renderowania. Oznacza to, że nie musisz czekać, aż metoda interfejsu React Server API wyrenderuje całą odpowiedź, zanim zostanie wysłana.

Innym sposobem na zapewnienie szybkiego przesyłania znaczników do przeglądarki jest zastosowanie renderowania statycznego, które na etapie kompilacji generuje pliki HTML. Gdy pełny plik jest dostępny od razu, serwery internetowe mogą od razu zacząć wysyłać plik, a naturalny charakter protokołu HTTP generuje znaczniki przesyłania strumieniowego. Mimo że to podejście nie jest odpowiednie w przypadku każdej strony w każdej witrynie – na przykład takich, które wymagają dynamicznej odpowiedzi w ramach wrażeń użytkownika – może być korzystne w przypadku stron, które nie wymagają znaczników i można dostosować je do konkretnego użytkownika.

Użyj skryptu service worker

Interfejs Service Worker API może mieć duży wpływ na TTFB zarówno w przypadku dokumentów, jak i wczytywanych przez nie zasobów. Dzieje się tak, ponieważ mechanizm Service Worker działa jako serwer proxy między przeglądarką a serwerem. Jednak to, czy ma to wpływ na TTFB witryny, zależy od sposobu skonfigurowania skryptu service worker i jego zgodności z wymaganiami aplikacji.

  • Korzystaj ze strategii nieaktualnej w czasie ponownej weryfikacji dotyczącej 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, którego wymaga dokument – strategia „Nieaktualne w czasie ponownej weryfikacji” obsługuje go z pamięci podręcznej najpierw, a następnie pobierze go w tle i będzie wyświetlać z pamięci podręcznej na potrzeby przyszłych interakcji.
    • Jeśli masz zasoby, które nie zmieniają się zbyt często, zastosowanie strategii nieaktualnej weryfikacji treści w trakcie ponownej weryfikacji może sprawić, że strona będzie niemal natychmiastowa. Ta metoda nie działa jednak zbyt dobrze, jeśli witryna wysyła dynamicznie generowane znaczniki, np. takie, które zmieniają się w zależności od uwierzytelnienia użytkownika. W takich przypadkach najlepiej jest zawsze trafić do sieci najpierw, aby dokument był jak najbardziej aktualny.
    • Jeśli dokument wczytuje niekrytyczne zasoby, które zmieniają się z pewną częstotliwością, ale pobieranie nieaktualnych zasobów nie wpłynie w znacznym stopniu na wygodę użytkowników (np. przez wybranie obrazów lub innych zasobów, które nie mają krytycznego znaczenia), można znacznie ograniczyć ilość informacji TTFB dla tych zasobów przy użyciu strategii nieaktualnej weryfikacji podczas ponownej weryfikacji.
  • W miarę możliwości używaj architektury skryptu service worker strumieniowania. Ta architektura skryptu service worker polega na tym, że części zasobów dokumentu są przechowywane w pamięci podręcznej skryptu service worker i łączone z fragmentami treści podczas żądania nawigacji. Efektem używania takiego wzorca jest to, że nawigacja będzie szybka, ale z sieci pobierane są mniejsze ładunki HTML. Chociaż ten wzorzec skryptu service worker nie działa w każdej witrynie, w przypadku witryn, które mogą z niego korzystać, czasy TTFB dotyczące zasobów dokumentów mogą być niemal natychmiastowe.
  • W przypadku aplikacji renderowanych przez 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 dynamiczna zawartość strony jest wypełniana i renderowana na późniejszym etapie cyklu życia strony.

Użyj metody 103 Early Hints w przypadku zasobów o kluczowym znaczeniu dla renderowania

Niezależnie od tego, jak dobrze backend aplikacji jest zoptymalizowany, serwer może wymagać znacznych nakładów pracy, na przykład kosztownych (ale niezbędnych) zadań związanych z bazą danych, które opóźniają dostarczenie odpowiedzi nawigacji. W efekcie niektóre późniejsze zasoby o znaczeniu krytycznym, takie jak kod CSS lub – w niektórych przypadkach – kod JavaScript, który renderuje znaczniki po stronie klienta, mogą zostać opóźnione.

Nagłówek 103 Early Hints to kod wczesnej odpowiedzi, który serwer może wysłać do przeglądarki, gdy backend przygotowuje znaczniki. Nagłówek może zasygnalizować przeglądarce, że istnieją zasoby o znaczeniu krytycznym, które należy rozpocząć w trakcie przygotowywania znaczników. W przypadku obsługi przeglądarek efektem może być szybsze renderowanie dokumentów (CSS) i szybsza dostępność głównych funkcji strony (JavaScript).

Podsumowanie

Ze względu na to, że jest tak wiele kombinacji stosów aplikacji backendu, nie ma jednego artykułu, który zawierałby wszystko, jak można obniżyć wartość TTFB w witrynie. Poniżej znajdziesz jednak kilka rozwiązań, które możesz wypróbować, aby przyspieszyć realizację zadań po stronie serwera.

Podobnie jak w przypadku wszystkich rodzajów danych, podejście jest zasadniczo podobne: mierz wyniki pomiarów podczas badania w terenie, korzystaj z narzędzi laboratoryjnych, aby analizować przyczyny i w miarę możliwości wprowadzać optymalizacje. Nie każda technika sprawdzi się w Twojej sytuacji, ale niektóre się sprawdzą. Jak zawsze, musisz dokładnie obserwować dane pól i w razie potrzeby wprowadzać odpowiednie zmiany, aby zapewnić jak największą wygodę użytkownikom.

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