W ostatnich latach coraz więcej platform do optymalizacji projektów front-end oferuje możliwości samodzielnego hostowania lub proxy zasobów stron trzecich. Akamai pozwala na ustawienie dla samodzielnie wygenerowanych adresów URL. Cloudflare ma technologię Edge Workers. Fasterzine może Adresy URL na stronach, tak aby wskazywały zasoby stron trzecich znajdujące się w domenie głównej serwisu.
Jeśli wiesz, że usługi zewnętrzne wykorzystywane w Twoim projekcie nie zmieniają się zbyt często, a proces ich dostarczania klientom mógłby zostać usprawniony, to prawdopodobnie zastanawiasz się nad proxy takich usług. Dzięki takiemu podejściu możesz bardzo łatwo przybliżyć te zasoby użytkownikom i uzyskać pełniejszą kontrolę nad ich buforowaniem po stronie klienta. Pozwala to dodatkowo chronić użytkowników przed problemami spowodowanymi „awarią” usługi strony trzeciej lub pogorszeniem jej wydajności.
Dobrze: Poprawiona wydajność
Samodzielne hostowanie cudzych zasobów poprawia wydajność w bardzo oczywisty sposób. Przeglądarka nie musi ponownie uzyskiwać dostępu do DNS, nie musi nawiązywać połączenia TCP i uzgadniać TLS w domenie innej firmy. Możesz zobaczyć, jak samodzielne hostowanie cudzych zasobów wpływa na wydajność, porównując poniższe dwie liczby.
Zasoby stron trzecich są pobierane ze źródeł zewnętrznych (pobranych z )
Zasoby stron trzecich są przechowywane w tym samym miejscu, co pozostałe materiały witryny (pobrane z )
Sytuację poprawia także fakt, że przeglądarka będzie wykorzystywać możliwość multipleksowania i priorytetyzacji danych z nawiązanego już z domeną główną połączenia HTTP/2.
Jeśli nie hostujesz zasobów stron trzecich, to ponieważ zostaną one załadowane z domeny innej niż główna, nie można nadać im priorytetu. Spowoduje to, że będą one konkurować ze sobą o przepustowość klienta. Może to spowodować, że czas ładowania treści niezbędnych do utworzenia strony będzie znacznie dłuższy, niż byłoby to możliwe w idealnych okolicznościach. porozmawiaj o ustalaniu priorytetów HTTP/2, który bardzo dobrze to wszystko wyjaśnia.
Można założyć, że użycie atrybutów w linkach do zasobów zewnętrznych preconnect pomoże w rozwiązaniu problemu. Jeśli jednak tych linków do różnych domen będzie zbyt wiele, może to faktycznie spowodować przeciążenie linii komunikacyjnej w najbardziej kluczowym momencie.
Jeśli samodzielnie hostujesz zasoby stron trzecich, możesz kontrolować, w jaki sposób zasoby te są przekazywane klientowi. Mianowicie mówimy o następujących kwestiach:
- Możesz upewnić się, że używany jest algorytm kompresji danych, który najlepiej pasuje do każdej przeglądarki (Brotli/gzip).
- Możesz zwiększyć czas buforowania dla zasobów, które zwykle nie są szczególnie długie, nawet w przypadku najbardziej znanych dostawców (na przykład odpowiednia wartość tagu GA jest ustawiona na 30 minut).
Możesz nawet przedłużyć TTL dla zasobu, powiedzmy, na rok, włączając odpowiednią treść do swojej strategii zarządzania pamięcią podręczną (hasze adresów URL, wersjonowanie itp.). Porozmawiamy o tym poniżej.
▍Ochrona przed przerwami w działaniu usług obcych lub ich wyłączeniem
Innym interesującym aspektem samodzielnego hostingu zasobów stron trzecich jest to, że pozwala to ograniczyć ryzyko związane z przerwami w świadczeniu usług stron trzecich. Załóżmy, że rozwiązanie do testów A/B innej firmy, którego używasz, jest zaimplementowane jako skrypt blokujący, który ładuje się w sekcji nagłówka strony. Ten skrypt ładuje się powoli. Jeśli odpowiedni skrypt nie zostanie załadowany, strona będzie pusta. Jeśli ładowanie trwa bardzo długo, strona pojawi się z dużym opóźnieniem. Załóżmy też, że projekt korzysta z biblioteki pobranej z zasobu CDN innej firmy. Wyobraźmy sobie, że zasób ten uległ awarii lub został zablokowany w określonym kraju. Taka sytuacja doprowadzi do naruszenia logiki witryny.
Aby dowiedzieć się, jak działa Twoja witryna, gdy jakaś usługa zewnętrzna jest niedostępna, możesz skorzystać z sekcji SPOF .
Sekcja SPOF na webpagetest.org
▍A co z problemami z buforowaniem materiałów w przeglądarkach? (wskazówka: to mit)
Można by pomyśleć, że korzystanie z publicznych sieci CDN automatycznie doprowadzi do lepszej wydajności zasobów, ponieważ usługi te mają sieci dość wysokiej jakości i są dystrybuowane na całym świecie. Ale tak naprawdę wszystko jest trochę bardziej skomplikowane.
Załóżmy, że mamy kilka różnych witryn: witryna1.com, witryna2.com, witryna3.com. Wszystkie te witryny korzystają z biblioteki jQuery. Łączymy go z nimi za pomocą CDN, na przykład - googleapis.com. Możesz oczekiwać, że przeglądarka raz pobierze i zapisze bibliotekę w pamięci podręcznej, a następnie użyje jej we wszystkich trzech witrynach. Może to zmniejszyć obciążenie sieci. Być może pozwoli ci to gdzieś zaoszczędzić pieniądze i pomoże poprawić wydajność zasobów. Z praktycznego punktu widzenia wszystko wygląda inaczej. Na przykład Safari ma funkcję o nazwie : Pamięć podręczna wykorzystuje podwójne klucze w zależności od źródła dokumentu i źródła zasobu strony trzeciej. dobry artykuł na ten temat.
stare studia и , a także nowsze Paul Calvano pokazują, że zasoby nie są przechowywane w pamięci podręcznej przeglądarki tak długo, jak moglibyśmy się tego spodziewać: „Istnieje poważna różnica pomiędzy czasem buforowania zasobów własnych projektu i zasobów stron trzecich. Mówimy o CSS i czcionkach internetowych. Mianowicie, 95% czcionek natywnych ma żywotność pamięci podręcznej dłuższą niż tydzień, podczas gdy 50% czcionek innych firm ma żywotność pamięci podręcznej krócej niż tydzień! Daje to twórcom stron internetowych ważny powód do samodzielnego hostowania plików czcionek!”
W rezultacie, jeśli hostujesz treści innych osób, nie zauważysz żadnych problemów z wydajnością spowodowanych buforowaniem przeglądarki.
Teraz, gdy omówiliśmy mocne strony samodzielnego hostingu przez strony trzecie, porozmawiajmy o tym, jak odróżnić dobre wdrożenie tego podejścia od złego.
Wady: Diabeł tkwi w szczegółach
Przeniesienia zasobów stron trzecich do własnej domeny nie można wykonać automatycznie bez upewnienia się, że takie zasoby są prawidłowo buforowane.
Jednym z głównych problemów jest czas buforowania. Na przykład informacje o wersji są zawarte w nazwach skryptów innych firm, takich jak ta: jquery-3.4.1.js. Taki plik nie ulegnie w przyszłości zmianie, w związku z czym nie będzie powodować problemów z jego buforowaniem.
Jeśli jednak podczas pracy z plikami nie zostanie zastosowany jakiś schemat wersjonowania, skrypty buforowane, których zawartość zmienia się, a nazwa pliku pozostaje niezmieniona, mogą stać się nieaktualne. Może to stanowić poważny problem, ponieważ na przykład nie pozwala na dodawanie automatycznych poprawek bezpieczeństwa do skryptów, które klienci muszą otrzymać tak szybko, jak to możliwe. Deweloper będzie musiał podjąć wysiłek, aby zaktualizować takie skrypty w pamięci podręcznej. Dodatkowo może to powodować awarie aplikacji z uwagi na to, że kod użyty na kliencie z pamięci podręcznej różni się od najnowszej wersji kodu, dla której przeznaczona jest część serwerowa projektu.
Co prawda, jeśli mówimy o materiałach, które są często aktualizowane (menedżery tagów, rozwiązania do testów A/B), to buforowanie ich za pomocą narzędzi CDN jest zadaniem, które można rozwiązać, ale jest ono znacznie bardziej złożone. Usługi takie jak Commanders Act, rozwiązanie do zarządzania tagami, korzystają z webhooków podczas publikowania nowych wersji. Daje to możliwość wymuszenia opróżnienia pamięci podręcznej w sieci CDN lub, jeszcze lepiej, możliwość wymuszenia aktualizacji skrótu lub adresu URL.
▍Adaptacyjne dostarczanie materiałów do klientów
Ponadto, gdy mówimy o buforowaniu, musimy wziąć pod uwagę fakt, że ustawienia buforowania stosowane w sieci CDN mogą nie być odpowiednie dla niektórych zasobów stron trzecich. Na przykład takie zasoby mogą wykorzystywać technologię wykrywania agenta użytkownika (obsługiwania adaptacyjnego) w celu udostępniania określonym przeglądarkom wersji treści zoptymalizowanych specjalnie dla tych przeglądarek. Technologie te opierają się na wyrażeniach regularnych lub bazie danych zawierających informacje nagłówka HTTP w celu określenia możliwości przeglądarki. User-Agent. Kiedy już wiedzą, z jaką przeglądarką mają do czynienia, przekazują jej przeznaczone dla niej materiały.
Tutaj możesz zapamiętać dwie usługi. Pierwsza to googlefonts.com. Drugi to Polyfill.io. Usługa Google Fonts udostępnia dla danego zasobu różny kod CSS w zależności od możliwości przeglądarki (podawanie linków do zasobów woff2 za pomocą unicode-range).
Oto wyniki kilku zapytań dotyczących czcionek Google wykonanych w różnych przeglądarkach.
Wynik zapytania dotyczącego czcionek Google z przeglądarki Chrome
Wynik zapytania Google Fonts wykonanego z IE10
Polyfill.io udostępnia przeglądarce tylko te wypełnienia, których potrzebuje. Odbywa się to ze względów wydajnościowych.
Przyjrzyjmy się na przykład, co się stanie, jeśli uruchomisz następujące żądanie w różnych przeglądarkach:
W odpowiedzi na takie żądanie wykonane z IE10 zostanie odebrane 34 KB danych. A odpowiedź na to pytanie, wykonana z Chrome, będzie pusta.
Zły: Kilka uwag dotyczących prywatności
Ten punkt jest ostatni w kolejności, ale nie najmniej ważny. Rzecz w tym, że self-hosting zasobów obcych na domenie głównej projektu lub na jego subdomenie może zagrozić prywatności użytkowników i negatywnie wpłynąć na główny projekt WWW.
Jeśli Twój system CDN nie jest poprawnie skonfigurowany, może się zdarzyć, że pliki cookie Twojej domeny zostaną wysłane do usługi strony trzeciej. Jeśli na poziomie CDN nie zostanie zorganizowane odpowiednie filtrowanie, wówczas pliki cookie sesji, których normalnie nie można używać w JavaScript (z httponly), mogą zostać przesłane do zagranicznego hosta.
Dokładnie to samo może się zdarzyć w przypadku trackerów takich jak Eulerian czy Criteo. Zewnętrzne moduły śledzące mogły ustawić unikalny identyfikator w pliku cookie. Jeżeli były częścią materiałów serwisu, mogły według własnego uznania odczytać identyfikator podczas pracy użytkownika z różnymi zasobami sieci.
Obecnie większość przeglądarek zapewnia ochronę przed tego typu zachowaniami modułów śledzących. W rezultacie urządzenia śledzące korzystają teraz z technologii , udając własne skrypty do różnych projektów. Mianowicie moduły śledzące oferują właścicielom witryn dodanie rekordu CNAME do swoich ustawień dla określonej domeny, której adres zwykle wygląda jak losowy zestaw znaków.
Chociaż nie zaleca się udostępniania plików cookie witryn wszystkim subdomenom (na przykład - *.website.com), wiele witryn tak robi. W takim przypadku takie pliki cookie są automatycznie wysyłane do ukrytego modułu śledzącego strony trzeciej. W rezultacie nie możemy już mówić o jakiejkolwiek prywatności.
To samo dzieje się z nagłówkami HTTP , które są wysyłane tylko do domeny głównej, ponieważ można je wykorzystać do tworzenia użytkownik. Upewnij się, że używana usługa CDN poprawnie filtruje te nagłówki.
Wyniki
Jeśli planujesz wkrótce wdrożyć własny hosting zasobów stron trzecich, pozwól, że dam Ci kilka wskazówek:
- Hostuj najważniejsze biblioteki JS, czcionki i pliki CSS. Zmniejszy to ryzyko awarii witryny lub pogorszenia wydajności z powodu niedostępności kluczowych dla witryny zasobów z powodu winy usługi strony trzeciej.
- Zanim umieścisz w pamięci podręcznej zasoby innych firm w sieci CDN, upewnij się, że podczas nadawania nazw plikom używany jest jakiś system kontroli wersji lub że możesz zarządzać cyklem życia tych zasobów, ręcznie lub automatycznie resetując pamięć podręczną CDN podczas publikowania nowej wersji scenariusz.
- Zachowaj szczególną ostrożność w zakresie ustawień CDN, serwera proxy i pamięci podręcznej. Dzięki temu zapobiegniesz wysyłaniu plików cookie do Twojego projektu lub nagłówków
Client-Hintsusługi stron trzecich.
Drodzy Czytelnicy! Czy przechowujesz na swoich serwerach materiały innych osób, które są niezwykle ważne dla funkcjonowania Twoich projektów?
Źródło: www.habr.com