[Nie] używaj CDN

Prawie w każdym artykule lub narzędziu do optymalizacji prędkości witryn znajduje się skromny punkt „używaj CDN”. Generalnie, CDN to sieć dystrybucji treści. W naszej firmie „Metod Lab” często spotykamy się z pytaniami klientów na ten temat, niektórzy samodzielnie włączają sobie CDN. Celem tego artykułu jest zrozumienie, co CDN może dać z perspektywy szybkości ładowania strony, jakie problemy mogą się pojawić i w jakich przypadkach użycie CDN jest uzasadnione.

Zaznaczone na obrazku opóźnienia są spowodowane użyciem CDN.

Historia

Jak wiele technologii, CDN pojawiły się z potrzeby. Wraz z rozwojem internetowych kanałów użytkowników sieci, pojawiły się usługi wideo online. Naturalnie, treści wideo wymagają znacznie większej przepustowości w porównaniu z tradycyjnymi treściami stron (zdjęcia, tekst i kod CSS lub JS).

Podczas próby równoległej transmisji strumienia wideo do wielu klientów z jednego serwera wąskim gardłem prawdopodobnie będzie kanał internetowy serwera. Zazwyczaj wystarczy kilka tysięcy strumieni, aby zablokować typowy kanał serwera. Oczywiście mogą wystąpić także inne ograniczenia zasobów, ale w tej chwili nie są one istotne. Ważne jest również, że rozszerzenie kanału serwera jest zbyt drogie (a czasem niemożliwe) i nieopłacalne. Obciążenie kanału podczas transmisji będzie miało charakter cykliczny.

Problem ograniczonego kanału pojedynczego serwera doskonale rozwiązują CDN. Klienci łączą się nie bezpośrednio z serwerem, ale z węzłami sieci CDN. W idealnej sytuacji serwer przesyła jeden strumień do węzła CDN, a następnie sieć wykorzystuje własne zasoby do dostarczenia tego strumienia wielu użytkownikom. Z punktu widzenia ekonomii płacimy tylko za faktycznie wykorzystane zasoby (to może być przepustowość lub ruch) i uzyskujemy doskonałą skalowalność naszej usługi. Użycie CDN do dostarczania ciężkich treści jest w pełni uzasadnione i logiczne. Warto zauważyć, że najwięksi gracze w tej dziedzinie (na przykład Netflix) budują swoje własne CDN zamiast korzystać z dużych komercyjnych CDN (Akamai, Cloudflare, Fastly itd.).

W miarę rozwoju internetu aplikacje webowe stały się coraz bardziej skomplikowane i obciążające. Na pierwszy plan wyszła kwestia prędkości ładowania. Entuzjaści prędkości stron internetowych szybko zidentyfikowali kilka głównych problemów prowadzących do wolnego ładowania. Jednym z nich były opóźnienia w sieci (RTT – round trip time lub czas ping). Opóźnienia wpływają na wiele procesów w ładowaniu strony: nawiązywanie połączenia TCP, uruchamianie sesji TLS, ładowanie każdego zasobu z osobna (obrazków, plików JS, dokumentów HTML itp.)

Problem potęgował się tym, że przy korzystaniu z protokołu HTTP/1.1 (do czasu pojawienia się SPDY, QUIC i HTTP/2, był to jedyny wariant) przeglądarki otwierają nie więcej niż 6 połączeń TCP do jednego hosta. Wszystko to prowadziło do przestoju połączeń i nieefektywnego wykorzystania przepustowości. Problem częściowo rozwiązywano poprzez shardowanie domen – tworzenie dodatkowych hostów, aby obejść limit dotyczący liczby połączeń.

Tutaj pojawia się druga zdolność CDN – redukcja opóźnień (RTT) dzięki dużej liczbie punktów i bliskości węzłów do użytkownika. Odległość odgrywa kluczową rolę: prędkość światła jest ograniczona (około 200 000 km/s w światłowodzie). Oznacza to, że każde 1000 km drogi dodaje 5 ms opóźnienia lub 10 ms w RTT. To minimalny czas potrzebny na transmisję, ponieważ istnieją również opóźnienia na sprzęcie pośredniczącym. Ponieważ CDN zazwyczaj potrafi buforować obiekty na swoich serwerach, możemy zyskać na ładowaniu takich obiektów przez CDN. Warunki konieczne do tego to: obecność obiektu w pamięci podręcznej i bliskość punktu CDN do użytkownika w porównaniu z serwerem aplikacji internetowej (serwerem źródłowym). Ważne jest, aby zrozumieć: geograficzna bliskość węzła CDN nie gwarantuje niskich opóźnień. Trasowanie między klientem a CDN może być zbudowane w taki sposób, że klient połączy się z hostem w innym kraju, a być może i na innym kontynencie. Tutaj wchodzą w grę relacje między operatorami telekomunikacyjnymi a serwisem CDN (peering, dostępność połączeń, uczestnictwo w IX itp.) oraz polityka trasowania ruchu samego CDN. Na przykład, Cloudflare przy korzystaniu z dwóch podstawowych planów (darmowego i taniego) nie gwarantuje dostarczania treści z najbliższego węzła – wybór hosta będzie realizowany w celu osiągnięcia minimalnych kosztów.

Wiele czołowych firm internetowych przyciąga uwagę opinii publicznej (programistów i właścicieli usług) do tematu szybkości ładowania i działania stron internetowych. Wśród tych firm znajdują się Yahoo (narzędzie Yslow), AOL (WebPageTest) oraz Google (usługa Page Speed Insights), które opracowują swoje zalecenia dotyczące przyspieszania stron (przede wszystkim dotyczą one optymalizacji po stronie klienta). Później pojawiają się nowe narzędzia do testowania szybkości stron, które również udzielają wskazówek dotyczących zwiększania szybkości stron. W każdej z tych usług lub wtyczek znajduje się niezmienna rekomendacja: „Używaj CDN”. Jako wyjaśnienie efektu CDN zazwyczaj podaje się skrócenie opóźnień sieciowych. Niestety, nie wszyscy są gotowi zgłębiać, jak właściwie osiąga się efekt przyspieszenia dzięki CDN i jak można go zmierzyć, dlatego rekomendacja ta jest przyjmowana na wiarę i stosowana jako postulat. W rzeczywistości nie wszystkie CDN są równie użyteczne.

Zastosowanie CDN dzisiaj

Aby ocenić użyteczność stosowania CDN, należy je sklasyfikować. Co można spotkać obecnie w praktyce (oczywiście przykłady w nawiasach nie są wyczerpujące):

1. Darmowe CDN do dystrybucji bibliotek JS (MaxCDN, Google, Yandex).
2. CDN usług optymalizacji po stronie klienta (na przykład Google Fonts do czcionek, Cloudinary, Cloudimage do obrazków).
3. CDN dla statyk i optymalizacji zasobów w CMS (występuje w Bitrixie, WordPress i innych).
4. CDN ogólnego przeznaczenia (StackPath, CDNVideo, NGENIX, MegaFon).
5. CDN do przyspieszania stron (Cloudflare, Imperva, Airy).

Kluczowa różnica między tymi typami polega na tym, jaka część ruchu przechodzi przez CDN. Typy 1-3 to dostarczanie tylko części treści: od jednego żądania do kilku dziesiątek (zwykle obrazków). Typy 4 i 5 to pełne proxy ruchu przez CDN.

W praktyce oznacza to liczbę połączeń, które są używane do ładowania strony. Przy użyciu HTTP/2 korzystamy z jednego połączenia TCP z hostem do przetwarzania dowolnej liczby żądań. Jeśli dzielimy zasoby między głównym hostem (origin) a CDN, należy kierować żądania na kilka domen i tworzyć kilka połączeń TCP. W najgorszym przypadku to: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. W tym wzorze nie uwzględnia się opóźnień w sieciach mobilnych związanych z aktywacją kanału radiowego urządzenia (jeśli nie był on aktywny) oraz opóźnień na wieży komórkowej.

Tak to wygląda na stronie ładowania witryny (opóźnienia dla połączenia z CDN przy RTT 150 ms są wyróżnione):

Jeśli CDN pokrywa cały ruch witryny (z wyjątkiem zewnętrznych usług), możemy użyć jednego połączenia TCP, oszczędzając opóźnienia związane z łączeniem się z dodatkowymi hostami. Oczywiście dotyczy to połączeń HTTP/2.

Dalsze różnice zależą od funkcjonalności konkretnego CDN – dla pierwszego typu to tylko hosting pliku statycznego, dla piątego to zmiana kilku typów treści witryny w celu optymalizacji.

Możliwości CDN w przyspieszaniu witryny

Opiszmy pełen zakres możliwości CDN w przyspieszaniu witryn, niezależnie od funkcjonalności poszczególnych typów CDN, a potem sprawdźmy, co z tego zostało wdrożone w każdym z nich.

1. Kompresja zasobów tekstowych

Najbardziej podstawowa i zrozumiała możliwość, mimo to często realizowana źle. Obecność kompresji deklarują wszystkie CDN jako swoją funkcję przyspieszającą. Ale jeśli przyjrzymy się bliżej, ujawniają się niedociągnięcia:

• mogą być stosowane niskie stopnie dla dynamicznej kompresji – 5-6 (na przykład maksymalnie dla gzip – 9);
• w statycznej kompresji (pliki w cache) nie są używane dodatkowe możliwości (na przykład, zopfi lub brotli ze stopniem 11)
• brak wsparcia dla efektywnej kompresji brotli (oszczędność około 20% w porównaniu do gzip).

Jeśli korzystasz z CDN, warto sprawdzić te kilka punktów: pobrać plik, który przyszedł z CDN, zarejestrować jego rozmiar w skompresowanej wersji i ponownie skompresować ręcznie w celu porównania (można użyć jakiegoś serwisu online obsługującego brotli, na przykład wszystkościśnić.pl).

2. Ustawienie nagłówków buforowania po stronie klienta

Również prosta funkcja przyspieszająca: ustawienie nagłówków do buforowania treści przez klienta (przeglądarkę). Najbardziej aktualny nagłówek to cache-control, a przestarzały – expires. Dodatkowo można użyć Etag. Ważne, aby max-age w cache-control był wystarczająco duży (od miesiąca lub więcej), jeśli chcesz maksymalnie sztywno zbuforować zasób, możesz dodać opcję immutable.

CDN mogą obniżać wartość max-age, co zmusza użytkowników do częstszego ponownego ładowania statycznych zasobów. Z czym to się wiąże: z chęcią zwiększenia ruchu w sieci czy poprawą kompatybilności z witrynami, które nie potrafią resetować pamięci podręcznej – nie jest jasne. Na przykład, domyślna wartość czasu pamięci podręcznej w nagłówkach Cloudflare wynosi 1 godzinę, co jest bardzo mało dla niezmiennych zasobów statycznych.

3. Optymalizacja obrazów

Ponieważ CDN przejmuje funkcje pamięci podręcznej i dostarczania obrazów, sensowne jest ich optymalizowanie po stronie CDN i w tej formie dostarczanie użytkownikom. Od razu zaznaczamy, że ta możliwość jest dostępna tylko dla typów CDN 2, 3 i 5.

Obrazy można optymalizować na różne sposoby: używając zaawansowanych formatów kompresji (na przykład WebP), efektywniejszych kodowników (MozJPEG) lub po prostu oczyszczając z nadmiarowych metadanych.

Ogólnie istnieją dwa typy takich optymalizacji: z utratą jakości i bez utraty jakości. CDN zazwyczaj starają się stosować optymalizację bez strat – aby uniknąć ewentualnych skarg klientów na zmianę jakości obrazów. W takich warunkach zyski będą minimalne. W rzeczywistości często poziom jakości JPEG znacznie przekracza potrzebny, więc można bezpiecznie przeprowadzić rekompresję przy niższym wskaźniku jakości, bez szkody dla percepcji użytkowników. Z drugiej strony, określenie poziomu jakości i ustawień uniwersalnie dla wszystkich możliwych aplikacji webowych jest trudne, dlatego CDN stosują bardziej konserwatywne ustawienia w porównaniu z tymi, które można zastosować biorąc pod uwagę kontekst (przeznaczenie obrazów, typ aplikacji webowej itd.)

4. Optymalizacja połączenia TLS

Większość ruchu dzisiaj przesyłana jest przez połączenia TLS, co oznacza, że tracimy dodatkowy czas na ustalenie połączenia TLS. Ostatnio opracowano nowe technologie przyspieszające ten proces. Na przykład, jest to kryptografia EC, TLS 1.3, pamięć podręczna sesji i bilety (session tickets), sprzętowe przyspieszenie szyfrowania (AES-NI) itd. Prawidłowa konfiguracja TLS pozwala skrócić czas połączenia do 0-1 RTT (nie licząc DNS i TCP).

Przy nowoczesnym oprogramowaniu wdrożenie takich praktyk nie jest skomplikowane na własnych zasobach.

Nie wszystkie CDN stosują najlepsze praktyki dotyczące TLS, co można sprawdzić, mierząc czas połączenia TLS (na przykład w Webpagetest). Idealnie dla nowego połączenia — 1RTT, 2RTT — średni poziom, 3RTT i więcej — źle.

Należy również zauważyć, że nawet przy użyciu TLS na poziomie CDN, serwer z naszą aplikacją webową również musi obsługiwać TLS, ale po stronie CDN, ponieważ ruch między serwerem a CDN przechodzi przez publiczną sieć. W najgorszym przypadku otrzymamy podwójne opóźnienia połączenia TLS (pierwsze do hosta CDN, drugie między nim a naszym serwerem).

W niektórych zastosowaniach warto zwrócić uwagę na kwestie bezpieczeństwa: zwykle ruch jest deszyfrowany na węzłach CDN, co stwarza potencjalną możliwość przechwycenia ruchu. Opcja pracy bez ujawniania ruchu jest zwykle oferowana w najlepszych planach taryfowych za dodatkową opłatą.

5. Skracanie opóźnień połączenia

Główną zaletą CDN, o której wszyscy mówią: niskie opóźnienia (krótsza odległość) między hostem CDN a użytkownikiem. Osiąga się to poprzez tworzenie geograficznie rozproszonej architektury sieci, w której hosty znajdują się w punktach koncentracji użytkowników (miastach, punktach wymiany ruchu itp.).

W praktyce priorytety dla różnych sieci mogą koncentrować się w określonych regionach. Na przykład rosyjskie CDN będą miały więcej punktów obecności w Rosji. Amerykańskie przede wszystkim będą rozwijać sieć w USA. Na przykład jeden z największych CDN, Cloudflare, ma tylko 2 punkty w Rosji — Moskwa i Petersburg. To znaczy, maksymalnie możemy zaoszczędzić około 10 ms opóźnienia w porównaniu z bezpośrednim umiejscowieniem w Moskwie.

Większość zachodnich CDN w ogóle nie ma punktów w Rosji. Łącząc się z nimi, możesz jedynie zwiększyć opóźnienia dla swojej rosyjskiej publiczności.

6. Optymalizacja treści (minifikacja, zmiany strukturalne)

Najtrudniejszy i najbardziej technologiczny punkt. Zmiana treści podczas dostarczania może być bardzo ryzykowna. Nawet jeśli mówimy o minifikacji: redukcja kodu źródłowego (poprzez usunięcie zbędnych spacji, nieistotnych konstrukcji itp.) może wpłynąć na jego funkcjonalność. Jeśli chodzi o poważniejsze zmiany — przeniesienie kodu JS na koniec HTML, łączenie plików i podobne — ryzyko naruszenia funkcjonalności strony jest jeszcze wyższe.

Dlatego tylko niektóre CDN typu 5 zajmują się tym. Oczywiście nie wszystkie potrzebne zmiany przyspieszające można zautomatyzować – wymagane jest ręczne analizowanie i optymalizacja. Na przykład usuwanie nieużywanego lub powielającego się kodu należy do zadań ręcznych.

Zazwyczaj wszystkie tego typu optymalizacje są zarządzane przez ustawienia, a najbardziej niebezpieczne są domyślnie wyłączone.

Wsparcie możliwości przyspieszających według typów CDN

Zatem przyjrzyjmy się, jakie potencjalne możliwości przyspieszania oferują różne typy CDN.

Dla wygody powtórzmy klasyfikację.

1. Darmowe CDN do dystrybucji bibliotek JS (MaxCDN, Google, Yandex).
2. CDN usług optymalizacji po stronie klienta (na przykład Google Fonts do czcionek, Cloudinary, Cloudimage do obrazków).
3. CDN dla statyk i optymalizacji zasobów w CMS (występuje w Bitrixie, WordPress i innych).
4. CDN ogólnego przeznaczenia (StackPath, CDNVideo, NGENIX, MegaFon).
5. CDN do przyspieszania stron (Cloudflare, Imperva, Airy).

Teraz porównajmy funkcje i typy CDN.

Możliwość
Typ 1
Typ 2
Typ 3
Typ 4
Typ 5

Kompresja tekstu
+–
–
+–
+–
+

Nagłówki pamięci podręcznej
+
+
+
+
+

Obrazy
–
+–
+–
–
+

TLS
–
–
–
+–
+

Opóźnienia
–
–
–
+
+

Treść
–
–
–
–
+

W tej tabeli „+” oznacza pełne wsparcie, „–” oznacza brak, a „+–” to wsparcie częściowe. Oczywiście możliwe są odchylenia od tej tabeli w rzeczywistości (na przykład jakiś uniwersalny CDN wdroży funkcje optymalizacji obrazów), ale dla ogólnego obrazu jest ona przydatna.

Podsumowanie

Mam nadzieję, że po przeczytaniu tego artykułu uzyskacie jaśniejszy obraz dotyczący zalecenia „użyj CDN” w celu przyspieszenia stron internetowych.

Jak w każdej sprawie, nie można wierzyć w marketingowe obietnice jakiejkolwiek usługi. Efekt trzeba mierzyć i sprawdzać w rzeczywistych warunkach. Jeśli już korzystasz z jakiegoś CDN, sprawdź jego skuteczność według kryteriów opisanych w artykule.

Możliwe, że korzystanie z CDN w tej chwili spowalnia ładowanie twojej strony.

Jako ogólna rekomendacja można wskazać na następujące: zrozum swoją publiczność, określ jej ramy geograficzne. Jeśli twoja główna publiczność koncentruje się w promieniu 1-2 tysięcy kilometrów, nie potrzebujesz CDN w podstawowym celu – redukcji opóźnień. Zamiast tego możesz umieścić swój serwer bliżej użytkowników i odpowiednio go skonfigurować, uzyskując większość optymalizacji opisanych w artykule (bezpłatnie i na stałe).

Jeśli Twoja publiczność jest rzeczywiście geograficznie rozproszona (w promieniu ponad 3000 kilometrów), korzystanie z wysokiej jakości CDN może naprawdę przynieść korzyści. Jednak warto wcześniej zrozumieć, co dokładnie może przyspieszyć Twoją CDN (patrz tabela możliwości i ich opis). Przyspieszenie strony internetowej pozostaje złożonym zadaniem, które nie rozwiązuje się jedynie przez podłączenie CDN. Oprócz wymienionych optymalizacji, z boku CDN pozostają najskuteczniejsze metody przyspieszania: optymalizacja serwera, zaawansowane zmiany po stronie klienta (usunięcie nieużywanego kodu, optymalizacja procesu renderowania, praca z treścią, czcionkami, responsywnością itd.)

Źródło: habr.com