Wczytywanie JavaScriptu innej firmy

Jeśli po zoptymalizowaniu kodu witryna nadal wczytuje się zbyt wolno, przyczyną problemu prawdopodobnie są skrypty innych firm.

Skrypty innych firm udostępniają wiele przydatnych funkcji, które sprawiają, że sieć jest bardziej dynamiczna, interaktywna i połączona ze sobą. Niektóre z nich mogą być nawet kluczowe dla funkcji witryny lub źródła przychodów. Ich stosowanie jest jednak ryzykowne:

• Mogą one spowalniać wydajność witryny.
• Mogą powodować problemy z prywatnością i bezpieczeństwem.
• Mogą one być nieprzewidywalne, a ich zachowanie może mieć niezamierzone konsekwencje.

Idealnie upewnij się, że skrypty innych firm nie wpływają na krytyczną ścieżkę renderowania witryny. W tym przewodniku pokażemy, jak wykryć i rozwiązać problemy związane z wczytywaniem kodu JavaScript innej firmy oraz jak zminimalizować ryzyko, z którego będą korzystać użytkownicy.

Co to są skrypty innych firm?

Kod JavaScript firmy zewnętrznej 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 w mediach społecznościowych (Facebook, X, LinkedIn, Mastodon)

• Umieszczone odtwarzacze (YouTube, Vimeo)

• Elementy iframe reklam

• Skrypty statystyk i danych

• Skrypty testów A/B do eksperymentów

• Biblioteki pomocnicze, np. do formatowania dat, animacji czy bibliotek funkcjonalnych

<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 tym, że będą one szybko działać i nie spowalniać naszych stron. Skrypty innych firm są częstą przyczyną spowolnienia działania witryny spowodowanych zasobami pozostającymi poza kontrolą właściciela witryny. Są to między innymi:

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

• Wysyłanie zbyt dużej ilości kodu JavaScript, która powoduje zajęcie wątku głównego. Zbyt duża ilość kodu JavaScript może zablokować konstrukcję DOM, co opóźni renderowanie strony. Przetwarzanie i wykonywanie skryptów obciążające procesor może opóźnić interakcję użytkownika i wyczerpać baterię.

• Wysyłanie dużych, niezoptymalizowanych plików graficznych lub filmów może konsumować dane i generować koszty dla użytkowników.

• Problemy z bezpieczeństwem, które mogą powodować pojedynczy punkt awarii (SPOF), gdy strona wczytuje skrypt bez ostrożności.

• Niewystarczająca pamięć podręczna HTTP, która zmusza przeglądarkę do wysyłania większej liczby żądań sieciowych w celu pobrania zasobów.

• Brak wystarczającej kompresji serwera powoduje wolne ładowanie zasobów.

• Blokuje wyświetlanie treści do czasu zakończenia ich przetwarzania. Dotyczy to także skryptów do testów A/B asynchronicznych.

• wykorzystywanie starszych interfejsów API, np. document.write(), które zmniejszają wygodę użytkowników.

• Nadmierne elementy DOM lub drogie selektory CSS.

• Uwzględnienie wielu elementów osadzonych przez inne firmy może spowodować kilkukrotne pobieranie wielu platform i bibliotek, zmarnowanie zasobów i pogorszenie występujących problemów z wydajnością.

• Skrypty innych firm często używają technik umieszczania, które mogą blokować parametr window.onload, jeśli ich serwery reagują powoli, nawet jeśli osadzanie jest stosowane asynchroniczne lub opóźniane.

Możliwość rozwiązywania problemów ze skryptami firm zewnętrznych może zależeć od Twojej witryny i możliwości skonfigurowania sposobu wczytywania kodu zewnętrznego. Na szczęście istnieją rozwiązania i narzędzia umożliwiające znajdowanie i rozwiązywanie problemów z zasobami zewnętrznymi.

Jak rozpoznajecie na stronie zewnętrzny skrypt?

Zidentyfikowanie w witrynie skryptów innych firm i określenie ich wpływu na wydajność to pierwszy krok do ich optymalizacji. Do wykrywania kosztownych skryptów zalecamy korzystanie z bezpłatnych narzędzi do testowania szybkości działania internetu, takich jak Chrome DevTools, PageSpeed Insights i WebPageTest. Zawierają one rozbudowane informacje diagnostyczne, dzięki którym dowiesz się, z ilu skryptów firm zewnętrznych korzysta Twoja witryna i które ich wykonanie zajmuje najwięcej czasu.

Widok kaskadowy dostępny w WebPageTest pozwala podkreślić wpływ intensywnego korzystania ze skryptów zewnętrznych. Poniższy obraz z prezentacji Tags Gone Wild przedstawia przykładowy diagram z żądaniami sieciowymi wymaganymi do wczytania głównej zawartości witryny, w przeciwieństwie do skryptów śledzenia i skryptów marketingowych.

Dostępna w WebPageTest podział na domeny może się też przydać do zobrazowania, ile treści pochodzi ze źródeł zewnętrznych. Dane są rozbite na łączną liczbę bajtów i liczbę żądań:

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

Gdy zobaczysz skrypt powodujący problemy, sprawdź, jak działa, i zdecyduj, czy Twoja witryna potrzebuje go do działania. W razie potrzeby przeprowadź test A/B, aby zrównoważyć postrzeganą wartość reklamy z jej wpływem na kluczowe dane dotyczące zaangażowania użytkowników lub skuteczności.

Kontrola czasu uruchamiania Lighthouse

Kontrola czasu uruchamiania JavaScriptu w Lighthouse wyróżnia skrypty, które mają kosztowny czas analizowania, kompilowania lub oceny. Pomoże Ci to zidentyfikować skrypty zewnętrzne, które obciążają procesor.

Kontrola ładunków sieciowych w Lighthouse

Kontrola sieci ładunków w Lighthouse identyfikuje żądania sieciowe, w tym żądania zewnętrzne, które spowalniają czas wczytywania strony i sprawiają, że użytkownicy wykorzystują mobilną transmisję danych więcej, niż się spodziewają.

Blokowanie żądań sieciowych w Chrome DevTools

Narzędzia deweloperskie w Chrome pozwalają sprawdzić, jak zachowuje się strona, gdy określony skrypt, arkusz stylów lub inny zasób są niedostępne. Odbywa się to za pomocą blokowania żądań sieciowych – funkcji, która pomaga mierzyć wpływ usunięcia z Twojej strony określonych zasobów zewnętrznych.

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

Panel wydajności Narzędzi deweloperskich w Chrome

Panel wydajności w Narzędziach deweloperskich w Chrome pomaga wykrywać problemy z szybkością działania strony.

1. Kliknij Nagraj.
2. Wczytaj stronę. W Narzędziach deweloperskich znajdziesz diagram kaskadowy pokazujący, jak Twoja witryna spędza czas wczytywania.
3. U dołu panelu Skuteczność kliknij Od dołu do góry.
4. Kliknij Pogrupuj według usługi i posortuj skrypty zewnętrzne strony według czasu wczytywania.

Więcej informacji o analizowaniu szybkości wczytywania stron za pomocą Narzędzi deweloperskich w Chrome znajdziesz w artykule Pierwsze kroki z analizowaniem wydajności środowiska wykonawczego.

Poniżej przedstawiamy zalecany proces pomiaru wpływu skryptów zewnętrznych:

1. W panelu Sieć możesz sprawdzić, ile czasu trwa wczytanie strony.
   • Aby emulować rzeczywiste warunki, włącz ograniczanie sieci i ograniczanie procesora. Twoi użytkownicy prawdopodobnie nie będą mieli szybkich połączeń sieciowych ani sprzętu komputerowego, które zmniejszałoby wpływ kosztownych skryptów w warunkach laboratoryjnych.
2. Zablokuj adresy URL lub domeny odpowiedzialne za skrypty innych firm, które Twoim zdaniem stanowią problem (wskazówki dotyczące identyfikowania kosztownych skryptów znajdziesz w panelu wydajności Chrome DevTools).
3. Załaduj ponownie stronę i jeszcze raz zmierz czas wczytywania.
   • Aby uzyskać dokładniejsze dane, mierz czas wczytywania co najmniej trzy razy. Dotyczy to skryptów firm zewnętrznych pobierających różne zasoby przy każdym wczytaniu strony. Aby to ułatwić, panel wydajności Narzędzi deweloperskich obsługuje wiele nagrań.

Mierz wpływ skryptów zewnętrznych za pomocą WebPageTest

WebPageTest umożliwia blokowanie wczytywania poszczególnych żądań w celu zmierzenia ich wpływu w sekcji Ustawienia zaawansowane > Zablokuj. Ta funkcja pozwala określić listę domen, które mają być blokowane, np. domeny reklam.

Jeśli chcesz użyć tej funkcji, zalecamy następujący przepływ pracy:

1. Przetestuj stronę bez blokowania innych firm.
2. Powtórz test z zablokowanymi innymi firmami.
3. Wybierz 2 wyniki z Historii testów.
4. Kliknij Porównaj.

Na ilustracji poniżej pokazano funkcję paska zdjęć dostępna w aplikacji WebPageTest, która porównuje sekwencje wczytywania stron z aktywnymi zasobami firm zewnętrznych i bez nich. Zalecamy zaznaczenie go w przypadku testów poszczególnych źródeł zewnętrznych, które pozwolą Ci określić, które domeny najbardziej wpływają na wydajność Twojej strony.

WebPageTest obsługuje również 2 polecenia działające na poziomie DNS do blokowania domen:

• blockDomains pobiera listę domen do zablokowania.
• blockDomainsExcept pobiera listę domen i blokuje wszystkie te, które nie są na niej.

WebPageTest ma też kartę SPOF, która pozwala symulować przekroczenie limitu czasu lub całkowitą nieudaną próbę wczytania zasobu. W przeciwieństwie do blokowania domen SPOF powoli przekracza limit czasu, co może być przydatne przy sprawdzaniu działania stron, gdy usługi innych firm są przeciążone lub tymczasowo niedostępne.

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

Gdy skrypty w zewnętrznych elementach iframe uruchomione przez dłuższy czas działają, mogą zablokować wątek główny i opóźnić inne zadania. Takie długie zadania mogą spowolnić działanie modułów obsługi zdarzeń lub pogorszyć wrażenia użytkownika.

Aby wykrywać długie zadania w przypadku Real User Monitoring (RUM), użyj interfejsu JavaScript PerformanceObserver API do obserwowania wpisów longtask. Te wpisy zawierają właściwość atrybucji, która pozwala określić, który kontekst ramki spowodował długie zadanie.

Ten kod rejestruje w konsoli wpisy longtask, w tym jeden dla „drogowego” 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 Ukierunkowanie na użytkownika wskaźników wydajności.

Jak wydajnie wczytywać skrypt zewnętrzny?

Jeśli skrypt zewnętrzny spowalnia wczytywanie strony, możesz zwiększyć wydajność na kilka sposobów:

• Wczytaj skrypt za pomocą atrybutu async lub defer, aby uniknąć zablokowania analizy dokumentu.
• Jeśli serwer firmy zewnętrznej działa wolno, rozważ możliwość hostowania skryptu we własnym zakresie.
• Jeśli skrypt nie wnosi wyraźnej wartości w witrynie, usuń go.
• Użyj wskazówek dotyczących zasobów, takich jak <link rel=preconnect> lub <link rel=dns-prefetch>, aby przeprowadzić wyszukiwanie DNS domen hostujących skrypty innych firm.

Użyj konta async lub defer

Wykonanie JavaScriptu wymaga blokowania parsera. Gdy przeglądarka napotyka skrypt, musi wstrzymać konstrukcję DOM, przekazać go do mechanizmu JavaScript i zezwolić na jego wykonanie przed kontynuacją konstrukcji DOM.

Atrybuty async i defer zmieniają to działanie w ten sposób:

• async powoduje, że przeglądarka asynchronicznie pobiera skrypt, podczas gdy nadal analizuje dokument HTML. Po zakończeniu pobierania skryptu analiza jest zablokowana na czas wykonywania skryptu.

• defer powoduje, że przeglądarka asynchronicznie pobiera skrypt, podczas gdy nadal analizuje dokument HTML, a następnie czeka na uruchomienie skryptu do momentu zakończenia analizy dokumentu.

W przypadku skryptów innych firm zawsze używaj async lub defer, chyba że skrypt jest niezbędny na krytycznej ścieżce renderowania. Użyj async, jeśli skrypt powinien uruchamiać się na wcześniejszym etapie wczytywania, np. w przypadku niektórych skryptów analitycznych. Używaj właściwości defer w przypadku mniej ważnych zasobów, np. filmów, które renderują się na stronie niżej niż widzi użytkownik.

Jeśli zależy Ci przede wszystkim na wydajności, zalecamy dodanie skryptów asynchronicznych dopiero po wczytaniu kluczowych treści na stronie. Nie zalecamy korzystania z async w przypadku niezbędnych bibliotek, takich jak jQuery.

Niektóre skrypty należy ładować bez elementów async i defer. Dotyczy to zwłaszcza tych, które są kluczowymi częściami witryny. Obejmują one biblioteki UI lub platformy sieci dostarczania treści (CDN), bez których Twoja witryna nie może działać.

Inne skrypty po prostu nie będą działać, jeśli są ładowane asynchronicznie. Sprawdź dokumentację dotyczącą używanych przez Ciebie skryptów i zastąp te, których nie można ładować asynchronicznie, innymi skryptami, których używasz. 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 strona zawiera dużą liczbę skryptów, np. skryptów śledzenia do celów reklamowych, ich asynchroniczne wczytywanie nie zapobiegnie spowolnieniu wczytywania strony.

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

Nawiązywanie połączeń z zewnętrznymi źródłami może zajmować dużo czasu, zwłaszcza w przypadku powolnych sieci, ponieważ żądania sieciowe mają wiele złożonych komponentów, w tym wyszukiwania DNS i przekierowania. Możesz skorzystać ze wskazówek dotyczących zasobów, takich jak , aby przeprowadzić wyszukiwanie DNS domen hostujących skrypty innych firm na wczesnym etapie procesu wczytywania strony. Dzięki temu reszta żądań sieciowych może być zrealizowana szybciej:

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

Jeśli domena firmy zewnętrznej, z którą się łączysz, korzysta z protokołu HTTPS, też możesz użyć usługi , która przeprowadza wyszukiwania DNS oraz rozwiązuje obwód wymiany protokołu TCP i obsługuje negocjacje TLS. Te pozostałe kroki mogą być bardzo powolne, ponieważ wymagają weryfikacji certyfikatów SSL, więc wstępne połączenie może znacznie skrócić czas ładowania.

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

Skrypty „Piaskownica” z elementem iframe

Jeśli wczytasz skrypt innej firmy bezpośrednio do elementu iframe, nie zablokuje on wykonania strony głównej. AMP korzysta z tego podejścia, aby uniemożliwiać JavaScriptowi obsługę krytycznej ścieżki. Pamiętaj, że ta metoda nadal blokuje zdarzenie onload, więc nie dołączaj kluczowych funkcji do onload.

Chrome obsługuje też zasady dotyczące uprawnień (dawniej zasady dotyczące funkcji) – zbiór zasad, które pozwalają deweloperowi na selektywne wyłączanie dostępu do określonych funkcji przeglądarki. W ten sposób możesz zapobiec wprowadzaniu w witrynie niepożądanych zachowań użytkowników.

Własne skrypty innych firm

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

Z hostingiem własnym wiąże się jednak wiele problemów, zwłaszcza podczas aktualizowania skryptów. Własne skrypty nie będą automatycznie otrzymywać aktualizacji zmian w interfejsie API ani poprawek zabezpieczeń, które mogą prowadzić do utraty przychodów lub problemów z zabezpieczeniami, dopóki nie zaktualizujesz skryptu ręcznie.

Możesz też zapisywać skrypty zewnętrzne w pamięci podręcznej za pomocą skryptów service worker, aby mieć większą kontrolę nad częstotliwością pobierania skryptów z sieci. Możesz też używać mechanizmów Service Worker do tworzenia strategii wczytywania, które ograniczają nieistotne żądania zewnętrzne do czasu, aż Twoja strona osiągnie kluczowy moment dla użytkownika.

Testy A/B – mniejsze grupy użytkowników

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

Jednak z założenia testy A/B opóźniają renderowanie, aby określić, który eksperyment należy aktywować. JavaScript często używa się do sprawdzenia, czy którykolwiek z użytkowników uczestniczy w eksperymencie testowym A/B, i włączenia odpowiedniego wariantu. Ten proces może pogorszyć wrażenia użytkowników, którzy nie biorą udziału w eksperymencie.

Aby przyspieszyć renderowanie stron, zalecamy wysłanie skryptów testów A/B do mniejszej próbki użytkowników i uruchomienie kodu określającego, która wersja strony będzie wyświetlana po stronie serwera.

Leniwe ładowanie zasobów zewnętrznych

Umieszczone zasoby innych firm, takie jak reklamy i filmy, mogą być główną przyczyną spowolnienia działania strony, jeśli są niewłaściwie skonstruowane. Leniwe ładowanie może służyć do wczytywania umieszczonych zasobów tylko wtedy, gdy jest to konieczne, np. oczekiwania na wyświetlenie reklam w stopce strony, aż użytkownik przewinie stronę na tyle daleko, żeby je zobaczyć. Możesz też leniwie wczytywać treści należące do innych podmiotów po wczytaniu zawartości strony głównej, ale zanim użytkownik wejdzie w interakcję z nią.

Zachowaj ostrożność przy leniwym ładowaniu zasobów, ponieważ często obejmuje on kod JavaScript, na który mogą mieć wpływ niestabilne połączenie sieciowe.

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

Wydajne leniwe ładowanie z obserwacją skrzyżowań

W przeszłości metody wykrywania, czy element jest widoczny w widocznym obszarze na potrzeby leniwego ładowania, były podatne na błędy i często spowalniają działanie przeglądarki. Te nieefektywne metody często nasłuchują zdarzeń przewijania lub resize, a następnie używają interfejsów DOM API, np. getBoundingClientRect(), aby obliczać położenie elementów 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 widocznym obszarze przeglądarki, a kiedy poza nim. LazySizes ma też opcjonalną obsługę obiektu IntersectionObserver.

Analiza leniwego ładowania

Jeśli opóźnisz wczytywanie skryptów analitycznych na zbyt długo, możesz utracić cenne dane analityczne. Na szczęście istnieją strategie, które pozwalają na leniwe inicjowanie statystyk z zachowaniem danych dotyczących wczesnego wczytywania strony.

Jedną z takich strategii w Google Analytics jest post na blogu Phila Waltona The Google Analytics Setup I Use on Every Site I Build (Konfiguracja Google Analytics, którego używam w każdej utworzonej witrynie).

Bezpiecznie wczytuj skrypty innych firm

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

Unikaj: document.write()

Skrypty innych firm, zwłaszcza w przypadku starszych usług, czasami używają document.write() do wstrzykiwania i wczytywania skryptów. Problem ten wynika z tego, że document.write() zachowuje się niespójnie, a jego błędy są trudne do debugowania.

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

Jeśli zobaczysz ten błąd, możesz sprawdzić wykorzystanie document.write() w swojej witrynie, wyszukując nagłówki HTTP wysłane do przeglądarki. Lighthouse może też wyróżnić skrypty innych firm wciąż za pomocą document.write().

Ostrożnie korzystaj z Menedżera tagów

Tag to fragment kodu, który umożliwia zespołom ds. marketingu internetowego zbieranie danych, zapisywanie plików cookie lub integrowanie z witryną treści innych firm, np. widżetów mediów społecznościowych. Tagi te dodają do strony żądania sieciowe, zależności JavaScript i inne zasoby, które mogą wpływać na jej wydajność, a minimalizowanie tego wpływu dla użytkowników staje się coraz trudniejsze, gdy jest w nim więcej tagów.

Aby zapewnić szybkie wczytywanie strony, 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 sobie nawzajem wczytywania, zmniejsza liczbę wywołań sieciowych potrzebnych przeglądarce do wykonania tagów i zbiera dane tagów w interfejsie warstwy danych.

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

Chociaż menedżery tagów zostały zaprojektowane w celu usprawnienia wczytywania stron, używanie ich może spowalniać proces w taki 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ż potrzebowałaby, i zmniejsza zdolność kodu do szybkiego reagowania na zdarzenia.
• Każdy, kto ma dane logowania i ma dostęp, może dodać kod JavaScript do Twojego Menedżera tagów. Może to nie tylko zwiększyć liczbę kosztownych żądań sieciowych potrzebnych do wczytania strony, ale też zagrażać bezpieczeństwu i inne problemy z wydajnością spowodowane przez niepotrzebne skrypty. 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ą działać w różny sposób, powodując nieoczekiwane przerwy w działaniu strony:

• Skrypty ładujące zależności JavaScriptu mogą zanieczyszczać zakres globalny kodem, który źle współpracuje z Twoim kodem.
• Nieoczekiwane aktualizacje mogą spowodować zmiany powodujące niezgodność.
• Kod zewnętrzny można zmodyfikować podczas przesyłania, aby różnił się między testowaniem a wdrażaniem strony.

Zalecamy regularne audyty wczytywanych skryptów zewnętrznych w celu sprawdzenia, czy nie występują nieuczciwe podmioty. Aby chronić swoją stronę, możesz też wdrożyć autotestowanie, integralność zasobów podrzędnych i bezpieczne przesyłanie kodu zewnętrznego.

Strategie łagodzenia skutków

Oto kilka stosowanych na dużą skalę strategii minimalizowania wpływu skryptów zewnętrznych na wydajność i bezpieczeństwo witryny:

• HTTPS: witryny korzystające z protokołu HTTPS nie mogą zależeć od innych firm z protokołem HTTP. Więcej informacji znajdziesz w sekcji Treści mieszane.

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

• Zasady bezpieczeństwa treści (CSP): w odpowiedzi serwera możesz używać nagłówków HTTP, aby zdefiniować zachowanie zaufanych skryptów w witrynie oraz wykrywać i łagodzić skutki niektórych ataków, takich jak cross Site Scripting (XSS).

Poniżej znajdziesz 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 optymalizacji kodu JavaScript innej firmy, przeczytaj ten artykuł:

• Wydajność i odporność: firmy zewnętrzne przeprowadzające testy w warunkach stresowych
• Dodawanie funkcji interaktywnych w języku JavaScript
• Potencjalne zagrożenia ze strony skryptów innych firm
• Jak skrypty innych firm mogą efektywnie działać w internecie
• Dlaczego szybkość jest ważna – magia CSS
• Paradoks łańcucha dostaw JavaScript: SRI, CSP i zaufanie w bibliotekach zewnętrznych
• Usługa porównywania cen firmy zewnętrznej jest niebezpieczna

Dziękujemy Kenjim Baheux, Jeremy Wagner, Pat Meenan, Philipowi Walton, Jeff Posnick i Cheney Tsai za ich recenzje.