Selbsthosting von Ressourcen von Drittanbietern: gut, schlecht, böse

In den letzten Jahren bieten immer mehr Plattformen zur Optimierung von Front-End-Projekten die Möglichkeit, Ressourcen von Drittanbietern unabhängig zu hosten oder zu proxen. Mit Akamai können Sie bestimmte Parameter für selbst erstellte URLs festlegen. Cloudflare verfügt über Edge Workers-Technologie. Fasterzine kann URLs auf Seiten so umschreiben , dass sie auf Ressourcen von Drittanbietern verweisen, die sich in der Hauptdomäne der Site befinden.



Wenn Sie wissen, dass sich die in Ihrem Projekt verwendeten Dienste von Drittanbietern nicht allzu oft ändern und dass der Prozess ihrer Lieferung an Kunden verbessert werden kann, sollten Sie überlegen, solche Dienste zu vertreten. Mit diesem Ansatz können Sie diese Ressourcen näher an die Benutzer bringen und mehr Kontrolle über deren Zwischenspeicherung auf der Clientseite erlangen. Dies ermöglicht es Ihnen außerdem, Benutzer vor Problemen zu schützen, die durch den "Ausfall" eines Drittanbieter-Dienstes oder die Beeinträchtigung seiner Leistung verursacht werden.

Gut: erhöhte Produktivität

Das Selbst-Hosting der Ressourcen anderer verbessert die Leistung auf sehr offensichtliche Weise. Der Browser muss nicht erneut auf den DNS zugreifen, keine TCP-Verbindung herstellen und keinen TLS-Handshake für eine Drittanbieter-Domain ausführen. Wie sich das unabhängige Hosting der Ressourcen anderer Personen auf die Leistung auswirkt, können Sie anhand der folgenden beiden Zahlen sehen.


Ressourcen von Drittanbietern werden von externen Quellen heruntergeladen ( von hier entnommen).


Ressourcen von Drittanbietern werden am selben Ort wie die übrigen Materialien der Website gespeichert ( von hier entnommen).

Die Situation wird auch dadurch verbessert, dass der Browser die Funktionen zum Multiplexen und Priorisieren von HTTP / 2-Verbindungsdaten verwendet, die bereits mit der Hauptdomäne eingerichtet wurden.

Wenn Sie keine Ressourcen von Drittanbietern hosten, können diese nicht priorisiert werden, da sie von einer anderen als der Hauptdomäne heruntergeladen werden. Dies führt dazu, dass sie miteinander um die Bandbreite des Clients konkurrieren. Dies kann dazu führen, dass die Ladezeit von Materialien, die für die Bildung der Seite kritisch sind, viel länger ist als die Zeit, die unter idealen Umständen erreichbar ist. Hier ist ein Vortrag über die Priorisierung von HTTP / 2, der das alles sehr gut erklärt.

Es kann davon ausgegangen werden, dass die Verwendung von preconnect in Links zu externen Ressourcen zur Lösung des Problems preconnect . Wenn es jedoch zu viele solcher Links zu verschiedenen Domänen gibt, kann dies die Kommunikationsleitung im kritischsten Moment tatsächlich überlasten.

Wenn Sie Ressourcen von Drittanbietern selbst hosten, können Sie steuern, wie diese Ressourcen dem Client zugewiesen werden. Wir sprechen nämlich über Folgendes:

• Sie können sicherstellen, dass der für jeden Browser am besten geeignete Datenkomprimierungsalgorithmus (Brotli / gzip) angewendet wird.
• Sie können die Caching-Zeit von Ressourcen erhöhen, die normalerweise auch für die bekanntesten Anbieter nicht sehr groß sind (z. B. wird der entsprechende Wert für das GA-Tag auf 30 Minuten festgelegt).

Sie können die TTL für eine Ressource sogar auf ein Jahr verlängern, indem Sie die entsprechenden Materialien in Ihre Caching-Verwaltungsstrategie aufnehmen (URL-Hashes, Versionsverwaltung usw.). Wir werden weiter unten darauf eingehen.

▍ Schutz vor Unterbrechungen im Betrieb von Diensten Dritter oder vor deren Abschaltung

Ein weiterer interessanter Aspekt des unabhängigen Hostings von Ressourcen von Drittanbietern ist, dass Sie so die Risiken verringern können, die mit Unterbrechungen im Betrieb von Diensten von Drittanbietern verbunden sind. Angenommen, Ihre Drittanbieterlösung für A / B-Tests ist als Blockierungsskript implementiert, das im Kopfbereich der Seite geladen wird. Dieses Skript wird langsam geladen. Wenn das entsprechende Skript nicht geladen werden kann, ist die Seite leer. Wenn das Laden viel Zeit in Anspruch nimmt, wird die Seite mit einer langen Verzögerung angezeigt. Angenommen, das Projekt verwendet eine Bibliothek, die aus einer CDN-Ressource eines Drittanbieters geladen wurde. Stellen Sie sich vor, dass diese Ressource in einem bestimmten Land abgestürzt ist oder blockiert wurde. Eine solche Situation führt zu einem Verstoß gegen die Logik der Website.

Um herauszufinden, wie Ihre Website unter den Bedingungen funktioniert, dass ein externer Dienst nicht erreichbar ist, können Sie den Abschnitt SPOF auf webpagetest.org verwenden .


SPOF-Bereich auf webpagetest.org

▍ Wie wäre es mit Caching-Problemen mit Browsern? (Hinweis: Dies ist ein Mythos)

Sie könnten denken, dass die Verwendung öffentlich verfügbarer CDNs automatisch zu einer besseren Ressourcenleistung führt, da diese Dienste über einigermaßen gute Netzwerke verfügen und auf der ganzen Welt verteilt sind. Tatsächlich ist aber alles etwas komplizierter.

Angenommen, wir haben mehrere verschiedene Websites: website1.com, website2.com, website3.com. Alle diese Sites verwenden die jQuery-Bibliothek. Wir verbinden es mit ihnen über CDN, zum Beispiel googleapis.com. Sie können davon ausgehen, dass der Browser die Bibliothek einmal herunterlädt und zwischenspeichert und sie dann bei der Arbeit mit allen drei Sites verwendet. Dies könnte die Netzwerklast verringern. Vielleicht wird dadurch irgendwo Geld gespart und die Ressourcenproduktivität verbessert. Aus praktischer Sicht sieht alles anders aus. Safari implementiert beispielsweise eine Funktion namens Intelligent Tracking Prevention : Der Cache verwendet doppelte Schlüssel, die auf der Quelle des Dokuments und der Quelle einer Drittanbieter-Ressource basieren. Hier ist ein guter Artikel zu diesem Thema.

Alte Yahoo- und Facebook- Forschungen sowie neuere Forschungen von Paul Calvano zeigen, dass Ressourcen nicht so lange in Browser-Caches gespeichert werden, wie wir es erwartet haben: „Es besteht eine gravierende Lücke zwischen der Caching-Zeit unserer eigenen Projektressourcen und der von Drittanbietern. Es geht um CSS und Webfonts. Die Caching-Laufzeit von 95% der eigenen Schriften überschreitet eine Woche, während die Caching-Laufzeit von 50% der Schriften von Drittanbietern weniger als eine Woche beträgt! Dies gibt Webentwicklern einen guten Grund, Schriftdateien selbst zu hosten! “

Wenn Sie die Materialien anderer Benutzer hosten, werden Sie daher keine Leistungsprobleme feststellen, die durch das Zwischenspeichern des Browsers verursacht werden.

Nachdem wir die Stärken von Ressourcen von Drittanbietern, die sich selbst hosten, untersucht haben, wollen wir uns damit befassen, wie eine gute Implementierung dieses Ansatzes von einer schlechten unterschieden werden kann.

Schlimm: Der Teufel steckt im Detail

Das Verschieben von Ressourcen von Drittanbietern in Ihre eigene Domain kann nicht automatisch durchgeführt werden, ohne auf das korrekte Zwischenspeichern solcher Ressourcen zu achten.

Eines der Hauptprobleme hierbei ist die Caching-Zeit. Beispielsweise sind Versionsinformationen in jquery-3.4.1.js wie den folgenden enthalten: jquery-3.4.1.js . Eine solche Datei wird sich in Zukunft nicht ändern, so dass sie keine Probleme mit dem Caching verursacht.

Wenn jedoch beim Arbeiten mit Dateien ein bestimmtes Versionsschema nicht angewendet wird, können zwischengespeicherte Skripts, deren Inhalt sich ändert, wenn der Dateiname geändert wird, veraltet sein. Dies kann zu einem ernsthaften Problem werden, da beispielsweise nicht automatisch Sicherheitsupdates in Skripten eingefügt werden können, die Clients so schnell wie möglich erhalten sollten. Der Entwickler muss sich bemühen, solche Skripte im Cache zu aktualisieren. Darüber hinaus kann dies zu Anwendungsabstürzen führen, da der auf dem Client verwendete Code aus dem Cache von der neuesten Version des Codes abweicht, für den der Serverteil des Projekts entworfen wurde.

Wenn wir über Materialien sprechen, die häufig aktualisiert werden (Tag-Manager, Lösungen für A / B-Tests), ist das Zwischenspeichern mit CDN zwar eine Aufgabe, die gelöst werden kann, aber bereits viel komplizierter ist. Dienste wie das Commanders Act, Tag-Management-Lösungen, verwenden Web-Hooks, um neue Versionen zu veröffentlichen. Dies ermöglicht das Organisieren eines Cache-Flushs im CDN oder, noch besser, das Aufrufen eines Hash-Updates oder einer URL-Version.

▍ Adaptive Lieferung von Materialien an Kunden

Wenn wir über Caching sprechen, müssen wir außerdem berücksichtigen, dass die auf dem CDN verwendeten Caching-Einstellungen möglicherweise nicht für Ressourcen von Drittanbietern geeignet sind. Beispielsweise können solche Ressourcen die User-Agent-Sniffing-Technologie (adaptives Serving) verwenden, um bestimmten Browsern Versionen von Materialien bereitzustellen, die speziell für diese Browser optimiert wurden. Diese Technologien basieren auf regulären Ausdrücken oder auf einer Datenbank, die Informationen zum HTTP-Header von User-Agent sammelt, um die Funktionen des Browsers zu ermitteln. Nachdem sie erfahren haben, mit welchem ​​Browser sie es zu tun haben, geben sie ihm Materialien, die dafür entworfen wurden.

Hier können Sie zwei Dienste abrufen. Der erste ist googlefonts.com. Die zweite ist polyfill.io. Der Google Fonts-Dienst bietet für einige Ressourcen je nach den Fähigkeiten des Browsers verschiedene CSS-Codes (Links zu woff2-Ressourcen mithilfe des unicode-range ).

Hier sind die Ergebnisse einiger Google Fonts-Abfragen aus verschiedenen Browsern.


Abfrageergebnis für Chrome-Schriftarten


Google Fonts-Abfrageergebnis aus IE10

Mit Polyfill.io erhält der Browser nur die Polyfills, die er benötigt. Dies geschieht aus Performancegründen.

Sehen Sie sich beispielsweise an, was passiert, wenn Sie die folgende Anforderung in verschiedenen Browsern ausführen: https://polyfill.io/v3/polyfill.js?features=default

Als Antwort auf eine solche Anfrage von IE10 werden 34 KB Daten kommen. Und die Antwort darauf, gemacht aus Chrome, wird leer sein.

Wütend: einige Datenschutzaspekte

Dieser Artikel ist der letzte in der Reihenfolge, aber nicht von Bedeutung. Der Punkt ist, dass das unabhängige Hosten von Ressourcen von Drittanbietern in der Hauptdomäne des Projekts oder in seiner Unterdomäne die Privatsphäre der Benutzer gefährden und das Hauptwebprojekt beeinträchtigen kann.

Wenn Ihr CDN-System nicht richtig konfiguriert ist, werden möglicherweise Cookies von Ihrer Domain an einen Drittanbieter gesendet. Wenn auf CDN-Ebene keine ordnungsgemäße Filterung erfolgt, können Ihre Sitzungscookies, die unter normalen Umständen nicht in JavaScript (mit dem Attribut httponly ) verwendet werden können, an einen externen Host gesendet werden.

Genau das kann mit Trackern wie Eulerian oder Criteo passieren. Tracker von Drittanbietern können in Cookies eine eindeutige Kennung festlegen. Wenn sie Teil der Materialien der Websites wären, könnten sie die Kennung nach eigenem Ermessen während der Arbeit des Benutzers mit verschiedenen Webressourcen lesen.

Heutzutage bieten die meisten Browser einen Schutz gegen ein solches Verhalten von Trackern. Aus diesem Grund verwenden Tracker jetzt die CNAME Cloaking- Technologie und tarnen sich als eigene Skripte für verschiedene Projekte. Tracker bieten Site-Eigentümern nämlich die Möglichkeit, CNAME zu ihren Domain-Einstellungen für eine bestimmte Domain hinzuzufügen, deren Adresse normalerweise wie eine zufällige Zeichenfolge aussieht.

Obwohl nicht empfohlen wird, dass die Cookies der Website für alle Unterdomänen zugänglich sind (z. B. * .website.com), tun dies viele Websites. In diesem Fall werden solche Cookies automatisch an den getarnten Drittanbieter-Tracker gesendet. Infolgedessen können Sie nicht mehr über den Datenschutz sprechen.

Dasselbe passiert auch mit den Client-Hints- HTTP-Headern, die nur an die Hauptdomäne gesendet werden, da sie zum Erstellen eines digitalen Fingerabdrucks des Benutzers verwendet werden können. Stellen Sie sicher, dass der von Ihnen verwendete CDN-Dienst solche Header richtig filtert.

Zusammenfassung

Wenn Sie in Kürze das unabhängige Hosting von Ressourcen von Drittanbietern einführen möchten, möchte ich Ihnen einige Tipps geben:

• Hosten Sie Ihre wichtigsten JS-Bibliotheken, Schriften und CSS-Dateien. Auf diese Weise wird das Risiko eines Standortausfalls oder einer Leistungsminderung verringert, da die für den Betrieb des Standorts erforderliche Ressource aufgrund eines Drittanbieterdienstes nicht verfügbar war.
• Stellen Sie vor dem Zwischenspeichern von Ressourcen von Drittanbietern auf einem CDN sicher, dass Sie beim Benennen der Dateien ein Versionsverwaltungssystem verwenden oder dass Sie den Lebenszyklus dieser Ressourcen steuern können, indem Sie den CDN-Cache beim Veröffentlichen einer neuen Version des Skripts manuell oder automatisch leeren.
• Seien Sie sehr vorsichtig mit den Einstellungen für CDN, Proxyserver und Cache. Auf diese Weise können Sie das Senden von Cookies Ihres Projekts oder von Client-Hints Headern an Dienste von Drittanbietern verhindern.

Sehr geehrte Leser! Veröffentlichen Sie auf Ihren Servern Materialien anderer Personen, die für Ihre Projekte äußerst wichtig sind?