Wczytywanie kodu JavaScript firmy zewnętrznej

Addy Osmani

Arthur Evans

Jeśli kod został zoptymalizowany, ale witryna nadal ładuje się zbyt wolno, prawdopodobnie jest to spowodowane skryptami innych firm.

Skrypty innych firm udostępniają wiele przydatnych funkcji, dzięki którym internet jest bardziej dynamiczny, interaktywny i połączony. Niektóre z nich mogą być nawet kluczowe dla działania witryny lub generowania przychodów. Jednak ich używanie jest ryzykowne:

• Mogą one spowolnić działanie witryny.
• Mogą powodować problemy z prywatnością lub bezpieczeństwem.
• Mogą być nieprzewidywalne, a ich działanie może mieć niezamierzone konsekwencje.

Najlepiej upewnić się, że skrypty innych firm nie wpływają na krytyczną ścieżkę renderowania witryny. W tym przewodniku dowiesz się, jak znaleźć i rozwiązać problemy związane z ładowaniem kodu JavaScript innych firm oraz jak zminimalizować ryzyko dla użytkowników.

Co to są skrypty innych firm?

JavaScript innych firm często odnosi się do skryptów, które można umieścić w dowolnej witrynie bezpośrednio od zewnętrznego dostawcy. Przykłady:

• przyciski udostępniania społecznościowego (Facebook, X, LinkedIn, Mastodon);

• umieszczone odtwarzacze wideo (YouTube, Vimeo);

• Elementy iframe reklamy

• Skrypty statystyk i danych

• Skrypty testów A/B na potrzeby eksperymentów

• biblioteki pomocnicze, np. do formatowania daty, animacji lub biblioteki funkcjonalne;

Przykład umieszczonego filmu na YouTube, który można dodać do strony za pomocą poniższego kodu.

<iframe
  width="560"
  height="315"
  src="https://www.youtube.com/embed/mo8thg5XGV0"
  frameborder="0"
  allow="autoplay; encrypted-media"
  allowfullscreen
>
</iframe>

Niestety umieszczanie skryptów innych firm oznacza, że często polegamy na nich, aby działały szybko i nie spowalniały naszych stron. Skrypty innych firm są częstą przyczyną spowolnienia działania witryny spowodowanego przez zasoby, nad którymi właściciel witryny nie ma kontroli. Oto niektóre z problemów:

• wysyłanie zbyt wielu żądań sieciowych do wielu serwerów; Im więcej żądań musi wysłać witryna, tym dłużej może się wczytywać.

• wysyłanie zbyt dużej ilości kodu JavaScript, który zajmuje główny wątek; Zbyt dużo kodu JavaScript może blokować tworzenie DOM, co opóźnia renderowanie strony. Analiza i wykonywanie skryptów obciążających procesor mogą opóźniać interakcję użytkownika i powodować rozładowanie baterii.

• Wysyłanie dużych, niezoptymalizowanych plików graficznych lub filmów może zużywać dane i kosztować użytkowników pieniądze.

• Problemy z bezpieczeństwem, które mogą działać jako pojedynczy punkt awarii, jeśli strona wczytuje skrypt bez zachowania ostrożności.

• Niewystarczające buforowanie HTTP, które zmusza przeglądarkę do wysyłania większej liczby żądań sieciowych w celu pobrania zasobów.

• Brak wystarczającej kompresji serwera powoduje powolne wczytywanie zasobów.

• blokowanie wyświetlania treści do czasu zakończenia przetwarzania. Może to dotyczyć również asynchronicznych skryptów testów A/B.

• używanie starszych interfejsów API, które negatywnie wpływają na wrażenia użytkownika, takich jak document.write();

• nadmierna liczba elementów DOM lub kosztowne selektory CSS;

• Uwzględnienie wielu elementów osadzonych innych firm może prowadzić do wielokrotnego pobierania wielu platform i bibliotek, co marnuje zasoby i pogarsza istniejące problemy z wydajnością.

• Skrypty innych firm często używają technik umieszczania, które mogą blokować window.onload, jeśli serwery wolno odpowiadają, nawet jeśli umieszczony skrypt używa atrybutu async lub defer.

Możliwość rozwiązywania problemów ze skryptami innych firm może zależeć od Twojej witryny i możliwości skonfigurowania sposobu wczytywania kodu innych firm. Na szczęście istnieje wiele rozwiązań i narzędzi, które pomagają znaleźć i rozwiązać problemy z zasobami innych firm.

Jak rozpoznać skrypt firmy zewnętrznej na stronie?

Zidentyfikowanie skryptów innych firm w witrynie i określenie ich wpływu na wydajność to pierwszy krok do ich optymalizacji. Aby zidentyfikować kosztowne skrypty, zalecamy korzystanie z bezpłatnych narzędzi do testowania szybkości stron internetowych, takich jak Narzędzia deweloperskie w Chrome, PageSpeed Insights i WebPageTest. Narzędzia te wyświetlają szczegółowe informacje diagnostyczne, które mogą wskazywać, ile skryptów innych firm używa Twoja witryna i które z nich wymagają najwięcej czasu na wykonanie.

Widok kaskadowy WebPageTest może pokazać wpływ intensywnego korzystania ze skryptów innych firm. Poniższy obraz z artykułu Tags Gone Wild przedstawia przykładowy diagram żądań sieciowych wymaganych do wczytania głównej zawartości witryny, w odróżnieniu od skryptów śledzących i marketingowych.

Wczytywanie skryptów na tej stronie trwa dłużej niż wczytywanie samej strony.

Podział według domen w WebPageTest może być też przydatny do wizualizacji, ile treści pochodzi ze źródeł zewnętrznych. Dane są podzielone według łącznej liczby bajtów i liczby żądań:

Wykresy podziału domen pokazują, jaka część zawartości strony pochodzi od osób trzecich.

Jak zmierzyć wpływ skryptu zewnętrznego na moją stronę?

Jeśli zauważysz, że skrypt powoduje problemy, dowiedz się, co robi, i ustal, czy jest on niezbędny do działania witryny. W razie potrzeby przeprowadź test A/B, aby znaleźć równowagę między postrzeganą wartością a wpływem na kluczowe wskaźniki zaangażowania użytkowników lub skuteczności.

Audyt czasu uruchamiania w Lighthouse

Kontrola czasu uruchamiania JavaScriptu w Lighthouse wyróżnia skrypty, które wymagają dużo czasu na analizę, kompilację lub ocenę. Może to pomóc w zidentyfikowaniu skryptów innych firm, które mocno obciążają procesor.

Kontrola czasu uruchamiania pokazuje, które skrypty wczytują się najdłużej.

Kontrola ładunków sieciowych w Lighthouse

Kontrola ładunków sieciowych w Lighthouse identyfikuje żądania sieciowe, w tym żądania sieciowe innych firm, które spowalniają czas wczytywania strony i powodują, że użytkownicy wydają więcej, niż oczekują, na mobilną transmisję danych.

Kontrola ładunków sieciowych pokazuje, które żądania sieciowe zajmują najwięcej czasu i pobierają najwięcej danych.

Blokowanie żądań sieciowych w Narzędziach deweloperskich w Chrome

Narzędzia deweloperskie w Chrome pozwalają sprawdzić, jak zachowuje się strona, gdy określony skrypt, arkusz stylów lub inny zasób jest niedostępny. Można to zrobić za pomocą blokowania żądań sieciowych, czyli funkcji, która pomaga mierzyć wpływ usunięcia poszczególnych zasobów innych firm ze strony.

Aby włączyć blokowanie żądań, kliknij prawym przyciskiem myszy dowolne żądanie w panelu Sieć i wybierz Zablokuj adres URL żądania. W panelu Narzędzi deweloperskich pojawi się karta blokowania żądań, na której możesz zarządzać zablokowanymi żądaniami.

Zablokuj poszczególne żądania sieciowe, aby zobaczyć, jak strona zachowuje się bez nich.

Panel wydajności w Narzędziach deweloperskich w Chrome

Panel Wydajność w Narzędziach deweloperskich w Chrome pomaga identyfikować problemy z wydajnością strony.

1. Kliknij Nagraj.
2. Wczytaj stronę. Narzędzia dla programistów wyświetlają diagram kaskadowy pokazujący, jak witryna wykorzystuje czas ładowania.
3. Przejdź do sekcji Oddolnie u dołu panelu Wydajność.
4. Kliknij Grupuj według usługi i posortuj skrypty innych firm na stronie według czasu wczytywania.

Skrypty innych firm posortowane według usługi, zaczynając od najdłuższego czasu wczytywania.

Więcej informacji o używaniu Narzędzi deweloperskich w Chrome do analizowania wydajności wczytywania strony znajdziesz w artykule Analizowanie wydajności środowiska wykonawczego.

Oto zalecany przez nas przepływ pracy, który pozwala mierzyć wpływ skryptów innych firm:

1. Za pomocą panelu Sieć możesz sprawdzić, ile czasu zajmuje wczytanie strony.
   • Aby odtworzyć warunki rzeczywiste, zalecamy włączenie ograniczania wykorzystania sieci i ograniczania wykorzystania procesora. Użytkownicy raczej nie mają szybkich połączeń sieciowych i sprzętu komputerowego, które zmniejszają wpływ kosztownych skryptów w warunkach laboratoryjnych.
2. Zablokuj adresy URL lub domeny odpowiedzialne za skrypty innych firm, które Twoim zdaniem powodują problemy (wskazówki dotyczące identyfikowania kosztownych skryptów znajdziesz w panelu wydajności Narzędzi deweloperskich w Chrome).
3. Odśwież stronę i ponownie zmierz czas wczytywania.
   • Aby uzyskać dokładniejsze dane, zmierz czas wczytywania co najmniej 3 razy. Wynika to z tego, że niektóre skrypty innych firm pobierają różne zasoby przy każdym wczytaniu strony. Aby ułatwić to zadanie, panel Wydajność w Narzędziach deweloperskich obsługuje wiele nagrań.

Pomiar wpływu skryptów innych firm za pomocą WebPageTest

WebPageTest umożliwia blokowanie wczytywania poszczególnych żądań, aby zmierzyć ich wpływ. Aby to zrobić, kliknij Advanced Settings (Ustawienia zaawansowane) > Block (Blokuj). Użyj tej funkcji, aby określić listę domen do zablokowania, np. domen reklamowych.

W tym panelu podaj listę domen, które chcesz zablokować.

Aby korzystać z tej funkcji, zalecamy wykonanie tych czynności:

1. Przetestuj stronę bez blokowania usług innych firm.
2. Powtórz test z zablokowanymi niektórymi usługami innych firm.
3. Wybierz 2 wyniki z historii testów.
4. Kliknij Porównaj.

Wybierz wyniki testu obciążenia do porównania.

Obraz poniżej przedstawia funkcję paska zdjęć w WebPageTest, która porównuje sekwencje wczytywania stron z aktywnymi zasobami innych firm i bez nich. Zalecamy sprawdzenie tego w przypadku testów poszczególnych źródeł zewnętrznych, aby określić, które domeny mają największy wpływ na wydajność strony.

Wpływ blokowania zasobów innych firm, z artykułu Using WebPageTest To Measure The Impact Of Third-Party Tags autorstwa Andy'ego Daviesa.

WebPageTest obsługuje też 2 polecenia działające na poziomie DNS, które służą do blokowania domen:

• blockDomains przyjmuje listę domen do zablokowania.
• blockDomainsExcept pobiera listę domen i blokuje wszystko, co nie znajduje się na liście.

WebPageTest ma też kartę pojedynczego punktu awarii (SPOF), która umożliwia symulowanie przekroczenia limitu czasu lub całkowitego niepowodzenia wczytywania zasobu. W przeciwieństwie do blokowania domen SPOF powoli przekracza limit czasu, co może być przydatne do testowania zachowania stron, gdy usługi innych firm są mocno obciążone lub tymczasowo niedostępne.

Użyj funkcji testowania SPOF, aby zasymulować awarię określonych domen.

Wykrywanie kosztownych elementów iframe za pomocą długich zadań

Gdy skrypty w elementach iframe innych firm działają przez dłuższy czas, mogą blokować wątek główny i opóźniać inne zadania. Te długie zadania mogą powodować powolne działanie modułów obsługi zdarzeń lub pomijanie klatek, co pogarsza wrażenia użytkownika.

Aby wykrywać długie zadania na potrzeby monitorowania rzeczywistych użytkowników (RUM), użyj interfejsu API PerformanceObserver w języku JavaScript do obserwowania wpisów longtask. Te wpisy zawierają właściwość atrybucji, której możesz użyć do określenia, który kontekst ramki spowodował długie zadanie.

Ten kod rejestruje w konsoli wpisy longtask, w tym jeden dotyczący „kosztownego” elementu iframe:

<script>
  const observer = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      // Attribution entry including "containerSrc":"https://example.com"
      console.log(JSON.stringify(entry.attribution));
    }
  });

  observer.observe({entryTypes: ['longtask']});
</script>

<!-- Imagine this is an iframe with expensive long tasks -->
<iframe src="https://example.com"></iframe>

Więcej informacji o monitorowaniu długich zadań znajdziesz w artykule Wskaźniki skuteczności zorientowane na użytkownika.

Jak skutecznie wczytywać skrypt innej firmy?

Jeśli skrypt innej firmy spowalnia wczytywanie strony, możesz poprawić wydajność na kilka sposobów:

• Wczytaj skrypt za pomocą atrybutu async lub defer, aby uniknąć blokowania analizy dokumentu.
• Jeśli zewnętrzny serwer działa wolno, rozważ samodzielne hostowanie skryptu.
• Jeśli skrypt nie wnosi wyraźnej wartości do Twojej witryny, usuń go.
• Używaj wskazówek dotyczących zasobów, takich jak <link rel=preconnect> lub <link rel=dns-prefetch>, aby przeprowadzać wyszukiwanie DNS w domenach hostujących skrypty innych firm.

Użyj async lub defer

Wykonywanie kodu JavaScript blokuje parser. Gdy przeglądarka napotka skrypt, musi wstrzymać tworzenie DOM, przekazać skrypt do silnika JavaScriptu i pozwolić na jego wykonanie, zanim będzie kontynuować tworzenie DOM.

Atrybuty async i defer zmieniają to działanie w następujący sposób:

• async powoduje, że przeglądarka pobiera skrypt asynchronicznie, kontynuując analizowanie dokumentu HTML. Po zakończeniu pobierania skryptu analiza jest blokowana podczas jego wykonywania.

• defer powoduje, że przeglądarka pobiera skrypt asynchronicznie, kontynuując analizowanie dokumentu HTML, a następnie czeka z uruchomieniem skryptu do zakończenia analizowania dokumentu.

Zawsze używaj atrybutu async lub defer w przypadku skryptów innych firm, chyba że skrypt jest niezbędny do krytycznej ścieżki renderowania. Użyj async, jeśli ważne jest, aby skrypt został uruchomiony wcześniej w procesie wczytywania, np. w przypadku niektórych skryptów analitycznych. Używaj defer w przypadku mniej istotnych zasobów, takich jak filmy, które renderują się niżej na stronie, niż użytkownik początkowo widzi.

Jeśli wydajność jest dla Ciebie najważniejsza, zalecamy dodanie skryptów asynchronicznych dopiero po załadowaniu najważniejszych treści strony. Nie zalecamy używania async w przypadku podstawowych bibliotek, takich jak jQuery.

Uwaga: w Chrome i innych przeglądarkach opartych na Blink atrybuty async i defer obniżają priorytet żądania sieciowego dotyczącego zasobów, co może spowodować, że zasoby będą ładować się znacznie później niż w przypadku skryptu blokującego. Jest to przydatne zwłaszcza w przypadku skryptów analitycznych.

Niektóre skrypty muszą być wczytywane bez atrybutu async lub defer, zwłaszcza te, które są kluczowymi elementami witryny. Obejmuje to biblioteki interfejsu lub platformy sieci dostarczania treści (CDN), bez których witryna nie może działać.

Inne skrypty po prostu nie działają, jeśli są ładowane asynchronicznie. Sprawdź dokumentację wszystkich używanych skryptów i zastąp te, których nie można wczytywać asynchronicznie, takimi, które można wczytywać w ten sposób. Pamiętaj, że niektóre firmy zewnętrzne zalecają uruchamianie skryptów synchronicznie, nawet jeśli działają one równie dobrze asynchronicznie.

Pamiętaj, że async nie rozwiązuje wszystkich problemów. Jeśli Twoja strona zawiera dużą liczbę skryptów, np. skryptów śledzących do celów reklamowych, ich asynchroniczne wczytywanie nie zapobiegnie spowolnieniu wczytywania strony.

Używaj wskazówek dotyczących zasobów, aby skrócić czas konfiguracji połączenia

Nawiązywanie połączeń z zewnętrznymi źródłami może zająć dużo czasu, zwłaszcza w przypadku wolnych sieci, ponieważ żądania sieciowe składają się z wielu złożonych komponentów, w tym wyszukiwań DNS i przekierowań. Możesz użyć wskazówek dotyczących zasobów, takich jak , aby przeprowadzić wyszukiwanie DNS w domenach hostujących skrypty innych firm na wczesnym etapie procesu wczytywania strony. Dzięki temu pozostałe żądania sieciowe będą mogły być realizowane szybciej:

<link rel="dns-prefetch" href="http://example.com" />

Jeśli domena innej firmy, z którą się łączysz, używa protokołu HTTPS, możesz też użyć , który wykonuje wyszukiwania DNS oraz rozwiązuje problemy z połączeniami TCP w obie strony i obsługuje negocjacje TLS. Te inne kroki mogą być bardzo powolne, ponieważ obejmują weryfikację certyfikatów SSL, więc wstępne połączenie może znacznie skrócić czas wczytywania.

<link rel="preconnect" href="https://cdn.example.com" />

Skrypty „piaskownicy” z elementem iframe

Jeśli wczytasz skrypt innej firmy bezpośrednio do elementu iframe, nie zablokuje on działania strony głównej. AMP wykorzystuje to podejście, aby usunąć JavaScript ze ścieżki krytycznej. Pamiętaj, że to podejście nadal blokuje zdarzenie onload, więc staraj się nie dołączać do niego onload kluczowych funkcji.

Chrome obsługuje też zasady dotyczące uprawnień (wcześniej zasady dotyczące funkcji), czyli zestaw zasad, które umożliwiają deweloperowi selektywne wyłączanie dostępu do niektórych funkcji przeglądarki. Możesz użyć tej funkcji, aby zapobiec wprowadzaniu przez treści osób trzecich niepożądanych zachowań w witrynie.

Samodzielne hostowanie skryptów innych firm

Jeśli chcesz mieć większą kontrolę nad sposobem wczytywania krytycznego skryptu, na przykład aby skrócić czas DNS lub ulepszyć nagłówki pamięci podręcznej HTTP, możesz hostować go samodzielnie.

Jednak samodzielne hostowanie wiąże się z pewnymi problemami, zwłaszcza jeśli chodzi o aktualizowanie skryptów. Skrypty hostowane samodzielnie nie będą otrzymywać automatycznych aktualizacji dotyczących zmian w interfejsie API ani poprawek zabezpieczeń, co może prowadzić do utraty przychodów lub problemów z bezpieczeństwem, dopóki nie zaktualizujesz skryptu ręcznie.

Możesz też zapisywać skrypty innych firm w pamięci podręcznej za pomocą skryptów service worker, aby mieć większą kontrolę nad tym, jak często skrypty są pobierane z sieci. Możesz też użyć skryptów service worker, aby utworzyć strategie wczytywania, które ograniczają nieistotne żądania innych firm, dopóki strona nie osiągnie kluczowego momentu dla użytkownika.

Przeprowadzanie testów A/B na mniejszych próbkach użytkowników

Testy A/B (lub testy porównawcze) to technika eksperymentowania z 2 wersjami strony w celu analizy wrażeń i zachowań użytkowników. Udostępnia wersje strony różnym próbkom ruchu w witrynie i na podstawie statystyk określa, która wersja zapewnia lepszy współczynnik konwersji.

Jednak testy A/B z założenia opóźniają renderowanie, aby określić, który eksperyment powinien być aktywny. JavaScript jest często używany do sprawdzania, czy użytkownicy należą do eksperymentu testu A/B, i włączania odpowiedniego wariantu. Może to pogorszyć wrażenia nawet tych użytkowników, którzy nie biorą udziału w eksperymencie.

Aby przyspieszyć renderowanie strony, zalecamy wysyłanie skryptów testów A/B do mniejszej próbki użytkowników i uruchamianie kodu, który decyduje o tym, którą wersję strony wyświetlić po stronie serwera.

Leniwe ładowanie zasobów z innych witryn

Umieszczone na stronie zasoby innych firm, takie jak reklamy i filmy, mogą być główną przyczyną wolnego działania strony, jeśli są nieprawidłowo skonstruowane. Leniwe ładowanie może służyć do wczytywania zasobów osadzonych tylko wtedy, gdy jest to konieczne, np. do wyświetlania reklam w stopce strony dopiero wtedy, gdy użytkownik przewinie stronę wystarczająco daleko, aby je zobaczyć. Możesz też ustawić leniwe ładowanie treści osób trzecich po załadowaniu głównej treści strony, ale przed interakcją użytkownika ze stroną.

Możesz zastosować leniwe ładowanie do zasobów, których użytkownik nie zobaczy od razu po wczytaniu strony.

Zachowaj ostrożność podczas leniwego ładowania zasobów, ponieważ często wymaga ono kodu JavaScript, na który mogą wpływać niestabilne połączenia sieciowe.

Uwaga: LazySizes to popularna biblioteka JavaScript do leniwego ładowania obrazów i elementów iframe. Obsługuje umieszczone filmy z YouTube i widżety.

Wskazówki dotyczące leniwego ładowania reklam znajdziesz w oficjalnej dokumentacji DoubleClick.

Wydajne leniwe ładowanie z wykorzystaniem interfejsu Intersection Observer

W przeszłości metody wykrywania, czy element jest widoczny w obszarze widocznym na potrzeby leniwego ładowania, były podatne na błędy i często spowalniały działanie przeglądarki. Te nieefektywne metody często nasłuchują zdarzeń scroll lub resize, a następnie używają interfejsów API DOM, takich jak getBoundingClientRect(), aby obliczyć, gdzie znajdują się elementy względem widocznego obszaru.

IntersectionObserver to interfejs API przeglądarki, który umożliwia właścicielom stron skuteczne wykrywanie, kiedy obserwowany element pojawia się w obszarze widocznym przeglądarki lub go opuszcza. LazySizes opcjonalnie obsługuje też IntersectionObserver.

Analityka leniwego ładowania

Jeśli zbyt długo będziesz opóźniać wczytywanie skryptów analitycznych, możesz utracić cenne dane analityczne. Na szczęście istnieją strategie, które umożliwiają opóźnione inicjowanie analityki przy jednoczesnym zachowaniu danych z początkowego wczytywania strony.

Post na blogu Phila Waltona The Google Analytics Setup I Use on Every Site I Build (Konfiguracja Google Analytics, której używam w każdej tworzonej witrynie) opisuje jedną z takich strategii w przypadku Google Analytics.

Bezpieczne wczytywanie skryptów innych firm

W tej sekcji znajdziesz wskazówki dotyczące jak najbezpieczniejszego wczytywania skryptów innych firm.

Unikaj: document.write()

Skrypty innych firm, zwłaszcza w przypadku starszych usług, czasami używają metody document.write() do wstrzykiwania i wczytywania skryptów. Jest to problem, ponieważ document.write() zachowuje się niespójnie, a błędy są trudne do debugowania.

Rozwiązaniem problemów z document.write() jest nieużywanie tej metody. W Chrome 53 i nowszych wersjach Narzędzia deweloperskie w Chrome rejestrują w konsoli ostrzeżenia dotyczące problematycznego użycia document.write():

Użycie flag document.write() Narzędzi deweloperskich w Chrome.

Jeśli pojawi się ten błąd, możesz sprawdzić, czy Twoja witryna używa document.write(), szukając nagłówków HTTP wysyłanych do przeglądarki. Lighthouse może też wyróżnić skrypty innych firm, które nadal używają document.write().

Raport Lighthouse pokazujący, które skrypty używają document.write().

Rozważne używanie menedżerów tagów

Tag to fragment kodu, który umożliwia zespołom ds. marketingu internetowego zbieranie danych, ustawianie plików cookie lub integrowanie z witryną treści osób trzecich, np. widżetów mediów społecznościowych. Tagi te dodają do strony żądania sieciowe, zależności JavaScriptu i inne zasoby, które mogą wpływać na jej wydajność. Im więcej tagów dodasz, tym trudniej będzie Ci zminimalizować ich wpływ na użytkowników.

Aby wczytywanie stron było szybkie, zalecamy korzystanie z menedżera tagów, np. Menedżera tagów Google. Menedżer tagów Google umożliwia asynchroniczne wdrażanie tagów, dzięki czemu nie blokują one wzajemnie swojego wczytywania, zmniejsza liczbę wywołań sieciowych, których przeglądarka potrzebuje do uruchamiania tagów, oraz zbiera dane tagów w interfejsie warstwy danych.

Zagrożenia związane z używaniem menedżerów tagów

Menedżery tagów mają usprawniać wczytywanie strony, ale nieostrożne korzystanie z nich może je spowolnić w następujący sposób:

• Zbyt duża liczba tagów i detektorów zdarzeń automatycznych w menedżerze tagów powoduje, że przeglądarka wysyła więcej żądań sieciowych, niż jest to konieczne, i zmniejsza zdolność kodu do szybkiego reagowania na zdarzenia.
• Każda osoba mająca dane logowania i dostęp może dodać kod JavaScript do Menedżera tagów. Może to nie tylko zwiększyć liczbę kosztownych żądań sieciowych potrzebnych do wczytania strony, ale też spowodować zagrożenia bezpieczeństwa i inne problemy z wydajnością związane z niepotrzebnymi skryptami. Aby zmniejszyć to ryzyko, zalecamy ograniczenie dostępu do menedżera tagów.

Unikaj skryptów, które zanieczyszczają zakres globalny

Skrypty innych firm mogą zachowywać się na różne sposoby, które mogą nieoczekiwanie uszkodzić stronę:

• Skrypty wczytujące zależności JavaScriptu mogą zanieczyszczać zakres globalny kodem, który nie współdziała prawidłowo z Twoim kodem.
• Nieoczekiwane aktualizacje mogą spowodować zmiany powodujące niezgodność.
• Kod zewnętrzny może zostać zmodyfikowany podczas przesyłania, aby zachowywał się inaczej podczas testowania i wdrażania strony.

Zalecamy regularne sprawdzanie skryptów innych firm pod kątem nieuczciwych podmiotów. Możesz też wdrożyć autotesty, integralność zasobów podrzędnych i bezpieczne przesyłanie kodu innych firm, aby zapewnić bezpieczeństwo strony.

Strategie ograniczania ryzyka

Oto kilka strategii na dużą skalę, które pozwalają zminimalizować wpływ skryptów innych firm na wydajność i bezpieczeństwo witryny:

• HTTPS: witryny korzystające z protokołu HTTPS nie mogą być zależne od usług innych firm, które korzystają z protokołu HTTP. Więcej informacji znajdziesz w artykule na temat treści mieszanych.

• Piaskownica: rozważ uruchamianie skryptów innych firm w elementach iframe z atrybutem sandbox, aby ograniczyć działania dostępne dla skryptów.

• Content Security Policy (CSP): możesz używać nagłówków HTTP w odpowiedzi serwera, aby definiować zachowania zaufanych skryptów w witrynie oraz wykrywać i ograniczać skutki niektórych ataków, takich jak cross-site scripting (XSS).

Poniżej znajduje się przykład użycia dyrektywy script-src CSP do określenia dozwolonych źródeł JavaScriptu na stronie:

// Given this CSP header Content-Security-Policy: script-src
https://example.com/ // The following third-party script will not be loaded or
executed

<script src="https://not-example.com/js/library.js"></script>

Więcej informacji

Aby dowiedzieć się więcej o optymalizowaniu kodu JavaScript innych firm, przeczytaj te artykuły:

• Wydajność i odporność: testy obciążeniowe usług innych firm
• Dodawanie interaktywności za pomocą JavaScriptu
• Potencjalne zagrożenia związane ze skryptami innych firm
• Jak skrypty innych firm mogą być wydajnymi elementami w internecie
• Why Fast Matters - CSS Wizardry
• Paradoks łańcucha dostaw JavaScriptu: SRI, CSP i zaufanie do bibliotek innych firm
• Zewnętrzny kod CSS nie jest bezpieczny

Dziękujemy Kenjiemu Baheux, Jeremy'emu Wagnerowi, Patowi Meenanowi, Philipowi Waltonowi, Jeffowi Posnickowi i Cheneyowi Tsai za ich opinie.