Eines der ersten Dinge, die ich meinen Kunden empfehle, um Websites zu beschleunigen, erscheint zunächst paradox: Sie müssen statische Ressourcen auf Ihrem Hosting platzieren und die CDN-Infrastruktur von Drittanbietern aufgeben. In diesem kurzen und hoffentlich sehr einfachen Beitrag möchte ich die Nachteile des Speicherns Ihrer statischen Dateien "nebenbei" und die enormen Vorteile des Hostings auf meinem Hosting skizzieren.
Worüber rede ich?
Entwickler klicken häufig auf den Link zu statischen Assets wie Bibliotheken oder Plugins, die sich auf Websites und CDN-Ressourcen befinden. Ein klassisches Beispiel ist jQuery.
Es gibt eine Reihe offensichtlicher Vorteile, aber mein Ziel später in diesem Artikel ist es, diesen Ansatz aufzuzeigen und zu zeigen, dass die Nachteile viel häufiger auftreten.
(Betrachten Sie zunächst die Vorteile).
- Das ist bequem. Das Verbinden von Dateien erfordert nur sehr wenig Aufwand. Kopieren Sie die HTML-Codezeile, und Sie sind fertig. Einfach.
- Wir erhalten Zugang zum CDN. code.jquery.com wird von StackPath bereitgestellt, es ist ein CDN. Durch die Verbindung mit den Inhalten dieser Ressource erhalten wir eine kostenlose Lieferung in CDN-Qualität.
- Benutzerdateien sind möglicherweise bereits zwischengespeichert. Wenn website-a.com auf code.jquery.com/jquery-3.3.1.slim.min.js verweist und der Benutzer von hier zu website-b.com wechselt, das auch auf code.jquery.com/jquery-3.3 verweist .1.slim.min.js , dann hat der Benutzer diese Datei im Cache.
Risiko: Geschwindigkeitsabfall und Ausfälle
Ich werde in diesem Beitrag nicht auf zu viele Details eingehen. Ich habe einen ganzen Artikel über die Lebensfähigkeit eines Dritten und die mit Verzögerungen und Unterbrechungen verbundenen Risiken. Es genügt zu sagen, dass wenn Sie über kritische Ressourcen im Zusammenhang mit Drittanbietern verfügen und der Anbieter unter Abstürzen und einem Rückgang der Geschwindigkeit oder Ausfällen leidet, dies eine ziemlich unangenehme Nachricht für Sie ist. Sie werden auch darunter leiden.
Wenn Sie Render-blockierendes CSS oder synchrones JS auf Ressourcen von Drittanbietern gehostet haben, übertragen Sie diese sofort auf Ihre eigene Infrastruktur. Kritische Assets sind zu wertvoll, um auf Servern von Drittanbietern belassen zu werden.
Risiko: Beendigung des Dienstes
Dies kommt viel seltener vor. Was passiert jedoch, wenn der Anbieter entscheidet, dass der Dienst eingestellt werden muss? Dies ist genau das, was Rawgit im Oktober 2018 getan hat. Bisher (zum Zeitpunkt des Schreibens) bietet eine grobe Suche im GitHub-Code immer noch mehr als eine Million Links zu dem Dienst, der derzeit geschlossen wird, und fast 20.000 bestehende Websites werden weiterhin verwendet beziehen Sie sich darauf.
Risiko: Sicherheitslücken
Eine andere Sache, auf die man achten sollte, ist eine einfache Vertrauenssache. Wenn wir Inhalte von Ressourcen Dritter auf unsere Seite bringen, müssen wir hoffen, dass die Dateien, die wir erhalten, genau das sind, was wir erwarten, und genau das tun, was wir von ihnen erwarten.
Stellen Sie sich den Schaden vor, der entstehen könnte, wenn jemand die Kontrolle über einen Anbieter wie code.jquery.com erlangen und kompromittierte oder böswillige Inhalte bereitstellen könnte. Es ist beängstigend darüber nachzudenken!
Subressourcenintegrität
Wir müssen allen in diesem Artikel genannten Drittanbietern Tribut zollen. Sie tun alles, um die Integrität der Subressource (Subresource Integrity - SRI) sicherzustellen. SRI ist der Mechanismus, mit dem der Anbieter den Hash (technisch gesehen einen Hash gefolgt von einer Base64-Codierung) der spezifischen Datei bereitstellt, die Sie erwarten und verwenden möchten. Der Browser kann dann überprüfen, ob die empfangene Datei genau Ihren Anforderungen entspricht.
<script src="https://code.jquery.com/jquery-3.4.1.slim.min.js" integrity="sha256-pasqAKBDmFT4eHoN2ndd6lN370kFiGUFyTiUHWhU7k8=" crossorigin="anonymous"></script>
Wenn Sie statische Inhalte unbedingt mit einer Ressource eines Drittanbieters verbinden müssen, stellen Sie erneut sicher, dass SRI aktiv ist. Sie können SRI selbst anschließen.
Abrechnung: Netzwerkverhandlungen
Eine der größten und dringendsten Kosten, die uns entstehen, sind die Kosten für die Eröffnung neuer TCP-Verbindungen. Für jede neue Ressource, die wir besuchen müssen, muss eine Verbindung hergestellt werden, was sehr teuer sein kann: DNS-Auflösung, TCP-Handshake, TLS-Aushandlung, die alle dazu beitragen, und die Geschichte wird schlimmer, wenn sich die Verbindung verzögert.
Ich werde ein Beispiel geben, das direkt von Bootstraps eigener Seite "Erste Schritte" stammt. Sie weisen Benutzer an, vier Dateien anzuhängen.
Diese vier Dateien befinden sich auf drei verschiedenen Ressourcen, dh wir müssen drei TCP-Verbindungen öffnen. Wie viel kostet das? Nun, mit einer ziemlich schnellen Verbindung ist der Inhalt dieser statischen Dateien auf der Seite 311 ms oder 1,65-mal langsamer als wenn Sie sie auf Ihrem eigenen Hosting platzieren.
Durch die Kontaktaufnahme mit drei verschiedenen Quellen für die Wartung statischer Assets verlieren wir gemeinsam die unnötigen 805 ms für Netzwerkgenehmigungen.
OK, es ist nicht so beängstigend, aber Trainline, mein Kunde, stellte fest, dass Besucher, als die Verzögerung um 300 ms reduziert wurde, zusätzliche 8 Millionen Pfund pro Jahr zahlten. Dies ist ein ziemlich einfacher Weg, um 8 Millionen zu verdienen.
Durch die Verlagerung unserer Ressourcen auf Ihre Domain entfallen die Kosten für zusätzliche Verbindungen vollständig.
Bei einer langsameren Verbindung mit einer längeren Verzögerung ist die Geschichte viel schlimmer. Für 3G ist die Version von Drittanbietern langsamer als 1.765s. Ich dachte, es sollte unsere Seite schneller machen.
Bei einer Verbindung mit großer Verzögerung betragen die gesamten Netzwerkkosten ungeheure 5,037 Sekunden. Was kann völlig vermieden werden.
Durch das Verschieben von Dateien in unsere eigene Infrastruktur wird die Downloadzeit von 5,4 auf 3,6 Sekunden reduziert.
Wenn dies kein guter Grund ist, Ihre statischen Ressourcen zu hosten, weiß ich nicht, was ich sonst noch mitbringen soll.
Voranschließen
Der springende Punkt meiner Präsentation hier ist natürlich, dass Sie keine statischen Ressourcen nebenbei veröffentlichen sollten, wenn Sie dies auf Ihrem Hosting tun können. Wenn Ihnen jedoch die Hände gebunden sind, können Sie mithilfe der Ressourcenverbindungsvorverbindung proaktiv eine TCP-Verbindung zu einer bestimmten Quelle (n) öffnen: Darüber hinaus ist die Bereitstellung als HTTP-Header noch schneller.
Hinweis Selbst wenn Sie Preconnect verwenden, verringert sich der Zeitverlust nur geringfügig: Sie müssen immer noch die entsprechenden Verbindungen öffnen, und es ist unwahrscheinlich, dass die Kosten jemals gerechtfertigt werden, insbesondere bei langsamen Verbindungen.
Abrechnung: Verlust der Priorisierung
Die zweite Abrechnung erfolgt in Form einer Optimierung auf Protokollebene, die wir vermissen, wenn wir den Inhalt in Domänen aufteilen. Wenn Sie HTTP / 2 verwenden, erhalten Sie Zugriff auf die Priorisierung.
Alle Flows (daher Ressourcen) mit derselben TCP-Verbindung behalten ihre Priorität, und Browser und Server arbeiten zusammen, um den Abhängigkeitsbaum aller dieser priorisierten Flows zu erstellen, sodass wir kritische Ressourcen schneller zurückgeben und möglicherweise die Lieferung weniger wichtiger Ressourcen verzögern können.
Hinweis Technisch gesehen können Anforderungen aufgrund des Zusammenführens von HTTP / 2-Verbindungen über verschiedene Domänen hinweg relativ zueinander priorisiert werden, sofern sie dieselbe IP-Adresse verwenden.
Wenn wir unsere Ressourcen auf verschiedene Domänen verteilen, müssen wir mehrere eindeutige TCP-Verbindungen öffnen. Wir können keine Prioritäten für diese Verbindungen setzen, dh wir verlieren die Fähigkeit, Dateien auf eine bestimmte durchdachte Weise zu liefern.
Indem wir den gesamten Inhalt auf einem Hosting hosten, können wir einen komplexeren Abhängigkeitsbaum erstellen. Jeder Thread hat eine eigene ID, da sie zum selben Baum gehören. Wenn wir so viel Inhalt wie möglich von einer Domain bereitstellen, können wir HTTP / 2 seine Arbeit erledigen lassen und Assets in der Hoffnung auf eine schnellere Antwort umfassender priorisieren.
Caching
Im Großen und Ganzen scheinen statische Ressourcen-Hosts ziemlich gut mit dem Festlegen langlebiger Max-Age-Direktiven zurechtzukommen. Dies ist sinnvoll, da sich statische Inhalte auf versionierten URLs (wie oben angegeben) niemals ändern werden. Dies macht es sehr sicher und rational, eine einigermaßen aggressive Cache-Richtlinie durchzusetzen.
Dies ist jedoch nicht immer der Fall. Wenn Sie Ihre Ressourcen unabhängig voneinander platzieren, können Sie viel individuellere Caching-Strategien entwickeln.
Mythos: Domänenübergreifendes Caching
Interessanter ist die Möglichkeit, domänenübergreifendes Asset-Caching durchzuführen. Das heißt, wenn viele Websites auf dieselbe Version von jQuery verweisen, die sich auf dem CDN befindet, haben Benutzer diese bestimmte Datei sicherlich bereits auf ihrem Computer. So etwas wie Peer-to-Peer-Ressourcenfreigabe. Dies ist eines der häufigsten Argumente für die Verwendung eines statischen Asset-Anbieters eines Drittanbieters.
Leider gibt es keine veröffentlichten Beweise, die diese Behauptungen stützen: Es gibt keinen Grund zu der Annahme, dass dies wahr ist. Umgekehrt deutet eine aktuelle Studie von Paul Calvano darauf hin, dass das Gegenteil der Fall sein könnte:
Es gibt eine merkliche Lücke zwischen dem Alter des CSS-Ressourcencaches und den Webschriftarten von Erst- und Drittanbietern. 95% der Erstanbieter-Schriftarten sind älter als 1 Woche, verglichen mit 50% der Drittanbieter-Schriftarten, die weniger als 1 Woche alt sind. Dies bietet gute Gründe für selbst gehostete Web-Schriftarten.
Im Allgemeinen scheint es, dass Inhalte von Drittanbietern schlechter zwischengespeichert werden als ihre eigenen.
Noch wichtiger ist, dass Safari diese Funktion aufgrund von Bedenken hinsichtlich des Missbrauchs der Privatsphäre vollständig deaktiviert hat, sodass die Shared-Cache-Technologie zum Zeitpunkt dieses Schreibens für 16% der Benutzer weltweit möglicherweise nicht funktioniert.
Kurz gesagt, obwohl dies theoretisch gut ist, gibt es keine Hinweise darauf, dass domänenübergreifendes Caching irgendwie effizient ist.
CDN-Zugang
Ein weiterer weit verbreiteter Vorteil der Kontaktaufnahme mit einem statischen Ressourcenanbieter besteht darin, dass wahrscheinlich eine leistungsstarke Infrastruktur mit CDN-Funktionen verwendet wird: globale Verteilung, Skalierbarkeit, geringe Latenz und hohe Verfügbarkeit.
Da dies absolut richtig ist, sollten Sie, wenn Sie sich für Ihre Leistung interessieren, Ihre eigenen Inhalte über das CDN ausführen. Angesichts der aktuellen Hosting-Preise gibt es nur wenige Gründe, warum Sie dies nicht für Ihre Ressourcen verwenden.
Mit anderen Worten: Wenn Sie glauben, dass Sie ein CDN für Ihre jQuery benötigen, benötigen Sie für alles ein CDN.
Hosten Sie statische Ressourcen auf Ihrem Hosting
Tatsächlich gibt es nur sehr wenige Gründe, Ihre statischen Ressourcen in der Infrastruktur eines anderen zu belassen. Die möglichen Vorteile sind oft ein Mythos, und selbst wenn nicht, sind Kompromisse einfach nicht wert. Das Laden von Ressourcen aus verschiedenen Quellen ist viel langsamer. Nehmen Sie sich in den nächsten Tagen zehn Minuten Zeit, um Ihre Projekte zu prüfen und die Kontrolle über alle statischen Ressourcen von Drittanbietern zu übernehmen.