Dwa rozwiązania, dwa różne zadania
CDN, czyli sieć dostarczania treści, przechowuje kopie wybranych zasobów w wielu lokalizacjach. Gdy użytkownik pobiera obraz, arkusz stylów lub skrypt, może otrzymać go z węzła bliższego niż główny serwer witryny. Szybszy serwer działa inaczej: sprawniej obsługuje żądania kierowane do źródła, na przykład generowanie strony z systemu CMS albo zapytania do bazy danych.
Te rozwiązania nie są zamiennikami w każdej sytuacji. CDN może skrócić drogę, którą pokonują pliki, ale nie naprawi wolnego generowania strony, jeśli każde żądanie musi trafić do serwera źródłowego. Z kolei wydajniejszy serwer nie usunie całego opóźnienia sieciowego, gdy odbiorcy znajdują się daleko od niego. Wybór warto więc zacząć od pytania: na którym etapie użytkownik czeka najdłużej?
Kiedy CDN może przynieść największą korzyść
CDN jest szczególnie przydatny w serwisie z dużą liczbą plików, które nie zmieniają się przy każdej odsłonie. Przykładem jest sklep z wieloma zdjęciami produktów albo portal publikujący grafiki w artykułach. Jeśli te zasoby można buforować, kolejne osoby nie muszą pobierać ich bezpośrednio z głównego serwera. Może to zmniejszyć jego obciążenie i skrócić oczekiwanie na pliki, zwłaszcza przy odbiorcach rozproszonych geograficznie.
Nie wystarczy jednak samo włączenie usługi. Trzeba sprawdzić, czy zasoby rzeczywiście trafiają do pamięci podręcznej i jak długo mogą w niej pozostać. Pierwsze żądanie pliku, którego CDN jeszcze nie ma, może nadal wymagać pobrania go ze źródła. Strony koszyka, panelu użytkownika czy treści zależne od zalogowania wymagają ostrożnych reguł buforowania, aby nie podawać niewłaściwej zawartości. Jeśli obrazy są nadmiernie duże, warto je również odpowiednio przygotować: CDN nie zastępuje doboru rozmiaru i kompresji.
Kiedy priorytetem jest serwer lub aplikacja
Jeżeli przeglądarka długo czeka na początek odpowiedzi HTML, przyczyną może być praca wykonywana na serwerze. Strona może za każdym razem budować widok od nowa, wykonywać kosztowne zapytania do bazy albo czekać na zewnętrzną usługę. W takiej sytuacji warto najpierw sprawdzić aplikację i jej konfigurację. Zmiana planu hostingowego bez rozpoznania problemu może przynieść mniejszy efekt, niż oczekiwano.
Szybsze zasoby serwera mogą pomóc, gdy obecna maszyna regularnie osiąga swoje limity, na przykład podczas większej liczby równoczesnych odwiedzin. Czasem lepszym pierwszym krokiem będzie jednak ograniczenie pracy aplikacji: buforowanie wygenerowanych stron tam, gdzie to bezpieczne, usprawnienie zapytań do bazy lub usunięcie zbędnych wtyczek. W sklepie, w którym lista produktów ładuje się wolno tylko po zastosowaniu filtrów, warto zbadać właśnie obsługę filtrów. CDN dla zdjęć nie rozwiąże opóźnienia w wygenerowaniu wyników.
Jak odróżnić opóźnienie sieci od wąskiego gardła u źródła
Otwórz narzędzia deweloperskie przeglądarki i porównaj czas oczekiwania na dokument HTML z czasem pobierania obrazów, stylów oraz skryptów. Sprawdź kilka typów podstron: stronę główną, artykuł, kartę produktu i widok z filtrowaniem, jeśli występuje. Pojedynczy pomiar może być mylący, dlatego powtórz próbę. Zwróć uwagę, czy problem dotyczy wszystkich odsłon, czy tylko pierwszego wejścia lub wybranych podstron.
Jeśli korzystasz już z CDN, sprawdź w jego panelu lub nagłówkach odpowiedzi, czy badane pliki są podawane z pamięci podręcznej, czy pobierane ze źródła. Porównanie czasu odpowiedzi dla użytkowników z różnych lokalizacji może pomóc ocenić wpływ odległości, o ile masz dostęp do takich pomiarów. Patrz też na odczuwalny efekt: szybka odpowiedź serwera nie oznacza jeszcze, że najważniejsza treść pojawi się szybko. Duże obrazy, ciężki JavaScript i sposób wyświetlania strony również wpływają na doświadczenie użytkownika.
Krótka lista kontrolna przed zmianą
Najpierw zapisz, które podstrony i zasoby działają wolno oraz czy problem dotyczy głównie HTML, plików statycznych czy obu grup. Następnie sprawdź rozmiary największych plików, czas odpowiedzi źródła, obciążenie serwera i obowiązujące reguły pamięci podręcznej. Jeśli pliki są ciężkie, zacznij od ich uporządkowania. Jeśli źródło długo generuje HTML, zbadaj aplikację i zasoby serwera. Gdy duża część oczekiwania wiąże się z dostarczaniem powtarzalnych plików do odległych odbiorców, rozważ CDN.
Po zmianie wykonaj podobne pomiary na tych samych typach podstron. Sprawdź nie tylko średni czas, lecz także zachowanie przy pierwszej odsłonie, powtórnym wejściu i większym obciążeniu, jeśli możesz je bezpiecznie przetestować. CDN i sprawniejszy serwer mogą działać razem: jeden dostarcza buforowane zasoby, drugi obsługuje żądania, które nadal muszą trafić do źródła. Celem jest usunięcie rozpoznanego opóźnienia, a nie wdrożenie rozwiązania tylko dlatego, że brzmi jak uniwersalny sposób na szybką stronę.
