Sieci dystrybucji treści (CDN)

Zwiększ skuteczność, korzystając z sieci dostarczania treści.

Sieci dostarczania treści (CDN) poprawiają wydajność witryny dzięki wykorzystaniu rozproszonej sieci serwerów do dostarczania zasobów użytkownikom. Sieci CDN zmniejszają obciążenie serwera, więc obniżają koszty serwera i są świetnie przygotowane do obsługi gwałtownych skoków natężenia ruchu. Z tego artykułu dowiesz się, jak działają sieci CDN, a także uzyskasz wskazówki niezależne od platformy dotyczące wyboru, konfigurowania i optymalizacji konfiguracji sieci CDN.

Przegląd

Sieć dostarczania treści składa się z sieci serwerów zoptymalizowanych pod kątem szybkiego dostarczania treści użytkownikom. Sieci CDN są zapewne najlepiej znane z wyświetlania treści z pamięci podręcznej, ale mogą też usprawnić wyświetlanie treści, których nie można przechowywać w pamięci podręcznej. Ogólnie rzecz biorąc, im więcej treści z Twojej witryny wyświetla Twoja sieć CDN, tym lepiej.

Ogólnie rzecz biorąc, korzyści w zakresie wydajności sieci CDN wynikają z kilku zasad: serwery CDN znajdują się bliżej użytkowników niż serwery origin i dlatego mają krótszy czas oczekiwania w obie strony (RTT). Optymalizacja sieci pozwala sieciom CDN na dostarczanie treści szybciej niż w przypadku ich ładowania „bezpośrednio” z serwera pierwotnego. W końcu pamięć podręczna CDN eliminuje konieczność przesyłania żądań do serwera pierwotnego.

Dostarczanie zasobów

Chociaż może się to wydawać nieintuicyjne, wykorzystanie sieci CDN do przesyłania zasobów (nawet tych, których nie można buforować) jest zwykle szybsze niż wczytywanie ich przez użytkownika „bezpośrednio” z Twoich serwerów.

Gdy do przesyłania zasobów z punktu początkowego używana jest sieć CDN, między klientem a pobliskim serwerem CDN tworzone jest nowe połączenie. Pozostała część ścieżki (czyli przesyłanie danych między serwerem CDN a punktem początkowym) odbywa się przez sieć CDN, która często obejmuje istniejące trwałe połączenia ze punktem początkowym. Korzyści są dwie po drugiej stronie: zakończenie nowego połączenia jak najbliżej użytkownika eliminuje niepotrzebne koszty konfiguracji (jest to kosztowne i wymaga kilku transferów danych w obie strony). Wstępnie przygotowane połączenie pozwala na natychmiastowe przeniesienie danych z maksymalną przepustowością.

Niektóre sieci CDN jeszcze bardziej to doskonalą, przekierowując ruch do punktu początkowego przez wiele serwerów CDN rozmieszczonych w internecie. Połączenia między serwerami CDN powstają na niezawodnych i wysoce zoptymalizowanych trasach zamiast na trasach określonych za pomocą protokołu Border Gateway Protocol (BGP). Chociaż BGP to defaktywny protokół routingu w internecie, jego decyzje dotyczące routingu nie zawsze są uzależnione od wydajności. Z tego powodu trasy określone przez BGP będą prawdopodobnie mniej wydajne niż dostrojone trasy między serwerami CDN.

Zapisywanie w pamięci podręcznej

Przechowywanie zasobów w pamięci podręcznej na serwerach CDN eliminuje konieczność przesłania żądania aż do punktu początkowego, aby je wyświetlić. W rezultacie zasób jest dostarczany szybciej, a jednocześnie zmniejsza obciążenie serwera pierwotnego.

Dodawanie zasobów do pamięci podręcznej

Najczęściej stosowaną metodą wypełniania pamięci podręcznych CDN jest udostępnianie potrzebnych zasobów CDN w miarę potrzeb – jest to tzw. pobieranie źródła. Przy pierwszym żądaniu konkretnego zasobu z pamięci podręcznej CDN wysyła żądanie do serwera pierwotnego i zapisuje w pamięci podręcznej odpowiedź. W ten sposób zawartość pamięci podręcznej jest kumulowana wraz z upływem czasu w miarę wysyłania żądań dotyczących dodatkowych niebuforowanych zasobów.

Usuwanie zasobów z pamięci podręcznej

Sieci CDN używają usuwania z pamięci podręcznej do okresowego usuwania z niej nieprzydatnych zasobów. Oprócz tego właściciele witryn mogą użyć funkcji trwałego usuwania zasobów, aby ją usunąć.

• Usuwanie z pamięci podręcznej

  Pamięć podręczna ma ograniczoną pojemność. Gdy pamięć podręczna wkrótce się wyczerpie, zwolni się miejsce na nowe zasoby, które nie były ostatnio używane lub zajmują dużo miejsca. Ten proces jest nazywany usuwaniem z pamięci podręcznej. Trwale usunięty zasób z jednej pamięci podręcznej nie musi oznaczać, że został usunięty ze wszystkich pamięci podręcznych w sieci CDN.

• Trwałe usuwanie

  Trwałe usuwanie (nazywane też „unieważnieniem pamięci podręcznej”) to mechanizm usuwania zasobu z pamięci podręcznych sieci CDN bez konieczności oczekiwania na jego wygaśnięcie lub wykluczenie. Zwykle jest wykonywany przez interfejs API. Jest to bardzo ważne w sytuacjach, gdy trzeba będzie wycofać treść (np. gdy chcesz poprawić literówki, błędy w cenach lub nieprawidłowe artykuły z wiadomościami). Może też odgrywać kluczową rolę w strategii buforowania witryny w witrynie.

  Jeśli sieć CDN obsługuje niemal natychmiastowe trwałe usunięcie, można użyć trwałego usunięcia jako mechanizmu zarządzania przechowywaniem treści dynamicznych w pamięci podręcznej: buforowanie zawartości dynamicznej z użyciem długiego czasu TTL, a następnie trwałe usuwanie zasobu po każdej jego aktualizacji. W ten sposób można zmaksymalizować czas przechowywania zasobu dynamicznego w pamięci podręcznej, mimo że nie wiadomo z wyprzedzeniem, kiedy zasób się zmieni. Ta technika jest czasami określana jako „buforowanie wiadomości z wstrzymaniem do wyświetlenia”.

  Gdy trwałe usuwanie jest stosowane na dużą skalę, zwykle stosuje się je w połączeniu z pojęciem znanym jako „tagi pamięci podręcznej” lub „zastępczy klucz pamięci podręcznej”. Ten mechanizm umożliwia właścicielom witryn powiązanie jednego lub wielu dodatkowych identyfikatorów (nazywanych czasami „tagami”) z zasobem zapisanym w pamięci podręcznej. Tych tagów można następnie użyć do bardzo precyzyjnego usuwania danych. Możesz na przykład dodać tag „stopka” do wszystkich zasobów (np. /about, /blog), które zawierają stopkę witryny. Po zaktualizowaniu stopki poinstruuj sieć CDN, aby trwale usunęła wszystkie zasoby powiązane z tagiem „footer”.

Zasoby zapisywane w pamięci podręcznej

To, czy i w jaki sposób zasób ma być buforowany, zależy od tego, czy jest on publiczny, czy prywatny: statyczny czy dynamiczny.

Zasoby prywatne i publiczne

• Zasoby prywatne

  Zasoby prywatne zawierają dane przeznaczone dla pojedynczego użytkownika, dlatego nie powinny być buforowane przez CDN. Zasoby prywatne są oznaczone w nagłówku Cache-Control: private.

• Zasoby publiczne

  Zasoby publiczne nie zawierają informacji dotyczących konkretnego użytkownika i dlatego można je buforować przez CDN. Zasób może zostać uznany za buforowany przez sieć CDN, jeśli nie ma nagłówka Cache-Control: no-store ani Cache-Control: private. Czas, przez jaki zasób publiczny może być przechowywany w pamięci podręcznej, zależy od tego, jak często się on zmienia.

Treści dynamiczne i statyczne

• Treści dynamiczne

  Zawartość dynamiczna to treści, które często się zmieniają. Przykładami tego typu treści są odpowiedź interfejsu API i strona główna sklepu. Jednak fakt, że taka treść często się zmienia, nie musi oznaczać, że zostanie ona zapisana w pamięci podręcznej. W okresach dużego ruchu przechowywanie tych odpowiedzi w pamięci podręcznej na bardzo krótki czas (na przykład 5 sekund) może znacznie zmniejszyć obciążenie serwera pierwotnego, a jednocześnie mieć minimalny wpływ na częstotliwość aktualizacji danych.

• Treść statyczna

  Treści statyczne zmieniają się rzadko lub w ogóle. Przykładem tego typu treści są obrazy, filmy i biblioteki z różnymi wersjami. Ponieważ zawartość statyczna się nie zmienia, powinna być przechowywana w pamięci podręcznej z długim czasem życia danych (TTL), na przykład 6 miesięcy lub 1 rokem.

Wybieranie sieci CDN

Przy wyborze sieci CDN zwykle bierzemy pod uwagę wydajność. Przy wyborze sieci musisz jednak wziąć pod uwagę inne funkcje dostępne w sieci CDN (np. funkcje zabezpieczeń i analityki), a także ceny, obsługę i wprowadzenie.

Występy

Ogólnie strategię dotyczącą wydajności sieci CDN można traktować jako kompromis między minimalizacją czasu oczekiwania a maksymalizacją współczynnika trafień w pamięci podręcznej. Sieci CDN z wieloma punktami obecności (PoP) mogą zapewniać mniejsze opóźnienie, ale współczynnik trafień w pamięci podręcznej może być niższy z powodu podziału ruchu między większą liczbę pamięci podręcznych. Sieci CDN z mniejszą liczbą PoP mogą znajdować się w dalszej odległości od użytkowników, ale mogą uzyskać wyższy współczynnik trafień w pamięci podręcznej.

W związku z tym niektóre sieci CDN stosują wielopoziomowe podejście do buforowania: platformy PoP znajdujące się blisko użytkowników (nazywane również „bonusowymi pamięciami podręcznymi”) są uzupełniane przez centralne punkty PoP o większych współczynnikach trafień pamięci podręcznej. Gdy pamięć podręczna na brzegu nie może znaleźć zasobu, szuka go w centralnym punkcie PoP. Ta metoda przekłada się na nieco dłuższy czas oczekiwania na większe prawdopodobieństwo, że zasób może być udostępniany z pamięci podręcznej sieci CDN, ale niekoniecznie z serwera brzegowego.

Wynik między minimalizacją czasu oczekiwania a maksymalizacją współczynnika trafień w pamięci podręcznej jest spektakularny. Żadne konkretne podejście nie jest uniwersalne. Jednak w zależności od charakteru witryny i liczby użytkowników może się okazać, że któraś z nich zapewnia znacznie większą skuteczność niż druga.

Warto też pamiętać, że wydajność CDN może się znacznie różnić w zależności od położenia geograficznego, pory dnia, a nawet bieżących wydarzeń. Chociaż zawsze warto samodzielnie sprawdzić wydajność sieci CDN, przewidzenie dokładnej wydajności sieci CDN może być trudne.

Wpływ na największe wyrenderowanie treści (LCP)

Jak już wspomnieliśmy, głównym celem sieci CDN jest skrócenie czasu oczekiwania przez dystrybucję zasobów na serwery znajdujące się bliżej użytkowników. Dlatego jej główną zaletą jest zwiększenie szybkości wczytywania. Czas do pierwszego bajtu (TTFB) zasobu można znacznie poprawić podczas wprowadzania sieci CDN do architektury po stronie serwera witryny.

Chociaż TTFB nie jest zorientowanym na użytkownika wskaźnikiem skuteczności, jest ważnym wskaźnikiem przy diagnozowaniu problemów z największym wyrenderowaniem treści (LCP), czyli zorientowanym na użytkownika danymi.

Sieci CDN są szczególnie skuteczne w poprawianiu LCP, ponieważ mogą poprawić zarówno dostarczanie dokumentów (przez ograniczenie TTFB podczas konfiguracji połączenia i buforowanie dokumentu), jak i poprawę dostarczania zasobów statycznych niezbędnych do renderowania elementu LCP.

Dodatkowe funkcje

Sieci CDN zwykle oferują szeroki zakres funkcji oprócz swojej podstawowej oferty CDN. Popularne funkcje to między innymi równoważenie obciążenia, optymalizacja obrazów, strumieniowe przesyłanie wideo, przetwarzanie brzegowe i usługi zabezpieczające.

Jak skonfigurować sieć CDN

Najlepiej jest używać sieci CDN do wyświetlania reklam w całej witrynie. Ogólnie proces konfiguracji obejmuje zarejestrowanie się u dostawcy CDN, a następnie zaktualizowanie rekordu DNS CNAME, aby wskazywał dostawcę CDN. Na przykład rekord CNAME domeny www.example.com może wskazywać na example.my-cdn.com. W wyniku tej zmiany DNS ruch do Twojej witryny będzie kierowany przez sieć CDN.

Jeśli nie możesz skorzystać z sieci CDN do obsługi wszystkich zasobów, możesz ją skonfigurować tak, by obsługiwała tylko podzbiór zasobów, na przykład tylko zasoby statyczne. Możesz to zrobić, tworząc oddzielny rekord CNAME, który będzie używany tylko na potrzeby zasobów, które powinny być udostępniane przez CDN. Możesz na przykład utworzyć rekord CNAME static.example.com wskazujący example.my-cdn.com. Konieczne będzie też przepisanie adresów URL zasobów obsługiwanych przez sieć CDN, aby wskazywały utworzoną przez Ciebie subdomenę static.example.com.

Chociaż na tym etapie zostanie skonfigurowana sieć CDN, prawdopodobnie konfiguracja będzie miała niską wydajność. W 2 kolejnych sekcjach tego artykułu opisujemy, jak w pełni wykorzystać możliwości sieci CDN, zwiększając współczynnik trafień w pamięci podręcznej i włączając funkcje wydajności.

Poprawa współczynnika trafień w pamięci podręcznej

Efektywna konfiguracja CDN udostępnia jak najwięcej zasobów z pamięci podręcznej. Wartość ta jest zwykle mierzona współczynnikiem trafień w pamięci podręcznej (CHR). Współczynnik trafień w pamięci podręcznej to liczba trafień w pamięci podręcznej podzielona przez liczbę wszystkich żądań w danym przedziale czasu.

Świeżo zainicjowana pamięć podręczna będzie miała współczynnik CHR wynoszący 0, ale ta wartość rośnie, gdy pamięć podręczna jest zapełniana zasobami. CHR na poziomie 90% to dobry cel dla większości witryn. Dostawca CDN powinien dostarczyć Ci statystyki i raporty dotyczące CHR.

Przy optymalizacji CHR najpierw należy sprawdzić, czy wszystkie zasoby dostępne w pamięci podręcznej są buforowane przez odpowiedni czas. To prosta ocena, którą powinny przeprowadzać wszystkie witryny.

Kolejnym poziomem optymalizacji CHR jest dostrajanie ustawień CDN, aby logicznie równoważne odpowiedzi serwera nie były przechowywane w pamięci podręcznej oddzielnie. Jest to typowa nieefektywność wynikająca z wpływu na buforowanie czynników takich jak parametry zapytań, pliki cookie i nagłówki żądań.

Wstępny audyt

Większość sieci CDN zapewnia analizy pamięci podręcznej. Możesz też użyć narzędzi takich jak WebPageTest i Lighthouse, aby szybko sprawdzić, czy wszystkie statyczne zasoby strony są przechowywane w pamięci podręcznej przez odpowiedni czas. W tym celu sprawdza nagłówki pamięci podręcznej HTTP każdego zasobu. Buforowanie zasobu z użyciem maksymalnego odpowiedniego czasu życia danych (TTL) zapobiega niepotrzebnym pobieraniu źródła w przyszłości i tym samym zwiększa CHR.

Aby zasób był zapisywany w pamięci podręcznej przez CDN, zwykle trzeba ustawić co najmniej jeden z tych nagłówków:

• Cache-Control: max-age=
• Cache-Control: s-maxage=
• Expires

Nie ma to wpływu na to, czy zasób jest zapisywany w pamięci podręcznej przez CDN i w jaki sposób, warto jednak ustawić także dyrektywę Cache-Control: immutable.Cache-Control: immutable wskazuje, że zasób „nie będzie aktualizowany w trakcie swojej aktualności”. W efekcie przeglądarka nie weryfikuje zasobów podczas udostępniania go z pamięci podręcznej przeglądarki, eliminując niepotrzebne żądania serwera. Jest ona obsługiwana tylko w przeglądarkach Firefox i Safari (nie jest obsługiwana w przeglądarkach opartych na Chromium). Ten problem śledzi obsługę klienta Cache-Control: immutable w Chromium. Oznaczenie tego problemu gwiazdką może zachęcić do tego zespołu pomocy.

Bardziej szczegółowe objaśnienie funkcji buforowania HTTP znajdziesz w artykule Zapobiegaj niepotrzebnym żądaniam sieciowym przy użyciu pamięci podręcznej HTTP.

Dostrajanie

Nieco uproszczone wyjaśnienie działania pamięci podręcznej CDN polega na tym, że adres URL zasobu służy jako klucz do buforowania i pobierania zasobu z tej pamięci. W praktyce jest to w ogóle prawdą, ale jest nieco skomplikowane ze względu na wpływ czynników takich jak nagłówki żądań i parametry zapytania. W związku z tym przeredagowanie adresów URL żądań reklamy jest ważną metodą zarówno dla maksymalizacji skuteczności CHR, jak i zapewniania użytkownikom dostępu do właściwych treści. Prawidłowo skonfigurowana instancja CDN zapewnia odpowiednią równowagę między nadmiernie szczegółowym buforowaniem (co negatywnie wpływa na CHR) a niewystarczająco szczegółową pamięcią podręczną (co prowadzi do wyświetlania użytkownikom nieprawidłowych odpowiedzi).

Parametry zapytania

Domyślnie sieci CDN uwzględniają parametry zapytania podczas buforowania zasobu. Jednak niewielkie zmiany w obsłudze parametrów zapytań mogą mieć znaczący wpływ na CHR. Na przykład:

• Niepotrzebne parametry zapytania

  Domyślnie sieć CDN będzie zapisywać w pamięci podręcznej example.com/blog i example.com/blog?referral_id=2zjk oddzielnie, choć prawdopodobnie są to te same zasoby bazowe. Aby rozwiązać ten problem, dostosuj konfigurację sieci CDN tak, aby ignorowała parametr zapytania referral\_id.

• Kolejność parametrów zapytania

  CDN będzie buforować example.com/blog?id=123&query=dogs niezależnie od example.com/blog?query=dogs&id=123. W przypadku większości witryn kolejność parametrów zapytań nie ma znaczenia, więc skonfigurowanie sieci CDN tak, aby sortowała parametry zapytań (poprzez normalizację adresu URL używanego do buforowania odpowiedzi serwera) zwiększy CHR.

Zmieniaj

Nagłówek odpowiedzi Vary informuje pamięci podręcznej, że odpowiedź serwera odpowiadająca określonemu adresowi URL może się zmieniać w zależności od nagłówków ustawionych w żądaniu (np. nagłówków żądania Accept-Language lub Accept-Encoding). W efekcie sieć CDN przechowuje te odpowiedzi w pamięci podręcznej oddzielnie. Nagłówek Vary nie jest powszechnie obsługiwany przez sieci CDN, przez co zasób może nie być wyświetlany z pamięci podręcznej w inny sposób.

Nagłówek Vary może być przydatnym narzędziem, ale jego nieodpowiednie użycie szkodzi CHR. Ponadto, jeśli używasz Vary, normalizacja nagłówków żądań pomoże ulepszyć CHR. Na przykład bez normalizacji nagłówki żądań Accept-Language: en-US i Accept-Language: en-US,en;q=0.9 spowodowałyby utworzenie 2 osobnych wpisów w pamięci podręcznej, choć ich zawartość prawdopodobnie byłaby identyczna.

Ciastka

Pliki cookie są tworzone w żądaniach za pomocą nagłówka Cookie i w odpowiedziach za pomocą nagłówka Set-Cookie. Nie należy niepotrzebnie używać nagłówka Set-Cookie, ponieważ pamięci podręczne zwykle nie zapisują odpowiedzi serwera z tym nagłówkiem.

Funkcje związane z wydajnością

W tej sekcji omawiamy funkcje związane z wydajnością, które są zwykle oferowane przez sieci CDN w ramach głównej oferty usług. Wiele witryn zapomina o włączeniu tych funkcji, tracąc w ten sposób łatwy dostęp do skutecznych rozwiązań.

Kompresja

Wszystkie odpowiedzi tekstowe powinny być skompresowane za pomocą programu gzip lub Brotli. Jeśli masz możliwość, wybierz Brotli zamiast gzip. Brotli to nowszy algorytm kompresji. W porównaniu z gzip może uzyskać wyższe współczynniki kompresji.

Istnieją 2 rodzaje obsługi kompresji CDN w sieci CDN: „Brotli z punktu początkowego” i „automatyczna kompresja Brotli”.

Brotli z miejsca początkowego

Brotli z punktu początkowego ma miejsce, gdy sieć CDN udostępnia zasoby skompresowane przez punkt początkowy Brotli. Może się wydawać, że jest to funkcja, którą wszystkie sieci CDN powinny od razu obsługiwać, ale wymaga też, aby sieć CDN mogła przechowywać w pamięci podręcznej wiele wersji (czyli wersji skompresowanych gzip i brotli) zasobu odpowiadającego danemu adresowi URL.

Automatyczna kompresja Brotli

Automatyczna kompresja Brotli ma miejsce, gdy zasoby są kompresowane przez CDN. Sieci CDN mogą kompresować zarówno zasoby zapisywane w pamięci podręcznej, jak i niezapisywane w pamięci podręcznej.

Przy pierwszym żądaniu zasobu jest on udostępniany przy użyciu „wystarczająco dobrej” kompresji, np. Brotli-5. Ten typ kompresji ma zastosowanie do zasobów zarówno z pamięci podręcznej, jak i niezapisanych w pamięci podręcznej.

Tymczasem, jeśli zasób można zapisać w pamięci podręcznej, sieć CDN użyje przetwarzania offline, aby skompresować go na silniejszym, ale znacznie wolniejszym poziomie kompresji, np. Brotli-11. Po zakończeniu tej kompresji bardziej skompresowana wersja będzie przechowywana w pamięci podręcznej i będzie używana w kolejnych żądaniach.

Sprawdzone metody dotyczące kompresji

Witryny, które chcą zmaksymalizować wydajność, powinny stosować kompresję Brotli zarówno na swoim serwerze źródłowym, jak i na sieci CDN. Kompresja Brotli w punkcie początkowym minimalizuje rozmiar transferu zasobów, których nie można obsłużyć z pamięci podręcznej. Aby uniknąć opóźnień w obsłudze żądań, źródło powinno skompresować zasoby dynamiczne przy użyciu dość zachowawczego poziomu kompresji, np. Brotli-4. Zasoby statyczne można kompresować za pomocą metody Brotli-11. Jeśli źródło nie obsługuje Brotli, możesz użyć polecenia gzip-6 do skompresowania zasobów dynamicznych, a gzip-9 do skompresowania zasobów statycznych.

TLS 1.3

TLS 1.3 to najnowsza wersja protokołu TLS (Transport Layer Security) używanego przez HTTPS. Protokół TLS 1.3 zapewnia większą prywatność i wydajność w porównaniu z protokołem TLS 1.2.

TLS 1.3 skraca proces uzgadniania połączenia TLS z dwóch cykli wymiany danych do jednego. W przypadku połączeń korzystających z HTTP/1 lub HTTP/2 skrócenie uzgadniania połączenia TLS do jednego ruchu w obie strony skutecznie skraca czas konfiguracji połączenia o 33%.

HTTP/2 i HTTP/3

HTTP/2 i HTTP/3 zapewniają lepszą wydajność w porównaniu z HTTP/1. Protokół HTTP/3 zapewnia większe potencjalne korzyści w zakresie wydajności. Protokół HTTP/3 nie jest jeszcze w pełni ustandaryzowany, ale po jego wprowadzeniu będzie powszechnie obsługiwany.

HTTP/2

Jeśli nie masz jeszcze włączonej obsługi protokołu HTTP/2 domyślnie w Twojej sieci CDN, rozważ włączenie tego protokołu. HTTP/2 ma wiele poprawek wydajności w porównaniu z HTTP/1 i jest obsługiwany przez wszystkie popularne przeglądarki. Funkcje związane z wydajnością HTTP/2 obejmują: multipleksowanie, określanie priorytetów strumienia i kompresję nagłówków.

• multipleksowanie

  Multipleksowanie to prawdopodobnie najważniejsza funkcja protokołu HTTP/2. Multipleksowanie umożliwia jednorazowe obsługę wielu par żądanie-odpowiedź na potrzeby pojedynczego połączenia TCP. Dzięki temu unikniesz niepotrzebnych konfiguracji połączeń, ponieważ liczba połączeń, które przeglądarka może otworzyć w danym czasie, jest ograniczona, a więc może to również spowodować, że przeglądarka może równolegle żądać dostępu do większej liczby zasobów strony. Multipleksowanie teoretycznie eliminuje potrzebę optymalizacji HTTP/1, np. konkatenacji i arkuszy sprite, ale w praktyce te techniki będą nadal przydatne, ponieważ większe pliki lepiej kompresują.

• Określanie priorytetów transmisji

  Multipleksowanie umożliwia użycie wielu jednoczesnych strumieni. Nadawanie priorytetów strumieniom zapewnia interfejs do przekazywania względnego priorytetu każdego z tych strumieni. Dzięki temu serwer może wysłać najpierw najważniejsze zasoby, nawet jeśli nie zostały one żądane wcześniej.

Priorytet strumienia jest określany przez przeglądarkę za pomocą drzewa zależności i jest po prostu oświadczeniem o ustawieniu. Inaczej mówiąc, serwer nie jest zobowiązany do spełnienia (ani nawet do rozważenia) priorytetów określonych przez przeglądarkę. Priorytety strumieni staje się skuteczniejsze, gdy większa część witryny jest wyświetlana przez CDN.

Wdrożenia CDN na potrzeby ustalania priorytetów zasobów HTTP/2 znacznie się różnią. Aby sprawdzić, czy Twoja sieć CDN w pełni i prawidłowo obsługuje ustalanie priorytetów zasobów HTTP/2, zajrzyj do artykułu Czy HTTP/2 działa jeszcze szybko?.

Chociaż przełączenie instancji CDN na HTTP/2 to w dużej mierze kwestia zmiany przełącznika, ważne jest dokładne przetestowanie tej zmiany przed włączeniem jej w środowisku produkcyjnym. W HTTP/1 i HTTP/2 stosowane są te same konwencje nagłówków żądań i odpowiedzi, ale w przypadku nieprzestrzegania tych konwencji w protokole HTTP/2 jest dużo mniej wyrozumiałe. W rezultacie po włączeniu HTTP/2 działania niezgodne ze specyfikacją, takie jak umieszczanie w nagłówkach znaków spoza zestawu ASCII lub wielkich liter, mogą powodować błędy. W takim przypadku próba pobrania zasobu przez przeglądarkę zakończy się niepowodzeniem. Nieudana próba pobrania będzie widoczna na karcie „Sieć” w Narzędziach deweloperskich. Dodatkowo w konsoli wyświetli się komunikat o błędzie „ERR_HTTP2_PROTOCOL_ERROR”.

HTTP/3,

HTTP/3 to następca HTTP/2. Od września 2020 roku wszystkie najpopularniejsze przeglądarki obsługują protokół HTTP/3 oraz niektóre sieci CDN. Wydajność jest główną zaletą protokołu HTTP/3 w porównaniu z HTTP/2. HTTP/3 eliminuje blokowanie treści typu „head-line” na poziomie połączenia i skraca czas konfiguracji połączenia.

• Wyeliminowanie blokowania wyświetlania strony głównej

  W protokole HTTP/2 wprowadzono multipleksowanie, czyli funkcję pozwalającą używać pojedynczego połączenia do przesyłania wielu strumieni danych jednocześnie. Jednak w przypadku HTTP/2 pojedynczy utracony pakiet blokuje wszystkie strumienie w połączeniu (jest to zjawisko znane jako blokowanie na początku wiersza). W przypadku HTTP/3 utracony pakiet blokuje tylko 1 strumień. To ulepszenie jest w dużej mierze wynikiem protokołu HTTP/3 z użyciem UDP (HTTP/3 używa protokołu UDP przez QUIC), a nie TCP. Dzięki temu protokół HTTP/3 jest szczególnie przydatny w przypadku przesyłania danych w sieciach złożonych i stratnych.

• Krótszy czas konfigurowania połączenia

  HTTP/3 korzysta z protokołu TLS 1.3 i w związku z tym ma zalety w zakresie wydajności: nawiązanie nowego połączenia wymaga tylko jednej sesji w obie strony, a wznowienie obecnego połączenia nie wymaga żadnych takich operacji.

HTTP/3 ma największy wpływ na użytkowników korzystających z połączenia o niskiej jakości: nie tylko dlatego, że HTTP/3 obsługuje utratę pakietów lepiej niż jego poprzednicy, ale też dlatego, że bezwzględna oszczędność czasu związana z konfiguracją połączenia 0-RTT lub 1-RTT będzie większa w sieciach o dużych opóźnieniach.

Optymalizacja obrazu

Usługi optymalizacji obrazów CDN zwykle koncentrują się na optymalizacji obrazów, które można zastosować automatycznie w celu zmniejszenia rozmiaru transferu obrazu. Dotyczy to na przykład usuwania danych EXIF, kompresji bezstratnej i konwersji obrazów do nowszych formatów (np. WebP). Obrazy stanowią około 50% przesyłanych bajtów na medianie strony internetowej, więc optymalizacja obrazów może znacznie zmniejszyć rozmiar strony.

Minifikacja

Minifikacja usuwa niepotrzebne znaki z JavaScript, CSS i HTML. Zmniejszenie kampanii lepiej jest przeprowadzić na serwerze pierwotnym, a nie na sieci CDN. Właściciele witryn mają szerszy kontekst na temat zminifikowania kodu i dlatego często mogą stosować bardziej agresywne techniki minifikacji niż sieci CDN. Jeśli jednak minifikacja kodu w miejscu początkowym nie jest możliwa, dobrym rozwiązaniem alternatywnym jest minifikacja przez CDN.

Podsumowanie

• Używaj sieci CDN: sieci CDN szybko dostarczają zasoby, zmniejszają obciążenie serwera pierwotnego i przydają się w przypadku nagłego zwiększenia ruchu.
• Jak najbardziej agresywnie zapisuj treści w pamięci podręcznej: zarówno zawartość statyczna, jak i dynamiczna może być przechowywana w pamięci podręcznej, ale na różne czasy. Okresowo sprawdzaj witrynę, aby mieć pewność, że jej treść w pamięci podręcznej jest optymalna.
• Włącz funkcje wydajności CDN: funkcje takie jak Brotli, TLS 1.3, HTTP/2 i HTTP/3 jeszcze bardziej poprawiają wydajność.