„document.write()“ eingreifen

Paul Kinlan

Haben Sie in letzter Zeit in Ihrer Developer Console in Chrome eine Warnung wie die folgende gesehen und sich gefragt, was es damit auf sich hat?

(index):34 A Parser-blocking, cross-origin script,
https://paul.kinlan.me/ad-inject.js, is invoked via document.write().
This may be blocked by the browser if the device has poor network connectivity.

Die Zusammensetzbarkeit ist einer der großen Vorteile des Webs. Sie ermöglicht es uns, problemlos Dienste von Drittanbietern zu integrieren, um großartige neue Produkte zu entwickeln. Einer der Nachteile der Zusammensetzbarkeit ist, dass sie eine gemeinsame Verantwortung für die User Experience mit sich bringt. Wenn die Integration nicht optimal ist, wird die Nutzerfreundlichkeit beeinträchtigt.

Eine bekannte Ursache für eine schlechte Leistung ist die Verwendung von document.write() auf Seiten, insbesondere bei Verwendungen, bei denen Skripts eingefügt werden. So harmlos die folgende Aussage auch aussehen mag, sie kann für Nutzer zu echten Problemen führen.

document.write('<script src="https://example.com/ad-inject.js"></script>');

Bevor der Browser eine Seite rendern kann, muss er den DOM-Baum erstellen, indem er das HTML-Markup parst. Wenn der Parser auf ein Skript trifft, muss er anhalten und es ausführen, bevor er mit dem Parsen des HTML-Codes fortfahren kann. Wenn das Skript dynamisch ein anderes Skript einfügt, muss der Parser noch länger warten, bis die Ressource heruntergeladen ist. Das kann einen oder mehrere Netzwerk-Roundtrips zur Folge haben und die Zeit bis zum ersten Rendern der Seite verzögern.

Bei Nutzern mit langsamen Verbindungen wie 2G kann das dynamische Einfügen externer Skripte über document.write() dazu führen, dass sich das Anzeigen des Contents der Hauptseite mehrere Sekunden verzögert. Möglicherweise verlässt der Nutzer die Seite dann, noch bevor sie gerendert wurde. Anhand von Instrumentierung in Chrome haben wir festgestellt, dass Seiten mit Skripts von Drittanbietern, die über document.write() eingefügt werden, bei einer 2G-Verbindung meist doppelt so lang wie andere Seiten benötigen, um geladen zu werden.

Wir haben Daten aus einem 28-tägigen Feldversuch mit 1% der stabilen Chrome-Nutzer erhoben, die auf 2G-Verbindungen beschränkt waren. Wir haben festgestellt, dass bei 7,6% aller Seitenaufrufe über 2G mindestens ein parserblockierendes, websiteübergreifendes Script enthalten war, das über document.write() in das Dokument der obersten Ebene eingefügt wurde. Durch das Blockieren des Ladens dieser Skripts konnten wir die folgenden Verbesserungen erzielen:

  • 10% mehr Seitenaufrufe, bei denen First Contentful Paint erreicht wird (eine visuelle Bestätigung für den Nutzer, dass die Seite tatsächlich geladen wird), 25% mehr Seitenaufrufe, bei denen der vollständig geparste Status erreicht wird, und 10% weniger Neuladevorgänge deuten auf eine geringere Frustration der Nutzer hin.
  • 21% weniger durchschnittliche Zeit (über eine Sekunde schneller) bis zum First Contentful Paint
  • 38% weniger durchschnittliche Zeit zum Parsen einer Seite, was einer Verbesserung von fast sechs Sekunden entspricht. Dadurch wird die Zeit, die zum Anzeigen wichtiger Inhalte für den Nutzer benötigt wird, erheblich verkürzt.

Auf Grundlage dieser Daten greift Chrome ab Version 55 im Namen aller Nutzer ein, wenn dieses bekannte schädliche Muster erkannt wird. Dazu wird die Verarbeitung von document.write() in Chrome geändert (siehe Chrome-Status). Insbesondere führt Chrome die über document.write() eingefügten <script>-Elemente nicht aus, wenn alle der folgenden Bedingungen erfüllt sind:

  1. Der Nutzer hat eine langsame Verbindung, insbesondere wenn er 2G verwendet. In Zukunft kann die Änderung auf andere Nutzer mit langsamen Verbindungen ausgeweitet werden, z. B. auf Nutzer mit langsamen 3G- oder WLAN-Verbindungen.
  2. document.write() befindet sich in einem Dokument der obersten Ebene. Die Maßnahme gilt nicht für document.written-Scripts in iFrames, da sie das Rendern der Hauptseite nicht blockieren.
  3. Das Skript in document.write() blockiert den Parser. Skripts mit den Attributen async oder defer werden weiterhin ausgeführt.
  4. Das Skript wird nicht auf derselben Website gehostet. Mit anderen Worten: Chrome greift nicht bei Skripten mit einer übereinstimmenden eTLD+1 ein (z.B. ein Skript, das auf js.beispiel.de gehostet und auf www.beispiel.de eingefügt wird).
  5. Das Skript befindet sich noch nicht im HTTP-Cache des Browsers. Bei Skripts im Cache kommt es nicht zu einer Netzwerkverzögerung und sie werden weiterhin ausgeführt.
  6. Die Anfrage für die Seite ist kein Neuladen. Chrome greift nicht ein, wenn der Nutzer ein Neuladen ausgelöst hat, und führt die Seite wie gewohnt aus.

In Drittanbieter-Snippets wird manchmal document.write() verwendet, um Skripts zu laden. Glücklicherweise bieten die meisten Drittanbieter Alternativen für das asynchrone Laden an, mit denen Drittanbieterskripts geladen werden können, ohne die Anzeige der übrigen Inhalte auf der Seite zu blockieren.

Wie kann ich das beheben?

Die einfache Antwort lautet: Verwenden Sie document.write() nicht, um Skripts einzufügen. Wir führen eine Liste mit bekannten Diensten für die Unterstützung des asynchronen Loaders, die Sie regelmäßig aufrufen sollten.

Wenn Ihr Anbieter nicht in der Liste aufgeführt ist, aber asynchrones Laden von Scripts unterstützt, informieren Sie uns bitte, damit wir die Seite für alle Nutzer aktualisieren können.

Wenn Ihr Anbieter das asynchrone Laden von Skripts auf Ihrer Seite nicht unterstützt, empfehlen wir Ihnen, ihn zu kontaktieren und uns und ihm mitzuteilen, wie sich das auf ihn auswirken wird.

Wenn Ihr Anbieter Ihnen ein Snippet zur Verfügung stellt, das das document.write()-Element enthält, können Sie dem Skriptelement möglicherweise ein async-Attribut hinzufügen oder die Skriptelemente mit DOM-APIs wie document.appendChild() oder parentNode.insertBefore() hinzufügen.

So stellen Sie fest, ob Ihre Website betroffen ist

Es gibt eine Vielzahl von Kriterien, die darüber entscheiden, ob die Einschränkung durchgesetzt wird. Wie können Sie also feststellen, ob Sie betroffen sind?

Erkennen, wenn ein Nutzer 2G nutzt

Um die potenziellen Auswirkungen dieser Änderung zu verstehen, müssen Sie zuerst wissen, wie viele Ihrer Nutzer 2G verwenden. Mit der Network Information API, die in Chrome verfügbar ist, können Sie den aktuellen Netzwerktyp und die aktuelle Geschwindigkeit des Nutzers ermitteln und dann eine Benachrichtigung an Ihre Analyse- oder RUM-Systeme (Real User Metrics) senden.

if(navigator.connection &&
    navigator.connection.type === 'cellular' &&
    navigator.connection.downlinkMax <= 0.115) {
    // Notify your service to indicate that you might be affected by this restriction.
}

Warnungen in den Chrome-Entwicklertools erkennen

Seit Chrome 53 werden in den Entwicklertools Warnungen für problematische document.write()-Anweisungen ausgegeben. Wenn eine document.write()-Anfrage die Kriterien 2 bis 5 erfüllt (Chrome ignoriert die Verbindungskriterien beim Senden dieser Warnung), sieht die Warnung in etwa so aus:

Warnung beim Schreiben von Dokumenten.

Warnungen in den Chrome-Entwicklertools sind hilfreich, aber wie lässt sich das in großem Maßstab erkennen? Sie können nach HTTP-Headern suchen, die bei der Intervention an Ihren Server gesendet werden.

HTTP-Header der Skriptressource prüfen

Wenn ein über document.write eingefügtes Script blockiert wurde, sendet Chrome den folgenden Header an die angeforderte Ressource:

Intervention: <https://shorturl/relevant/spec>;

Wenn ein über document.write eingefügtes Skript gefunden wird, das unter Umständen blockiert werden könnte, sendet Chrome möglicherweise Folgendes:

Intervention: <https://shorturl/relevant/spec>; level="warning"

Der Interventionsheader wird als Teil der GET-Anfrage für das Skript gesendet (bei einer tatsächlichen Intervention asynchron).

Was wird die Zukunft bringen?

Der ursprüngliche Plan sieht vor, diese Maßnahme auszuführen, wenn die Kriterien erfüllt sind. In Chrome 53 haben wir zunächst nur eine Warnung in der Entwicklerkonsole angezeigt. (Die Betaphase war im Juli 2016. Wir gehen davon aus, dass die stabile Version im September 2016 für alle Nutzer verfügbar sein wird.)

Wir werden eingreifen, um eingefügte Skripts für 2G-Nutzer zu blockieren. Dies wird voraussichtlich ab Chrome 54 geschehen, das Mitte Oktober 2016 als stabile Version für alle Nutzer verfügbar sein wird. Weitere Updates finden Sie im Chrome-Status-Eintrag.

Im Laufe der Zeit möchten wir eingreifen, wenn ein Nutzer eine langsame Verbindung hat (z. B. langsames 3G oder WLAN). Chrome-Statuseintrag

Möchten Sie mehr erfahren?

Weitere Informationen finden Sie in den folgenden Ressourcen: