Dowiedz się, jak optymalizować dane pod kątem wartości Czas do pierwszego bajtu.
Czas do pierwszego bajtu (TTFB) to podstawowe dane o wydajności witryny, które wyprzedzają wszystkie inne istotne dane dotyczące wrażeń użytkowników, 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 potrzebny do napisania danych, które za nim następują.
Zalecamy, aby Twój serwer wystarczająco szybko odpowiadał na żądania nawigacji, tak aby FCP w ramach „dobrego” w przypadku 75 centyla użytkowników . Większość witryn powinna dążyć do tego, by wskaźnik TTFB był krótszy niż 0,8 sekundy.
Jak mierzyć TTFB
Zanim będzie można zoptymalizować TTFB, trzeba obserwować jego wpływ na użytkowników witryny. Wykorzystuj dane z terenu jako główne źródło informacji o przekierowaniach, w przypadku których występują przekierowania. Natomiast narzędzia laboratoryjne są często mierzone za pomocą końcowego adresu URL, dlatego tego dodatkowego opóźnienia brakuje.
PageSpeed Insights to jeden ze sposobów uzyskania informacji pól i z modułów dotyczących witryn publicznych, które są dostępne w Raporcie na temat użytkowania Chrome.
Funkcja TTFB dla prawdziwych użytkowników jest widoczna w górnej sekcji Dowiedz się, co robią Twoi użytkownicy:
Część TTFB jest widoczna w audycie czasu odpowiedzi serwera:
Więcej informacji o pomiarach TTFB zarówno w terenie, jak i w laboratorium, znajdziesz na stronie z danymi dotyczącymi TTFB.
Debuguj dużą ilość TTFB w terenie za pomocą narzędzia 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ą powodować duże opóźnienia. Struktura wartości nagłówka jest elastyczna i akceptuje co najmniej zdefiniowany przez Ciebie nick. Wartości opcjonalne obejmują czas trwania (za pomocą parametru dur), a także opcjonalny opis zrozumiały dla człowieka (w polu desc).
Serving-Timing może służyć do pomiaru wielu procesów backendu aplikacji, ale na to warto zwrócić szczególną uwagę:
- Zapytania do bazy danych
- Czas renderowania po stronie serwera (w stosownych przypadkach)
- Przewijanie na dysku
- Trafienia/braki w pamięci podręcznej serwera brzegowego (w przypadku korzystania z CDN)
Wszystkie części wpisu Server-Timing są rozdzielone dwukropkiem, a więcej wpisów można rozdzielić 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. W języku PHP możesz na przykład ustawić nagłówek w taki 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 skonfigurowany, będą się pojawiać informacje, których możesz użyć zarówno w module, jak i w polu.
Każda strona z ustawionym nagłówkiem odpowiedzi Server-Timing będzie zawierać w tym polu 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 tym module dane z nagłówka odpowiedzi Server-Timing zostaną zwizualizowane w panelu czasu na karcie Network (Sieć) w Narzędziach deweloperskich w Chrome:
Nagłówki odpowiedzi Server-Timing są wizualizowane na karcie sieci w Narzędziach deweloperskich w Chrome. Metoda Server-Timing służy do mierzenia, czy żądanie dotyczące zasobu trafiło do pamięci podręcznej CDN oraz ile czasu potrzeba, aby dotrzeć do serwera brzegowego sieci CDN, a następnie do punktu początkowego.
Gdy przeanalizujesz dostępne dane, ustalisz, że masz problematyczny element TTFB, możesz przejść do jego rozwiązywania.
Sposoby optymalizacji TTFB
Największym wyzwaniem w optymalizacji TTFB jest to, że chociaż stosem frontendu witryny 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 poszczególnych wskazówkach dotyczących stosu.
Wskazówki dotyczące poszczególnych platform
Platforma, z której korzystasz w witrynie, może mieć duży wpływ na TTFB. Na przykład na wydajność WordPressa wpływa liczba i jakość wtyczek lub używanych motywów. Dostosowanie platformy wpływa również na inne platformy. Zapoznaj się z dokumentacją platformy, aby uzyskać porady od konkretnego dostawcy i uzupełnić ogólne wskazówki dotyczące wydajności podane w tym poście. Audyt Lighthouse polegający na skróceniu czasu odpowiedzi serwera zawiera też ograniczone wskazówki dotyczące stosunków usługi.
Hosting, hosting, hosting
Zanim zdecydujesz się na inne sposoby optymalizacji, najpierw musisz zastanowić się nad hostingiem. Nie możemy podać tu żadnych konkretnych wskazówek, ale ogólną zasadą jest upewnienie się, że host witryny jest w stanie obsłużyć generowany ruch.
Hosting współdzielony działa zazwyczaj wolniej. Jeśli prowadzisz małą osobistą witrynę, która zawiera głównie pliki statyczne, jest to prawdopodobnie do zaakceptowania. Niektóre techniki optymalizacji pomogą Ci maksymalnie ograniczyć ilość TTFB.
Jeśli jednak korzystasz z większej aplikacji 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, ponieważ zmniejsza ilość TTFB w tej dziedzinie.
Wybierając dostawcę usług hostingowych, weź pod uwagę te kwestie:
- Ile pamięci jest przydzielona Twojej instancji aplikacji? Jeśli aplikacja ma niewystarczającą ilość pamięci, będzie mieć problemy z jak najszybszym wyświetlaniem stron.
- Czy Twój dostawca usług hostingowych dba o aktualność stosu backendu? W miarę udostępniania nowych wersji języków backendu aplikacji, implementacji HTTP i oprogramowania baz danych wydajność tego oprogramowania będzie się z czasem zwiększać. Współpraca z dostawcą usług hostingowych, który zajmuje się tego rodzaju utrzymaniem, jest kluczową sprawą.
- 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 dostosowanie backendu własnej instancji aplikacji ma sens.
Jest wielu dostawców usług hostingowych, którzy zajmują się tym za Ciebie, ale jeśli zauważysz długie wartości TTFB nawet w przypadku dedykowanych dostawców usług hostingowych, może to oznaczać, że musisz ponownie przeanalizować możliwości obecnego dostawcy usług hostingowych, aby zapewnić jak największą wygodę użytkowników.
Korzystanie z sieci dostarczania treści (CDN)
Temat Korzystanie z CDN jest dobrze znany, ale nie bez powodu możesz mieć bardzo dobrze zoptymalizowany backend aplikacji, ale użytkownicy, którzy znajdują się daleko od serwera pierwotnego, mogą nadal zauważyć w terenie dużą ilość TTFB.
Sieci CDN rozwiązują problem znajdujący się w pobliżu użytkownika 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ą to tzw. serwery brzegowe.
Dostawcy CDN mogą też oferować inne 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 lub HTTP/3.
- Protokół HTTP/3 rozwiązuje problem blokowania na początku wiersza występujący w protokołach TCP (od których zależy działanie protokołu HTTP/2) dzięki użyciu protokołu UDP.
- CDN może też zapewnić nowoczesne wersje protokołu TLS, które skracają czas oczekiwania na negocjacje TLS. Zwłaszcza protokół TLS 1.3 został zaprojektowany tak, aby negocjacje TLS były jak najkrótsze.
- Niektórzy dostawcy CDN udostępniają funkcję często nazywana „instancją brzegową”, która używa interfejsu API podobnego do interfejsu Service Worker API do przechwytywania żądań, programowego zarządzania odpowiedziami w pamięci podręcznej na serwerach brzegowych lub całkowitego przepisywania odpowiedzi.
- Dostawcy CDN są bardzo dobrzy w optymalizacji pod kątem kompresji. Samodzielne kompresowanie jest trudne. W niektórych przypadkach może prowadzić do wydłużenia czasu odpowiedzi dzięki dynamicznie generowanym znacznikom, które należy kompresować na bieżąco.
- Dostawcy CDN będą również automatycznie zapisywać w pamięci podręcznej skompresowane odpowiedzi zasobów statycznych, co zapewnia najlepsze połączenie współczynnika kompresji i czasu odpowiedzi.
Choć wdrożenie sieci CDN wiąże się z różnym nakładem pracy, od trywialnym po znaczną, warto postawić na optymalizację TTFB, jeśli jeszcze jej nie używasz.
tam, gdzie to możliwe, treści z pamięci podręcznej
Sieci CDN umożliwiają przechowywanie treści w pamięci podręcznej na serwerach brzegowych znajdujących się fizycznie bliżej użytkowników, o ile treść jest skonfigurowana za pomocą odpowiednich nagłówków HTTP Cache-Control. Chociaż nie jest to odpowiednie w przypadku treści spersonalizowanych, wymaganie przejścia aż do samego punktu początkowego może negatywnie wpłynąć na wartość sieci CDN.
W przypadku witryn, które często aktualizują treść, nawet krótki czas przechowywania w pamięci podręcznej może spowodować zauważalny wzrost wydajności w przypadku popularnych witryn, ponieważ tylko pierwszy użytkownik w tym czasie doświadcza pełnego opóźnienia z powrotem na serwer pierwotny, podczas gdy wszyscy pozostali użytkownicy mogą ponownie korzystać z zasobów zapisanych w pamięci podręcznej z serwera brzegowego. Niektóre sieci CDN pozwalają na unieważnienie pamięci podręcznej wersji witryny, co zapewnia korzyści obu tych rozwiązań – długie czasy przechowywania w pamięci podręcznej, ale szybkie aktualizacje w razie potrzeby.
Nawet jeśli pamięć podręczna jest skonfigurowana prawidłowo, można ją zignorować za pomocą unikalnych parametrów ciągu zapytania do pomiarów w Analytics. Mogą one wyglądać jak inne treści niż sieć CDN, mimo że są takie same, więc ich wersja z pamięci podręcznej nie będzie używana.
Starsze lub rzadziej odwiedzane 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 niż na innych. Wydłużenie czasu buforowania może zmniejszyć to skutki, ale pamiętaj, że dłuższy czas buforowania zwiększa ryzyko wyświetlania potencjalnie nieaktualnych treści.
Wpływ treści z pamięci podręcznej nie tylko na osoby korzystające z sieci CDN. Gdy nie można ponownie użyć zawartości pamięci podręcznej, infrastruktura serwerów może generować treści z kosztownych wyszukiwań w bazie danych. Częstsze korzystanie z danych lub strony w pamięci podręcznej często mają większą skuteczność.
Unikaj wielokrotnych przekierowań
Jedną z najczęstszych przyczyn wysokiego współczynnika TTFB są przekierowania. Przekierowania występują, gdy żądanie nawigacji dotyczące dokumentu otrzymuje odpowiedź informującą przeglądarkę, że zasób istnieje w innej lokalizacji. Jedno przekierowanie z pewnością zwiększa niechciane opóźnienie w żądaniu nawigacji, ale może się pogorszyć, jeśli przekierowanie wskazuje inny zasób, który powoduje kolejne przekierowanie – i tak dalej. Może to mieć szczególnie wpływ na witryny o dużej liczbie użytkowników dzięki reklamom lub newsletterom, ponieważ w celach pomiarowych często następuje przekierowanie za pomocą usług analitycznych. Wyeliminowanie przekierowań pod Twoją bezpośrednią kontrolą może pomóc w uzyskaniu dobrej jakości TTFB.
Istnieją 2 typy przekierowań:
- Przekierowania z tej samej domeny – czyli w całości w witrynie.
- Przekierowania między domenami, w przypadku których przekierowanie następuje początkowo z innego źródła – np. z usługi skracania adresów URL w mediach społecznościowych – przed otwarciem Twojej witryny.
Skup się na wyeliminowaniu przekierowań z tej samej domeny, ponieważ masz nad tym bezpośrednią kontrolę. Obejmuje to sprawdzenie, czy linki w Twojej witrynie powodują wyświetlenie kodu odpowiedzi 302 lub 301. Często może to wynikać z braku zastosowania schematu https:// (w takim przypadku przeglądarki domyślnie stosują tag http://, który następnie przekierowuje) lub ukośniki końcowe nie są odpowiednio dołączane do adresu URL lub wykluczane z niego.
Przekierowania między domenami są trudniejsze, ponieważ często nie masz na to wpływu. W miarę możliwości unikaj jednak wielu przekierowań – na przykład korzystaj z usług skracania linków podczas udostępniania. Sprawdź, czy adres URL udostępniany reklamodawcom lub w newsletterze jest prawidłowym końcowym adresem URL, aby nie dodawać kolejnego przekierowania do stron używanych przez te usługi.
Innym ważnym źródłem czasu przekierowania mogą być przekierowania HTTP do HTTPS. Aby obejść ten problem, możesz użyć nagłówka Strict-Transport-Security (HSTS), który wymusza stosowanie HTTPS przy pierwszej wizycie w źródle, a następnie przy okazji kolejnych wizyt informuje przeglądarkę, że ma natychmiastowy dostęp do punktu początkowego za pomocą schematu HTTPS.
Gdy już wdrożysz dobrą zasadę HSTS, możesz przyspieszyć działanie witryny już przy pierwszej wizycie, dodając ją do listy wstępnego ładowania HSTS.
Przesyłanie znaczników do przeglądarki
Przeglądarki są zoptymalizowane pod kątem efektywnego przetwarzania znaczników podczas ich przesyłania strumieniowego, co oznacza, że znaczniki są obsługiwane we fragmentach po otrzymaniu ich z serwera. Ma to kluczowe znaczenie w przypadku dużych ładunków znaczników, ponieważ dzięki temu przeglądarka może analizować fragmenty w sposób stopniowy i nie musi czekać na zebranie całej odpowiedzi przed rozpoczęciem analizy.
Choć przeglądarki świetnie radzą sobie ze znacznikami strumieniowania, ważne jest, aby robić wszystko, co w Twojej mocy, aby strumień działał jak najszybciej. Jeśli backend zawiesza się, to już jest problem. Ponieważ stosów backendu jest wiele, to omówienie każdego z nich i problemy, które mogą wystąpić w każdym z nich, byłoby poza zakresem tego przewodnika.
Na przykład React i inne platformy, które mogą renderować znaczniki na żądanie na serwerze, stosują synchroniczne podejście do renderowania po stronie serwera. W nowszych wersjach React dostępne są jednak metody serwerowe do obsługi strumieniowego przesyłania znaczników podczas renderowania. Oznacza to, że nie musisz czekać, aż metoda interfejsu React Server API wyrenderuje całą odpowiedź przed wysłaniem.
Innym sposobem na zapewnienie szybkiego strumieniowego przesyłania znaczników do przeglądarki jest wykorzystanie renderowania statycznego, które generuje pliki HTML w czasie kompilacji. Gdy pełny plik jest dostępny od razu, serwery WWW mogą od razu rozpocząć jego wysyłanie, a z nieodłączną naturą protokołu HTTP powstaną znaczniki strumieniowego przesyłania danych. Chociaż nie jest to odpowiednie rozwiązanie w przypadku każdej strony w każdej witrynie – na przykład w przypadku stron wymagających dynamicznej odpowiedzi w celu zapewnienia wygody użytkownikom – może być korzystne w przypadku stron, które nie wymagają personalizacji znaczników pod kątem konkretnego użytkownika.
Użyj skryptu service worker
Interfejs Service Worker API może mieć duży wpływ na funkcję TTFB zarówno w przypadku dokumentów, jak i ładowanych przez nie zasobów. Powodem jest to, że skrypt service worker działa jako serwer proxy między przeglądarką a serwerem, ale to, czy ma to wpływ na funkcję TTFB witryny, zależy od tego, jak skonfigurowano mechanizm Service Worker oraz od tego, czy konfiguracja jest zgodna z wymaganiami aplikacji.
- Stosuj w przypadku komponentów strategię nieprzerwaną i oczekującą na ponowną weryfikację. Jeśli zasób znajduje się w pamięci podręcznej mechanizmu Service Worker – niezależnie od tego, czy jest to dokument czy zasób, którego wymaga dokument – strategia nieaktualności w czasie ponownej weryfikacji uruchomi ten zasób najpierw z pamięci podręcznej, a następnie pobierze go w tle i wyświetli z pamięci podręcznej na potrzeby przyszłych interakcji.
- Jeśli masz zasoby dokumentu, które nie zmieniają się zbyt często, zastosowanie strategii dotyczącej nieaktualnych i ponownych walidacji może sprawić, że funkcja TTFB strony stanie się niemal natychmiastowa. Nie działa to jednak zbyt dobrze, jeśli witryna wysyła znaczniki generowane dynamicznie, np. znaczniki, które zmieniają się w zależności od tego, czy użytkownik jest uwierzytelniony. W takich przypadkach najlepiej jest zawsze połączyć się najpierw z siecią, aby dokument był jak najbardziej aktualny.
- Jeśli dokument wczytuje mniej istotne zasoby, które z pewną częstotliwością się zmieniają, ale ich pobranie nie ma istotnego wpływu na wygodę użytkowników (np. wybranie obrazów lub innych zasobów, które nie mają krytycznego znaczenia), można znacznie ograniczyć użycie TTFB do tych zasobów, stosując strategię dotyczącą nieaktualnych i ponownych weryfikacji.
- W przypadku aplikacji renderowanych przez klienta używaj modelu powłoki aplikacji. Ten model najlepiej sprawdza się w aplikacjach SPA, w których „powłoka” strony może zostać natychmiast dostarczona z pamięci podręcznej skryptu service worker, a dynamiczna zawartość strony jest uzupełniana i renderowana później w cyklu życia strony.
Użyj zasady 103 Early Hints, aby korzystać z zasobów o krytycznym znaczeniu dla renderowania
Bez względu na to, jak dobrze Twój backend aplikacji jest zoptymalizowany, przygotowanie odpowiedzi może wymagać od serwera dużej ilości pracy, w tym kosztownej (ale niezbędnej) pracy baz danych, która opóźnia odpowiedź nawigacji. W efekcie mogą występować opóźnienia w przypadku niektórych kolejnych zasobów o znaczeniu krytycznym dla renderowania, np. plików CSS lub, w niektórych przypadkach – JavaScriptu, który renderuje znaczniki po stronie klienta.
Nagłówek 103 Early Hints to wczesny kod odpowiedzi, który serwer może wysłać do przeglądarki, gdy backend przygotowuje znaczniki. Ten nagłówek może być wskazówką dla przeglądarki, że istnieją zasoby o znaczeniu krytycznym dla renderowania, a strona powinna rozpocząć pobieranie w czasie przygotowywania znaczników. W przypadku przeglądarek, które obsługują przeglądarki, efektem może być szybsze renderowanie dokumentów (CSS) i szybsza dostępność podstawowych funkcji strony (JavaScript).
Podsumowanie
Istnieje tak wiele kombinacji stosów aplikacji backendu, dlatego nie ma jednego artykułu, który opisuje wszystko, co można zrobić, aby zmniejszyć liczbę TTFB witryny. Poniżej znajdziesz jednak kilka sposobów na przyspieszenie działania witryny po stronie serwera.
Podobnie jak w przypadku optymalizacji każdego rodzaju danych, podejście jest bardzo podobne: mierz wyniki w terenie, korzystaj z narzędzi laboratoryjnych, aby poznać przyczyny, i w miarę możliwości wprowadzaj optymalizacje. Nie każda z tych metod może się sprawdzić w Twojej sytuacji, ale niektóre będą dostępne. Jak zawsze musisz uważnie śledzić dane i w razie potrzeby wprowadzać korekty, aby zapewnić jak największą wygodę użytkowników.
Baner powitalny Taylor Vick, zaczerpnięty z Unsplash.