Ogólne kwestie związane z wydajnością kodu HTML

Pierwszym etapem tworzenia witryny, która szybko się ładuje, jako odpowiedź z serwera na kod HTML strony. Po wpisaniu adresu URL w polu paska adresu przeglądarki, przeglądarka wysyła do serwera żądanie GET, aby go pobrać. Pierwsze żądanie strony internetowej dotyczy zasobu HTML. Zapewnianie szybkiego dostarczania kodu HTML z minimalnymi opóźnieniami jest kluczową wydajnością cel.

Początkowe żądanie kodu HTML składa się z kilku etapów, z których każdy za jakiś czas. Skrócenie czasu potrzebnego na każdy etap pozwala szybciej uzyskać pomoc Pierwszy bajt (TTFB). Chociaż TTFB nie jest jedynym wskaźnikiem, na którym warto się skupić, jeśli chodzi o szybkość wczytywania stron, duża część TTFB utrudni dotarcie do oznaczonych jako „dobre”. wartości progowe wskaźników takich jak Największe wyrenderowanie treści (LCP) i Pierwsze wyrenderowanie treści (FCP).

Zminimalizuj przekierowania

Na żądanie zasobu serwer może odpowiedzieć przekierowaniem, na przykład: z trwałym przekierowaniem (odpowiedź 301 Moved Permanently) lub tymczasowym jeden (odpowiedź 302 Found).

Przekierowania spowalniają wczytywanie stron, ponieważ wymagają od przeglądarki wykonania aby pobrać zasób za pomocą dodatkowego żądania HTTP do nowej lokalizacji. Istnieją 2 typy przekierowań:

1. Przekierowania z tej samej domeny, które występują w całości w pierwotnym miejscu. Typy te masz pełną kontrolę nad przekierowaniami, ponieważ masz do dyspozycji mechanizmy zarządzania są w całości na Twoim serwerze WWW.
2. Przekierowania między domenami inicjowane przez inne źródło. Typy są zwykle poza Twoją kontrolą.

Przekierowania między domenami są często używane przez reklamy, usługi do skracania adresów URL usług innych firm. Chociaż nie masz wpływu na przekierowania między domenami, warto nadal sprawdzać, czy nie masz wielokrotnych przekierowań – na przykład mieć reklamę, która prowadzi do strony HTTP, która z kolei przekierowuje do jej protokołu HTTPS odpowiednik lub przekierowanie między domenami, które dociera do punktu początkowego, ale później uruchamia przekierowanie z tej samej domeny.

Buforuj odpowiedzi HTML

Zapisywanie odpowiedzi HTML w pamięci podręcznej jest trudne, ponieważ odpowiedź może zawierać linki do inne ważne zasoby, takie jak pliki CSS, JavaScript, obrazy i inne zasoby . Te zasoby mogą zawierać unikalny odcisk cyfrowy które zmieniają się w zależności od zawartości pliku. Oznacza to, że dane z pamięci podręcznej Po wdrożeniu dokument HTML może stać się nieaktualny, ponieważ zawierałby odniesień do nieaktualnych zasobów podrzędnych.

Krótki czas przechowywania w pamięci podręcznej – zamiast braku jej działania – może przynosić korzyści Na przykład dzięki temu, że zasób można przechowywać w pamięci podręcznej w sieci CDN, co zmniejsza liczbę z serwera pierwotnego i przeglądarki, co pozwala zasobów do ponownej weryfikacji, a nie do ponownego pobrania. Ta metoda się sprawdza najlepiej sprawdza się w przypadku treści statycznych, które nie zmieniają się w żadnym kontekście. czas buforowania zasobów można ustawić na określoną liczbę minut odpowiednie. Poświęć 5 minut na statyczne zasoby HTML. by okresowe aktualizacje były dobrze widoczne.

Jeśli treść HTML na stronie jest w jakiś sposób spersonalizowana – na przykład na potrzeby uwierzytelniony użytkownik – prawdopodobnie w ogóle nie chcesz buforować treści z różnych powodów, w tym związanych z bezpieczeństwem i aktualność. Jeśli odpowiedź HTML to zapisanych w pamięci podręcznej przeglądarki użytkownika, nie można unieważnić pamięci podręcznej. Jest dlatego w takich przypadkach najlepiej unikać buforowania kodu HTML.

Aby zachować ostrożność podczas zapisywania kodu HTML w pamięci podręcznej, użyj funkcji ETag lub Nagłówki odpowiedzi Last-Modified. Element ETag – inaczej encja tag – nagłówek to identyfikator, który jednoznacznie reprezentuje żądany zasób; często za pomocą szyfrowania treści zasobu:

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Po każdej zmianie zasobu musi zostać wygenerowana nowa wartość ETag. Wł. kolejnych żądań przeglądarka wysyła wartość ETag za pomocą funkcji If-None-Match nagłówek żądania. Jeśli ETag na serwerze jest zgodny z adresem wysyłanych przez przeglądarkę, serwer odpowiada w odpowiedzi 304 Not Modified, a przeglądarka korzysta z zasobu z pamięci podręcznej. W dalszym ciągu będzie to miało miejsce czas oczekiwania w sieci, odpowiedź 304 Not Modified jest znacznie mniejsza niż cała Zasób HTML.

Jednak opóźnienia sieciowe związane z ponowną weryfikacją aktualności zasobu są który wciąż ma pewną wadę. Podobnie jak w przypadku wielu innych aspektów programowania stron internetowych, kompromisów i kompromisów nie da się uniknąć. Od Ciebie zależy, czy warto włożyć dodatkowe wysiłki w pamięci podręcznej HTML w ten sposób lub jeśli aby zachować bezpieczeństwo i zrezygnować z zapisywania treści HTML w pamięci podręcznej.

Mierz czas reakcji serwera

Jeśli odpowiedź nie jest zapisana w pamięci podręcznej, czas odpowiedzi serwera w dużym stopniu zależy od dostawcy usług hostingowych i stosu aplikacji backendu. Strona internetowa pełniąca funkcję odpowiedzi generowanej dynamicznie, np. pobierania danych z bazy danych, – może ona mieć wyższy wskaźnik TTFB niż statyczna strona internetowa, którą można wyświetlić i nie wymaga to znacznego czasu obliczeniowego na backendzie. Wyświetlane wskaźnik postępu ładowania, a następnie pobranie wszystkich danych po stronie klienta przenosi z bardziej przewidywalnego środowiska po stronie serwera po stronie klienta. Mniejszy wysiłek po stronie klienta zwykle skutkuje na podstawie danych o użytkownikach.

Jeśli użytkownicy doświadczają wolnego czasu na stronie, możesz ujawnić informacje miejsca spędzanego na serwerze za pomocą interfejsu Server-Timing nagłówek odpowiedzi:

Server-Timing: auth;dur=55.5, db;dur=220

Wartość nagłówka Server-Timing może zawierać wiele danych, a także dla każdej z nich. Te dane mogą być następnie zbierane od użytkowników w terenie za pomocą Navigation Timing API, by sprawdzić, czy użytkownicy i opóźnienia. W poprzednim fragmencie kodu nagłówek odpowiedzi zawiera 2 czasy:

• Czas uwierzytelniania użytkownika (auth): 55,5 milisekunda.
• Czas dostępu do bazy danych (db), który trwał 220 milisekund.

Warto też sprawdzić infrastrukturę hostingową i potwierdzić, dysponujesz zasobami odpowiednimi do obsługi ruchu w Twojej witrynie. Udostępniona dostawcy usług hostingowych są często narażeni na wysokie ryzyko związane z TTFB, a specjalne rozwiązania które zapewniają krótszy czas odpowiedzi, mogą być droższe.

Kompresja

Odpowiedzi tekstowe, takie jak obrazy HTML, JavaScript, CSS i SVG, powinny być skompresowane, aby zmniejszyć rozmiar przesyłanych danych przez sieć i umożliwić ich pobieranie. Najczęściej stosowanymi algorytmami kompresji są gzip oraz Brotli. W wyniku Brotli można uzyskać lepsze wyniki o około 15–20% w porównaniu z gzip.

Kompresja jest często konfigurowana automatycznie przez większość dostawców usług hostingowych, ale jeśli możesz skonfigurować to rozwiązanie, musisz wziąć pod uwagę kilka ważnych kwestii lub samodzielnie dostosuj ustawienia kompresji:

1. W miarę możliwości używaj Brotli. Jak już wspomnieliśmy, Brotli zapewnia dość znaczącą poprawę w porównaniu z gzip, a Brotli jest obsługiwany we wszystkich przeglądarek. W miarę możliwości używaj witryny Brotli, ale jeśli Twoja witryna użytkowników korzystających ze starszych przeglądarek, należy użyć programu gzip, bo każda kompresja jest lepsza niż jej brak.
2. Rozmiar pliku ma znaczenie. Bardzo małe zasoby – mniejsze niż 1 KiB – nie kompresuj bardzo dobrze, a czasami nawet w ogóle nie skompresować. Skuteczność dowolnego typu kompresja danych zależy od dużych ilości danych, algorytm kompresji, by znaleźć więcej kompresowalnych bitów danych. Im większy jest plik, tym lepiej działa kompresja, ale nie wysyłają bardzo duże zasoby tylko dlatego, że mogą być bardziej kompresowane. co osłabia efektywność przekazu. W przypadku dużych zasobów, takich jak JavaScript i CSS, czas na analizę i ocenę, gdy przeglądarka są zdekompresowane i mogą zmieniać się częściej, nawet jeśli nieznacznie zmienione, ponieważ wszelkie zmiany powodują zmianę haszowania pliku.
3. Różnice między kompresją dynamiczną i statyczną. Dynamiczne i statyczne kompresja różni się w zależności od tego, kiedy zasób powinien skompresowane. Dynamiczna kompresja kompresuje zasób w momencie, gdy , a czasami za każdym razem, gdy jest to żądanie. Z drugiej strony, kompresja statyczna kompresuje pliki z wyprzedzeniem i nie wymaga kompresji. które należy wykonać w momencie przesłania żądania. Kompresja statyczna usuwa czas oczekiwania związany z samą kompresją i może wydłużać czas odpowiedzi serwera w przypadku kompresji dynamicznej. zasoby statyczne, takie jak Obrazy JavaScript, CSS i SVG – powinny być skompresowane statycznie, natomiast zasobów – zwłaszcza, jeśli są one generowane dynamicznie na potrzeby uwierzytelniania. użytkowników – powinna być skompresowana dynamicznie.

Samodzielne uzyskanie kompresji nie jest łatwym zadaniem i często najlepiej sieci dystrybucji treści (CDN), która została omówiona w następnej sekcji, zajmie się tym za Ciebie. Znajomość tych koncepcji pozwala jednak określić, sprawdzić, czy dostawca usług hostingowych prawidłowo stosuje kompresję. Wiedza ta może pomogą Ci znaleźć możliwości ulepszenia ustawień kompresji, aby przyniosą witrynie największe korzyści.

Sieci dostarczania treści (CDN)

Sieć dostarczania treści (CDN) to rozproszona sieć serwerów, buforować zasoby serwera pierwotnego i z kolei udostępniać je z brzegu sieci które znajdują się fizycznie bliżej użytkowników. Fizyczna odległość od zmniejsza czas przesyłania w obie strony (RTT), podczas gdy optymalizacje, na przykład HTTP/2 lub HTTP/3, buforowanie i kompresja umożliwiają sieci CDN szybsze wyświetlanie treści niż w przypadku pobierania z serwera pierwotnego. Użycie sieci CDN w niektórych przypadkach znacznie usprawniają funkcję TTFB witryny.

Sprawdź swoją wiedzę

Kolejny krok: zrozumienie ścieżki krytycznej

Znasz już niektóre aspekty dotyczące wydajności, które trzeba wziąć pod uwagę, za pomocą kodu HTML swojej witryny, będziesz mieć większą pewność, że wczytuje się ona jak najszybciej, ale to dopiero początek nauki internetowej skuteczność reklam. Kolejna teoria dotycząca krytycznej ścieżki renderowania to: i konkretnie. W tym module omówione są główne pojęcia, takie jak blokowanie renderowania, analizy zasobów blokujących analizę i jaką pełnią funkcję renderowanie w przeglądarce.