Wczytywanie JavaScriptu innej firmy

Arthur Evans

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;

przykład umieszczenia filmu z YouTube
Przykład umieszczenia filmu z YouTube na stronie za pomocą tego kodu.
<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 InsightsWebPageTest. 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.

Widok kaskadowy z webpagetest pokazujący rzeczywistą witrynę w porównaniu z czasem poświęconym na wczytywanie skryptów śledzenia
Wczytywanie skryptów na tej stronie trwa dłużej niż sama strona.

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ń:

podział treści według domeny (pierwsze wyświetlenie);
Pokazuje odsetek żądań i bajtów dla każdego źródła zewnętrznego.
Wykresy z podziałem na domeny pokazują, ile treści na stronie pochodzi od osób trzecich.

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.

Lighthouse obsługuje sprawdzanie i analizowanie skryptów
Audyt czasu uruchamiania pokazuje, które skrypty ładują się najdłużej.

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.

Lighthouse pokazuje obsługę dużych danych sieciowych
Sprawdzenie danych 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. 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.

Blokowanie adresów URL żądań w panelu sieci w Narzędziach deweloperskich
Zablokuj poszczególne żądania sieci, aby sprawdzić, jak zachowuje się Twoja strona bez nich.

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.
Panel skuteczności w Narzędziach dla deweloperów pokazujący widok od dołu pogrupowany według produktów (firm zewnętrznych)
Skrypty innych firm posortowane według produktu, zaczynając od tego, który ma najdłuższy czas 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.
  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.

Ustawienia zaawansowane WebPageTest < Blokuj.
Wyświetla obszar tekstowy do określenia domen do zablokowania.
W tym panelu podaj listę domen, które chcesz zablokować.

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.
WebPageTest wyświetla opcję porównywania, która umożliwia porównywanie 2 raportów
Wybierz wyniki testu obciążenia do porównania.

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.

Film WebPageTest pokazujący wpływ wczytywania witryny z wyłączonymi i bez wyłączonych plików cookie innych firm
Wpływ blokowania zasobów innych firm – artykuł Using WebPageTest To Measure The Impact Of Third-Party Tags (po angielsku) autorstwa Andy’ego Daviesa.

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

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.

Ustawienia zaawansowane WebPageTest > SPOF > hosty, które mają się nie powieść
Użyj funkcji testowania SPOF, aby symulować awarię określonych domen.

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ę.

Ilustracja pokazująca zasoby, które są krytyczne dla treści powyżej zagięcia, oraz te, które są mniej istotne i mogą być ładowane z opóźnieniem.
Możesz stosować leniwy sposób wczytywania zasobów, które użytkownik nie zobaczy od razu po załadowaniu strony.

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()

Ostrzeżenia w konsoli DevTools dotyczące naruszeń zasad w przypadku osadzenia kodu zewnętrznego za pomocą document.write()
Narzędzia deweloperskie w Chrome sygnalizują użycie 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().

Sprawdzona metoda: flagowanie w audytowaniu Lighthouse użycia funkcji document.write()
Raport Lighthouse pokazujący, które skrypty 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:

Dziękujemy za opinie Kenji Baheux, Jeremy Wagner, Pat Meenan, Philip Walton, Jeff Posnick i Cheney Tsai.