Drittanbieter-JavaScript laden

Wenn Sie Ihren Code optimiert haben, Ihre Website aber immer noch zu langsam lädt, liegt das wahrscheinlich an Drittanbieter-Skripts.

Drittanbieter-Skripts bieten eine Vielzahl nützlicher Funktionen, die das Web dynamischer, interaktiver und miteinander verbinden. Manche davon sind vielleicht sogar entscheidend für die Funktionalität oder die Einnahmequelle Ihrer Website. Ihre Verwendung ist jedoch riskant:

• Sie können die Leistung Ihrer Website beeinträchtigen.
• Sie können Datenschutz- oder Sicherheitsprobleme verursachen.
• Sie können unvorhersehbar sein und ihr Verhalten kann unbeabsichtigte Folgen haben.

Idealerweise sollten Sie dafür sorgen, dass Drittanbieter-Skripts keine Auswirkungen auf den kritischen Rendering-Pfad Ihrer Website haben. In diesem Leitfaden zeigen wir Ihnen, wie Sie Probleme im Zusammenhang mit dem Laden von Drittanbieter-JavaScript finden und beheben sowie die Risiken für Ihre Nutzer minimieren.

Was sind Drittanbieter-Skripts?

Bei JavaScript von Drittanbietern handelt es sich häufig um Skripts, die direkt von einem Drittanbieter in jede Website eingebettet werden können. Beispiele:

• Teilen-Schaltflächen für soziale Netzwerke (Facebook, X, LinkedIn, Mastodon)

• Eingebettete Videoplayer (YouTube, Vimeo)

• iFrames für Werbung

• Skripts für Analysen und Messwerte

• Skripts für A/B-Tests für Tests

• Hilfsbibliotheken, z. B. Datumsformatierung, Animationen oder Funktionsbibliotheken

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

Leider bedeutet das Einbetten von Drittanbieterskripts, dass wir uns oft darauf verlassen, dass sie schnell ausgeführt werden und unsere Seiten nicht verlangsamt. Drittanbieter-Skripts sind eine häufige Ursache für Leistungsverlangsamungen, die durch Ressourcen verursacht werden, die außerhalb der Kontrolle des Websiteinhabers liegen. Dazu gehören unter anderem folgende Probleme:

• Es werden zu viele Netzwerkanfragen an mehrere Server gesendet. Je mehr Anfragen eine Website stellen muss, desto länger kann das Laden dauern.

• Es wird zu viel JavaScript gesendet, das den Hauptthread nicht auslastet. Zu viel JavaScript kann die DOM-Erstellung blockieren, wodurch das Rendern der Seite verzögert wird. CPU-intensives Skript-Parsing und -Ausführung können die Nutzerinteraktion verzögern und zu einer schnellen Akkuentladung führen.

• Das Senden großer, nicht optimierter Bilddateien oder Videos kann Daten verbrauchen und Kosten für Nutzer verursachen.

• Sicherheitsprobleme, die als Single-Point-of-Failure (SPOF) auftreten können, wenn Ihre Seite ohne Vorsicht ein Skript lädt.

• Unzureichendes HTTP-Caching, das den Browser dazu zwingt, weitere Netzwerkanfragen zu senden, um Ressourcen abzurufen.

• Eine unzureichende Serverkomprimierung führt dazu, dass die Ressourcen langsam geladen werden.

• Anzeige von Inhalten wird blockiert, bis die Verarbeitung abgeschlossen ist. Dies kann auch bei asynchronen A/B-Testskripts der Fall sein.

• Verwendung von Legacy-APIs, die bekanntermaßen die Nutzerfreundlichkeit beeinträchtigen, z. B. document.write()

• Übermäßig viele DOM-Elemente oder teure CSS-Selektoren

• Das Einbinden mehrerer Einbettungen von Drittanbietern kann dazu führen, dass mehrere Frameworks und Bibliotheken mehrmals abgerufen werden, was Ressourcen verschwendet und bestehende Leistungsprobleme noch verschlimmert.

• Skripte von Drittanbietern verwenden häufig Einbettungstechniken, die window.onload blockieren können, wenn ihre Server langsam reagieren, selbst wenn die Einbettung asynchron oder verzögert reagiert.

Ihre Fähigkeit, Probleme mit Drittanbieter-Skripts zu beheben, hängt von Ihrer Website und Ihrer Fähigkeit ab, zu konfigurieren, wie Sie Drittanbietercode laden. Glücklicherweise gibt es eine Reihe von Lösungen und Tools, um Probleme mit Ressourcen von Drittanbietern zu finden und zu beheben.

Woran erkennst du Drittanbieter-Skripts auf einer Seite?

Der erste Schritt zur Optimierung ist das Identifizieren von Drittanbieter-Skripts auf Ihrer Website und das Ermitteln ihrer Auswirkungen auf die Leistung. Wir empfehlen, kostenlose Tools zum Testen der Webgeschwindigkeit wie Chrome-Entwicklertools, PageSpeed Insights und WebPageTest zu verwenden, um kostspielige Skripts zu ermitteln. Diese Tools liefern umfassende Diagnoseinformationen, die Aufschluss darüber geben, wie viele Drittanbieter-Skripts Ihre Website verwendet und deren Ausführung am längsten dauert.

Die Wasserfallansicht von WebPageTest kann die Auswirkungen einer intensiven Verwendung von Drittanbieter-Skripts hervorheben. Das folgende Bild von Tags Gone Wild zeigt ein Beispieldiagramm der Netzwerkanfragen, die zum Laden des Hauptinhalts einer Website erforderlich sind, anstatt die Tracking- und Marketing-Skripts.

Mithilfe der Domainaufschlüsselung von WebPageTest lässt sich visualisieren, wie viele Inhalte von Drittanbietern stammen. Es schlüsselt dies sowohl nach der Gesamtzahl der Byte als auch nach der Anzahl der Anfragen auf:

Wie kann ich die Auswirkungen von Drittanbieter-Skripts auf meine Seite messen?

Wenn Sie feststellen, dass ein Skript Probleme verursacht, finden Sie heraus, was das Skript bewirkt und ob Ihre Website es für das Funktionieren benötigt. Führe gegebenenfalls einen A/B-Test durch, um den wahrgenommenen Wert und dessen Auswirkungen auf wichtige Nutzerinteraktionen oder Leistungsmesswerte in Einklang zu bringen.

Audit der Lighthouse-Startzeit

Bei der Prüfung der JavaScript-Bootzeit in Lighthouse werden Scripts hervorgehoben, bei denen das Parsen, Kompilieren oder Auswerten kostspielig ist. So können Sie CPU-intensive Skripts von Drittanbietern identifizieren.

Audit der Lighthouse-Netzwerknutzlasten

Das Audit der Netzwerknutzlasten in Lighthouse identifiziert Netzwerkanfragen – einschließlich Netzwerkanfragen von Drittanbietern, die die Seitenladezeit verlangsamen und dazu führen, dass Nutzer mehr als erwartet für mobile Daten ausgeben.

Blockierung von Netzwerkanfragen für Chrome-Entwicklertools

Mit den Chrome-Entwicklertools können Sie sehen, wie sich Ihre Seite verhält, wenn ein bestimmtes Skript, ein Stylesheet oder eine andere Ressource nicht verfügbar ist. Möglich wird dies durch die Blockierung von Netzwerkanfragen. Mit dieser Funktion können Sie die Auswirkungen der Entfernung einzelner Drittanbieterressourcen von Ihrer Seite messen.

Klicken Sie im Steuerfeld „Netzwerk“ mit der rechten Maustaste auf eine Anfrage und wählen Sie Anfrage-URL blockieren aus, um die Blockierung von Anfragen zu aktivieren. In der Entwicklertools-Leiste wird dann ein Tab zum Blockieren von Anfragen angezeigt, auf dem du verwalten kannst, welche Anfragen blockiert wurden.

Leistungsbereich für Chrome-Entwicklertools

Im Bereich „Leistung“ in den Chrome-Entwicklertools lassen sich Probleme mit der Webleistung Ihrer Seite erkennen.

1. Klicken Sie auf Aufzeichnen.
2. Laden Sie die Seite. Die Entwicklertools zeigen ein Wasserfalldiagramm, das darstellt, wie Ihre Website die Ladezeit verbringt.
3. Klicken Sie unten im Steuerfeld „Leistung“ auf Bottom-up.
4. Klicken Sie auf Nach Produkt gruppieren und sortieren Sie die Drittanbieter-Skripts Ihrer Seite nach Ladezeit.

Weitere Informationen zur Verwendung der Chrome-Entwicklertools zum Analysieren der Seitenladeleistung finden Sie unter Erste Schritte bei der Analyse der Laufzeitleistung.

Der folgende Workflow wird empfohlen, um die Auswirkungen von Drittanbieter-Skripts zu messen:

1. Im Steuerfeld „Netzwerk“ können Sie messen, wie lange das Laden Ihrer Seite dauert.
   • Wenn Sie reale Bedingungen emulieren möchten, empfehlen wir, die Netzwerkdrosselung und die CPU-Drosselung zu aktivieren. Es ist unwahrscheinlich, dass Ihre Nutzer die schnellen Netzwerkverbindungen und Desktop-Hardware haben, die die Auswirkungen teurer Skripts unter Laborbedingungen reduzieren.
2. Blockieren Sie die URLs oder Domains, die für Drittanbieter-Scripts verantwortlich sind, die Ihrer Meinung nach ein Problem darstellen. Eine Anleitung zum Identifizieren kostspieliger Skripts finden Sie im Leistungsbereich der Chrome-Entwicklertools.
3. Aktualisieren Sie die Seite und messen Sie die Ladezeit noch einmal.
   • Um genauere Daten zu erhalten, empfiehlt es sich, die Ladezeit mindestens dreimal zu messen. Dadurch werden einige Drittanbieter-Skripts berücksichtigt, die bei jedem Seitenaufbau unterschiedliche Ressourcen abrufen. Zu diesem Zweck unterstützt der Leistungsbereich der Entwicklertools mehrere Aufzeichnungen.

Auswirkung von Drittanbieter-Skripts mit WebPageTest messen

Mit WebPageTest kannst du unter Erweiterte Einstellungen > Blockieren das Laden einzelner Anfragen verhindern und so ihre Auswirkungen messen. Mit dieser Funktion können Sie eine Liste von Domains angeben, die blockiert werden sollen, z. B. Werbedomains.

Wir empfehlen den folgenden Workflow, um diese Funktion zu nutzen:

1. Seite testen, ohne Dritte zu blockieren.
2. Wiederhole den Test bei einigen blockierten Drittanbietern.
3. Wählen Sie die beiden Ergebnisse aus Ihrem Testverlauf aus.
4. Klicken Sie auf Vergleichen.

Die folgende Abbildung zeigt die Filmstreifen-Funktion von WebPageTest, in der die Ladesequenzen für Seiten mit und ohne aktive Drittanbieterressourcen verglichen werden. Wir empfehlen, diese Option für Tests einzelner Drittanbieterursprünge zu aktivieren, um festzustellen, welche Domains sich am meisten auf die Leistung deiner Seite auswirken.

WebPageTest unterstützt außerdem zwei Befehle zum Blockieren von Domains auf DNS-Ebene:

• blockDomains erstellt eine Liste der zu blockierenden Domains.
• Mit blockDomainsExcept werden alle Domains blockiert, die nicht in der Liste enthalten sind.

WebPageTest hat auch einen Single Point of Failure (SPOF)-Tab, mit dem Sie ein Zeitlimit oder einen vollständigen Ausfall beim Laden einer Ressource simulieren können. Im Gegensatz zur Domainblockierung läuft beim SPOF nur langsam eine Zeitüberschreitung ab. Damit können Sie testen, wie sich Ihre Seiten verhalten, wenn Drittanbieterdienste stark ausgelastet oder vorübergehend nicht verfügbar sind.

Teure iFrames mit langen Aufgaben erkennen

Wenn die Ausführung von Skripts in Drittanbieter-iFrames lange dauert, können sie den Hauptthread blockieren und andere Aufgaben verzögern. Diese langen Aufgaben können dazu führen, dass Event-Handler langsam arbeiten oder Frames ausfallen, was die Nutzererfahrung verschlechtert.

Wenn Sie lange Aufgaben für das Real User Monitoring (RUM) erkennen möchten, verwenden Sie die JavaScript PerformanceObserver API, um Longtask-Einträge zu beobachten. Diese Einträge enthalten eine Attributionseigenschaft, mit der Sie ermitteln können, welcher Frame-Kontext die lange Aufgabe verursacht hat.

Mit dem folgenden Code werden longtask-Einträge in der Konsole protokolliert, darunter einer für einen "teure" 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>

Weitere Informationen zum Überwachen langer Aufgaben finden Sie unter Nutzerorientierte Leistungsmesswerte.

Wie werden Drittanbieter-Skripts effizient geladen?

Wenn ein Drittanbieterskript den Seitenaufbau verlangsamt, gibt es mehrere Möglichkeiten, die Leistung zu verbessern:

• Laden Sie das Skript mit dem Attribut async oder defer, um das Parsen von Dokumenten nicht zu blockieren.
• Wenn der Server des Drittanbieters langsam ist, sollten Sie das Skript eventuell selbst hosten.
• Wenn das Skript Ihrer Website keinen eindeutigen Mehrwert bietet, entfernen Sie es.
• Verwenden Sie Ressourcenhinweise wie <link rel=preconnect> oder <link rel=dns-prefetch>, um einen DNS-Lookup für Domains auszuführen, in denen Skripts von Drittanbietern gehostet werden.

Verwenden Sie async oder defer.

Die JavaScript-Ausführung blockiert den Parser. Wenn im Browser ein Skript erkannt wird, muss er die DOM-Erstellung anhalten, an die JavaScript-Engine übergeben und die Ausführung des Skripts zulassen, bevor mit der DOM-Erstellung fortgefahren wird.

Die Attribute async und defer ändern dieses Verhalten so:

• async bewirkt, dass der Browser das Skript asynchron herunterlädt, während das HTML-Dokument weiter geparst wird. Wenn das Skript den Download abgeschlossen hat, wird das Parsen blockiert, während es ausgeführt wird.

• defer bewirkt, dass der Browser das Skript asynchron herunterlädt, während das HTML-Dokument weiter geparst wird, und dann mit der Ausführung des Skripts wartet, bis das Parsen des Dokuments abgeschlossen ist.

Verwenden Sie für Drittanbieterskripts immer async oder defer, es sei denn, das Skript ist für den kritischen Rendering-Pfad erforderlich. Verwenden Sie async, wenn es wichtig ist, dass das Skript früher im Ladevorgang ausgeführt wird, z. B. bei einigen Analyseskripts. Verwenden Sie defer für weniger wichtige Ressourcen, z. B. für Videos, die weiter unten auf der Seite gerendert werden, als der Nutzer anfangs sehen wird.

Wenn Ihnen vor allem die Leistung wichtig ist, sollten Sie mit dem Hinzufügen asynchroner Skripts warten, bis die kritischen Inhalte Ihrer Seite geladen wurden. Wir raten davon ab, async für wichtige Bibliotheken wie jQuery zu verwenden.

Einige Skripts müssen ohne async oder defer geladen werden, insbesondere die, die wichtige Bereiche Ihrer Website sind. Dazu gehören UI-Bibliotheken oder Content Delivery Network-Frameworks (CDNs), ohne die Ihre Website nicht funktionieren kann.

Andere Skripts funktionieren einfach nicht, wenn sie asynchron geladen werden. Sehen Sie in der Dokumentation nach, welche Skripts Sie verwenden, und ersetzen Sie alle Skripts, die nicht asynchron geladen werden können, durch Alternativen. Beachten Sie, dass einige Drittanbieter empfehlen, ihre Skripts synchron auszuführen, auch wenn sie asynchron funktionieren würden.

Denk daran, dass async nicht alles korrigiert. Wenn Ihre Seite eine große Anzahl von Skripts enthält, z. B. Tracking-Skripts zu Werbezwecken, wird durch das asynchrone Laden nicht verhindert, dass sie den Seitenaufbau verlangsamen.

Mit Ressourcenhinweisen die Verbindungseinrichtungszeit reduzieren

Das Herstellen von Verbindungen zu Drittanbieterursprüngen kann insbesondere bei langsamen Netzwerken lange dauern, da Netzwerkanfragen mehrere komplexe Komponenten wie DNS-Lookups und Weiterleitungen umfassen. Mit Ressourcenhinweisen wie können Sie frühzeitig beim Laden der Seite DNS-Lookups für Domains durchführen, in denen Drittanbieterskripts gehostet werden. So kann der Rest der Netzwerkanfrage später schneller verarbeitet werden:

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

Wenn die Drittanbieterdomain, zu der Sie eine Verbindung herstellen, HTTPS verwendet, können Sie auch verwenden. Damit werden DNS-Lookups durchgeführt und TCP-Roundtrips aufgelöst und TLS-Verhandlungen verarbeitet. Diese anderen Schritte können sehr langsam sein, da sie die Überprüfung von SSL-Zertifikaten erfordern. Das Vorverbinden kann also die Ladezeit erheblich verkürzen.

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

"Sandbox"-Skripts mit einem iFrame

Wenn Sie ein Drittanbieterskript direkt in einen iFrame laden, wird die Ausführung der Hauptseite nicht blockiert. AMP nutzt diesen Ansatz, um JavaScript von dem kritischen Pfad fernzuhalten. Dabei wird das onload-Ereignis weiterhin blockiert. Fügen Sie onload also keine wichtigen Features hinzu.

Chrome unterstützt auch die Berechtigungsrichtlinie (früher „Funktionsrichtlinie“). Mit diesen Richtlinien können Entwickler den Zugriff auf bestimmte Browserfunktionen selektiv deaktivieren. Damit können Sie verhindern, dass Drittanbieterinhalte unerwünschtes Verhalten auf einer Website zeigen.

Drittanbieter-Scripts selbst hosten

Wenn Sie mehr Kontrolle darüber haben möchten, wie ein kritisches Skript geladen wird, um z. B. die DNS-Zeit zu reduzieren oder die HTTP-Caching-Header zu verbessern, können Sie es möglicherweise selbst hosten.

Das Selbsthosting bringt jedoch auch Probleme mit sich, insbesondere bei der Aktualisierung von Skripts. Selbst gehostete Skripts erhalten keine automatischen Updates für API-Änderungen oder Sicherheitsupdates. Dies kann zu Umsatzverlusten oder Sicherheitsproblemen führen, bis Sie Ihr Skript manuell aktualisieren können.

Alternativ können Sie Skripts von Drittanbietern mithilfe von Service Workern im Cache speichern, um besser steuern zu können, wie oft Skripts aus dem Netzwerk abgerufen werden. Sie können mit Service Workern auch Ladestrategien erstellen, die unwesentliche Anfragen von Drittanbietern drosseln, bis Ihre Seite einen wichtigen Nutzermoment erreicht.

A/B-Tests für kleinere Stichproben von Nutzern durchführen

A/B-Tests (oder Split-Tests) sind ein Verfahren zum Experimentieren mit zwei Versionen einer Seite, um die Nutzererfahrung und das Verhalten zu analysieren. Die Seitenversionen werden verschiedenen Stichproben der Zugriffe auf Ihre Website zur Verfügung gestellt. Außerdem wird anhand der Analysen ermittelt, welche Version eine bessere Conversion-Rate bietet.

A/B-Tests verzögern jedoch das Rendering, um zu entscheiden, welcher Test aktiv sein muss. JavaScript wird häufig verwendet, um zu prüfen, ob Nutzer zu einem A/B-Test gehören, und dann die richtige Variante zu aktivieren. Dadurch kann sich die Nutzerfreundlichkeit auch für Nutzer verschlechtern, die nicht am Test teilnehmen.

Um das Seiten-Rendering zu beschleunigen, empfehlen wir, eure A/B-Testskripts an eine kleinere Stichprobe der Nutzer zu senden und den Code auszuführen, der festlegt, welche Version der Seite serverseitig angezeigt wird.

Lazy Loading von Ressourcen von Drittanbietern

Eingebettete Ressourcen von Drittanbietern wie Anzeigen und Videos können bei unzureichender Erstellung erheblich zu einer verlangsamten Seitengeschwindigkeit beitragen. Lazy Loading kann verwendet werden, um eingebettete Ressourcen nur bei Bedarf zu laden. So kann beispielsweise gewartet werden, bis Anzeigen in der Fußzeile der Seite ausgeliefert werden, bis der Nutzer weit genug scrollt, um sie zu sehen. Sie können auch Drittanbieterinhalte per Lazy Loading laden, nachdem der Inhalt der Hauptseite geladen wurde, bevor der Nutzer aber mit der Seite interagiert.

Seien Sie beim Lazy Loading von Ressourcen vorsichtig, da dieser häufig JavaScript-Code beinhaltet, der von unzuverlässigen Netzwerkverbindungen beeinträchtigt werden kann.

Eine Anleitung zum Lazy Loading von Anzeigen finden Sie in der offiziellen Dokumentation von DoubleClick.

Effizientes Lazy Loading mit Intersection Observer

Methoden, mit denen sich feststellen lässt, ob ein Element im Darstellungsbereich sichtbar ist, waren in der Vergangenheit fehleranfällig und verlangsamen den Browser häufig. Diese ineffizienten Methoden warten häufig auf scroll- oder resize-Ereignisse und verwenden dann DOM APIs wie getBoundingClientRect(), um zu berechnen, wo die Elemente relativ zum Darstellungsbereich sind.

IntersectionObserver ist eine Browser-API, mit der Seiteninhaber effizient erkennen können, wann ein beobachtetes Element in den Darstellungsbereich des Browsers eintritt oder diesen verlässt. LazySizes bietet auch optionale Unterstützung für IntersectionObserver.

Lazy-Load-Analyse

Wenn Sie das Laden Ihrer Analyseskripts zu lange verzögern, können wertvolle Analysedaten nicht erfasst werden. Glücklicherweise gibt es Strategien, mit denen Analysen verzögert initialisiert werden können, während Daten beim frühen Seitenaufbau beibehalten werden.

Im Blogpost The Google Analytics Setup I Use on Every Site I Build von Phil Walton wird eine solche Strategie für Google Analytics beschrieben.

Drittanbieter-Scripts sicher laden

Dieser Abschnitt enthält eine Anleitung dazu, wie Sie Drittanbieterskripts so sicher wie möglich laden können.

Auf document.write() verzichten

Drittanbieter-Skripts, insbesondere für ältere Dienste, verwenden manchmal document.write(), um Skripts einzufügen und zu laden. Das ist ein Problem, weil das Verhalten von document.write() inkonsistent ist und Fehler schwer zu beheben sind.

Die Lösung für Probleme mit „document.write()“ besteht darin, die Funktion nicht zu verwenden. Ab Chrome 53 werden von den Chrome-Entwicklertools Warnungen bei problematischer Verwendung von document.write() in der Konsole protokolliert:

Wenn Sie diese Fehlermeldung erhalten, können Sie prüfen, ob Ihre Website document.write() verwendet. Suchen Sie dazu nach HTTP-Headern, die an Ihren Browser gesendet wurden. Lighthouse kann auch alle Drittanbieterskripts hervorheben, die noch document.write() verwenden.

Tag Manager mit Bedacht einsetzen

Ein Tag ist ein Code-Snippet, mit dem Teams für digitales Marketing Daten erheben, Cookies setzen oder Drittanbieterinhalte wie Widgets für soziale Medien auf einer Website einbinden können. Diese Tags fügen Ihrer Seite Netzwerkanfragen, JavaScript-Abhängigkeiten und andere Ressourcen hinzu, die sich auf die Leistung auswirken können. Es wird schwieriger, diese Auswirkungen auf Ihre Nutzer zu minimieren, wenn mehr Tags hinzugefügt werden.

Damit die Seiten schnell geladen werden, empfehlen wir die Verwendung eines Tag-Managers wie z. B. Google Tag Manager (GTM). Mit GTM können Sie Tags asynchron bereitstellen, damit sie sich nicht gegenseitig blockieren. Außerdem wird die Anzahl der Netzwerkaufrufe reduziert, die ein Browser zum Ausführen von Tags benötigt, und die Tag-Daten werden in der Datenschicht-UI erfasst.

Risiken bei der Verwendung von Tag-Managern

Tag-Manager sind zwar darauf ausgelegt, das Laden von Seiten zu optimieren. Wenn Sie sie aber unachtsam einsetzen, kann sie diesen Vorgang auf folgende Weise verlangsamen:

• Eine übermäßige Anzahl von Tags und Listenern für automatische Ereignisse in Ihrem Tag Manager führt dazu, dass der Browser mehr Netzwerkanfragen sendet, als er normalerweise hätte. Außerdem ist die Fähigkeit des Codes, schnell auf Ereignisse zu reagieren, eingeschränkt.
• Jeder Nutzer mit Anmeldedaten und Zugriff kann Ihrem Tag Manager JavaScript hinzufügen. Dies kann nicht nur die Anzahl kostspieliger Netzwerkanfragen zum Laden Ihrer Seite erhöhen, sondern auch Sicherheitsrisiken und andere Leistungsprobleme aufgrund unnötiger Skripts mit sich bringen. Um diese Risiken zu verringern, sollten Sie den Zugriff auf Ihren Tag Manager beschränken.

Skripts vermeiden, die den globalen Geltungsbereich beeinträchtigen

Drittanbieter-Skripts können sich auf verschiedene Weise verhalten, um Ihre Seite unerwartet zu beeinträchtigen:

• Skripts, die JavaScript-Abhängigkeiten laden, können den globalen Geltungsbereich durch Code beeinträchtigen, der schlecht mit Ihrem Code interagiert.
• Unerwartete Aktualisierungen können zu funktionsgefährdenden Änderungen führen.
• Drittanbietercode kann während der Übertragung geändert werden, um sich beim Testen und bei der Bereitstellung der Seite unterschiedlich zu verhalten.

Wir empfehlen Ihnen, die von Ihnen geladenen Drittanbieter-Skripts regelmäßig auf böswillige Akteure zu prüfen. Zum Schutz Ihrer Seite können Sie auch Selbsttests, die Integrität von Unterressourcen und die sichere Übertragung von Drittanbietercode implementieren.

Minderungsstrategien

Im Folgenden findest du einige umfangreiche Strategien, um die Auswirkungen von Drittanbieter-Skripts auf die Leistung und Sicherheit deiner Website zu minimieren:

• HTTPS: Websites, die HTTPS verwenden, dürfen nicht von Drittanbietern abhängig sein, die HTTP verwenden. Weitere Informationen finden Sie unter Gemischte Inhalte.

• Sandbox-Technologie: Du kannst Drittanbieter-Skripts in iFrames mit dem Attribut sandbox ausführen, um die für die Skripts verfügbaren Aktionen einzuschränken.

• Content Security Policy (CSP): Sie können HTTP-Header in der Antwort Ihres Servers verwenden, um vertrauenswürdiges Skriptverhalten für Ihre Website zu definieren und die Auswirkungen bestimmter Angriffe wie Cross-Site-Scripting (XSS) zu erkennen und zu mindern.

Das folgende Beispiel zeigt, wie Sie mit der Anweisung script-src der CSP die zulässigen JavaScript-Quellen einer Seite angeben:

// 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>

Weitere Informationen

Weitere Informationen zur Optimierung von Drittanbieter-JavaScript finden Sie in den folgenden Abschnitten:

• Leistung und Robustheit: Stresstest-Drittanbieter
• Interaktivität dank JavaScript
• Potenzielle Gefahren mit Scripts von Drittanbietern
• Wie Drittanbieter-Scripts im Web eine gute Leistung erzielen
• Warum Schnelligkeit zählt – CSS-Assistenten
• Das JavaScript Supply Chain Paradox: SRI, CSP und Vertrauen in Drittanbieterbibliotheken
• Preisvergleichsportal von Drittanbietern ist nicht sicher

Vielen Dank an Kenji Baheux, Jeremy Wagner, Pat Meenan, Philip Walton, Jeff Posnick und Cheney Tsai für ihre Rezensionen.