In den letzten Jahren bieten immer mehr Plattformen zur Optimierung von Frontend-Projekten Möglichkeiten für das Self-Hosting oder das Proxieren von Drittressourcen an. Akamai ermöglicht es, für selbst erstellte URLs festzulegen. Cloudflare verfügt über die Technologie Edge Workers. Fasterzine kann URLs auf den Seiten so gestalten, dass sie auf externe Ressourcen verweisen, die sich auf der Hauptdomain der Website befinden.
Wenn bekannt ist, dass die Drittservices, die in Ihrem Projekt verwendet werden, nicht allzu häufig geändert werden, und dass der Auslieferungsprozess an Endkunden verbessert werden kann, denken Sie sicherlich über das Proxieren solcher Services nach. Mit diesem Ansatz können Sie diese Ressourcen näher an die Nutzer bringen und mehr Kontrolle über ihr Caching auf der Clientseite erlangen. Dies schützt zudem die Nutzer vor Problemen, die durch den Ausfall eines Drittservices oder einer Verschlechterung seiner Leistung verursacht werden.
Gut: Leistungssteigerung
Die eigenständige Bereitstellung externer Ressourcen verbessert die Leistung auf eine ganz offensichtliche Weise. Der Browser muss nicht unnötig DNS-Anfragen stellen, keine TCP-Verbindungen aufbauen und kein TLS-Handshake auf einer externen Domain durchführen. Wie sich die eigenständige Bereitstellung externer Ressourcen auf die Leistung auswirkt, lässt sich deutlich an den folgenden beiden Abbildungen erkennen.
Externe Ressourcen werden aus externen Quellen geladen (entnommen )
Externe Ressourcen werden dort gespeichert, wo auch die anderen Materialien der Website liegen (entnommen )
Die Situation wird zusätzlich verbessert, da der Browser die Möglichkeiten zur Multiplexierung und Priorisierung von Daten über die bereits mit der Hauptdomain etablierte HTTP/2-Verbindung nutzen kann.
Wenn Sie keine externen Ressourcen hosten, können diese aufgrund der unterschiedlichen Domains nicht priorisiert werden. Dies führt dazu, dass sie um die Bandbreite des Kunden konkurrieren. Infolgedessen kann die Ladezeit für Seiteninhalte, die entscheidend für die Gestaltung der Seite sind, viel länger sein als bei optimalen Bedingungen. eine Präsentation über die HTTP/2-Priorisierung, in der dies ausführlich erklärt wird.
Es kann angenommen werden, dass die Verwendung von Attributen in Links zu externen Ressourcen preconnect bei der Lösung des Problems hilfreich sein kann. Wenn jedoch zu viele solcher Links zu verschiedenen Domains vorhanden sind, kann dies tatsächlich die Verbindung zu einem kritischen Zeitpunkt überlasten.
Wenn Sie externe Ressourcen selbst hosten, können Sie kontrollieren, wie diese Ressourcen dem Kunden bereitgestellt werden. Insbesondere geht es um Folgendes:
- Sie können einen Datenkompressionsalgorithmus anwenden, der am besten für jeden Browser geeignet ist (Brotli/gzip).
- Die Cache-Zeit für Ressourcen kann erhöht werden, die bei selbst den bekanntesten Anbietern oft nicht besonders hoch ist (zum Beispiel ist der entsprechende Wert für das GA-Tag auf 30 Minuten festgelegt).
Es ist sogar möglich, den TTL-Wert für eine Ressource, beispielsweise auf ein Jahr, zu erweitern, indem entsprechende Materialien in Ihre Cache-Management-Strategie aufgenommen werden (URL-Hashes, Versionsverwaltung und so weiter). Darauf werden wir gleich eingehen.
▍Schutz vor Ausfällen von Drittanbieterdiensten oder deren Abschaltung
Ein weiterer interessanter Aspekt des selbstständigen Hostings externer Ressourcen ist, dass es hilft, Risiken zu mindern, die mit Ausfällen von Drittanbieterdiensten verbunden sind. Stellen Sie sich vor, das von Ihnen verwendete externe Tool für A/B-Tests wird als blockierendes Skript implementiert, das im Kopfbereich der Seite geladen wird. Wenn dieses Skript langsam geladen wird oder gar nicht lädt, wird die Seite leer sein. Sollte das Laden des Skripts viel Zeit in Anspruch nehmen, erscheint die Seite mit großer Verzögerung. Oder nehmen wir an, das Projekt verwendet eine Bibliothek, die von einem externen CDN geladen wird. Angenommen, dieser Dienst hat einen Ausfall oder wurde in einem bestimmten Land blockiert. Eine solche Situation würde die Funktionsweise der Website beeinträchtigen.
Um herauszufinden, wie Ihre Website funktioniert, wenn ein externer Dienst nicht verfügbar ist, können Sie den Abschnitt SPOF auf .
Den Abschnitt SPOF auf webpagetest.org
▍Was ist mit Cache-Problemen in Browsern? (Hinweis: Das ist ein Mythos)
Es könnte den Anschein haben, dass die Nutzung öffentlicher CDNs automatisch zu einer besseren Leistung der Ressourcen führt, da diese Dienste über qualitativ hochwertige Netzwerke verfügen und global verteilt sind. Doch in Wirklichkeit ist alles etwas komplizierter.
Angenommen, wir haben mehrere verschiedene Websites: website1.com, website2.com, website3.com. Auf allen diesen Websites verwenden wir die jQuery-Bibliothek. Wir binden sie über ein CDN ein, zum Beispiel von googleapis.com. Man könnte erwarten, dass der Browser die Bibliothek einmal lockt und im Cache speichert und sie dann für die Nutzung auf allen drei Websites verwendet. Dies könnte die Netzwerklast reduzieren. Möglicherweise könnte es auch helfen, irgendwo Kosten zu sparen und die Leistung der Ressourcen zu verbessern. Aus praktischer Sicht sieht alles jedoch anders aus. Zum Beispiel verfügt Safari über eine Funktion, die als : im Cache werden doppelte Schlüssel verwendet, die auf der Quelle des Dokuments und der Quelle der Drittanbieter-Ressource basieren. einen guten Artikel zu diesem Thema.
Ältere Studien und , sowie aktuellere Pola Calvano zeigt, dass Ressourcen nicht so lange in den Browser-Caches gespeichert werden, wie wir erwarten könnten: „Es gibt eine erhebliche Diskrepanz zwischen der Cache-Dauer eigener und fremder Ressourcen des Projekts. Dabei geht es um CSS und Webfonts. Genauer gesagt, die Cache-Dauer von 95 % eigenen Schriftarten überschreitet eine Woche, während die Cache-Dauer von 50 % externen Schriftarten weniger als eine Woche beträgt! Dies gibt Webentwicklern triftige Gründe, Schriftdateien selbst zu hosten!".
Wenn Sie daher fremde Materialien selbst hosten, werden Sie keine Leistungseinbußen aufgrund des Browser-Cachings feststellen.
Nachdem wir nun die Vorteile des Selbsthostings externer Ressourcen betrachtet haben, lassen Sie uns darüber sprechen, wie man eine gute Umsetzung dieses Ansatzes von einer schlechten unterscheidet.
Schlecht: Der Teufel steckt im Detail
Das Verschieben externer Ressourcen auf die eigene Domain kann nicht automatisch erfolgen, ohne sich um das richtige Caching dieser Ressourcen zu kümmern.
Eines der Hauptprobleme hier ist die Cache-Zeit. Beispielsweise werden Versionsinformationen in die Namen von Drittanbieter-Skripten ungefähr so eingebaut: jquery-3.4.1.js. Eine solche Datei wird in Zukunft nicht geändert, was keine Probleme mit ihrem Caching verursachen sollte.
Wenn jedoch kein Versionsschema für die Arbeit mit Dateien verwendet wird, können zwischengespeicherte Skripte, deren Inhalte sich bei unverändertem Dateinamen ändern, veraltet sein. Dies kann ein ernsthaftes Problem darstellen, da es beispielsweise nicht ermöglicht, Sicherheitsupdates automatisch in Skripte einzufügen, die so schnell wie möglich an die Kunden geliefert werden sollten. Der Entwickler muss sich bemühen, solche Skripte im Cache zu aktualisieren. Darüber hinaus kann dies zu Problemen mit der Anwendung führen, da der im Cache verwendete Code von der aktuellen Version des Codes abweicht, auf die die Serverseite des Projekts angewiesen ist.
Es ist wahr, dass bei Materialien, die häufig aktualisiert werden (wie Tag-Manager oder A/B-Testlösungen), das Caching durch CDNs eine lösbare, aber deutlich komplexere Aufgabe darstellt. Dienste wie Commanders Act, die Tag-Management-Lösungen anbieten, verwenden beim Veröffentlichen neuer Versionen Webhooks. Dies ermöglicht das Organisieren des Cache-Flushs auf dem CDN oder, was noch besser ist, die Möglichkeit, die Hash- oder URL-Version zu aktualisieren.
▍Adaptive Bereitstellung von Inhalten an Kunden
Darüber hinaus muss man beim Thema Caching berücksichtigen, dass die Caching-Einstellungen, die auf CDNs verwendet werden, möglicherweise nicht für bestimmte Drittanbieterressourcen geeignet sind. Zum Beispiel können solche Ressourcen die Technologie des User-Agent-Sniffings (adaptive serving) einsetzen, um bestimmten Browsern speziell optimierte Versionen der Inhalte bereitzustellen. Diese Technologien verlassen sich auf reguläre Ausdrücke oder eine Datenbank, in der Informationen zu HTTP-Headern gesammelt werden. User-Agent. Basierend auf dem verwendeten Browser liefern sie ihm spezifische Inhalte.
Hier kann man an zwei Dienste denken. Der erste ist googlefonts.com. Der zweite ist polyfill.io. Der Dienst von Google Fonts stellt für eine bestimmten Ressource unterschiedliche CSS-Codes zur Verfügung, die von den Möglichkeiten des Browsers abhängen (indem er Links zu woff2-Ressourcen nutzt und unicode-range).
Hier sind die Ergebnisse einiger Anfragen an Google Fonts, die aus verschiedenen Browsern durchgeführt wurden.
Ergebnis der Anfrage an Google Fonts aus Chrome
Ergebnis der Anfrage an Google Fonts aus IE10
Polyfill.io liefert dem Browser nur die benötigten Polyfills. Dies geschieht aus Leistungsgründen.
Sehen wir uns zum Beispiel an, was passiert, wenn wir die folgende Anfrage aus verschiedenen Browsern durchführen:
Als Antwort auf eine solche Anfrage aus IE10 kommen 34 KB Daten zurück. Die Antwort aus Chrome hingegen bleibt leer.
Nachdenklich: einige Überlegungen zur Privatsphäre
Dieser Punkt steht am Ende, ist jedoch nicht weniger wichtig. Es geht darum, dass das Hosting von externen Ressourcen auf der Hauptdomain oder deren Subdomänen die Privatsphäre der Nutzer gefährden und sich negativ auf das Hauptwebprojekt auswirken kann.
Wenn Ihr CDN-System nicht richtig konfiguriert ist, kann es dazu führen, dass Sie Cookies Ihrer Domain an einen externen Dienst senden. Wenn auf CDN-Ebene keine ordnungsgemäße Filterung organisiert ist, könnten Ihre Sitzungscookies, die normalerweise in JavaScript nicht verwendet werden können (mit dem Attribut httponly), an einen fremden Host gesendet werden.
Genau das könnte mit Trackern wie Eulerian oder Criteo passieren. Externe Tracker könnten eine eindeutige Kennung in Cookies setzen. Wenn sie Teil von Website-Inhalten sind, könnten sie die Kennung nach Belieben während der Interaktion des Nutzers mit verschiedenen Webressourcen lesen.
Heutzutage verfügen die meisten Browser über Schutzmechanismen gegen ein solches Verhalten von Trackern. Infolgedessen verwenden Tracker jetzt Technologien wie , die sich als eigene Skripte verschiedener Projekte tarnen. Konkret bieten Tracker Webseitenbetreibern an, in ihren Einstellungen ein CNAME für eine bestimmte Domain hinzuzufügen, deren Adresse normalerweise wie eine zufällige Zeichenfolge aussieht.
Obwohl es nicht empfohlen wird, die Cookies der Webseite für alle Subdomains verfügbar zu machen (zum Beispiel — *.website.com), wird dies auf vielen Webseiten praktiziert. In diesem Fall werden solche Cookies automatisch an den getarnten Drittanbieter-Tracker gesendet. Das Ergebnis ist, dass von Privatsphäre nicht mehr gesprochen werden kann.
Darüber hinaus geschieht dasselbe mit den HTTP-Headern , die nur an die Hauptdomain gesendet werden, da sie zur Erstellung des Nutzers verwendet werden können. Achten Sie darauf, dass der von Ihnen verwendete CDN-Dienst solche Header korrekt filtert.
Ergebnisse
Wenn Sie in naher Zukunft planen, ein selbständiges Hosting von Drittressourcen einzuführen — lassen Sie mich Ihnen einige Ratschläge geben:
- Hosten Sie Ihre wichtigsten JS-Bibliotheken, Schriftarten und CSS-Dateien selbst. Dies reduziert das Risiko von Website-Ausfällen oder Leistungsabfällen aufgrund von unzugänglichen, für den Betrieb der Website essentiellen Ressourcen, die von einem Drittanbieter abhängig sind.
- Bevor Sie externe Ressourcen im CDN cachen, stellen Sie sicher, dass Sie eine Namenskonvention mit Versionskontrolle verwenden oder dass Sie den Lebenszyklus dieser Ressourcen verwalten können, indem Sie den CDN-Cache manuell oder automatisch bei der Veröffentlichung einer neuen Version des Skripts zurücksetzen.
- Achten Sie sehr genau auf die Einstellungen des CDN, des Proxy-Servers und des Caches. Dies ermöglicht es Ihnen, zu verhindern, dass Cookies oder Header Ihres Projekts an Drittanbieter gesendet werden.
Client-Hintsexternen Services.
Sehr geehrte Leser! Laden Sie auf Ihren Servern fremde Materialien hoch, die für den Betrieb Ihrer Projekte von entscheidender Bedeutung sind?
Quelle: habr.com
