t3n News Software

WordPress-Tipps: WordPress-Header entschlacken, Blog beschleunigen

WordPress-Tipps: WordPress-Header entschlacken, Blog beschleunigen

Wer die Geschwindigkeit seiner WordPress-Installation verbessern will, denkt vielleicht nicht gleich als erstes an den HTML-Header. Hier aber sammeln sich gerade beim Einsatz von Plugins schnell viele Inhalte an, die die Zahl der Anfragen an den unnötig in die Höhe treiben. Was bei einem wenig frequentierten noch kaum auffällt, wird bei steigendem Traffic schnell zum Problem. Guido Mühlwitz stellt in seinem Beitrag für t3n hier zwei Lösungswege vor: einen bequemen und einen unbequemen - mit unterschiedlichen Haken.

WordPress ist eine jener Applikationen, die auf eine Vielzahl von Plugins zurückgreifen kann, die allesamt ihre Existenzberechtigung besitzen. Je nach Ausrichtung des Blogs kann durch Plugins eine zusätzliche Spezialisierung des Contents erfolgen. So wundert es nicht, dass ein Blogger schnell auf eine zweistellige Anzahl dieser Erweiterungen kommt.

Auf der anderen Seite steigt die Ladezeit einer HTML-Seite aber mit der Anzahl der HTTP-Requests. Tools wie YSlow oder Page Speed haben uns gelehrt, dass eine Seite schneller ist, je weniger HTTP-Requests sie durchführt:

t3n-001
Page Speed Analyse eines typischen WordPress-Blogs

Das grundlegende Konzept von besagt, dass jedes Plugin mittels eines Hook dem System sowohl CSS- als auch JavaScript-Dateien hinzufügen darf. Diese werden dann von WordPress automatisch in den Header eingebunden. Hinzu kommt die Möglichkeit auch Inline CSS oder JavaScript hinzuzufügen. Meistens ist es eine bunte Mischung von allen Kombinationen pro Plugin!

Und genau hier liegt der Hund begraben. Man kann ganz schnell folgende Rechnung aufmachen: Geht man von nur 15 installierten Plugins aus, die allesamt dem System ein eigenes CSS und ein eigenes JavaScript hinzufügen, kommt man auf die stolze Summe von 30 zusätzlichen HTTP-Requests (jeweils 15 CSS-Dateien, und 15 JavaScript-Dateien).

WordPress fehlt eine eingebaute Optimierung

Das ist natürlich ein Worst-Case-Szenario, aber ein kurzer Blick in das eine oder andere Plugin zeigt, dass dieses durchaus noch übertroffen werden kann: Das durchaus beliebte WordPress-Plugin WP-Polls bringt es beispielsweise auf stolze zwei externe JavaScript-Dateien, ein CSS, ein wenig Inline CSS und ein wenig Inline JavaScript. Oder um es anders auszudrücken: Drei zusätzliche HTTP-Requests, plus den erweiterten Darstellungs-Aufwand des Clients durch das Inline CSS.

Lösungen? Negativ! Ich denke, wir reden hier über eine Schwachstelle in WordPress selbst, die im Core behoben werden muss. Denn das es auch anders geht zeigt zum Beispiel Drupal:

Optimierungseinstellungen von Drupal
Optimierungseinstellungen von Drupal

Auch hier können Plugins durch die entsprechenden Hooks CSS-Dateien und JavaScript hinzufügen. Allerdings besitzt Drupal im Administrationsbereich die Option, sowohl CSS als auch JavaScript zu optimieren. In dem Fall sammelt Drupal alle entsprechenden Dateien, fügt sie zu einer einzigen zusammen und bietet diese zum Download an. Das macht dann zwei HTTP-Requests bei einer beliebigen Anzahl von Plugins.

Lösung 1: Abhilfe per Plugin

Ein ähnliches Konstrukt bieten bei WordPress die beiden Plugins WP Minify bzw. WP PHP Speedy an. Auch hier werden sämtliche JavaScript- und CSS-Dateien gesammelt und als eine einzige Datei angeboten. Teilweise schaffen es die Plugins zusätzlich sogar, die Dateien minified anzubieten, was einen weiteren Geschwindigkeitsschub bringt.

Die Plugins sind sehr sinnvoll und bringen den meisten Blogs einen richtigen Performance-Schub. Aber Achtung: Dadurch, dass dies keine Core-Funktionalität ist, sind Plugin-Autoren (im Gegensatz zu Drupal) nicht darum bemüht, kompatibel zu diesen Plugins zu sein! Es gibt durchaus Plugins (z. B. WP Greet Box, das Ajax einsetzt) die nach Inbetriebnahme dieser Optimierungs-Plugins nicht mehr funktionieren. Also nach Einsatz dieser Plugins exakt prüfen, ob alles noch funktioniert!

Lösung 2: Manuelle Optimierung

Dies ist natürlich nicht sonderlich prickelnd, aber für die meisten Blogs durchaus praktikabel. Was bleibt den anderen Blogs übrig? Manuelle Optimierung! Dies ist wiederum sehr aufwändig, aber bei Blogs die unter Hochlast laufen, durchaus im Einsatz.

Was bedeutet das genau? Man legt händisch eine eigene CSS-Datei und eine eigene JavaScript-Datei an, in die man manuell alle benötigten Daten aller Plugins zusammen kopiert. Ferner wird anschließend das Plugin selbst gepatcht, da die Hooks für das Hinzufügen von JavaScript/CSS entfernt werden müssen (einfach nach den Dateinamen im Quelltext suchen).

Prima Lösung: Wir sind auch bei zwei Requests gelandet und können sogar die Dateien mit einem Minify komprimieren. Alles super! Jedenfalls bis das erste Plugin-Update kommt, und davon gibt es eine Menge. Hier steht nämlich jedes Mal die komplette Arbeit von neuem an: Überprüfen, ob sich im JavaScript oder im CSS etwas geändert hat, das Plugin patchen, und alles online setzen.

Fazit

Spätestens jetzt ist ein Grund klar, wieso einige Hochlast-Blogs so sparsam mit Updates sind. Eigentlich bleibt sinnvollerweise nur der Einsatz eines Optimierungs-Plugins übrig, was dazu führen wird, dass man nur noch dazu kompatible Erweiterungen einsetzen kann. Solange diese sehr sinnvolle Optimierung nicht Teil des Cores ist, werden die Plugin-Autoren sich nicht dazu genötigt fühlen, kompatibel zu einem solchen System zu sein. Entsprechend wartet so oder so auf den Betreiber eines Blogs bei den entsprechenden Zugriffszahlen vor allem eines: Arbeit. Denn wie jetzt klar sein dürfte, könnten viele der WordPress-Blogs wesentlich schneller ausgeliefert und beim Client dargestellt werden.

Über den Autor

Guido Mühlwitz ist freier Webworker und entwickelt seit über 15 Jahren Internet-Anwendungen. In seinem Blog berichtet er regelmäßig über aktuelle WordPress-Themen. Open Source Web Applications wie Drupal, CakePHP und ModX gehören regelmäßig zum Themenbereich seiner Veröffentlichungen.

Vorheriger Artikel Zurück zur Startseite Nächster Artikel
8 Antworten
  1. von Andreas am 03.11.2009 (10:06 Uhr)

    Das man am Header ansetzen kann/sollte um die Blog Performance zu steigern, ist mir noch gar nicht in den Sinn gekommen.
    Meistens sind es ja gerade Plug-ins, die einen Blog ausbremsen. Dies ist zumindest meine Erfahrung. Das es für WordPress Performance steigernde Plug-ins gibt, die nicht mit dem Cache rumpfuschen, war mir neu und scheint einen Testlauf wert.

    Sehr aufschlussreicher Artikel.

    Gruß,
    Andreas

    Antworten Teilen
  2. von Herr Voß am 03.11.2009 (10:21 Uhr)

    Sollten diese externen Dateien nicht im Browsercache landen und nach dem ersten Aufruf von dort geladen werden? Auch da gibt ySlow nämlich Tipps, wie man den Server dazu bringen kann, die Dateien komprimiert zu übertragen und die dann gecacht liegen zu lassen.

    Antworten Teilen
  3. von Guido Mühlwitz am 03.11.2009 (10:25 Uhr)

    @Herr Voß: Der Browsercache nützt ja nur, wenn eine Person mehrere Seiten aufruft, nicht wenn mehrere Personen mehrere Seiten aufrufen.

    Antworten Teilen
  4. von Herr Voß am 03.11.2009 (10:43 Uhr)

    Ja gut, wenn tatsächlich die meisten Besucher nur eine Seite angucken und dann nie wieder kommen, bringt Caching tatsächlich nix ;-)

    Antworten Teilen
  5. von Frank am 03.11.2009 (11:01 Uhr)

    Prinzipiell macht WordPress das ja seit 2.8, nur leider sind viele Plugins nicht mit Hilfe der empfohlenen Funktionen erstellt und damit kann WordPress sie nur schlecht bündeln. Die Optionen zum de- und aktivieren des Zusammenlegen von CSS und JS geschieht allerdings in der wp-config.php und damit ist es nicht immer für jeden leicht zu nutzen. Wobei ich das in dem Fall verstehe, denn viele User wissen gar nicht, was sie dort machen und warum es dann eventuell zu Probleme kommt. Ich nutze immer erst die Bordmittel, ehe ein Plugin zum Einsatz kommt.

    Antworten Teilen
  6. von ocean9 am 03.11.2009 (15:39 Uhr)

    Um CSS und JS Dateien auch im Frontend zusammenzupacken kann ich das Plugin W3 Total Cache empfehlen.
    Habe es seit kurzem auch in meinem Blog in Verwendung und finde es super gelungen.
    Dateien angeben und dann werden sie zusammengefügt und komprimiert. Anstatt meinen 5 JS Dateien nur noch eine.
    Leider holt sich das Plugin nicht die Daten aus wp_enque_script bzw wp_enque_style, dafür prüft das Plugin vorher den Quelltext, ob das Skript vorhanden ist, wenn ja, dann wirds entfernt.

    Schönen Gruß

    Antworten Teilen
  7. von Frank am 03.11.2009 (16:14 Uhr)

    Genau das macht WP im Standard, es legt alle JS und CSS zusammen; dies wurde mit WP 2.8 eingeführt und sorgte zum Teil für viele Probleme, da dieverse Browser damit nicht umegehen können. Insofern sollte man damit vorsichtig sein. Ein kleine Liste von Problemen kann man sich bei Heiko anschauen

    Antworten Teilen
  8. von Sören G. Prüfer am 04.11.2009 (10:00 Uhr)

    Danke für dieses Thema. Für mich die Bestätigung, dass dies doch eine offene WP-Baustelle ist. Das habe ich bisher nicht glauben wollen. Ich glaubte es läge an meinem mangelnden Verständnis.

    Dabei ist noch gar nicht erwähnt, dass ein Plugin ja gar nicht auf jeder Seite notwendig ist. Wird ein Plugin aktiviert, wird es jedesmal geladen und bei JS ggf. auch ausgeführt, ob dann benötigt oder auch nicht.

    Wenn z.B. ein Widget oder eine Funktionalität nur bei bestimmten Seiten gebraucht wird, sollte deren Code auch nur dort geladen werden! Teilweise werden Scripte ausgeführt und Initialisierungen vorgenommen. Verschwendung auf dem Server und beim Client.

    Eine Idee ging da hin, 2 WP-Installation parallel zu betreiben. Die einen hi-traffic Seiten sind schlank mit wenig Funktionalität und die Feature-reichen sind unter separater URL abrufbar. Problem ist die Pflege von 2 Installationen und deren vernünftige verknüpfung...

    Antworten Teilen
Deine Meinung

Bitte melde dich an!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden

Mehr zum Thema WordPress
Sicherheitslücken in Wordpress-Plugins: Admins müssen jetzt updaten
Sicherheitslücken in Wordpress-Plugins: Admins müssen jetzt updaten

Im Rahmen eines Hacking-Events wurden erneut Sicherheitslücken in vier beliebten Wordpress-Plugins aufgedeckt. Diesmal betroffen: Ninja-Forms, Icegram, Video-Player und Paid Membership Pro. » weiterlesen

SEO im Content-Marketing: 8 Tipps für effektivere Blog-Artikel
SEO im Content-Marketing: 8 Tipps für effektivere Blog-Artikel

Blogs sind ein beliebtes Mittel im Content-Marketing. Viele Unternehmen haben schon ein eigenes und befüllen es kontinuierlich mit Inhalten. Darauf sollten aber, wie bei anderen Blogs auch, … » weiterlesen

Von der Blog-Plattform zum Domain-Anbieter: Warum Wordpress 19 Millionen Dollar für .blog gezahlt hat
Von der Blog-Plattform zum Domain-Anbieter: Warum Wordpress 19 Millionen Dollar für .blog gezahlt hat

Automattic, das Unternehmen hinter Wordpress, hat vergangenes Jahr die Top-Level-Domain .blog ersteigert. Die Domains will der Blog-Betreiber auch außerhalb von Wordpress verkaufen. » weiterlesen

Alle Hefte Jetzt abonnieren – für nur 35 €

Kennst Du schon unser t3n Magazin?