Eigenes CDN in WordPress nutzen

bueltge.de [by:ltge.de] wird von Frank Bültge geführt, administriert und gestaltet. Alle Inhalte sind persönlich von mir ausgewählt und erstellt, nach bestem Gewissen und Können, was die Möglichkeit von Fehlern nicht ausschließt.

Kommentare

  
  1. Toller Artikel - wieder mal. Danke Frank! Das werde ich heute gleich ausprobieren. Das Wetter zwingt sich dafür geradezu auf. 🙂

  2. Connie sagt:

    was ist CDN? Canadisches Diplomatisches Natrium?

    Wenn das nicht klar wird, nützt der ganze Artikel nichts...

    Ich weiß es jedenfalls nicht, Gruss,

    Connie

    • @Connie: ergänzt, auch wenn ich denke, dass man dies wissen sollte, wenn man den Inhalt des Artikels nutzen will. Nur machen bringt ja nichts, man sollte verstehen, wenn man in die Performance-Optimierung in diesem Grad geht.

  3. Dirk sagt:

    Ich habe ja einfach unter „Einstellungen › Mediathek“ bei „Uploads in folgendem Ordner speichern“ den Pfad entsprechend angepasst, so dass die Medien im htdocs des anderen Systems liegen, und dann bei „Kompletter Pfad zu den Dateien“ eben diesen entsprechend angepasst.

    So lange es sich nicht um tatsächlich hardwareseitig getrennte Systeme handelt, hat es allenfalls einen ästhetischen Nutzen 🙂

  4. Also, bei mir läuft es schon. Streng nach Vorgabe. 🙂 Danke noch einmal!

  5. Ralf sagt:

    Über CDNs habe ich mir auch schon lange Gedanken gemacht. Allerdings habe ich nicht daran gedacht die alten URLs per Funktion umzuleiten, sondern direkt per .htaccess.
    Gerade wenn man noch etwas ältere Plugins im Gebrauch hat die nicht ganz so sauber programmiert sind, fährt man mit einem URL-Rewrite vielleicht besser.
    Vor allem Medien in älteren Beiträgen kann man mit einem URL-Rewrite in der .htaccess weiterhin nutzen ohne die alten Beiträge erneut zu bearbeiten.

    Ist aber ein interessantes Thema das ich mal weiter verfolgen werde.

  6. Connie sagt:

    Hallo Frank,

    ja, wenn ich weiss was CDN ist, kann ich den Artikel nutzen
    wenn ich nicht weiss was das ist und erhalte eine Erklärung, kann ich auch Nutzen aus dem Artikel ziehen

    so beißt sich didaktisch die Katze in den Schwanz ;=)

    Danke für die Erkärung!

  7. Tim sagt:

    Hallo Frank,

    wie es aussieht ist das CDN für dein Blog noch nicht ganz fertig. Im Moment leitet jede Anfrag an eine deiner CDN Subdomains wieder auf die Hauptdomain zurück (301 Umleitung). Das macht das Ganze langsamer als ohne CDN.

    Ohne getrennte Webserver für die CDN Subdomains verpufft der Effekt. Der Browser kann zwar parallel mehrere Anforderungen an die verschiedenen Domains absetzen, aber er wird gleich anschließend ausgebremst, weil er auf die einzelne Hauptdomain warten muss, die alle Anfragen abwickelt.

    • @Tim: wenn ich eines der CDNs aufrufe, dann komme ich auf den Pfad, jedoch ein Forbidden, also kein 301 - oder übersehe ich da was? Danke

  8. Hallo Frank!

    Schöner Artikel, wobei ich als ich CDN gelesen hab erstmal etwas anderes erwartet hab. CDN hat - zumindest für mich - etwas mit verteilten Serveren zu tun an verschiedenen regionalen Standorten, die dann je nach schnellstmöglicher Verfügbarkeit die Daten liefern. Lokale CDN sind für mich keine echten CDN´s, wobei man natürlich die einzelnen Subdomenes auf auf verschiedenen Servern hosten kann.

    Dein Artikel ist trotzdem extrem gut, da hier eher das Problem der max. gleichzeitigen http-requests angegangen wird. Da sind ja im minimum max. 2 parallele Datendownloads. Wenn man jetzt alle bilder über ne Subdomain, alle css/js-files über ne andere Subdomain anbietet kann das die Performance steigern.

    Du hast im Technikwürze Postcast, Folge "WordPress total", vom W3 Caching Plugin gesprochen. Scheint ja ähnlich zu machen wie von dir oben besprochen, oder?

    Viele Grüsse!
    M

    p.s.: Schön wieder mehr hier im Blog zu lesen 🙂

    • @Markus: ja, es ist kein CDN, es ist lediglich ein Trick um die Werte beim Test zu erhöhen. Eventuell kann man die http-requests verbessern, wenn man alles auf Subdomains verteilt. Aber das war es auch schon. Ja, W3 Total Cache kann CDNs und eigene "CDNs" nutzen und die Daten direkt aus WP an diese Domains auslagern. Da ich aber gern im Standard von WP bin und das "weg" kopieren für ein Problem erachte, suchte ich mir eine andere Lösung. Das Problem mit dem kopieren durch ein Plugin ist die Abhängigkeit, die dann an das Plugin entsteht; wird es nicht mehr gepflegt, muss ich mir eine Lösung dazu überlegen. Daher würde ich das lieber selbst in die Hand nehmen.

  9. Vielen Dank für den gut aufbereiteten Beitrag. Damit können auch Nichtprogrammierer etwas anfangen. Ich werde das auf jeden Fall mal ausprobieren.

  10. Sascha sagt:

    Hallo Frank, vielen Dank für diesen Artikel.
    habs gleich mal ausprobiert und es scheint zu funktionieren.

    ich benutze Wp3.0 und Thesis Theme 17.
    Da es bei meiner installation kein /wp-content/images und ..../downloads gibt hab ich einfach mal /images in /uploads umbenannt und /downloads gelöscht.
    Und hab auch den Array in der 2. funktion von 4 auf drei cdn einträge verküzt.

    War diese Vorgehensweise richtig ?

    Wie gesagt es scheint zu funktionieren (bilder etc werden nun über die cdn domain ausgeliefert...allerdings nur bei neu erstellten artiken).

    Einen grossartigen geschwindigkeits gewinn kann ich allerdings noch nicht ausmachen.

    Gruss Sascha

    • @Sascha, @Frederic: korrekt; du musst natürlich die URLs anpassen; dieser Aufbau ist mein Arbeitsweise für das Beispiel. Es wird auch keinen Geschwindigkeitsschub geben; der Server ist doch der gleich. Aber die Werte im Test mit YSlow oder PageSpeed sollten besser sein und damit gefällt es Google besser, die ja die Geschwindigkeit in das Ranking einbeziehen.

  11. Frederic sagt:

    Danke für den interessanten Artikel!

    Was mich an dieser Stelle interessieren würde: Wie sind die tatsächlich gemessenen Performance-Verbesserungen bei einem lokalen CDN? Hat das in diesem Fall wirklich messbare Auswirkungen?

  12. Tim sagt:

    @Frank:

    Page Speed meldet:

    Remove the following redirect chain if possible:

    * http://cdn1.bueltge.de/wp/cdn-bueltge.png
    * http://bueltge.de/wp-content/images/wp/cdn-bueltge.png

    Und ein HTTP Trace auf die erste URL liefert:

    Redirect to: http://bueltge.de/wp-content/images/wp/cdn-bueltge.png

    mit 301 Statuscode.

    Getestet mir Firefox und leerem Cache.

    • @Tim: eventuell liegt es daran, dass Allinkl nur die Adresse bei einem Redirect anspringt; anderes kann man in der Konfiguration auch nicht anlegen - Tipp?

  13. Hm irgendwie interessant. Bei Make Better Websites nutze ich ja ein richtiges CDN und naja, gerade macht es Probleme mit einem Plugin. Aber das ist ja ein anderes Thema 😀

    Das hier klingt aber gut, ich denke ich werde - wenn die Zeit mal da ist - das ganze bei Make Better Apps mal austesten.

  14. Tim sagt:

    Schwierig einen Tipp abzugeben, wenn man den Hoster nicht kennt.

    Kannst du evtl. einen neuen Webspace anlegen, die Subdomain dorthin zeigen lassen und intern auf Filesystemebene einen Symlink zum WordPress Verzeichnis setzen?

    • @Tim: eventuell könnte ich via htaccess eine Weiterleitung einrichten, so dass die Subdomain immer erreicht wird; aber bringt das wirklich was.

  15. Klaus sagt:

    Ich verstehe nicht, wie man so offentsichtlich Links verkaufen (siehe Sidebar) kann. Keine Angst vor einer Abstrafung?

  16. Tim sagt:

    @Frank:
    Die Weiterleitung dürfte den Zeitgewinn durch die andere URL wieder auf brauchen.

    Ich wollte eben eine getrennte Domain als CDN vorschlagen - keine Subdomain. Wenn die dann von deinem Hoster auch mit einer Weiterleitung versehen wird, ist das aber auch keine Lösung.

    • @Tim: ja, mittels WordPress kann ich hier nicht weiter spielen. Hier hilft nur im Host eine neue Domain oder via .htaccess den Rewrite unterbinden; ein einfaches Off in der .htaccess genügt bei mir aber nicht, da meine Subdomains immer einen redirect haben. Die obige Lösung klappt aber in WP trotzdem, der Rest ist Hostingsache. Danke dir nochmals.

  17. Tim sagt:

    sorry, dass ich die Diskussion unterbrechen muss, aber wieso rallt der/die Connie nicht, das CDN gleich am Anfang des Beitrag - den ich sehr gut gelungen finde! - beschrieben wird!? *lol*

  18. Perun sagt:

    Hallo Frank,

    Natürlich müssen die Subdomains angelegt und richtig konfiguriert sein.

    nur eine kleine Verständnisfrage: was bedeute in diesem Kontext richtig?

    Grüße,
    Vlad

    • @Perun: ich will, dass die Subdomain keine Weiterleitung ist; es soll kein Rewrite laufen, da sonst der Effekt weg ist; alternativ hätte ein Eintrag für eine Weiterleitung in der .htaccess geholfen. Allerdings habe ich aktuell keine Ahnung, wie ich eine Subdomain bei allinkl anlege, die keine Weiterleitung ist. Alternativ könnte ich nur eine neue Domain nutzen, die ich aber nicht frei habe. Ich werde mal den Support fragen.

  19. Ralf sagt:

    @frank:

    eventuell liegt es daran, dass Allinkl nur die Adresse bei einem Redirect anspringt; anderes kann man in der Konfiguration auch nicht anlegen - Tipp?

    Das ist nicht richtig. Bei All-Inkl musst du im KAS den Punkt "Unteraccounts" wählen und dann "Als Subdomain". Das was du jetzt gemacht hast, hättest du auch mit einer Rewrite-Rule in der .htaccess erreicht. RewriteCond %{HTTP_HOST} ^cdn1\.bueltge\.de /wp/wp-content/uploads/ [NC]

    Wenn man allerdings einen neuen Webspace anlegt, dann funktioniert aufgrund mangelnder Rechte der Mediauploader von WP nicht mehr. Diesem müsste man dann ggf. irgendwie auf die Sprünge helfen.

    • @Ralf: die Erleuchtung kam mir erst, als ich mir die Konfiguration bei Allinkl genauer angeschaut habe. Ich will mal noch in meinem Account bei allinkl spielen bzw. den Support anfragen.

    • @Ralf: man kann Unteraccounts anlegen, die sind dann auch saubere Subdomain - die müsste man dann aber wieder via .htaccess auf das Verzeichnis leiten oder den kompletten Pfad in den obigen Funktionen angeben. Wie siehst du das?

  20. Ralf sagt:

    Das Verwirrende ist wohl gerade das man bei All-Inkl sowohl eine reine Subdomain (ohne eigenen Webspace) als auch einen Account (mit eigenem Wespace) anlegen kann.

    Du könntest z.B. einen Unteraccount als Subdomain anlegen, z.B. cdn.mydomain.tld mit 1GB Webspace. In diesen Account legst du dann weitere Verzeichnisse an:
    cdn.mydomain.tld/uploads
    cdn.mydomain.tld/scripts
    cdn.mydomain.tld/css

    usw.
    Die Subdomains cdn1.mydomain.tld; cdn2.mydomain.tld; cdn3.mydomain.tld usw. zeigen dann auf die entsprechenden Verzeichnisse:
    cdn1.mydomain.tld mit Redirect auf cdn.mydomain.tld/uploads
    cdn2.mydomain.tld mit Redirect auf cdn.mydomain.tld/scripts
    cdn3.mydomain.tld mit Redirect auf cdn.mydomain.tld/css

    Dies wäre eine Möglichkeit. Durch die Redirects würde sich der Effekt jedoch eher in Grenzen halten. Also die weiteren Subdomains weg lassen und direkt auf die entsprechenden Verzeichnisse in der Subdomain verweisen.
    Hat man den Platz und die Möglichkeit, dann für jeden Ordner eine eigene Subdomain mit Webspace (1-10MB sollten reichen, für Uploads entsprechend mehr). Dann hätte man den vollen Performanceschub (Ich habe in meinem Shared Host schon Platz für 150 Unteraccounts mit Webspace, dass sollte eigentlich reichen.)
    Bei beiden Lösungen müsstest du an deinem Script eigentlich nichts ändern. Die URLs zeigen dann bereits auf die entsprechenden Daten.

    Wirklich interessant ist das ganze jedoch nur für wirklich große Datenmengen. Stylesheets und JS werden i.d.R. recht zügig übertragen. Wartezeiten entstehen normalerweise eher bei Bildern, Sounds und Videos. Aber gerade da zickt dann der Mediauploader von WP rum weil er irgendwie mit einer Subdomain nicht klar kommt 🙁

    • @Ralf: diese Idee habe ich schon mal angespielt, da ich die Menuführung von Allinkl erst nicht ganz verstanden habe; bisher konnte auch der Support nicht helfen; mal sehen was noch kommt.

  21. Hans sagt:

    Also so wie Du das in der ersten Grafik beschrieben hast, war es bis auf den ersten Eintrag schon richtig. Ich nutze dieses Feature zum Unterteilen von Webspace auch bei AI und bekomme keine 301. Deshalb gehe mal davon aus, dass es sich hierbei intern um vhosts und nicht mod_rewrite handelt. Soweit alles ok, aber wie sich das auf die maximalen Requests auswirkt konnte ich bisher nicht klären. Ich vermute aber, dass sich die vhosts die maximalen Requests des Haupt-Hosts teilen und damit keine Steigerung der Performance erreicht wird.

    Die Idee mit den Subdomains als eigene Accounts ist nicht schlecht, denn hier dürfte eine eigene Instanz des Apache werkeln und seine eigenen maximalen Requests anbieten. Der Nachteil ist allerdings, dass es einerseits nicht mehr mit einer Standard-WP-Installation funktioniert, andererseits vermutlich alle Accounts auf einer physischen Hardware (mit festen Werten pro Account) liegen. Bei richtigen Lasten also auch kein Gewinn. Eine Maschine würde wahrscheinlich sogar bei 10 Accounts mehr in die Knie gehen als 1 Account mit hochgeschraubtem Wert für maximale Requests.

    Mein Vorschlag wäre, die Subdomains als eigene Accounts anlegen und dann entweder bei einem anderen Hoster oder in einem anderen Hosting-Paket bei AI (das dann auf einer anderen Maschine liegen dürfte), per DNS-Eintrag die Subdomain dorthin zu übernehmen. Das geht, in dem man dann in einem anderen Paket eine neue Subdomain im KAS einträgt und dafür einen Account einrichtet. Dort trägt man dann die Subdomain ein. Genauso wie man es bei einem Neuerwerb einer Domain macht, nur das man die nachher nicht beantragt, sondern seine eigene Subdomain per DNS übernimmt.
    Damit wären die Lasten schon auf 2 Pakete verteilt, kostet aber mehr.

    Bei dieser Handhabung könnte man jedenfalls schon mal alle statischen Bilder, Scripte und CSS des Templates verlagern. Dafür würde ich aber dann nicht mehr in die Scripte per Funktion eingreifen, sondern die Adressen direkt ins Template schreiben. Eventuell könnte man per Script auch eine statische RSS-Datei auf einen anderen Account pushen oder pullen (zeitgesteuertes Pull würde ich vorziehen).
    Andere Media-Files musste man dann per HTML in die Artikel einbinden und von Hand per FTP auf den anderen Account schieben oder tiefergehende Änderungen an WP durchführen.

    Wenn Du aber wirkliche Probleme mit Deinen Lasten hast, dann solltest Du auf eine eigene Maschine wechseln oder eine Größere nehmen und dann die maximalen Requests aufdrehen und die Laufzeit der Requests runtersetzen. Hilft das auch nicht mehr, dann auf eine Cluster- (Cloud-) Lösung umsteigen.

    Was man auf keinen Fall tun sollte: die Media-Files von einer anderen SLD laden.
    Es gibt einige Filter, die versuchen XSS durch Ausblenden externer Elemente zu verhindern.
    Beispiel: http://www.xyzdomain.dom lädt seine Bilder von http://www.abcdomain.dom, dann würde man die Bilder nicht sehen, ohne dass man in seinem Filter für die Domain xyzdomain.dom eine Ausnahme eingetragen hat. Bei einer Subdomain wie cdn.xyzdomain.dom wäre alles gut und die Bilder da, auch bei einer anderen IP.

    Diese Funktion alleine filtert schon mindestens 80% Werbung ab und ich staune oft, wieviele große Websites ohne Inhalte erscheinen, weil sich die Macher gar nicht dieses Problems bewusst sind.

  22. Marcus sagt:

    Wow, ein super Artikel und ausführlich beschrieben.
    Die Ladezeit einer Homepage wird immer wichtiger, gerade jetzt wo immer mehr die Möglichkeit haben mit Ihrem Handy ins Internet "zu gehen".
    Da jedoch unser UMTS-Netzabdeckung nur in großen Städten sehr gut ist, erfreut sich jeder Besucher vom Lande über eine schnell zu ladende Homepage

  23. Frauke sagt:

    Äähhm, Marcus: nett, dass du auf das Surfen via Handy aufmerksam machst, aber es doch auch heute noch so, dass man eine nicht für mobile Endgeräte adaptierte Seite nicht wirklich gut mit einem Handy oder auch nem Smartphone betrachten kann. Dafür ist das Display einfach zu klein. Ein iPad mag da schon besser sein aber selbst auf dem iPhone oder dem Blackberry oder HTC sind richtige Websites wirklich nicht oft schön anzusehen. Dafür gibt es dann halt das mobile Web 😉

  24. Ralf sagt:

    Marcus war wohl nur ein Spam-Kommentator der den Artikel nicht gelesen hat. Oder er war kein Spam-Kommentator und hat den Artikel nicht verstanden. Ein CDN reduziert nicht die Datenmenge, sondern verteilt sie auf mehrere Quellen. Deswegen ist es unerheblich welche Bandbreite der Besucher hat. Genau genommen ist es sogar genau umgekehrt. Je größer die Bandbreite des Besuchers, desto schneller lädt die Seite.

  25. Christian sagt:

    Sehr cool, ich bin nur durch Zufall auf diesen Artikel gestoßen, aber hier wird genau meine "Problematik" beschrieben. Ich werd das gleich mal testen!

  26. Thomas sagt:

    Danke für den Beitrag. Den Teil auf Wikipedia finde ich recht interessant.

  27. Toralf sagt:

    Danke für den Beitrag!
    Hat bei mir astrein gefunzt, nachdem ich da noch was bei den Subdomains einstellen musste!!

  28. Henry sagt:

    Also ich bin "nicht-programierer" (Kommentar #10) und kann damit leider nichts anfange 🙁

  29. Babs sagt:

    @henry
    mir geht's da nicht anders 🙂

  30. WD. sagt:

    @Frank
    irre ich mich, oder hast du einen kleinen Typo in den functions fb_add_static_wpurl und fb_add_static_stylesheet_uri?
    Wenn ich mir die konfigurierten Subdomains so anschaue sollte $wpurl . '/wp-content/plugins/' doch durch 'http://cdn4.bueltge.de/' ersetzt werden - oder nicht?

  31. WD. sagt:

    Beim Nachbauen ist mir noch was aufgefallen: in der letzten Funktion hast du überall uri statt url stehen - damit dürfte diese Funktion 1:1 kopiert vollkommen wirkungslos bleiben, denn diese Hooks sind WP nicht bekannt...

    Zwei Fragen hätte ich auch noch:

    1. Spricht irgendetwas dagegen, in allen drei Funktionen die gleichen search und replace Arrays zu verwenden?

    2. Gibt es eine Möglichkeit, schon im Header auf die CDN-Domains zuzugreifen? Damit könnten dann alle dort verlinkten css, js etc. aus dem CDN geliefert werden.

  32. WD. sagt:

    @Frank: Wie hinterhältig! Du hast natürlich Recht, ich war noch bei den Parametern von get_bloginfo()

  33. Matze sagt:

    Wow, habe mir gerade alle Kommentare durchgelesen, da ich gerade die CDNs einrichten wollte, bin aber jetzt total verwirrt. Bringt denn nun das Einrichten von den drei CDNs was für die Lade-Geschwindigkeit meines Blogs etwas oder habe ich dann nur bessere Testergebnisse? Besser wäre es, wenn ich das richtig verstanden habe, die CDNs auf einer komplett anderen Domain (auch andere IP) einzurichten oder?
    Dann noch eine Frage, ich habe alle Bilder, die in den Artikeln auftauchen im upload Verzeichnis mit der automatischen Ordnerstruktur von WordPress (Jarh/Monat). Kann ich dies auch irgendwie mit CDNs umsetzen?
    Danke schon mal.

    • @Matze: es bringt was, aber nicht so viel wie ein wirklich schneller Server, der ja bei CDNs zum Einsatz kommt. Dein Upload müsste dann vermutlich gespiegelt werden, so dass deine URLs passen, also den gleichen Inhalt inkl. Ordner(Jahr/Monat) auf dem CDN abbilden.

  34. brain sagt:

    Hi! Vielen Dank für den Artikel. Habe mich in letzter Zeit auch mal etwas mit der Optimierung von WP beschäftigt und bin gleich auf deinen Artikel gestoßen. Hab das ganze jetzt bei mir implementiert und bislang funktioniert alles tadellos 🙂

© 2016, since 2005 bueltge.de [by:ltge.de] · Theme is built by ThemeShift