Wczytywanie JavaScriptu innej firmy

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

Skrypty innych firm zapewniają wiele przydatnych funkcji, które sprawiają, że internet jest 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 innych firm i minimalizować zagrożenia dla użytkowników.

Czym 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 dane

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

• biblioteki pomocnicze, takie jak biblioteki do formatowania dat, animacji lub funkcji;

<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. Do takich problemów należą:

• 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 interfejsu 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ć też 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;

• Umieszczanie wielu elementów zewnętrznych może prowadzić do wielokrotnego wczytywania różnych frameworków i bibliotek, co powoduje marnowanie zasobów i pogłębia 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 ocena wpływu na wydajność. 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. Może to pomóc w zidentyfikowaniu skryptów 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 umożliwia zarządzanie 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 ponownie stronę 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ą 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 tym obrazie widać funkcję paska filmowego WebPageTest, która porównuje sekwencje 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 niepowodzenia wczytywania 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 działania modułów obsługi zdarzeń lub utraty 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:

<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 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ć wydajność, korzystając z kilku opcji:

• Aby uniknąć blokowania analizowania dokumentu, wczytaj skrypt za pomocą atrybutu async lub defer.
• Jeśli serwer innej firmy działa wolno, rozważ samodzielne hostowanie skryptu.
• Jeśli skrypt nie wnosi wyraźnej wartości do 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, które hostują 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 w tym samym czasie 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 asynchronicznie 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 innej firmy, z którą się łączysz, używa protokołu HTTPS, możesz też użyć parametru , 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 stosuje to podejście, 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 odpowiedzi DNS 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 workerów 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 na podstawie danych analitycznych określa, która wersja zapewnia lepszy współczynnik konwersji.

Jednak z powodu specyfikicznego działania 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, takie jak 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 treści 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ą interfejsu 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 DOM, takich jak getBoundingClientRect(), aby obliczyć położenie elementów względem widoku.

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

Analiza leniwego ładowania

Jeśli wczytywanie skryptów analitycznych opóźni się zbytnio, 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 Konfiguracja Google Analytics, której używam w każdej tworzonej przeze mnie witrynie znajdziesz 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ą skryptów document.write()do wstrzykiwania 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 Chrome DevTools wysyłają do konsoli ostrzeżenia o problematycznym użyciu tych funkcji: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 wysył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 treści zewnętrznych, np. widżetów mediów społecznościowych, w witrynie. 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 korzystanie z 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 wczytywania się nawzajem, 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ć w takie 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ż jest to konieczne, a kod ma mniejszą zdolność do szybkiej reakcji na zdarzenia.
• Każdy, kto ma 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ż stwarzać zagrożenia dla bezpieczeństwa i spowodować 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ą działać na różne sposoby, powodując nieoczekiwane błędy na stronie:

• 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 podczas 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 za opinie Kenji Baheux, Jeremy Wagner, Pat Meenan, Philip Walton, Jeff Posnick i Cheney Tsai.