Was WordPress angeht, wird im Moment viel über Optimierungswege und -potenziale diskutiert, aktuell zum Beispiel bei Frank Bueltge. Auch in der iX war vor einigen Monaten ein Artikel dazu zu finden. Letztlich gelten die dort und an anderen Stellen aufgezählten Tipps und Tricks aber für jede Website.
Für 99 % aller Websites spielen solche Optimierungsmaßnahmen keine Rolle – sie schaden sicherlich nicht, bringen aber auch keinen Nutzen. Wenn man sie nicht durchführt, um mehr über Website-Betrieb zu lernen oder weil man tatsächlich gravierende Probleme hat, sollte man seine Motivation hinterfragen.
Die Basis für jede Website-Optimierung ist die Struktur der Website selbst, also sauberes HTML und CSS. Das bedeutet zum Beispiel, class-Definitionen wie
zu vermeiden. Aus Sicht eines Template-Autors ist es vielleicht eine gute Idee, die class-Definition als Metadatencontainer zu missbrauchen, damit der Kunde maximale Flexibilität bei der Gestaltung hat. Genau diese Flexibilität wird aber teuer erkauft – und in den wenigsten Fällen tatsächlich genutzt. Man tut als Betreiber also gut daran, mit solchen Praktiken aufzuräumen. Auch die CSS-Dateien selbst sollten einer Generalinventur unterzogen werden.post-97 page type-page hentry
Gutes CSS zeichnet sich zum Beispiel dadurch aus, dass es seinem Namen gerecht wird. Man sollte gezielt die Kaskadierung (o. Vererbung) von Eigenschaften nutzen und fügt nur zu speziellen Elementen nur die Angaben hinzu, die tatsächlich neu oder anders sind. Hinzufügen ist dabei fast immer erlaubt, überschreibt man aber die meisten Eigenschaften, sollte man wahrscheinlich eine neue Klasse oder eine neue ID definieren. So macht man es den Rendering Engines der Browser einfacher und erleichtert sich bei zukünftigen Änderungen das Leben.
Javascript ist heutzutage aus kaum einer Website wegzudenken. Auch hier gilt es, mit Augenmaß an Einbindung und Nutzungshäufigkeit zu betrachten. Wenn sich nur auf der Startseite ein Karussell dreht, brauche ich das Javascript nicht auf jeder Seite einzubinden.
Anschließend kann man daran gehen, CSS und Javascript ggf. zusammenzufassen und mit z. B. Minify zu verkleinern und so Bandbreite zu sparen.
Man sieht, die allermeisten der vermeintlichen Frontend-Probleme lassen sich mit gesundem Menschenverstand lösen – ohne auf Plug-ins zurückzugreifen.
Auch für Optimierungen am oder auf Server wollen YSlow und Page Speed Tipps geben. Nicht alle sind wirklich relevant, viele sind – falsch oder halbherzig umgesetzt – sogar schädlich oder bestenfalls egal. Deswegen: Was man nicht versteht, macht man auch nicht. So geht zumindest nichts kaputt.
Zum Beispiel die in dem Artikel von Frank beschriebene Methode, Content Delivery Networks zu benutzen. Naja, eher zu faken ;)
Zunächst ist die Idee, statische Contents, also CSS, Javascript, Bilder und andere Medien von einem anderen Host aus zu laden, nicht verkehrt. Das entlastet den Applikationsserver und kann verhindern, dass Cookies hin und her gesendet werden müssen.
Solche Lösungen mit Plug-ins zu realisieren, die vom Applikationsserver/WCMS ausgeliefertes HTML nachträglich oder während der Zusammenstellung des Content verändern, ist keine clevere Idee. Der bessere und sinnvollere Weg ist, das WCMS bereits die korrekten Pfade verwenden zu lassen. Wenn das heißt, an der einen oder andere Stelle – im Falle von WordPress – auf sein heiß geliebtes Template Tag zu verzichten: wenn schon, denn schon.
(Nachträgliche Rewrites für die Auslieferung statischer Inhalte von einem anderen Host zu benutzen … Das ist nicht nur nicht clever, sondern völlig an der Zielsetzung vorbei.)
Zwei Buchtipps möchte ich nicht unerwähnt lassen, wenn ich schon Verständnis fordere: Even Faster Websites, den Nachfolger von High Performance Websites und Building Scalable Websites (wenn auch von 2006).
Bild: Jon Sullivan