WordPress beschleunigen – WordPress Performance

Und das in 3 einfachen Schritten (Für WordPress ab Version 3.3).

Was mir dabei wichtig ist: In der Kürze liegt die Würze. Neben zahlreichen Gründen aus SEO Sicht und Benutzer Zufriedenheit, gefällt es mir persönlich auch ganz gut, wenn die Site schnell ausgeliefert wird.

Vor der Optimierung kann man z.B. mit den Pingdom-Tools messen, wie lange die Auslieferung dauert. Geht natürlich auch mit yslow, google pagespeed und anderen Tools, aber pingdom speichert die Ergebnisse in einer Historie. So lässt sich später auch prüfen, ob die Ladezeit vielleicht vom Hoster, Server oder tageszeitabhängig beeinflusst wird.

Schritt 1: Auf unnötige Plugins verzichten

Welche dabei unnötig sind, lässt sich einfach mit dem Plugin P3 (Plugin Performance Profiler) feststellen. Nach der Plugin Installation lässt sich über Tools / Werkzeuge ein Ladeprofil erstellen, welches die Ladezeit der auf dem Server ausgeführten php Skripte erfasst. Meiner Meinung nach sind alle Plugins unnötig, die einen schlechten Einfluss auf die Ladezeit haben. Es gibt nicht viele Zusatzfunktionen, die dem Besucher auf einer „langsamen“ Website wieder ein Lächeln entlocken.

Also: Alle Plugins die nicht zur Kernfunktionalität gehören und langsam sind zumindest zum Test deaktivieren, gegen schnellere mit gleicher Funktion austauschen, oder darauf verzichten.

Schritt 2: Die Auslieferung von CSS und Javascript Dateien optimieren

Das lässt sich sehr einfach mit dem Plugin Better WordPress Minify realisieren. Nach der Installation lässt sich unter Settings / Einstellungen – BWP Minify festlegen, wie CSS und Javascript Dateien zu behandeln sind.

Schritt 3: Worpress um Cache Funktionalitäten „erweitern“

Und dazu lässt sich z.B. einfacherweise das Plugin WP Super Cache verwenden. Nach der Installation lässt sich unter Settings/ Einstellungen – WP Super Cache festlegen, wie die Seiten zu cachen sind. Die Cache Funktionalität ist übrigens schon in WordPress enthalten (ohne Persistenz, für die sorgt z.B. das Plugin) und ist hier beschrieben Class Reference/WP Object Cache. (define('WP_CACHE', true) in der wp-config.php einzutragen ist seit Version 2.6 unnötig, da diese Konfiguration nicht mehr zieht)

Noch nicht genug? Dann gibt es noch weitere Möglichkeiten

Schritt 4: Ein schnelles Template verwenden

Nicht jedes Template ist leichtgewichtig und nicht jedes gut designed. Es lohnt sich auf jeden Fall ein paar Templates zu probieren und sich die Ladezeiten anzusehen.

Schritt 5: Bilder später laden

Mit dem Plugin jQuery Image Lazy Load WP kann man erreichen, daß Bilder erst geladen werden, wenn sie im Viewport sichtbar sind, sprich, wenn der Besucher in der Seite soweit runter scrollt, daß das Bild angezeigt wird. Bringt aber nur was, wenn die Seite überhaupt Content in geeigneter Form darstellt.

Schritt 6: Bilder optimieren

Mach ich größtenteils „manuell“ mit der Hilfe von googles Pagespeed. Nach Analyse der Seite (z.B. über das Firefox Plugin) werden unter dem Punkt „Bilder optimieren“ alle Bilder auf Einsparungspotential geprüft und gleich eine verbesserte Version des Bildes zum Download angeboten, welches sich prima zum Austausch des Originals eignet.

Schritt 7: Die Datenbank sauber halten

Das hat mir noch nichts gebracht, da meine WordPress Instanzen zum einen nicht so viele Posts und Pages enthalten und sie auch noch recht neu sind. Es ist aber erstaunlich wie viele Revisions zusammen kommen, die man nicht benötigt und die gelöscht werden können. Dazu kann man sich des Plugins Delete-Revision bedienen, welches auf Knopfdruck unnötigen Ballast entfernt. Sinnvoll bei großen Sites oder langsamen mysql Installationen.

Schritt 8: Fehlerhafte Links suchen

Meine Meinung: Eine 404 Meldung ist die langsamste Form der Site Auslieferung: Der Besucher bekommt niemals zu Gesicht, was er sehen wollte 😉 Mit dem Plugin Broken Link Checker kann man sich mühelos auf die Suche nach fehlerhaften Verweisen machen.

Schritt 9: Die weiteren Tipps aus z.B. google Pagespeed umsetzen

Jetzt wird es nicht nur interessant sondern auch schwieriger. Nicht alle Potentiale lassen sich so ohne Weiteres ausschöpfen und die Umsetzung dauert zumindest länger oder ist z.T. garnicht möglich. Der Form halber gehe ich trotzdem kurz darauf ein.

  • serverseitige Komprimierung aktivieren
    • sorgt dafür, das Dateien komprimiert an den Client gesendet werden
      • lässt sich bei shared Hosting Angeboten selten selbst am Server konfigurieren
      • die Einstellungsmöglichkeiten in der .htaccess Datei werden je nach Server-Konfiguration und aktivierten Modulen ignoriert
      • die Komprimierung per php Funktion ist serverlastig oder nicht möglich (und auch nicht zu empfehlen)
      • nicht alle mobile devices unterstützen Komprimierung

 

  • Bilder in CSS Sprites kombinieren
    • dabei werden Bilder in einer Datei ausgeliefert und über CSS nur noch auf Teile der großen Datei zugegriffen, das vermindert die Anzahl Serverzugriffe
      • viel Spaß beim Erstellen der Datei und dem Zugriff auf die Einzelelemente ; (nimm doch einen Generator http://de.spritegen.website-performance.org/)
      • das Sprite muss manuell in das Theme / Template eingebaut werden

 

  • Javascript später parsen (weiter unten im HTML referenzieren / einfügen)
    • zuerst werden die sichtbaren Teile ( HTML / CSS / Bilder usw.) geladen und zur Anzeige gebracht, die javascript Dateien, die zuweilen auch sehr groß sein können (z.B. jquery), werden später geladen und Behindern so den Aufbau der Seite nicht
      • nicht jedes Template unterstützt das, es kommt zu Fehlern in der Ausgabe (aufklappbare Menüs, dynamische Elemente)
      • nicht jedes Plugin unterstützt das
      • z.T. müssen das Template oder verwendete Plugins manuell editiert werden

 

  • ein CDN verwenden
    •     Dateien der Präsenz werden auf „Contentproxys“ weltweit verteilt und dort optimiert zu Verfügung erstellt
      • he, dann verlier ich ja die volle Kontrolle 😉
      • ist mir zu aufwendig
        • siehe Update – Ausnahme jquery

 

  • Browser caching aktivieren
    • wird am Server konfiguriert und sorgt dafür, daß Dateien im Browser Cache bleiben
      • muss in der Datei .htaccess oder Apache Konfiguration aktiviert werden
      • steht bei den meisten Shared Hosting Angeboten nicht zu Verfügung

 

10. Plugin Lade-Reihenfolge verändern

Hierzu kann man sich eines Plugins bedienen, z.B. dem Plugin Organizer. Durch Änderung der Ladereihenfolge habe ich es geschafft, daß die dynamischen Twitter und Facebook Button nicht immer das Laden der Seite blockieren. Warum ist mir noch nicht ganz klar, zumindest stehen deren Javascript Elemente dadurch jetzt noch weiter am Ende der Seite. Mit Hilfe des Plugins lässt sich festlegen, auf welchen Seiten welches Plugin geladen wird. Das macht z.B. dann Sinn, wenn die Gallerie oder das Kontaktformular umfangreich Javascript und CSS lädt, deren Anzeige aber auf wenige Seiten beschränkt ist. Das dürfte mit den Javascript und CSS Optimierungen und dem Caching kollidieren, da ja dann unterschiedliche Dateien ausgeliefert werden. Getestet habe ich das noch nicht, da mir die Änderung der Ladereihenfolge den gewünschten Effekt gebracht hat.

 

Ich mach jetzt mal nen Punkt, die Möglichkeiten unter Punkt 9 habe ich getestet aber verworfen und komme mit den ersten 7 Tipps auf unter 3 Sekunden, das muss genügen.

Fehlerhafte Links sind ein no go und somit ist Punkt 8 ein Muss, auch wenn man auf den korrekt verlinkten Seiten keinen Effekt spürt.

UPDATE 01.06.2012:

Ein Dorn im Auge sind mir große Frameworks wie jquery. Da frage ich mich ständig, ob mein Shared Hosting Angebot für die Auslieferung optimal konfiguriert ist. Mit folgendem exemplarischen „Ersatz“ lässt sich jquery auch direkt vom google Server laden:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script>

Dazu muss (meist im Template) die Quelle zu jquery getauscht werden. Im Template Code sollte man dazu „lokale Aufrufe“ wie diesen hier „<script type=”text/javascript” src=”js/jquery-1.3.2.js”></script>“  gegen den oben aufgeführten tauschen. Dabei kann man auch eine andere Version angeben. Außerdem ist es möglich, per AJAX und google Load jquery zu laden …. aber das sei hie nur als ergänzende Bemerkung aufgeführt, je mehr man sich von externen APIs abhängig macht, um so mehr Zeit verwendet man darauf, deren Einsatz, Funktion und Verfügbarkeit zu „überwachen“. Das Einbinden von jquery von einem anderen Server wäre dann der erste Schritt ein „CDN – Content Delivery Network“ zu nutzen.

In Zusammenhang mit „Schritt 4 schnelles Template“ möchte ich noch ergänzen, daß es Templates gibt (wie z.B. suffusion) die per Konfiguration den Einsatz der minified Version von jquery erlauben (wobei suffusion cool, aber selbst nicht so schnell ist). Dumm, wenn dann ein Plugin die große Version des Frameworks mitbringt und verwendet, also immer wachsam sein 😉

UPDATE 25.02.2013:

Durch die rechtskonforme Einbindung der Empfehlen Button auf Basis der Heise Empfehlung (2-Klick Empfehlungsbutton) lässt sich die Ladezeit der Seite wesentlich beschleunigen (besonders, wenn man bisher ein Plugin/Addon für die Einbindung verwendet hat). Da in diesem Ansatz zunächst keine Ressourcen von facebook, twitter und Co. geladen werden, findet weder eine Adressauflösung noch irgendeine andere Kommunikation mit den Servern der Sozialen Netzwerke statt, Zeit für’s Rendering und Bandbreite kommen der Ladezeit der Seite zugute.

Erst wenn jemand die Button für die Empfehlung aktiviert, findet ein Nachladen der jeweiligen Ressourcen statt und dann auch nur der Ressourcen, die für den ausgewählten Dienst benötigt werden. Der Effekt war überraschend.

UPDATE 11.03.2013:

Adressauflösung absoluter Links

Wer die Pingdom Tools bemüht oder sich den Netzwerkverkehr bei Aufruf einer WordPress Seite anschaut, wird feststellen, daß alle Ressourcen (z.B. Bilder, CSS + Javaskript Dateien) absolut verlinkt sind, auch wenn die Pfade relativ sein könnten, weil die Dateien auf dem gleichen Server liegen bzw. unter der gleichen URL erreichbar sind.

Für jede Ressource findet dann eine Adressauflösung statt, was wiederum Zeit kostet. Abhilfe gibt es unter WordPress in Form von Plugins, welche alle Pfade zu relativen „kürzen“. Aber Obacht: Nach Aktivierung eines solchen Plugin sollte man die Seite eingehend checken. Bei mir hat z.B. der Website Anlayse Tracking Code nicht mehr funktioniert – Ursache noch unklar.

UPDATE 04.07.2013:

Der Webhoster und der Einfluss auf die Performance

Einen stark positiven Einfluss habe ich bei einigen Projekten durch den Wechsel des Webhosters erreicht. Bei gleichen Kosten bieten Anbieter wie z.B. hosteurope Pakete, die auch speziell den Einsatz von WordPress sehr gut unterstützen. Die Laufzeitunterschiede sind beachtlich! Zum Test kann man das entsprechende Projekt versuchsweise kopieren, um so Erfahrungswerte zu sammeln.

UPDATE 03.09.2013:

Verzögerungen durch Javascript und CSS

WordPress ist ja nicht zimperlich, was die Auslieferung an Javascript und CSS, sowohl in Anzahl der Dateien als auch deren Größe angeht. Mit jedem Plugin oder Widget, das auf irgendeiner Seite oder in irgendeinem Post eine Ausgabe generiert, wird meist auch die Menge an Javascript Code und CSS Definitionen größer.

Aber wie kann man das dem System abgewöhnen? Eine elegante Alternative habe ich noch nicht gefunden. Zunächst habe ich mich innerhalb der Plugins auf die Suche nach den Zeichenketten wp_enqueue_script und wp_enqueue_style gemacht. An einigen Stellen hebel ich nun die Ausgabe auf, z.B. wenn ich weiß, daß der Code auf der Startseite nicht benötigt wird (if (!is_front_page())…) und verhindere somit unnötige Datenübertragung.

In  diesem Zusammenhang ist mir ein Codeblock in der Datei script-loader.php aufgefallen, der doch tatsächlich ohne weiteres Plugin diverse Optimierungen zulässt. Seltsamerweise ist sowohl das Verbinden von Ladeanweisungen als auch die Komprimierung der Dateien defaultmäßig auf false gesetzt. Und jetzt ratet mal, was man so erreichen kann, wenn man an relevanter Stelle stattdessen ein true einfügt?

function script_concat_settings() {
    global $concatenate_scripts, $compress_scripts, $compress_css;

    $compressed_output = ( ini_get(‚zlib.output_compression‘) || ‚ob_gzhandler‘ == ini_get(‚output_handler‘) );

    if ( ! isset($concatenate_scripts) ) {
        $concatenate_scripts = defined(‚CONCATENATE_SCRIPTS‘) ? CONCATENATE_SCRIPTS : true;
        if ( ! is_admin() || ( defined(‚SCRIPT_DEBUG‘) && SCRIPT_DEBUG ) )
            $concatenate_scripts = true;
    }

    if ( ! isset($compress_scripts) ) {
        $compress_scripts = defined(‚COMPRESS_SCRIPTS‘) ? COMPRESS_SCRIPTS : true;
        if ( $compress_scripts && ( ! get_site_option(‚can_compress_scripts‘) || $compressed_output ) )
            $compress_scripts = true;
    }

    if ( ! isset($compress_css) ) {
        $compress_css = defined(‚COMPRESS_CSS‘) ? COMPRESS_CSS : true;
        if ( $compress_css && ( ! get_site_option(‚can_compress_scripts‘) || $compressed_output ) )
            $compress_css = true;
    }
}

VN:F [1.9.22_1171]
Rating: 4.8/5 (30 votes cast)
WordPress beschleunigen - WordPress Performance, 4.8 out of 5 based on 30 ratings