Dowiedz się, jak przeprowadzać optymalizację 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 dotyczące 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 do powiązanych z nimi danych.
Zalecamy, aby serwer na tyle szybko odpowiadał na żądania nawigacji, aby dla 75 centyla użytkowników wartość FCP nie przekraczała „dobrego” progu. Przybliżony czas tworzenia witryny to maksymalnie 0, 8 sekundy.
Pomiary TTFB
Zanim zaczniesz optymalizować TTFB, musisz przyjrzeć się, jak wpływa ona na użytkowników Twojej witryny. Jako główne źródło obserwacji należy korzystać z danych zgromadzonych jako głównego źródła obserwacji, na co mają wpływ przekierowania. W przypadku narzędzi laboratoryjnych często do pomiaru jest używany końcowy adres URL, dlatego brak dodatkowego opóźnienia.
Narzędzie PageSpeed Insights pozwala w prosty sposób uzyskać informacje dotyczące zarówno pól, jak i laboratoriów dotyczących witryn publicznych, dostępnych w Raporcie na temat użytkowania Chrome.
Widok TTFB dla prawdziwych użytkowników znajduje się w górnej sekcji Dowiedz się, jakie są wrażenia użytkowników:
Fragmenty TTFB są pokazywane w kontroli czasu odpowiedzi serwera:
Więcej informacji o sposobach pomiaru TTFB zarówno w polu, jak i w laboratorium znajdziesz na stronie danych TTFB.
Interpretacja wyników TTFB w przypadku Server-Timing
Nagłówka odpowiedzi Server-Timing możesz używać w backendzie aplikacji do pomiaru różnych procesów backendu, które mogą się wydłużać. Struktura wartości nagłówka jest elastyczna i akceptuje co najmniej zdefiniowany przez Ciebie nick. Opcjonalne wartości obejmują wartość czasu trwania (za pomocą dur), a także opcjonalny opis zrozumiały dla człowieka (za pomocą desc).
Parametru Serving-Timing można używać do pomiaru wielu procesów backendu aplikacji, ale warto zwrócić szczególną uwagę na niektóre procesy:
- Zapytania do bazy danych
- Czas renderowania po stronie serwera (w odpowiednich przypadkach)
- Przeszukiwanie 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 wiele wpisów może być też rozdzielonych 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ć 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 - $dbReadStarTime) / 1e+6;
// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>
Gdy ustawisz ten nagłówek, pojawią się w nim informacje, których możesz używać zarówno w module, jak i w polu.
Każda strona z zestawem nagłówków odpowiedzi Server-Timing w tym polu będzie zawierać właściwość serverTiming interfejsu 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ą wizualizowane w panelu kodów czasowych na karcie Sieć w Narzędziach deweloperskich w Chrome:
Nagłówki odpowiedzi (Server-Timing) wizualizowane na karcie sieci w Narzędziach deweloperskich w Chrome. Server-Timing służy tu do mierzenia, czy żądanie zasobu dotarło do pamięci podręcznej CDN oraz ile czasu potrzeba, by żądanie dotarło na serwer brzegowy CDN i do punktu początkowego.
Gdy już na podstawie dostępnych danych stwierdzisz, że problem techniczny jest problematyczny, możesz zająć się jego rozwiązaniem.
Sposoby optymalizacji TTFB
Największym wyzwaniem podczas optymalizacji TTFB jest to, że chociaż stos frontendu internetowego zawsze będzie stanowił 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 korzysta z własnych technik optymalizacji. Dlatego w tym przewodniku skupimy się na tym, co sprawdza się w przypadku większości architektur, a nie na ogólnych wskazówkach dotyczących stosu.
Wskazówki dotyczące poszczególnych platform
Platforma, której używasz do stworzenia witryny, może mieć duży wpływ na TTFB. Na przykład na wydajność WordPress wpływa liczba i jakość wtyczek lub używane motywy. Dostosowanie platformy wpływa podobnie na inne platformy. Wskazówki dotyczące konkretnych dostawców, które znajdziesz w tym poście, znajdziesz w dokumentacji swojej platformy. Inspekcja Lighthouse dotycząca skrócenia czasu odpowiedzi serwera obejmuje również ograniczone wytyczne dotyczące stosu.
Hosting, hosting i hosting
Zanim weźmiesz pod uwagę inne metody optymalizacji, musisz zacząć od hostingu. Nie możemy tu podać szczegółowych wskazówek, ale należy się upewnić, że host Twojej witryny jest w stanie obsłużyć kierowany do niej ruch.
Hostowanie współdzielone działa zwykle wolniej. Jeśli prowadzisz małą, osobistą witrynę, która serwuje głównie pliki statyczne, jest to normalne. Korzystając z podanych niżej technik optymalizacji, możesz maksymalnie ograniczyć tę zmianę.
Jeśli jednak korzystasz z większej aplikacji obejmującej wielu użytkowników i wymagających personalizacji, zapytań do bazy danych i innych wymagających operacji po stronie serwera, wybór hostingu ma kluczowe znaczenie dla zmniejszenia liczby TTFB.
Wybierając dostawcę usług hostingowych, pamiętaj o tych kwestiach:
- Ile pamięci jest przydzielone dla instancji aplikacji? Jeśli aplikacja ma za mało pamięci, będzie się ściszać i będzie mieć problemy z szybszym otwieraniem 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 baz danych wydajność tego oprogramowania będzie z czasem się zwiększać. Kluczem do tego jest współpraca z dostawcą usług hostingowych, który zajmuje się tego rodzaju kwestiami w pierwszej kolejności.
- Jeśli masz bardzo konkretne wymagania dotyczące aplikacji i chcesz mieć dostęp najniższego poziomu do plików konfiguracyjnych serwera, zapytaj, czy warto dostosować backend instancji aplikacji.
Jest wielu dostawców usług hostingowych, którzy zajmują się tymi kwestiami. Jeśli jednak zaczniesz obserwować długie wartości TTFB, nawet u specjalistów, może to oznaczać, że konieczna może być ponowna ocena możliwości obecnego dostawcy usług hostingowych, aby zapewnić jak najlepsze wrażenia użytkownikom.
Korzystanie z sieci dostarczania treści (CDN)
Temat Użycie sieci CDN jest dość popularny, ale z słusznego powodu: możesz mieć bardzo dobrze zoptymalizowany backend aplikacji, ale w przypadku użytkowników znajdujących się daleko od Twojego serwera źródłowego i tak może wystąpić wysoki poziom TTFB.
Sieci CDN rozwiązać problem odległości użytkowników od serwera pierwotnego, wykorzystując rozproszoną sieć serwerów, które zapisują zasoby w pamięci podręcznej na serwerach znajdujących się fizycznie bliżej użytkowników. Takie serwery są 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.
- HTTP/3 w szczególności rozwiązuje problem blokowania początku wiersza występujący w protokole TCP (na którym opiera się HTTP/2) przy użyciu protokołu UDP.
- CDN prawdopodobnie zapewnia też nowoczesne wersje protokołu TLS, które zmniejszają opóźnienia związane z negocjowaniem protokołu TLS. Zwłaszcza w celu skrócenia czasu negocjowania protokołu TLS w wersji TLS 1.3.
- Niektórzy dostawcy CDN udostępniają funkcję często zwaną „instancją roboczą graniczną”, która używa interfejsu API podobnego do interfejsu Service Worker API do przechwytywania żądań, automatycznego zarządzania odpowiedziami w nadrzędnych pamięciach podręcznych lub całkowitego przepisywania odpowiedzi.
- Dostawcy CDN są bardzo dobrymi w optymalizacji pod kątem kompresji. Kompresja nie jest łatwa do osiągnięcia. Może ona w niektórych przypadkach skrócić czas odpowiedzi przy użyciu dynamicznie generowanych znaczników, które należy skompresować na bieżąco.
- Dostawcy CDN będą też automatycznie buforować skompresowane odpowiedzi dla zasobów statycznych, co pozwala uzyskać najlepsze połączenie współczynnika kompresji i czasu reakcji.
Chociaż zastosowanie CDN wymaga nakładu pracy, od prostego po znaczne, priorytetem jest optymalizacja TTFB, jeśli Twoja witryna jeszcze z niej nie korzysta.
Tam, gdzie to możliwe, używano treści z pamięci podręcznej
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, wymaganie podróży aż z powrotem do punktu początkowego może negatywnie wpłynąć na korzyści związane z siecią CDN.
W przypadku witryn, które często aktualizują treść, nawet krótki czas buforowania 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 w powrotie do serwera pierwotnego, 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 wydań witryn, co pozwala korzystać z zalet obu formatów – długiego czasu zapisywania w pamięci podręcznej i natychmiastowych aktualizacji w razie potrzeby.
Nawet wtedy, gdy buforowanie jest prawidłowo skonfigurowane, można go zignorować, stosując unikalne parametry ciągu zapytania na potrzeby pomiarów analitycznych. Mogą one wyglądać inaczej niż CDN, mimo że są takie same, więc wersja z pamięci podręcznej nie będzie używana.
Starsze lub rzadziej odwiedzane treści 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 ograniczyć 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 ma wpływ nie tylko na użytkowników korzystających z sieci CDN. Gdy treści z pamięci podręcznej nie można ponownie użyć, infrastruktura serwera może musieć generować treści związane z kosztownymi wyszukiwaniami w bazie danych. Częstsze dane lub strony w pamięci podręcznej są często skuteczniejsze.
Unikaj wielokrotnych przekierowań
Częstym powodem wysokiej wartości TTFB są przekierowania. Przekierowania występują, gdy żądanie nawigacji po dokumencie otrzyma odpowiedź informującą przeglądarkę, że zasób znajduje się w innej lokalizacji. Jedno przekierowanie może z pewnością wydłużyć czas oczekiwania na żądanie nawigacji, ale z pewnością może się pogorszyć, jeśli przekierowanie wskaże inny zasób, który skutkuje innym przekierowaniem itd. Może to mieć szczególne znaczenie w przypadku witryn otrzymujących dużą liczbę użytkowników z reklam lub newsletterów, ponieważ często przekierowują one za pośrednictwem usług analitycznych w celach pomiarowych. Wyeliminowanie przekierowań, które pozostają pod Twoją bezpośrednią kontrolą, może pomóc w uzyskaniu dobrej jakości TTFB.
Istnieją 2 typy przekierowań:
- Przekierowania z tej samej domeny, w przypadku których przekierowanie zachodzi w całości w Twojej witrynie.
- Przekierowania między domenami, gdzie przekierowanie następuje początkowo w innym źródle, np. w usłudze skracania adresów URL w mediach społecznościowych, zanim wejdzie na Twoją stronę.
Musisz skupić się na wyeliminowaniu przekierowań z tej samej domeny, ponieważ masz nad tym 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 używają interfejsu http://, który następnie przekierowuje) lub końcowego ukośnika niewłaściwie uwzględnionego w adresie URL lub z niego wykluczone.
Przekierowania między domenami są trudniejsze, bo często pozostają poza kontrolą użytkownika, ale w miarę możliwości staraj się unikać wielu przekierowań, na przykład przez używanie kilku narzędzi do skracania linków podczas udostępniania linków. Upewnij się, że adres URL podany reklamodawcom lub newsletterom jest prawidłowym końcowym adresem URL, aby nie dodawać kolejnego przekierowania do adresów, z których korzystają te usługi.
Innym ważnym źródłem czasu przekierowania są przekierowania HTTP do HTTPS. Aby obejść to ograniczenie, możesz używać nagłówka Strict-Transport-Security (HSTS), który wymusza stosowanie protokołu HTTPS podczas pierwszej wizyty w witrynie źródłowej, a później informuje przeglądarkę, że przy kolejnych wizytach będzie od razu uzyskiwać dostęp do źródła przez protokół HTTPS.
Po wdrożeniu zasad HSTS możesz przyspieszyć pierwsze wizyty w witrynie, dodając ją do listy wstępnego ładowania HSTS.
Przesyłanie znaczników do przeglądarki
Przeglądarki są zoptymalizowane pod kątem wydajnego przetwarzania znaczników podczas przesyłania strumieniowego, co oznacza, że znaczniki są przetwarzane we fragmentach podczas przesyłania z serwera. Ma to ogromne znaczenie w przypadku dużych ładunków znaczników, ponieważ dzięki temu przeglądarka może analizować fragmenty znaczników stopniowo, zamiast czekać na nadejście całej odpowiedzi przed rozpoczęciem analizy.
Choć przeglądarki świetnie radzą sobie ze znacznikami strumieniowania, trzeba zadbać o to, by strumień działał płynnie, tak aby początkowy fragment kodu był w drodze jak najszybciej. Jeśli backend coś blokuje, to problem. Ponieważ stosów backendowych jest bardzo dużo, nie zawarłby w tym przewodniku informacji o każdym z nich i problemach, które mogą się pojawić w każdym z nich.
Na przykład platforma React oraz inne platformy, które mogą renderować znaczniki na żądanie na serwerze, stosują synchroniczne podejście do renderowania po stronie serwera. Jednak w nowszych wersjach React w trakcie renderowania stosowane są metody serwera do strumieniowego przesyłania danych. Oznacza to, że nie musisz czekać, aż metoda interfejsu React Server API wyrenderuje całą odpowiedź, zanim zostanie wysłana.
Innym sposobem zapewnienia szybkiego przesyłania znaczników do przeglądarki jest korzystanie z renderowania statycznego, które generuje pliki HTML podczas kompilacji. Gdy pełny plik jest dostępny od razu, serwery WWW mogą od razu rozpocząć jego wysyłanie, a naturalny charakter protokołu HTTP powoduje dodawanie znaczników przesyłanych strumieniowo. Chociaż nie jest to rozwiązanie odpowiednie dla każdej strony w każdej witrynie, np. tych, 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 dostosowywać je pod kątem 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 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 plik TTFB witryny, zależy od jego konfiguracji i zgodności z wymaganiami aplikacji.
- Stosuj strategię dotyczącą zasobów nieaktualnych w czasie ponownej weryfikacji. Jeśli zasób znajduje się w pamięci podręcznej skryptu service worker – niezależnie od tego, czy jest to dokument lub zasób, którego wymaga dokument – strategia „Nieaktualne podczas ponownej weryfikacji” najpierw obsługuje ten zasób z pamięci podręcznej, a potem pobiera go w tle i 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 „Nieaktualne podczas ponownej weryfikacji” może sprawić, że przekształcenie strony będzie niemal natychmiastowe. Ta metoda nie działa jednak zbyt dobrze, jeśli witryna wysyła dynamicznie generowane znaczniki, takie jak znaczniki, które zmieniają się w zależności od tego, czy użytkownik jest uwierzytelniony. W takich przypadkach najlepiej jest zawsze trafiać do sieci najpierw, aby dokument był jak najświeższy.
- Jeśli dokument wczytuje niekrytyczne zasoby, które zmieniają się z pewną częstotliwością, ale pobieranie nieaktualnych zasobów nie wpłynie znacząco na wygodę użytkowników (np. na wybrane obrazy lub inne zasoby, które nie mają krytycznego znaczenia), można znacznie ograniczyć ilość potrzebnego materiału na potrzeby tych zasobów, używając strategii „Nieaktualne podczas ponownej weryfikacji”.
- W miarę możliwości używaj architektury Service Worker strumieniowania. W tej architekturze skryptu service worker części zasobu dokumentu są przechowywane w pamięci podręcznej skryptu service worker oraz w połączeniu z fragmentami treści podczas żądania nawigacji. Efektem używania takiego wzorca jest to, że nawigacja przebiega szybko i są pobierane z sieci mniejsze ładunki HTML. Chociaż ten wzorzec skryptu service worker nie działa w przypadku każdej witryny, czasy TTFB mogą być niemal natychmiastowe w przypadku witryn, które mogą z niego korzystać.
- W przypadku aplikacji renderowanych przez klienta używaj modelu powłoki aplikacji. Ten model najlepiej sprawdza się w przypadku usług jednopłciowych, w których „powłoka” strony jest 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 103 Early Hints w przypadku zasobów o kluczowym znaczeniu dla renderowania
Niezależnie od tego, jak dobrze backend aplikacji jest zoptymalizowany, przygotowanie odpowiedzi przez serwer może wymagać dużo pracy. Przygotowanie odpowiedzi wymaga na przykład kosztownej (ale niezbędnej) pracy w bazie danych, która opóźnia dostarczenie odpowiedzi nawigacji. W efekcie niektóre zasoby o znaczeniu krytycznym przy renderowaniu mogą być opóźnione, np. CSS lub – w niektórych przypadkach – JavaScript, 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. Nagłówek ten 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 istnieje tak wiele kombinacji stosów aplikacji backendu, nie ma jednego artykułu, który zawierałby wszystko, co można zrobić, aby obniżyć liczbę konwersji TTFB w witrynie. Są to jednak niektóre opcje, które możesz wypróbować, aby przyspieszyć działanie serwera.
Podobnie jak w przypadku optymalizacji wszystkich danych, podejście jest zasadniczo podobne: dokonaj pomiaru TTFB w terenie, użyj narzędzi laboratoryjnych, aby przeanalizować przyczyny i w miarę możliwości wprowadzić optymalizacje. Nie każda z tych technik może się sprawdzić w Twojej sytuacji, ale niektóre mogą być skuteczne. Musisz jak zawsze uważnie obserwować dane pól i w razie potrzeby wprowadzać odpowiednie zmiany, aby zapewnić jak największą wygodę użytkowników.
Baner powitalny autorstwa Taylor Vick, pochodzący z Unsplash.