[Не] verwenden Sie CDN

In fast nahezu jedem Artikel oder Tool zur Optimierung der Ladegeschwindigkeit von Websites findet sich der bescheidene Hinweis «Verwenden Sie ein CDN». CDN steht für Content Delivery Network oder Netzwerk zur Bereitstellung von Inhalten. Bei der Firma „Method Lab“ erhalten wir häufig Anfragen von Kunden zu diesem Thema, und einige aktivieren selbst ein CDN. Ziel dieses Artikels ist es, herauszufinden, welche Vorteile ein CDN in Bezug auf die Ladegeschwindigkeit einer Website bietet, welche Probleme auftreten können und in welchen Fällen die Nutzung eines CDN gerechtfertigt ist.

Die in der Abbildung hervorgehobenen Verzögerungen sind durch die Verwendung eines CDN verursacht.

Ein wenig Geschichte

Wie viele Technologien entstanden auch CDNs aus Notwendigkeit. Mit dem Wachstum der Internetverbindungen der Nutzer tauchten Online-Video-Dienste auf. Es ist selbstverständlich, dass Videoinhalte deutlich mehr Bandbreite erfordern als herkömmliche Inhalte auf Websites (Bilder, Texte und CSS- oder JS-Code).

Bei dem Versuch, einen Video-Stream parallel an viele Kunden von einem Server aus zu übertragen, wird wahrscheinlich die Internetverbindung des Servers zum Engpass. In der Regel reichen bereits einige Tausend Streams aus, um die typische Serververbindung zu überlasten. Natürlich können auch andere Ressourcenbeschränkungen eine Rolle spielen, aber die sind derzeit nicht von Belang. Zudem ist es wichtig zu beachten, dass die Erweiterung des Serverkanals zu kostspielig (und manchmal unmöglich) ist und oft auch nicht sinnvoll. Die Belastung des Kanals während der Übertragungen wird zyklisch erfolgen.

Das Problem der Bandbreitenbegrenzung eines einzelnen Servers wird hervorragend durch ein CDN gelöst. Kunden verbinden sich nicht direkt mit dem Server, sondern mit Knoten im CDN-Netzwerk. Im Idealfall gibt der Server einen Stream an den CDN-Knoten weiter, und das Netzwerk nutzt dann eigene Ressourcen, um diesen Stream an viele Benutzer zu liefern. Aus wirtschaftlicher Sicht zahlen wir nur für tatsächlich genutzte Ressourcen (das kann Bandbreite oder Traffic sein) und profitieren von exzellenter Skalierbarkeit unseres Services. Der Einsatz eines CDNs zur Auslieferung von schwerem Content ist völlig gerechtfertigt und sinnvoll. Es ist jedoch anzumerken, dass die größten Akteure in diesem Bereich (zum Beispiel Netflix) ihre eigenen CDNs aufbauen, anstatt große kommerzielle CDNs (Akamai, Cloudflare, Fastly usw.) zu nutzen.

Mit der Weiterentwicklung des Webs sind auch die Webanwendungen komplexer und schwerer geworden. Ein zentrales Problem ist die Ladegeschwindigkeit. Geschwindigkeitsenthusiasten haben recht schnell mehrere grundlegende Probleme identifiziert, die zu langsamen Ladezeiten führen. Eines dieser Probleme sind Netzwerkverzögerungen (RTT – Round Trip Time oder Ping-Zeit). Verzögerungen wirken sich auf viele Prozesse beim Laden der Webseite aus: die Einrichtung der TCP-Verbindung, den Start der TLS-Sitzung und das Laden jeder einzelnen Ressource (Bilder, JS-Dateien, HTML-Dokumente usw.).

Das Problem wurde verschärft durch die Nutzung des Protokolls HTTP/1.1 (bis zur Einführung von SPDY, QUIC und HTTP/2 die einzige Option), bei dem Browser nicht mehr als 6 TCP-Verbindungen zu einem Host öffnen. All dies führte zu Leerlaufzeiten der Verbindungen und einer ineffizienten Nutzung der Bandbreite. Teilweise wurde das Problem durch Domain-Sharding gelöst – der Erstellung zusätzlicher Hosts, um das Limit der Verbindungen zu überwinden.

Hier kommt die zweite Fähigkeit des CDN ins Spiel – die Reduzierung der Latenzen (RTT) durch die Vielzahl an Knotenpunkten und deren Nähe zum Benutzer. Die Entfernung spielt hierbei eine entscheidende Rolle: Die Lichtgeschwindigkeit ist begrenzt (ca. 200.000 km/s in Glasfaser). Das bedeutet, dass jede 1.000 km Strecke 5 ms Latenz oder 10 ms in der RTT hinzufügt. Dies sind die minimalen Zeitverluste für die Übertragung, da noch zusätzliche Verzögerungen durch Zwischengeräte auftreten. Da CDNs in der Regel in der Lage sind, Objekte auf ihren Servern zwischenzuspeichern, können wir von der Bereitstellung solcher Objekte über das CDN profitieren. Die Voraussetzungen dafür sind: das Objekt muss im Cache vorhanden sein und die Nähe des CDN-Punkts zum Benutzer im Vergleich zum Server der Webanwendung (Origin-Server). Es ist wichtig zu verstehen: Geografische Nähe eines CDN-Knotens garantiert nicht niedrige Latenzen. Die Routing-Strategien zwischen dem Client und dem CDN können so gestaltet sein, dass der Client sich mit einem Host in einem anderen Land oder sogar auf einem anderen Kontinent verbindet. Hier kommen die Beziehungen der Telekommunikationsanbieter und des CDN-Dienstes (Peering, Verfügbarkeit von Interconnects, Teilnahme an IX usw.) sowie die Traffic-Routing-Politik des CDNs ins Spiel. Zum Beispiel garantiert Cloudflare bei Verwendung der beiden Basispläne (kostenlos und günstig) nicht die Bereitstellung von Inhalten vom nächstgelegenen Knoten – die Auswahl des Hosts erfolgt, um die minimalen Kosten zu erreichen.

Viele führende Internetunternehmen ziehen das Interesse von Webentwicklern und Dienstanbieter zu Themen wie Ladegeschwindigkeit und Leistung von Websites auf sich. Zu diesen Unternehmen gehören Yahoo (Tool Yslow), AOL (WebPageTest) und Google (Dienst Page Speed Insights), die ihre eigenen Empfehlungen zur Beschleunigung von Websites entwickeln (insbesondere zur Kundenoptimierung). Später erscheinen neue Testwerkzeuge zur Messung der Geschwindigkeit von Websites, die ebenfalls Ratschläge zur Erhöhung der Geschwindigkeit geben. In jedem dieser Dienste oder Plugins gibt es die unveränderte Empfehlung „Verwenden Sie ein CDN“. Zur Erklärung des CDN-Effekts wird in der Regel auf die Verringerung von Netzwerkverzögerungen hingewiesen. Leider sind nicht alle bereit, zu verstehen, wie genau der Beschleunigungseffekt durch ein CDN erzielt wird und wie er gemessen werden kann, sodass die Empfehlung oft als gegeben angenommen und als Postulat verwendet wird. In Wirklichkeit sind jedoch längst nicht alle CDNs gleichermaßen nützlich.

Die Nutzung von CDN heute

Um den Nutzen der Anwendung von CDNs zu bewerten, müssen sie klassifiziert werden. Was man heutzutage in der Praxis antreffen kann (die Beispiele in Klammern sind natürlich nicht abschließend):

1. Kostenlose CDNs für die Bereitstellung von JS-Bibliotheken (MaxCDN, Google, Yandex).
2. CDN-Dienste zur Kundenoptimierung (zum Beispiel Google Fonts für Schriftarten, Cloudinary, Cloudimage für Bilder).
3. CDN für statische Inhalte und Ressourcenoptimierung in CMS (verfügbar in Bitrix, WordPress und anderen).
4. Allzweck-CDN (StackPath, CDNVideo, NGENIX, MegaFon).
5. CDN zur Beschleunigung von Websites (Cloudflare, Imperva, Airy).

Der entscheidende Unterschied zwischen diesen Typen besteht darin, welcher Teil des Traffics durch das CDN läuft. Typen 1-3 liefern nur einen Teil des Inhalts: von einer Anfrage bis zu mehreren Dutzend (in der Regel Bilder). Typen 4 und 5 beinhalten das vollständige Proxieren des Traffics über das CDN.

In der Praxis bedeutet dies die Anzahl der Verbindungen, die zum Laden der Website verwendet werden. Bei Verwendung von HTTP/2 nutzen wir eine einzige TCP-Verbindung zum Host, um eine beliebige Anzahl von Anfragen zu verarbeiten. Wenn wir die Ressourcen auf den Haupt-Host (Origin) und das CDN aufteilen, müssen die Anfragen auf mehrere Domains verteilt werden, was mehrere TCP-Verbindungen erfordert. Im schlimmsten Fall ergibt sich daraus: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. In dieser Formel sind die Verzögerungen in mobilen Netzwerken zur Aktivierung des Funkkanals des Geräts (sofern nicht aktiv) und die Verzögerungen am Mobilfunkmast nicht berücksichtigt.

So sieht es beim Laden der Website aus (die Verzögerungen beim Anschluss an das CDN bei RTT 150 ms sind hervorgehoben):

Wenn das CDN den gesamten Traffic der Website abdeckt (außer für externe Dienste), können wir eine einzige TCP-Verbindung verwenden und Verzögerungen bei der Verbindung zu zusätzlichen Hosts einsparen. Natürlich gilt dies für HTTP/2-Verbindungen.

Weitere Unterschiede ergeben sich aus der Funktionalität des jeweiligen CDNs – für den ersten Typ handelt es sich lediglich um und sogar eine statische Datei, für den fünften um die Anpassung mehrerer Inhaltsarten der Website zur Optimierung.

Die Möglichkeiten von CDNs zur Beschleunigung von Websites

Lassen Sie uns das vollständige Spektrum der Möglichkeiten von CDNs zur Beschleunigung von Websites beschreiben, ohne die Funktionalität der einzelnen CDN-Typen zu betrachten, und dann sehen wir, was in jedem von ihnen umgesetzt ist.

1. Textressourcen komprimieren

Die grundlegendste und verständlichste Möglichkeit, die jedoch häufig schlecht umgesetzt wird. Alle CDNs deklarieren Compression als Feature zur Beschleunigung. Wenn man jedoch näher hinsieht, zeigen sich Mängel:

• Es können niedrige Stufen für die dynamische Kompression verwendet werden – 5-6 (zum Beispiel für gzip maximal 9);
• In der statischen Komprimierung (Cache-Dateien) werden keine zusätzlichen Funktionen verwendet (z. B. zopfi oder brotli mit Stufe 11).
• Es gibt keine Unterstützung für effektive Brotli-Komprimierung (Einsparungen von etwa 20 % im Vergleich zu gzip).

Wenn Sie ein CDN verwenden, sollten Sie diese Punkte überprüfen: Nehmen Sie eine Datei, die vom CDN erhalten wurde, notieren Sie ihre Größe im komprimierten Format und dekomprimieren Sie sie manuell zum Vergleich (Sie können einen Online-Dienst mit Brotli-Unterstützung verwenden, z. B. всёсжать.рф).

2. Festlegung von Client-Cache-Headern

Eine einfache Funktion zur Beschleunigung: Setzen Sie Header für die Client-Caching (Browser). Der relevanteste Header ist cache-control, veraltet ist expires. Zusätzlich kann Etag verwendet werden. Wichtig ist, dass max-age bei cache-control groß genug ist (mindestens einen Monat und mehr); wenn Sie die Ressource maximal hart cachen möchten, können Sie die Option immutable hinzufügen.

CDN können den Wert von max-age herabsetzen, was Benutzer dazu zwingt, statische Inhalte häufiger neu zu laden. Ob dies mit dem Ziel verbunden ist, den Traffic im Netz zu erhöhen oder mit einer verbesserten Kompatibilität zu Websites, die den Cache nicht zurücksetzen können – ist unklar. Zum Beispiel beträgt der Standardwert für die Cache-Dauer in den Cloudflare-Headern 1 Stunde, was für unveränderliche statische Inhalte sehr wenig ist.

3. Bildoptimierung

Da CDN die Funktionen des Cachings und der Auslieferung von Bildern übernimmt, wäre es sinnvoll, diese auf der CDN-Seite zu optimieren und in dieser Form den Benutzern bereitzustellen. Abgesehen davon ist diese Möglichkeit nur für die CDN-Typen 2, 3 und 5 verfügbar.

Bilder können auf verschiedene Weisen optimiert werden: durch die Verwendung von fortschrittlichen Komprimierungsformaten (z. B. WebP), effizienteren Codierern (MozJPEG) oder einfach durch das Entfernen unnötiger Metadaten.

Im Allgemeinen gibt es zwei Arten solcher Optimierungen: mit Qualitätsverlust und ohne Qualitätsverlust. CDNs streben normalerweise danach, Verlustfreie Optimierung zu verwenden, um mögliche Beschwerden von Kunden über die Qualitätsänderung von Bildern zu vermeiden. In solchen Fällen wird der Gewinn minimal sein. In der Realität übersteigt die JPEG-Qualität häufig das erforderliche Niveau, sodass man sicher eine Rekompression mit einem niedrigeren Qualitätsfaktor durchführen kann, ohne das Nutzererlebnis zu beeinträchtigen. Auf der anderen Seite ist es schwierig, das Qualitätsniveau und die Einstellungen universell für alle möglichen Webanwendungen zu bestimmen, weshalb CDNs konservativere Einstellungen verwenden im Vergleich zu denen, die kontextabhängig angewendet werden könnten (Verwendungszweck der Bilder, Art der Webanwendung usw.)

4. Optimierung der TLS-Verbindung

Der Großteil des Traffics wird heute über TLS-Verbindungen übertragen, was bedeutet, dass wir zusätzliche Zeit für die TLS-Aushandlung aufwenden. In letzter Zeit wurden neue Technologien entwickelt, um diesen Prozess zu beschleunigen. Dazu gehören beispielsweise EC-Kryptografie, TLS 1.3, Sitzungs-Caching und Session Tickets, hardwarebeschleunigte Verschlüsselung (AES-NI) usw. Eine richtige TLS-Konfiguration ermöglicht es, die Verbindungszeit auf 0-1 RTT (ohne DNS und TCP) zu reduzieren.

Mit moderner Software ist es nicht schwierig, solche Praktiken in eigenen Infrastrukturen zu implementieren.

Nicht alle CDN-Anbieter setzen die besten Praktiken im Bereich TLS um. Dies kann durch das Messen der Zeit für die TLS-Verbindung überprüft werden (zum Beispiel mit WebPageTest). Ideal für eine neue Verbindung sind 1 RTT, 2 RTT ist ein durchschnittliches Niveau, 3 RTT und mehr sind schlecht.

Es ist auch zu beachten, dass selbst bei der Verwendung von TLS auf CDN-Ebene der Server mit unserer Webanwendung ebenfalls TLS verarbeiten muss, jedoch von der CDN-Seite, da der Traffic zwischen dem Server und dem CDN über das öffentliche Netzwerk verläuft. Im schlimmsten Fall erhalten wir doppelte Verzögerungen bei der TLS-Verbindung (die erste zu dem CDN-Host, die zweite zwischen diesem und unserem Server).

Bei einigen Anwendungen sollte man auf Sicherheitsaspekte achten: Der Datenverkehr wird normalerweise an den Knotenpunkten des CDN entschlüsselt, was eine potenzielle Möglichkeit für den Datenverkehrsabbau darstellt. Eine Option zur Verarbeitung ohne Offenlegung des Datenverkehrs wird in der Regel in den Premium-Tarifen gegen eine zusätzliche Gebühr angeboten.

5. Reduzierung der Verbindungslatenz

Der Hauptvorteil eines CDN, über den alle reden: niedrige Latenzen (geringere Distanz) zwischen dem CDN-Host und dem Nutzer. Dies wird durch die Schaffung einer geografisch verteilten Netzwerkarchitektur erreicht, in der sich die Hosts an den Verbraucherzentren (Städten, Traffic Exchange Points usw.) befinden.

In der Praxis können die Prioritäten für unterschiedliche Netzwerke in bestimmten Regionen liegen. Zum Beispiel haben russische CDNs mehr Points of Presence in Russland. Amerikanische Anbieter konzentrieren sich hauptsächlich auf den Ausbau des Netzwerks in den USA. Zum Beispiel hat einer der größten CDNs, Cloudflare, nur zwei Punkte in Russland – Moskau und St. Petersburg. Das bedeutet, dass wir maximal etwa 10 ms Latenz im Vergleich zur direkten Bereitstellung in Moskau sparen können.

Die meisten westlichen CDNs haben überhaupt keine Knoten in Russland. Wenn Sie sich mit ihnen verbinden, können Sie nur die Latenz für Ihr russisches Publikum erhöhen.

6. Inhaltsoptimierung (Minifizierung, strukturelle Änderungen)

Der komplizierteste und technisch anspruchsvollste Punkt. Änderungen des Inhalts während der Lieferung können sehr riskant sein. Selbst bei der Minifizierung: Die Reduzierung des Quellcodes (durch überflüssige Leerzeichen, unwichtige Konstruktionen usw.) kann die Funktionalität beeinflussen. Wenn es um ernsthaftere Änderungen geht – das Verschieben von JavaScript-Code an das Ende des HTML, das Zusammenführen von Dateien und ähnliches – steigt das Risiko, die Funktionalität der Website zu beeinträchtigen, noch mehr.

Deshalb beschäftigen sich nur einige CDNs vom Typ 5 damit. Natürlich wird es nicht möglich sein, alle notwendigen Änderungen zur Beschleunigung zu automatisieren – eine manuelle Analyse und Optimierung ist erforderlich. Beispielsweise gehört das Entfernen von ungenutztem oder doppeltem Code zu den manuellen Aufgaben.

In der Regel werden alle derartigen Optimierungen über die Einstellungen verwaltet, und die gefährlichsten sind standardmäßig deaktiviert.

Unterstützung von Beschleunigungsfunktionen je nach Art des CDN

Lassen Sie uns also schauen, welche Beschleunigungsmöglichkeiten die verschiedenen Arten von CDN bieten.

Zur besseren Übersicht wiederholen wir die Klassifikation.

1. Kostenlose CDNs für die Bereitstellung von JS-Bibliotheken (MaxCDN, Google, Yandex).
2. CDN-Dienste zur Kundenoptimierung (zum Beispiel Google Fonts für Schriftarten, Cloudinary, Cloudimage für Bilder).
3. CDN für statische Inhalte und Ressourcenoptimierung in CMS (verfügbar in Bitrix, WordPress und anderen).
4. Allzweck-CDN (StackPath, CDNVideo, NGENIX, MegaFon).
5. CDN zur Beschleunigung von Websites (Cloudflare, Imperva, Airy).

Nun vergleichen wir die Funktionen und Arten von CDN.

Möglichkeit
Typ 1
Typ 2
Typ 3
Typ 4
Typ 5

Textkompression
+–
–
+–
+–
+

Cache-Header
+
+
+
+
+

Bilder
–
+–
+–
–
+

TLS
–
–
–
+–
+

Latenzzeiten
–
–
–
+
+

Inhalt
–
–
–
–
+

In dieser Tabelle zeigt „+“ vollständige Unterstützung an, „–“ kein Support und „+–“ partielle Unterstützung. Es können natürlich Abweichungen von dieser Tabelle in der Realität auftreten (z.B. könnte ein allgemeines CDN Funktionen zur Bildoptimierung implementieren), aber sie ist für ein allgemeines Verständnis hilfreich.

Ergebnisse

Ich hoffe, dass Sie nach dem Lesen dieses Artikels ein klareres Bild über die Empfehlung „verwenden Sie CDN“ zur Beschleunigung von Websites haben.

Wie in allen Dingen sollte man den Marketingversprechungen eines Dienstes nicht blind glauben. Der Effekt muss gemessen und unter realen Bedingungen getestet werden. Wenn Sie bereits ein CDN nutzen, überprüfen Sie dessen Effektivität anhand der in diesem Artikel beschriebenen Kriterien.

Es ist möglich, dass die Nutzung eines CDN momentan die Ladezeiten Ihrer Website verlangsamt.

Als allgemeine Empfehlung können Sie Folgendes beachten: Lernen Sie Ihr Publikum kennen und bestimmen Sie dessen geografische Reichweite. Wenn Ihr Hauptpublikum im Umkreis von 1-2 Tausend Kilometern konzentriert ist, benötigen Sie kein CDN für seinen eigentlichen Zweck – die Senkung der Latenzzeiten. Stattdessen können Sie Ihren Server näher an den Nutzern platzieren und ihn entsprechend konfigurieren, um die meisten der in dem Artikel beschriebenen Optimierungen kostenlos und dauerhaft zu erhalten.

Falls Ihr Publikum tatsächlich geografisch verteilt ist (Radius von über 3000 Kilometern), kann die Nutzung eines hochwertigen CDNs von Vorteil sein. Sie sollten jedoch im Voraus verstehen, was Ihr CDN beschleunigen kann (siehe Tabelle der Möglichkeiten und deren Beschreibung). Die Geschwindigkeit Ihrer Website bleibt dennoch eine komplexe Aufgabe, die nicht allein durch die Anbindung eines CDNs gelöst werden kann. Neben den angegebenen Optimierungen bleiben die effektivsten Mittel zur Beschleunigung außen vor: die Optimierung des Servers, fortgeschrittene Änderungen auf der Clientseite (Entfernung ungenutzten Codes, Optimierung des Renderprozesses, Arbeiten mit Inhalten, Schriften, Responsivität usw.).

Quelle: habr.com