Warum ein CDN meistens sinnlos ist

Wenn es um die Geschwindigkeit einer Webseite geht, liest man Immer wieder von verschiedenen Seiten, wie sinnvoll ein CDN ist. Bei einem CDN (Content Delivery Network) handelt es sich meistens um über die Welt verteilte Server, von denen man Inhalte statt vom eigenen Server abruft. Bekannte Vertreter sind z.B. Cloudflare, CloudFront von aws (Amazon) oder Azure CDN von Microsoft.

Vorteile eines CDN für eigene Inhalte

  • Der eigene (langsame) Server wird entlastet
  • Leistungsspitzen werden besser aufgefangen
  • Bei weltweiten Besuchern wird der Inhalt von einem näheren Server des Besuchers (z.B. USA statt Deutschland) ausgeliefert

Muss die eigene Webseite also ab und an mit einem Besucheransturm rechnen oder hat viele internationale Besucher, macht ein CDN durchaus Sinn. Bei einer Webseite eines regionalen Geschäftes wie z.B. einem Friseur sind weder Leistungsspitzen noch weltweite Besucher erwartbar. Und bei einem langsamen eigenen Server ist der Umzug zu einem besseren Hoster sinnvoller als auf ein CDN zu setzen.

Vorteile für fremde Inhalte

Ein bekanntes CDN für fremde Inhalte ist z.B. Google Fonts. Der Vorteil daran war (ja, war – dazu später mehr), dass der Inhalt nur einmal von den Google-Servern geladen wird und dann im Browser des Besuchers gespeichert wird. Der beliebte Font ‚Roboto‘ musste so z.B. nicht noch einmal für eine Webseite geladen werden, wenn eine andere Webseite ihn schon verhwendet hat und der Font lokal im Speicher des Browsers zwischengespeichert wurde. Genauso gibt es CDN für andere beliebte Dateien, wie z.B. jquery, Bootstrap usw. Man sparte bei deren Verwendung also viel unnötige Ladezeit.

Browser-Cache ist auf eine Domain begrenzt

Beginnend mit der Version 85 von Chrome hat sich das nun geändert (und auch Firefox wird wahrscheinlich es zukünftig genauso handhaben): Der lokale Cache im Browser gilt nur noch für eine Domain. Das heißt, wenn die Domain www.eins.de den Font Roboto von den Google Webfonts lädt, wird der nun lokal gespeicherte Roboto-Font nur noch für die Domain www.eins.de genutzt. Die Domain www.zwei.de wird denn Font also wieder von Google herunterladen und erneut lokal speichern.

Das macht doch keinen Sinn, oder?

Nun ja, es verschlechtern sich auf jeden Fall die Ladezeiten sowie der Speicherverbrauch des Browsers. Der Sinn dahinter ist, das manipulierte Dateien auf Seiten keine Gefahr für andere Seiten mehr darstellen sollen. Wurde oben z.B. die Domain www.eins.de gehackt, so dass sie statt den Font Roboto einen schädlichen Trojaner verwendet, würde dieser Trojaner eventuell auch auf der Seite www.zwei.de ausgeführt, wenn diese den vermeintlichen Roboto-Font im Cache des Browsers verwendet.

Warum so viele WordPress-Plugins ein CDN integrieren

Sehr sehr viele WordPress-Plugins integrieren mittlerweile ein CDN, egal ob es sich um Cache-Plugins, Sicherheits-Plugins, Medien-Plugins (die natürlich alle Bilder auf ein CDN auslagern wollen) oder was auch immer handelt. Es erweckt den Anschein, das WordPress-Nutzer unbedingt ein CDN benötigen.

Doch ist das so? In meinen Augen sprechen zwei Gründe für den CDN-Hype bei Plugin-Erstellern:

  • Affiliate: Wenn ein Nutzer ein Abo für ein CDN über ein WordPress-Plugin abschließt, bekommt der Plugin-Ersteller eine nicht unerhebliche Summe an Provision.
  • Abo: WordPress-Plugins unterliegen der GPL, sie dürfen also kostenlos beliebig weiter gegeben werden. Ja, auch bezahlte Plugins! Es macht also wenig Sinn, für ein Plugin, das man z.B. öfters benötigt, mehr als eine ‚Lizenz‘ zu zahlen. Die Plugin-Betreiber wissen das und schaffen so eine künstliche Abhängigkeit. Deshalb integrieren viele Plugins so SaaS (Software as a Service), oder eben ein CDN.
    Das heißt, ein Teil der Funktion eines Plugins findet nicht auf dem eigenen Server, sondern auf einem fremden Server statt. Mit dieser Strategie generiert man als Plugin-Autor konstante monatliche / jährliche Zahlungen. Außerdem muss so für jede Installation ein seperates Abo abgeschlossen werden.

Der Hauptgrund ist also wie so oft lediglich das liebe Geld und nicht der Vorteil für den Nutzer, der bei vielen Plugins sehr vorgeschoben wirkt.

CDN und DSGVO – oft nicht vereinbar

Bei jedem CDN wird auch unweigerlich die IP des Nutzers übermittelt. Das ist künftig aber ohne Zustimmung des Users untersagt. Sie benötigen also auf jeden Fall eine Auftragsdatenvereinbarung mit dem CDN. Außerdem müsste nach meinem Rechtsverständnis in den Consent-Banner (‚Cookie-Banner‘) auf das CDN hingewiesen werden. Dies wird jedoch von den meisten Webseiten ignoriert, bin gespannt wann es darüber die ersten Gerichtsurteile gibt.

Fazit

Bei Leistungsdefiziten sollten sie als erstes ihre Webseite sowie den Webserver optimieren. Statt Shared Hosting oder Shared Server z.B. einen eigenen Dedicated Server. Sollten sie dann immer noch Geschwindigkeitsprobleme feststellen, und erst dann, sollten sie über den Einsatz eines CDN nachdenken.

5 Kommentare

    • Ganz deiner Meinung, gigantisch trifft es gut. Bei hohem Datenaufkommen sollte man erstmal über einen Load-Balancer mit mehreren Servern dahinter nachdenken, bevor man sich einem CDN ausliefert. Da dieser Kreis hier aber nicht meine ‚Zielgruppe‘ ist, finde ich wie du ein CDN meistens unsinnig

  1. Hast du das mit den Fonts mal überprüft? Durch Privacy-Maßnahmen in den Browsern wird mittlerweile jede Ressource separat gecached.
    d.h. Fonts von Google Fonts helfen nur Google aber nicht der Performance der eigenen Seite weil sie trotzdem geladen werden obwohl auf einer anderen Seite der selbe Font schon mal gebraucht wurde.
    (by the way die Checkboxen unter dem Commentfeld sind durch den weißen Rahmen nicht sichtbar)

    • Danke für den Hinweis, werde die Kommentarfelder doch farblich etwas abheben. Mit den Fonts sind wir ja einer Meinung, wie dein nächster Kommentar zeigt 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert