Wczytywanie JavaScriptu innej firmy

Addy Osmani

Arthur Evans

Jeśli kod został zoptymalizowany, ale witryna nadal ładuje się zbyt wolno, prawdopodobnie problemem są skrypty innych firm.

Skrypty innych firm udostępniają wiele przydatnych funkcji, które sprawiają, że internet staje się bardziej dynamiczny, interaktywny i połączony. Niektóre z nich mogą być nawet kluczowe dla działania Twojej witryny lub źródła przychodów. Korzystanie z nich wiąże się z ryzykiem:

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

Najlepiej jest mieć pewność, że skrypty innych firm nie wpływają na krytyczną ścieżkę renderowania witryny. W tym przewodniku opisujemy, jak znajdować i rozwiązywać problemy związane z wczytywaniem kodu JavaScript pochodzącego od osób trzecich oraz minimalizować zagrożenia dla użytkowników.

Co to są skrypty innych firm?

Skrypt JavaScript innej firmy często odnosi się do skryptów, które można umieszczać na dowolnej stronie bezpośrednio od zewnętrznego dostawcy. Przykłady:

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

• Osadzone odtwarzacze wideo (YouTube, Vimeo)

• Elementy iframe reklam

• Skrypty Analytics i danych

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

• biblioteki pomocnicze, takie jak biblioteki formatowania dat, animacji lub funkcjonalne;

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

Niestety, osadzanie skryptów innych firm oznacza, że często polegamy na ich szybkim działaniu i nie spowalnianiu naszych stron. Skrypty innych firm są częstą przyczyną spowolnienia działania spowodowanego przez zasoby, na które właściciel witryny nie ma wpływu. Obejmuje to te problemy:

• Wysyłanie zbyt wielu żądań sieciowych do wielu serwerów. Im więcej żądań musi wysłać witryna, tym dłużej może trwać jej wczytywanie.

• Wysyłanie zbyt dużej ilości kodu JavaScript, który zajmuje wątek główny. Zbyt dużo kodu JavaScript może blokować tworzenie DOM, co opóźnia renderowanie strony. Przetwarzanie i wykonywanie skryptów wymagające dużych zasobów procesora może opóźniać interakcje z użytkownikiem i spowodować szybsze zużycie baterii.

• Wysyłanie dużych, nie zoptymalizowanych 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 (SPOF), jeśli strona wczytuje skrypt bez ostrzeżenia.

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

• Niewystarczająca kompresja serwera powoduje wolne wczytywanie zasobów.

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

• Korzystanie ze starszych interfejsów API, które mogą negatywnie wpływać na wrażenia użytkowników, np. document.write().

• nadmiar elementów DOM lub kosztowne selektory CSS;

• Wstawianie wielu elementów zewnętrznych może prowadzić do wielokrotnego wczytywania różnych frameworków i bibliotek, co powoduje marnowanie zasobów i pogarsza istniejące problemy z wydajnością.

• Skrypty innych firm często wykorzystują techniki wklejania, które mogą blokować window.onload, jeśli ich serwery odpowiadają wolno, nawet jeśli wklejanie jest asynchroniczne lub opóźnione.

Możliwość rozwiązania problemów ze skryptami innych firm może zależeć od Twojej witryny i od tego, czy możesz skonfigurować sposób ładowania kodu innych firm. Na szczęście istnieje wiele rozwiązań i narzędzi, które umożliwiają wykrywanie i rozwiązywanie problemów z zasobami zewnętrznymi.

Jak zidentyfikować skrypt innej firmy na stronie?

Pierwszym krokiem do ich optymalizacji jest ich zidentyfikowanie w witrynie i ustalenie wpływu na skuteczność. 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. Te narzędzia wyświetlają szczegółowe informacje diagnostyczne, które mogą Ci powiedzieć, ile skryptów innych firm używa Twoja witryna i które z nich zajmują najwięcej czasu na wykonanie.

Widok kaskady w WebPageTest może pokazać wpływ intensywnego korzystania ze skryptów innych firm. Na poniższym obrazie pochodzącym z Tags Gone Wild widać przykładowy diagram żądań sieciowych wymaganych do wczytania głównej zawartości witryny, a nie skryptów marketingowych i śledzących.

Podział domen w WebPageTest może być też przydatny do zobrazowania, ile treści pochodzi z źródeł zewnętrznych. Dane te są podzielone na łączną liczbę bajtów i liczbę żądań:

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

Jeśli zauważysz, że skrypt powoduje problemy, sprawdź, do czego służy, i ustanów, czy Twoja witryna potrzebuje go do działania. W razie potrzeby przeprowadź test A/B, aby zrównoważyć postrzeganą wartość z jej wpływem na kluczowe wskaźniki zaangażowania użytkowników lub wydajności.

Audyt czasu uruchamiania Lighthouse

Audyt czasu uruchamiania JavaScriptu w Lighthouse wskazuje skrypty, które mają długi czas analizowania, kompilowania lub oceny. Pomoże Ci to zidentyfikować skrypty innych firm, które mocno obciążają procesor.

Audyty danych pakietu sieciowego Lighthouse

Audyt danych sieciowych w Lighthouse wykrywa żądania sieciowe, w tym żądania sieciowe innych firm, które wydłużają czas wczytywania strony i sprawiają, że użytkownicy zużywają więcej danych mobilnych, niż się spodziewali.

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. Aby to zrobić, możesz użyć blokowania żądań sieci, czyli funkcji, która pozwala mierzyć wpływ usuwania poszczególnych zasobów innych firm ze strony.

Aby włączyć blokowanie żądań, kliknij żądanie prawym przyciskiem myszy w panelu Sieć i wybierz Zablokuj adres URL żądania. W schowku DevTools pojawi się karta blokowania żądań, która pozwoli Ci zarządzać zablokowanymi żądaniami.

Panel wydajności w Narzędziach deweloperskich w Chrome

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

1. Kliknij Nagrywaj.
2. Załaduj stronę. Narzędzia dla programistów wyświetlają diagram kaskadowy przedstawiający, jak długo trwa wczytywanie witryny.
3. U dołu panelu Skuteczność kliknij Od dołu.
4. Kliknij Grupuj według produktu i posortuj skrypty zewnętrzne strony według czasu wczytywania.

Więcej informacji o analizowaniu wydajności wczytywania stron za pomocą Narzędzi deweloperskich w Chrome znajdziesz w artykule Pierwsze kroki w analizowaniu wydajności w czasie wykonywania.

Oto zalecany przez nas proces pomiaru wpływu skryptów innych firm:

1. W panelu Sieć możesz mierzyć czas wczytywania strony.
   • Aby emulować warunki rzeczywiste, zalecamy włączenie ograniczania przepustowości sieci i ograniczania przepustowości procesora. Użytkownicy prawdopodobnie nie mają szybkiego połączenia z internetem ani komputera z procesorem, który w warunkach laboratoryjnych zmniejsza wpływ drogich skryptów.
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 Narzędzi deweloperskich w Chrome).
3. Załaduj stronę ponownie i zmierz czas wczytywania.
   • Aby uzyskać dokładniejsze dane, warto zmierzyć 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ć Ci to zadanie, panel wydajności w DevTools obsługuje wiele nagrań.

Pomiar wpływu skryptów zewnętrznych za pomocą narzędzia WebPageTest

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

Zalecamy wykonanie tych czynności:

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

Na poniższym obrazie widać funkcję paska filmowego WebPageTest, która porównuje sekwencję wczytywania stron z aktywnymi i nieaktywnymi zasobami innych firm. 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 skuteczność strony.

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

• blockDomains przekazuje listę domen do zablokowania.
• blockDomainsExcept przejmuje listę domen i blokuje wszystko, co nie się na niej znajduje.

WebPageTest ma też kartę „Single Point of Failure” (SPOF), która umożliwia symulowanie przekroczenia limitu czasu lub całkowitego braku możliwości załadowania zasobu. W przeciwieństwie do blokowania domeny SPOF ma długi czas oczekiwania na zakończenie działania, co może być przydatne do testowania zachowania Twoich stron, gdy usługi innych firm są obciążone lub tymczasowo niedostępne.

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

Jeśli skrypty w ramkach iframe innych firm uruchamiają się długo, mogą blokować główny wątek i opóźniać inne zadania. Te długie zadania mogą powodować spowolnienie modułów obsługi zdarzeń lub wypadanie klatek, co pogarsza wrażenia użytkownika.

Aby wykrywać długie zadania w monitorowaniu użytkowników rzeczywistych (RUM), użyj interfejsu JavaScript PerformanceObserver API, aby obserwować wpisy longtask. Te wpisy zawierają właściwość atrybucji, za pomocą której możesz określić, który kontekst ramki spowodował długie zadanie.

Ten kod rejestruje w konsoli longtask wpisów, w tym jeden dla „drogiego” iframe’a:

<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 poście Optymalizacja działania stron pod kątem użytkownika.

Jak efektywnie wczytywać skrypt zewnętrzny?

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

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

Użyj właściwości async lub defer

Wykonanie kodu JavaScript blokuje parsowanie. Gdy przeglądarka napotka skrypt, musi wstrzymać tworzenie DOM, przekazać skrypt do modułu JavaScript i zezwolić na jego wykonanie, a dopiero potem kontynuować tworzenie DOM.

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

• async powoduje, że przeglądarka pobiera skrypt asynchronicznie, a zarazem kontynuuje analizowanie dokumentu HTML. Gdy skrypt zakończy pobieranie, analizowanie zostanie zablokowane na czas jego wykonywania.

• defer powoduje, że przeglądarka pobiera skrypt asynchronicznie, a zarazem kontynuuje analizowanie dokumentu HTML, a potem czeka na uruchomienie skryptu, aż do zakończenia analizowania dokumentu.

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

Jeśli Twoim głównym celem jest wydajność, zalecamy dodanie asynchronicznych skryptów dopiero po załadowaniu kluczowych treści strony. Nie zalecamy używania async w przypadku niezbędnych bibliotek, takich jak jQuery.

Niektóre skrypty muszą być wczytane bez async ani defer, zwłaszcza te, które są kluczowymi elementami witryny. Obejmują one biblioteki interfejsu użytkownika lub frameworki sieci dystrybucji treści (CDN), bez których Twoja witryna nie może działać.

Inne skrypty nie działają, jeśli są ładowane asynchronicznie. Sprawdź dokumentację skryptów, których używasz, i zastąp skrypty, których nie można wczytywać asynchronicznie, alternatywnymi skryptami, które można wczytywać asynchronicznie. 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 wczytanie w sposób asynchroniczny nie zapobiegnie spowolnieniu wczytywania strony.

Korzystanie z wskazówek dotyczących zasobów w celu skrócenia czasu konfiguracji połączenia

Nawiązanie połączeń z zewnętrznych źródeł może zająć dużo czasu, zwłaszcza w wolnych sieciach, ponieważ żądania sieciowe mają wiele złożonych komponentów, w tym wyszukiwania DNS i przekierowania. Możesz użyć 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 czemu pozostała część żądania sieci może przebiegać szybciej:

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

Jeśli domena zewnętrzna, z którą się łączysz, używa protokołu HTTPS, możesz też użyć , który wykonuje zapytania DNS i rozwiązuje dwukierunkowe połączenia TCP oraz 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 „sandbox” z elementem iframe

Jeśli skrypt innej firmy jest wczytywany bezpośrednio do elementu iframe, nie blokuje wykonania strony głównej. AMP używa tego podejścia, aby kod JavaScript nie był częścią ścieżki krytycznej. Pamiętaj, że to podejście nadal blokuje zdarzenie onload, więc staraj się nie łączyć funkcji krytycznych z zdarzeniem onload.

Chrome obsługuje też zasady dotyczące uprawnień (dawniej zasady dotyczące funkcji), czyli zestaw zasad, które umożliwiają deweloperowi wybiórcze wyłączanie dostępu do niektórych funkcji przeglądarki. Możesz użyć tej opcji, aby zapobiec niepożądanym działaniom w witrynie wywoływanym przez treści pochodzące od innych firm.

Hostowanie skryptów innych firm

Jeśli chcesz mieć większą kontrolę nad sposobem wczytywania ważnego skryptu, np. aby skrócić czas DNS-a lub poprawić nagłówki buforowania HTTP, możesz go hostować samodzielnie.

Jednak hosting własny wiąże się z własnymi problemami, zwłaszcza w przypadku aktualizacji skryptów. Skrypty hostowane samodzielnie nie będą automatycznie aktualizowane o zmiany w interfejsie API ani poprawki 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ż zapisać w pamięci podręcznej skrypty innych firm za pomocą usług dla programistów, aby mieć większą kontrolę nad częstotliwością pobierania skryptów z sieci. Możesz też używać usług workera do tworzenia strategii wczytywania, które ograniczają nieistotne żądania pochodzące od innych firm do momentu, gdy strona osiągnie kluczowy moment dla użytkownika.

Testy A/B z udziałem mniejszych próbek użytkowników

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

Jednak z powodu specyfiki testów A/B renderowanie jest opóźniane, aby można było zdecydować, który eksperyment ma być aktywny. Kod JavaScript jest często używany do sprawdzania, czy któryś z użytkowników należy do eksperymentu z testem A/B, a następnie do włączania odpowiedniego wariantu. Ten proces może pogorszyć wrażenia nawet w przypadku użytkowników, którzy nie biorą udziału w eksperymencie.

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

Leniwe ładowanie zasobów z innych witryn

Umieszczone na stronie zasoby zewnętrzne, np. reklamy i filmy, mogą znacznie spowolnić wczytywanie strony, jeśli są źle skonstruowane. Leniwe ładowanie może służyć do wczytywania zasobów 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ż leniwie wczytywać treści innych firm po wczytaniu głównej strony, ale zanim użytkownik będzie mógł z nią wejść w interakcję.

Zachowaj ostrożność podczas leniwego wczytywania zasobów, ponieważ często wiąże się to z kodem JavaScript, na który mogą mieć wpływ niestabilne połączenia z internetem.

W oficjalnej dokumentacji DoubleClick znajdziesz wskazówki dotyczące leniwego wczytywania reklam.

Skuteczne ładowanie opóźnione za pomocą Intersection Observer

Dotychczas metody wykrywania, czy element jest widoczny w widżecie na potrzeby ładowania opóźnionego, 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 potem używają interfejsów API DOM, takich jak getBoundingClientRect(), aby obliczyć, gdzie znajdują się elementy względem widoku.

IntersectionObserver to interfejs API przeglądarki, który umożliwia właścicielom stron skuteczne wykrywanie, kiedy obserwowany element wchodzi do widocznego obszaru przeglądarki lub go opuszcza. LazySizes obsługuje też opcjonalnie interfejs IntersectionObserver.

Analiza leniwego ładowania

Jeśli opóźnisz wczytywanie skryptów analitycznych na zbyt długo, możesz stracić cenne dane analityczne. Na szczęście istnieją strategie umożliwiające inicjowanie usług analitycznych w trybie opóźnionym przy jednoczesnym zachowaniu wczesnych danych o wczytywaniu strony.

W artykule w 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 przeze mnie witrynie) opisano jedną z takich strategii dotyczących Google Analytics.

Bezpieczne wczytywanie skryptów zewnętrznych

W tej sekcji znajdziesz wskazówki dotyczące ładowania skryptów innych firm w jak najbezpieczniejszy sposób.

Unikaj document.write()

Skrypty innych firm, zwłaszcza w przypadku starszych usług, czasami używają komponentu document.write() do wstawiania i wczytywania skryptów. Jest to problem, ponieważ document.write() działa niekonsekwentnie, a jego błędy są trudne do debugowania.

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

Jeśli pojawi się ten błąd, możesz sprawdzić, czy w witrynie nie jest używany document.write(), szukając nagłówków HTTP wysłanych do przeglądarki. Lighthouse może też zwrócić uwagę na skrypty innych firm, które nadal używają document.write().

Ostrożnie używaj Menedżerów tagów

Tag to fragment kodu, który umożliwia zespołom ds. marketingu cyfrowego zbieranie danych, ustawianie plików cookie lub integrowanie w witrynie treści pochodzących od innych firm, np. widżetów mediów społecznościowych. Te tagi dodają do strony żądania sieci, zależności od JavaScriptu i inne zasoby, które mogą wpływać na jej działanie. Wraz z dodatkiem kolejnych tagów minimalizowanie tego wpływu na użytkowników staje się trudniejsze.

Aby zapewnić szybkie wczytywanie stron, zalecamy używanie menedżera tagów, np. Menedżera tagów Google (MTG). GTM umożliwia wdrażanie tagów asynchronicznie, dzięki czemu nie blokują one sobie nawzajem wczytywania, zmniejsza liczbę wywołań sieci, których potrzebuje przeglądarka do wykonania tagów, oraz zbiera dane tagów w interfejsie warstwy danych.

Ryzyko związane z korzystaniem z menedżera tagów

Menedżery tagów zostały zaprojektowane tak, aby usprawnić wczytywanie strony, ale ich nieostrożne używanie może ją spowolnić. Może się to zdarzyć na 2 sposoby:

• 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ż byłoby to konieczne, a kod ma mniejszą zdolność do szybkiej reakcji na zdarzenia.
• Każdy, kto ma odpowiednie poświadczenia i dostęp, może dodać kod JavaScriptu do menedżera tagów. Może to nie tylko zwiększyć liczbę kosztownych żądań sieciowych potrzebnych do załadowania strony, ale też stworzyć zagrożenia dla bezpieczeństwa i spowodować inne problemy z wydajnością z powodu niepotrzebnych skryptów. 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ć na różne sposoby, które mogą nieoczekiwanie zepsuć stronę:

• Skrypty wczytujące zależności JavaScript mogą zanieczyszczać zakres globalny kodem, który źle współdziała z Twoim kodem.
• Nieoczekiwane aktualizacje mogą spowodować zmiany w funkcjonalności.
• Kod zewnętrzny może być modyfikowany w trakcie testowania i wdrażania strony, aby zachowywał się inaczej w trakcie testowania i wdrażania.

Zalecamy regularne sprawdzanie wczytywanych skryptów innych firm pod kątem nieuczciwych działań. Aby zapewnić bezpieczeństwo strony, możesz też wdrożyć samotestowanie, integralność zasobów podrzędnych i bezpieczną transmisję kodu stron trzecich.

Strategie zapobiegania

Oto kilka ogólnych strategii minimalizowania wpływu 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 stron trzecich korzystających z protokołu HTTP. Więcej informacji znajdziesz w artykule Treści mieszane.

• Sandboxing: rozważ uruchomienie skryptów innych firm w ramach iframe z atrybutem sandbox, aby ograniczyć działania, które mogą wykonywać te skrypty.

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

Poniżej przedstawiamy przykład użycia dyrektywy script-src w regułach CSP, aby określić dozwolone źródła kodu JavaScript 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 firm zewnętrznych, przeczytaj te artykuły:

• Skuteczność i odporność: testy obciążeniowe firm zewnętrznych
• Dodawanie interakcji za pomocą JavaScriptu
• Potencjalne zagrożenia związane ze skryptami innych firm
• Jak skrypty innych firm mogą być wydajnymi obywatelami internetu
• Dlaczego szybkość ma znaczenie – sztuczki z CSS
• Paradoks łańcucha dostawy kodu JavaScript: SRI, CSP i zaufanie do bibliotek innych firm
• Usługa porównywania cen w usłudze zewnętrznej nie jest bezpieczna

Dziękujemy Kenji Baheux, Jeremy’emu Wagnerowi, Patowi Meenanowi, Philipowi Waltonowi, Jeffowi Posnickowi i Cheney Tsai za opinie.