Wenn ihr euren Code optimiert habt, eure Website aber immer noch zu langsam geladen wird, liegt das wahrscheinlich an Drittanbieterskripten.
Drittanbieterskripte bieten eine Vielzahl nützlicher Funktionen, die das Web dynamischer, interaktiver und vernetzter machen. Einige davon sind möglicherweise sogar entscheidend für die Funktion oder den Umsatz 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 Drittanbieterscripts den kritischen Rendering-Pfad Ihrer Website nicht beeinträchtigen. In diesem Leitfaden wird beschrieben, wie Sie Probleme im Zusammenhang mit dem Laden von JavaScript von Drittanbietern finden und beheben und die Risiken für Ihre Nutzer minimieren können.
Was sind Drittanbieterskripts?
Drittanbieter-JavaScript bezieht sich oft auf Skripts, die direkt von einem Drittanbieter in eine beliebige Website eingebettet werden können. Beispiele:
Schaltflächen zum Teilen in sozialen Netzwerken (Facebook, X, LinkedIn, Mastodon)
Eingebettete Videoplayer (YouTube, Vimeo)
Werbe-iFrames
Analyse- und Messwert-Scripts
A/B-Testscripts für Tests
Hilfsbibliotheken, z. B. für Datumsformatierung, Animation oder funktionale Bibliotheken
<iframe
width="560"
height="315"
src="https://www.youtube.com/embed/mo8thg5XGV0"
frameborder="0"
allow="autoplay; encrypted-media"
allowfullscreen
>
</iframe>
Leider sind wir beim Einbetten von Drittanbieterskripts oft darauf angewiesen, dass sie schnell ausgeführt werden und unsere Seiten nicht verlangsamen. Skripts von Drittanbietern sind eine häufige Ursache für Leistungseinbußen, die durch Ressourcen außerhalb der Kontrolle des Websiteinhabers verursacht werden. Dazu gehören die folgenden Probleme:
Zu viele Netzwerkanfragen an mehrere Server senden. Je mehr Anfragen eine Website stellen muss, desto länger kann das Laden dauern.
Es wird zu viel JavaScript gesendet, sodass der Hauptthread ausgelastet ist. Zu viel JavaScript kann die DOM-Erstellung blockieren, was das Seitenrendering verzögert. CPU-intensives Parsen und Ausführen von Scripts kann die Nutzerinteraktion verzögern und den Akku belasten.
Das Senden großer, nicht optimierter Bilddateien oder Videos kann Daten verbrauchen und Nutzer Geld kosten.
Sicherheitsprobleme, die als Single Point of Failure (SPOF) fungieren können, wenn Ihre Seite ein Skript ohne Vorsichtsmaßnahmen lädt.
Unzureichendes HTTP-Caching, wodurch der Browser mehr Netzwerkanfragen zum Abrufen von Ressourcen senden muss.
Eine unzureichende Serverkomprimierung führt dazu, dass Ressourcen langsam geladen werden.
Die Anzeige von Inhalten wird blockiert, bis die Verarbeitung abgeschlossen ist. Das kann auch für asynchrone A/B-Testscripts gelten.
Verwendung von Legacy-APIs, die die Nutzerfreundlichkeit beeinträchtigen, z. B. document.write().
Übermäßige DOM-Elemente oder aufwendige CSS-Selektoren.
Wenn mehrere Drittanbieter-Einbettungen verwendet werden, kann es passieren, dass mehrere Frameworks und Bibliotheken mehrmals abgerufen werden. Dadurch werden Ressourcen verschwendet und bestehende Leistungsprobleme verschlimmert.
In Drittanbieterskripts werden häufig Einbettungstechniken verwendet, die window.onload blockieren können, wenn die Server langsam reagieren, auch wenn die Einbettung asynchron oder verzögert erfolgt.
Wie gut Sie Probleme mit Drittanbieterskripts beheben können, hängt von Ihrer Website und Ihren Möglichkeiten ab, das Laden von Drittanbietercode zu konfigurieren. Glücklicherweise gibt es eine Reihe von Lösungen und Tools, mit denen sich Probleme mit Drittanbieterressourcen finden und beheben lassen.
Wie erkennen Sie Drittanbieterskripts auf einer Seite?
Der erste Schritt zur Optimierung von Drittanbieterskripts auf Ihrer Website besteht darin, sie zu identifizieren und ihre Auswirkungen auf die Leistung zu ermitteln. Wir empfehlen die Verwendung kostenloser Tools für Geschwindigkeitstests im Web, darunter die Chrome-Entwicklertools, PageSpeed Insights und WebPageTest, um kostenintensive Skripts zu identifizieren. Diese Tools zeigen umfangreiche Diagnoseinformationen an, die Aufschluss darüber geben, wie viele Drittanbieterskripte auf Ihrer Website verwendet werden und welche am meisten Zeit für die Ausführung benötigen.
In der Wasserfallansicht von WebPageTest können Sie die Auswirkungen der intensiven Nutzung von Drittanbieterskripts sehen. Die folgende Abbildung aus Tags Gone Wild zeigt ein Beispieldiagramm der Netzwerkanfragen, die zum Laden des Hauptinhalts einer Website erforderlich sind, im Gegensatz zu den Tracking- und Marketingskripts.
Die Domainaufschlüsselung von WebPageTest kann auch nützlich sein, um zu visualisieren, wie viele Inhalte von Drittanbietern stammen. Diese werden sowohl nach der Gesamtzahl der Byte als auch nach der Anzahl der Anfragen aufgeschlüsselt:
Wie kann ich die Auswirkungen von Drittanbieterskripts auf meine Seite messen?
Wenn ein Skript Probleme verursacht, solltet ihr herausfinden, was es tut, und feststellen, ob es für die Funktion eurer Website erforderlich ist. Führen Sie bei Bedarf einen A/B-Test durch, um den wahrgenommenen Wert mit den Auswirkungen auf wichtige Messwerte für Nutzerinteraktion und ‑bindung oder Leistung in Einklang zu bringen.
Lighthouse-Prüfung der Startzeit
Die Lighthouse-Prüfung der JavaScript-Startzeit hebt Skripts hervor, die eine aufwendige Skriptanalyse, Kompilierung oder Auswertung erfordern. So können Sie CPU-intensive Drittanbieterskripts identifizieren.
Lighthouse-Prüfung der Netzwerknutzlasten
Bei der Prüfung der Netzwerknutzlasten von Lighthouse werden Netzwerkanfragen identifiziert, einschließlich Netzwerkanfragen von Drittanbietern, die die Seitenladezeit verlangsamen und dazu führen, dass Nutzer mehr mobile Daten verbrauchen als erwartet.
Blockierung von Netzwerkanfragen in den Chrome-Entwicklertools
Mit den Chrome-Entwicklertools können Sie sehen, wie sich Ihre Seite verhält, wenn ein bestimmtes Script, ein bestimmtes Stylesheet oder eine andere Ressource nicht verfügbar ist. Dazu wird die Blockierung von Netzwerkanfragen verwendet. Mit dieser Funktion lässt sich die Auswirkung des Entfernens einzelner Drittanbieterressourcen von Ihrer Seite messen.
Wenn Sie die Blockierung von Anfragen aktivieren möchten, rechtsklicken Sie im Netzwerkbereich auf eine beliebige Anfrage und wählen Sie Anfrage-URL blockieren aus. In der DevTools-Leiste wird dann ein Tab zum Blockieren von Anfragen angezeigt, über den Sie die blockierten Anfragen verwalten können.
Bereich „Leistung“ in den Chrome-Entwicklertools
Mit dem Bereich „Leistung“ in den Chrome-Entwicklertools können Sie Probleme mit der Webleistung Ihrer Seite identifizieren.
- Klicken Sie auf Aufzeichnen.
- Laden Sie die Seite. In den DevTools wird ein Wasserfalldiagramm angezeigt, das darstellt, wie die Ladezeit Ihrer Website aufgeteilt ist.
- Gehen Sie unten im Bereich „Leistung“ zu Bottom-up.
- Klicken Sie auf Nach Produkt gruppieren und sortieren Sie die Drittanbieterskripts Ihrer Seite nach Ladezeit.
Weitere Informationen zur Verwendung der Chrome-Entwicklertools zur Analyse des Seitenaufbaus finden Sie unter Erste Schritte mit der Analyse der Laufzeitleistung.
Wir empfehlen den folgenden Workflow, um die Auswirkungen von Drittanbieterskripts zu messen:
- Im Netzwerkbereich können Sie messen, wie lange es dauert, bis Ihre Seite geladen ist.
- Um reale Bedingungen zu simulieren, empfehlen wir, die Netzwerkdrosselung und die CPU-Drosselung zu aktivieren. Es ist unwahrscheinlich, dass Ihre Nutzer über die schnellen Netzwerkverbindungen und die Desktop-Hardware verfügen, die die Auswirkungen teurer Skripts unter Laborbedingungen reduzieren.
- Blockieren Sie die URLs oder Domains, die für Drittanbieterskripts verantwortlich sind, die Ihrer Meinung nach ein Problem darstellen. Eine Anleitung zum Identifizieren kostspieliger Skripts finden Sie im Bereich „Leistung“ in den Chrome-Entwicklertools.
- Aktualisieren Sie die Seite und messen Sie die Ladezeit noch einmal.
- Für genauere Daten sollten Sie die Ladezeit mindestens dreimal messen. Dies ist darauf zurückzuführen, dass einige Drittanbieterskripts bei jedem Seitenaufbau unterschiedliche Ressourcen abrufen. Das DevTools-Leistungspanel unterstützt mehrere Aufzeichnungen, um Sie dabei zu unterstützen.
Auswirkungen von Drittanbieterskripts mit WebPageTest messen
WebPageTest unterstützt das Blockieren des Ladens einzelner Anfragen, um deren Auswirkungen zu messen. Die entsprechende Option finden Sie unter Advanced Settings (Erweiterte Einstellungen) > Block (Blockieren). Mit dieser Funktion können Sie eine Liste von Domains angeben, die blockiert werden sollen, z. B. Werbedomains.
Wir empfehlen den folgenden Workflow für die Verwendung dieser Funktion:
- Testen Sie eine Seite, ohne Drittanbieter zu blockieren.
- Wiederholen Sie den Test, wobei einige Drittanbieter blockiert sind.
- Wählen Sie die beiden Ergebnisse aus Ihrem Testverlauf aus.
- Klicken Sie auf Vergleichen.
Die folgende Abbildung zeigt die Filmstreifenfunktion von WebPageTest, mit der die Ladesequenzen für Seiten mit und ohne aktive Drittanbieterressourcen verglichen werden. Wir empfehlen, dies bei Tests einzelner Drittanbieter-Ursprünge zu prüfen, um festzustellen, welche Domains die Leistung Ihrer Seite am stärksten beeinträchtigen.
WebPageTest unterstützt auch zwei Befehle, die auf DNS-Ebene zum Blockieren von Domains verwendet werden:
blockDomainsakzeptiert eine Liste von Domains, die blockiert werden sollen.- blockDomainsExcept nimmt eine Liste von Domains und blockiert alles, was nicht auf der Liste steht.
WebPageTest hat auch einen Tab „Single Point of Failure“ (SPOF), mit dem Sie eine Zeitüberschreitung oder einen vollständigen Fehler beim Laden einer Ressource simulieren können. Im Gegensatz zur Domainblockierung kommt es bei SPOF langsam zu einem Zeitüberschreitungsfehler. Das kann nützlich sein, um zu testen, wie sich Ihre Seiten verhalten, wenn Drittanbieterdienste stark ausgelastet oder vorübergehend nicht verfügbar sind.
Teure iFrames mithilfe von Long Tasks erkennen
Wenn die Ausführung von Skripts in iFrames von Drittanbietern lange dauert, können sie den Hauptthread blockieren und andere Aufgaben verzögern. Diese Long Tasks können dazu führen, dass Event-Handler langsam arbeiten oder Frames verloren gehen, was die Nutzererfahrung beeinträchtigt.
Wenn Sie Long Tasks für das Real User Monitoring (RUM) erkennen möchten, verwenden Sie die JavaScript-API PerformanceObserver, um longtask-Einträge zu beobachten. Diese Einträge enthalten ein Attributionsattribut, mit dem Sie feststellen können, welcher Frame-Kontext die Long Task verursacht hat.
Mit dem folgenden Code werden longtask-Einträge in der Console protokolliert, darunter einer für einen „teuren“ 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 Monitoring von Long Tasks finden Sie unter Nutzerorientierte Leistungsmesswerte.
Wie lade ich Drittanbieter-Scripts effizient?
Wenn ein Drittanbieterskript den Seitenaufbau verlangsamt, hast du mehrere Möglichkeiten, die Leistung zu verbessern:
- Lade das Script mit dem Attribut
asyncoderdefer, um zu vermeiden, dass das Parsen des Dokuments blockiert wird. - Wenn der Server des Drittanbieters langsam ist, kannst du das Script auch selbst hosten.
- Wenn das Script keinen klaren Mehrwert für deine Website bietet, solltest du es entfernen.
- Verwenden Sie Ressourcenhinweise wie
<link rel=preconnect>oder<link rel=dns-prefetch>, um eine DNS-Suche für Domains durchzuführen, die Drittanbieterskripts hosten.
Verwenden Sie async oder defer.
Die JavaScript-Ausführung blockiert den Parser. Wenn der Browser auf ein Script stößt, muss er die DOM-Erstellung pausieren, das Script an die JavaScript-Engine übergeben und die Ausführung des Scripts zulassen, bevor er mit der DOM-Erstellung fortfährt.
Die Attribute async und defer ändern dieses Verhalten so:
asyncbewirkt, dass der Browser das Script asynchron herunterlädt, während er das HTML-Dokument weiter parst. Wenn das Script heruntergeladen wurde, wird das Parsen blockiert, während das Script ausgeführt wird.deferbewirkt, dass der Browser das Skript asynchron herunterlädt, während er das HTML-Dokument weiter parst. Das Skript wird erst ausgeführt, wenn das Parsen des Dokuments abgeschlossen ist.
Verwende für Drittanbieterskripts immer async oder defer, es sei denn, das Skript ist für den kritischen Renderingpfad erforderlich. Verwenden Sie async, wenn es wichtig ist, dass das Skript früher im Ladevorgang ausgeführt wird, z. B. bei einigen Analysescripts. Verwende defer für weniger wichtige Ressourcen, z. B. Videos, die weiter unten auf der Seite gerendert werden, als der Nutzer sie anfangs sieht.
Wenn die Leistung für Sie im Vordergrund steht, empfehlen wir, asynchrone Scripts erst hinzuzufügen, nachdem die wichtigen 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 solche, die wichtige Teile deiner Website sind. Dazu gehören UI-Bibliotheken oder CDN-Frameworks (Content Delivery Network), ohne die Ihre Website nicht funktioniert.
Andere Skripts funktionieren einfach nicht, wenn sie asynchron geladen werden. Prüfe die Dokumentation für alle von dir verwendeten Skripts und ersetze alle Skripts, die nicht asynchron geladen werden können, durch Alternativen, die das können. Beachte, dass einige Drittanbieter empfehlen, ihre Scripts synchron auszuführen, auch wenn sie asynchron genauso gut funktionieren würden.
Denken Sie daran, dass async nicht alle Probleme löst. Wenn Ihre Seite eine große Anzahl von Skripts enthält, z. B. Tracking-Skripts für Werbezwecke, werden sie durch asynchrones Laden nicht daran gehindert, den Seitenaufbau zu verlangsamen.
Ressourcenhinweise verwenden, um die Verbindungsaufbauzeit zu verkürzen
Das Herstellen von Verbindungen zu Drittanbieter-Ursprüngen kann lange dauern, insbesondere in langsamen Netzwerken, da Netzwerkanfragen mehrere komplexe Komponenten umfassen, einschließlich DNS-Lookups und Weiterleitungen. Sie können Ressourcenhinweise wie verwenden, um DNS-Suchen für Domains, die Drittanbieterscripts hosten, früh im Seitenaufbauprozess durchzuführen, damit der Rest der Netzwerkanfrage später schneller fortgesetzt werden kann:
<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 sowohl DNS-Suchen durchgeführt als auch TCP-Roundtrips aufgelöst und TLS-Verhandlungen verarbeitet. Diese anderen Schritte können sehr langsam sein, da sie die Überprüfung von SSL-Zertifikaten beinhalten. Daher kann die Vorverbindung die Ladezeit erheblich verkürzen.
<link rel="preconnect" href="https://cdn.example.com" />
Skripts mit einem iFrame in einer Sandbox ausführen
Wenn Sie ein Drittanbieterscript direkt in einen iFrame laden, wird die Ausführung der Hauptseite nicht blockiert. AMP verwendet diesen Ansatz, um JavaScript aus dem kritischen Pfad herauszuhalten. Beachten Sie, dass bei diesem Ansatz das onload-Ereignis weiterhin blockiert wird. Versuchen Sie daher, keine wichtigen Funktionen an onload anzuhängen.
Chrome unterstützt auch die Permissions Policy (früher „Feature Policy“), eine Reihe von Richtlinien, mit denen Entwickler den Zugriff auf bestimmte Browserfunktionen selektiv deaktivieren können. So kannst du verhindern, dass Inhalte von Dritten unerwünschte Verhaltensweisen auf einer Website einführen.
Drittanbieterskripts selbst hosten
Wenn du mehr Kontrolle darüber haben möchtest, wie ein wichtiges Script geladen wird, z. B. um die DNS-Zeit zu reduzieren oder HTTP-Caching-Header zu verbessern, kannst du es selbst hosten.
Das Self-Hosting bringt jedoch eigene Probleme mit sich, insbesondere wenn es um die Aktualisierung von Skripts geht. Selbst gehostete Scripts erhalten keine automatischen Updates für API-Änderungen oder Sicherheitskorrekturen. Das kann zu Umsatzeinbußen oder Sicherheitsproblemen führen, bis Sie Ihr Script manuell aktualisieren.
Alternativ können Sie Drittanbieterskripts mit Service Workern im Cache speichern, um besser steuern zu können, wie oft Skripts aus dem Netzwerk abgerufen werden. Sie können auch Service Worker verwenden, um Ladestrategien zu erstellen, die nicht wesentliche Drittanbieteranfragen drosseln, bis Ihre Seite einen wichtigen Nutzermoment erreicht.
A/B-Tests mit kleineren Nutzerstichproben
A/B-Tests (oder Split-Tests) sind eine Technik, bei der zwei Versionen einer Seite getestet werden, um die Nutzerfreundlichkeit und das Nutzerverhalten zu analysieren. Die Seitenversionen werden verschiedenen Stichproben des Website-Traffics zur Verfügung gestellt. Anhand von Analysen wird dann ermittelt, welche Version eine bessere Conversion-Rate bietet.
Bei A/B-Tests wird das Rendering jedoch absichtlich verzögert, um zu entscheiden, welcher Test aktiv sein muss. Mit JavaScript wird oft geprüft, ob Nutzer zu einem A/B-Test gehören, und dann die richtige Variante aktiviert. Dieser Prozess kann die Nutzerfreundlichkeit auch für Nutzer verschlechtern, die nicht am Experiment teilnehmen.
Um das Rendern von Seiten zu beschleunigen, empfehlen wir, Ihre A/B-Testskripts an eine kleinere Stichprobe Ihrer Nutzerbasis zu senden und den Code, der entscheidet, welche Version der Seite angezeigt werden soll, serverseitig auszuführen.
Lazy Loading von Drittanbieterressourcen
Eingebettete Drittanbieterressourcen wie Anzeigen und Videos können bei schlechter Konstruktion erheblich zur Verlangsamung der Page Speed beitragen. Mit Lazy Loading können eingebettete Ressourcen nur bei Bedarf geladen werden. Beispielsweise werden Anzeigen in der Fußzeile der Seite erst dann ausgeliefert, wenn der Nutzer weit genug scrollt, um sie zu sehen. Sie können auch Lazy Loading für Inhalte von Dritten verwenden, nachdem der Hauptinhalt der Seite geladen wurde, aber bevor ein Nutzer mit der Seite interagiert.
Seien Sie vorsichtig, wenn Sie Ressourcen per Lazy Loading laden, da dies oft JavaScript-Code beinhaltet, der durch instabile Netzwerkverbindungen beeinträchtigt werden kann.
In der offiziellen Dokumentation von DoubleClick finden Sie eine Anleitung zum Lazy Loading von Anzeigen.
Effizientes Lazy Loading mit Intersection Observer
In der Vergangenheit waren Methoden, mit denen erkannt wurde, ob ein Element im Darstellungsbereich sichtbar ist, um es verzögert zu laden, fehleranfällig und haben den Browser oft verlangsamt. Diese ineffizienten Methoden warten oft auf scroll- oder resize-Ereignisse und verwenden dann DOM APIs wie getBoundingClientRect(), um die Position von Elementen relativ zum Darstellungsbereich zu berechnen.
IntersectionObserver ist eine Browser-API, mit der Seitenbetreiber effizient erkennen können, wann ein beobachtetes Element den Darstellungsbereich des Browsers betritt oder verlässt. LazySizes bietet auch optionale Unterstützung für IntersectionObserver.
Lazy Loading von Analysen
Wenn Sie das Laden Ihrer Analysescripts zu lange verzögern, können Ihnen wertvolle Analysedaten entgehen. Glücklicherweise gibt es Strategien, um Analysen verzögert zu initialisieren und gleichzeitig Daten zum frühen Seitenaufbau beizubehalten.
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.
Drittanbieterskripts sicher laden
In diesem Abschnitt finden Sie eine Anleitung zum möglichst sicheren Laden von Drittanbieterskripts.
Auf document.write() verzichten
In Drittanbieter-Skripts, insbesondere für ältere Dienste, wird manchmal document.write() verwendet, um Skripts einzufügen und zu laden. Das ist ein Problem, da sich document.write() inkonsistent verhält und Fehler schwer zu beheben sind.
Die Lösung für Probleme mit document.write() besteht darin, es nicht zu verwenden. In Chrome 53 und höher werden in den Chrome-Entwicklertools Warnungen in der Konsole für die problematische Verwendung von document.write() protokolliert:
document.write().Wenn Sie diesen Fehler erhalten, können Sie Ihre Website auf die Verwendung von document.write() prüfen. Suchen Sie dazu nach HTTP-Headern, die an Ihren Browser gesendet werden.
Lighthouse kann auch Drittanbieter-Scripts hervorheben, die noch document.write() verwenden.
document.write() verwenden.Tag-Manager mit Bedacht verwenden
Ein Tag ist ein Code-Snippet, mit dem Teams für digitales Marketing Daten erheben, Cookies setzen oder Inhalte von Dritten wie Widgets für soziale Medien in eine 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. Je mehr Tags hinzugefügt werden, desto schwieriger wird es, diese Auswirkungen für Ihre Nutzer zu minimieren.
Damit der Seitenaufbau schnell ist, empfehlen wir die Verwendung eines Tag-Managers wie Google Tag Manager (GTM). Mit dem GTM können Sie Tags asynchron bereitstellen, damit sie sich nicht gegenseitig beim Laden blockieren. Außerdem wird die Anzahl der Netzwerkaufrufe reduziert, die ein Browser zum Ausführen von Tags benötigt, und Tag-Daten werden in der Benutzeroberfläche der Datenebene erfasst.
Risiken bei der Verwendung von Tag-Managern
Tag-Manager sind zwar darauf ausgelegt, den Seitenaufbau zu optimieren, können es aber bei unbedachtem Einsatz auf folgende Weise verlangsamen:
- Eine übermäßige Anzahl von Tags und automatischen Ereignis-Listenern in Ihrem Tag-Manager führt dazu, dass der Browser mehr Netzwerkanfragen stellt, als er sonst müsste. Außerdem wird die Fähigkeit Ihres Codes, schnell auf Ereignisse zu reagieren, beeinträchtigt.
- Jeder, der über die entsprechenden Anmeldedaten und Zugriffsberechtigungen verfügt, kann JavaScript in Ihren Tag Manager einfügen. Dies kann nicht nur die Anzahl der kostspieligen Netzwerkanfragen erhöhen, die zum Laden Ihrer Seite erforderlich sind, sondern auch Sicherheitsrisiken und andere Leistungsprobleme durch unnötige Skripts verursachen. Um diese Risiken zu minimieren, empfehlen wir, den Zugriff auf Ihren Tag Manager einzuschränken.
Skripts vermeiden, die den globalen Bereich beeinträchtigen
Skripts von Drittanbietern können sich auf verschiedene Arten verhalten, die Ihre Seite unerwartet beeinträchtigen:
- Skripts, die JavaScript-Abhängigkeiten laden, können den globalen Bereich mit Code verunreinigen, der sich negativ auf Ihren Code auswirkt.
- Unerwartete Updates können zu funktionsgefährdenden Änderungen führen.
- Drittanbietercode kann während der Übertragung geändert werden, sodass er sich zwischen dem Testen und der Bereitstellung Ihrer Seite unterschiedlich verhält.
Wir empfehlen, die von Ihnen geladenen Drittanbieterskripts regelmäßig auf schädliche Akteure zu überprüfen. Du kannst auch Selbsttests, Subresource Integrity und die sichere Übertragung von Drittanbietercode implementieren, um deine Seite zu schützen.
Strategien zur Aussetzung von Maßnahmen
Hier sind einige umfassende Strategien, um die Auswirkungen von Drittanbieterskripts 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.
Sandboxing: Erwäge, Drittanbieterskripts in iFrames mit dem Attribut
sandboxauszufü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 einiger Angriffe wie Cross-Site-Scripting (XSS) zu erkennen und zu minimieren.
Im folgenden Beispiel wird die CSP-Anweisung script-src verwendet, um die zulässigen JavaScript-Quellen einer Seite anzugeben:
// 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 JavaScript von Drittanbietern finden Sie hier:
- Leistung und Resilienz: Stresstests für Drittanbieter
- Interaktivität mit JavaScript hinzufügen
- Potenzielle Gefahren bei Drittanbieter-Scripts
- How 3rd Party Scripts can be performant citizens on the web
- Why Fast Matters - CSS Wizardry
- The JavaScript Supply Chain Paradox: SRI, CSP and Trust in Third Party Libraries
- CSS 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.