High Speed: Was WordPress-Websites wirklich schnell macht [#5]

In dieser kleinen Serie beschäftigen wir uns mit den Dingen, die WordPress-Websites wirklich schnell machen, also in den Millisekunden-Bereich der Ladegeschwindigkeit bringen. Viel Handarbeit ist angesagt, wie wir im letzten Beitrag herausgefunden haben. Im diesem letzten Teil beschäftigen wir uns mit den Nacharbeiten, die noch bleiben. Wir tunen die URLs, verschaffen Jetpack eine Schlankheitskur, wandeln die Website mit Caching in statische HTML-Seiten um und lassen Videos defer (= zuletzt) laden.

Performance durch die richtige Permalinkstruktur

Die Permalinks in WordPress lassen sich nach Belieben verändern. WordPress erlaubt uns jede nur erdenkliche Struktur. Die natürliche Struktur der Permalinks in WordPress nennt sich Messy-URLs, da keinerlei erkennbare Struktur ausgegeben wird. Ein Link direkt nach einer frischen Installation würde so aussehen:

http://www.drweb.de/magazin/?p=123

Diese Struktur ist für Mensch und Maschine nicht sehr gut lesbar, deshalb ging man dazu über, lesbare Permalinks mit Keywords zu verwenden.

http://www.drweb.de/magazin/beispiel-beitrag/

Solcherlei Links zu erstellen geht blitzschnell mit WordPress und zurzeit ist diese Struktur immer noch die beliebteste. Jedoch sind auch viele andere Strukturen denkbar, du kannst ein Datum, die Kategorie und auch Tags wählen. Doch geschickt ist das nicht, denn Permalinks können massiv an den Ressourcen deines Servers ziehen, man mag es kaum glauben. Pauschal lässt sich sagen, dass stark angepasste Permalinks schlecht für die Performance sind.

Natürlich macht das keine Sekunden auf die Ladezeit bezogen aus, doch im Paket mit anderen Performance-Fressern ist das durchaus deutlich messbar. Bei sehr vielen Beiträgen innerhalb eines Blogs und in Spitzenzeiten, wenn der Besuchersturm losbricht, sind Link-Adressen mit einfacher ID um einiges schneller.

Google legt kaum noch Wert auf die sprechenden URLs

Die Zeiten ändern sich und Google selbst scheint kaum noch einen Wert auf die sprechenden URLs zu legen. Ganz im Gegenteil, Google selbst geht dazu über, einfache IDs statt Keywords in seinen URLs zu nutzen. Beobachten kann man dieses zum Beispiel bei YouTube und Google+. Google verlegt sich immer mehr darauf, auf Benutzerfreundlichkeit, schnelle Ladezeiten und guten Inhalt Wert zu legen. Die alten Tricks mit der sprechenden Adresse,  mit Keywords optimiert, scheinen nicht mehr zu wirken. Es ergibt also durchaus Sinn, darüber nachzudenken, schnelle und kurze URLs zu verwenden und die Struktur auch bei bestehenden Projekten zu ändern.

Permalinks auf einfache IDs umstellen

Google scheint neuerdings auf kurze URLs wert zu legen und diese Stärker zu gewichten. Das ist meine ganz persönliche Beobachtung, seitdem ich bei meiner Democratic Post die Permalink-Struktur von sprechenden URLs auf einfache IDs umgestellt habe. Seitdem bekomme ich mehr Traffic über Google. Daher empfehle ich eine einfache Permalink-Struktur mit IDs zu nutzen. Eine Umstellung auch bei bestehenden Projekten ist kein Problem, WordPress selbst kümmert sich um die nötigen Weiterleitungen von der alten auf die neue URL. Ein Link mit ID sähe so aus:

http://andreas-hecht.com/466/

Der folgende Screenshot verdeutlicht die nötigen Einstellungen:

Videos Defer laden lassen

Videos zuletzt laden zu lassen macht die Website nun nicht wirklich schneller, was die reine Ladezeit angeht. Doch die Website baut sich bedeutend schneller auf. Zumindest wird der Besucher deiner Website den Eindruck gewinnen, dass dein Blog rasant und schnell lädt, weil sich der sichtbare Bereich der Website wesentlich schneller zeigt. Um das zu erreichen, wird das Laden der Videos einfach nur an das Ende verschoben. Wenn ein Video direkt im sichtbaren Bereich eingebunden sein sollte, erscheint für kurze Zeit ein weißer Bereich, der sich nach dem Laden des Videos mit dem Video füllen wird. Das Laden der Website wird also nicht mehr von den Videos unterbrochen. Der Code ist sehr minimalistisch gehalten und besteht aus zwei Teilen:

Die Code-Snippets für die functions.php eures Themes:

Teil 1: Die PHP-Funktion

Ein Klick öffnet das Gist bei GitHub

Teil 2: Der JavaScript-Code

Ein Klick öffnet das Gist bei GitHub

Der zweite Teil des Codes wird nur auf der Seite eines einzelnen Beitrags geladen. Wer Videos auch auf Seiten oder der Homepage verwendet, muss das Snippet noch auf die eigenen Bedürfnisse anpassen.

Caching: Blog auf statische HTML-Seiten umstellen

Schon ein normales Caching macht eine Website wesentlich schneller. Allerdings wird bei jedem Seitenaufruf immer noch der PHP-Interpreter aufgerufen, was deinen Blog langsamer macht, als er sein müsste. Willst du eine wirklich schnelle Website, musst du das Caching der Website auf die Erzeugung statischer Websites umstellen. Dann wird der PHP-Interpreter umgangen und die angeforderte Seite sofort aufgerufen. Das macht wirklich einiges aus, hat aber auch seine Nachteile.

Vorteil:

Die einzelnen Seiten werden wesentlich schneller geladen, die Website wird rasend schnell.

Nachteil:

Es sind keine geplanten Beiträge mehr möglich, da der PHP-Interpreter umgangen wird.

Lösung:

Eine brauchbare Alternative wäre der Aufruf der WordPress-Datei wp-cron.php (zu lokalisieren im Hauptverzeichnis der WordPress-Instanz) mithilfe eines Server-Cronjobs (Hoster fragen) oder eines Dienstleisters wie zum Beispiel cronjob.de. – Cachify Wiki

Statische HTML-Seiten mit dem Plugin Cachify erzeugen

Das kostenlose WordPress-Plugin Cachify ist richtig konfiguriert das zurzeit schnellste Caching-Plugin für WordPress-Websites. Zusammen mit einer .htaccess Erweiterung erzeugt es von jeder Seite eines Blogs eine GZIP-komprimierte HTML-Version.

Cachify Download von WordPress.org

Die .htaccess Datei ist im Hauptverzeichnis von WordPress zu finden. Die nötige Erweiterung für Cachify muss oberhalb der WordPress-Regeln einkopiert werden. Bitte fertige vor der Bearbeitung der Datei ein Backup an.

Ein Klick öffnet das Gist bei GitHub

Die nötigen Einstellungen des Cachify-Plugins

Die Schlankheitskur für Jetpack

Jetpack ist ein tolles Plugin, wenn man vorsichtig ist bei dem, was man aktiviert. Ich gehe sehr bewusst mit dem Plugin um und habe nur sehr wenige Module aktiviert. Aktiv sind die folgenden Module auf der Democratic Post:

• Shortcode-Einbettungen – für Youtube, Flickr und andere Dienste
• Website-Statistiken – für einen schnellen Überblick der meist-aufgerufenen Beiträge im Dashboard
• Zusätzliche Seitenleisten-Widgets – für die Anzeige der beliebtesten Beiträge (Top-Post-Widget)
• Daten Backup – für die VaultPress-Backups

Jetpacks schlechter Ruf als Performance-Fresser ist dadurch entstanden, dass das Plugin für alle ihm möglichen einzelnen Funktionen ein Stylesheet oder JavaScript lädt. Leider kann man nicht genau einstellen, welche Scripts und Styles geladen werden sollen, und welche nicht. Daher muss man selbst Hand anlegen und genau bestimmen, was wirklich benötigt wird. Ich lasse das Plugin genau noch eine JavaScript- und keine einzige CSS-Datei laden.

Das für das Top-Post-Widget nötige CSS habe ich aus der Jetpack CSS-Datei heraus kopiert und in mein Style.css eingefügt. Im Anschluss wurde das Jetpack-CSS dann am Laden gehindert.

Teil 1 der Jetpack-Optimierungen: Die Kontrolle über die Module

Die Jetpack-Module lassen sich mit dem Plugin hervorragend kontrollieren und auch an einer automatischen Aktivierung durch Jetpack hindern. Jedes Modul, welches deaktiviert wurde, lädt auch keine Scripte mehr. Ein Blick auf die Einstellungen:

Download Module Control for Jetpack

Teil 2 der Jetpack-Optimierungen: CSS am Laden hindern, wenn nicht benötigt

Jetpack lädt eine Unmenge an CSS-Dateien, die nicht in allen Fällen auch benötigt werden. Meine Website benötigt kein einziges, deshalb habe ich alle deaktiviert. Der dazu nötige Code ist jedoch so verfasst, dass einzelne Elemente daraus gelöscht werden können, wenn man sie doch benötigt.

Ein Klick öffnet das Gist bei GitHub

Das Endergebnis: Eine wirklich schnelle Website

Der erste Durchgang mit den Pingdom Tools

Der zweite Durchgang mit den Pingdom Tools

Mit allen bisher getätigten Einstellungen wurde eine Website realisiert, die im Millisekundenbereich lädt. Trotzdem wäre an dieser Stelle noch nicht Schluss, es ginge durchaus noch mehr. Ich könnte auf das Top-Post-Widget verzichten oder auf die großformatigen Werbebilder für meine E-Books. Das de:comments Plugin für die Kommentare könnte deaktiviert werden und ich könnte die WordPress-Kommentare mit einem Caching für die Gravatare nutzen. Zudem könnten die Werbeblöcke von Google Adsense und Plista rausfliegen.

Möglich wäre also durchaus eine Ladezeit von 300 Millisekunden. Doch das ist nicht mehr praktikabel, meiner Meinung nach.

WordPress-Websites wirklich schnell: die Serie

• Dr. Web: High Speed: Was WordPress-Websites wirklich schnell macht – [#1]
• Dr. Web: High Speed: Was WordPress-Websites wirklich schnell macht – [#2]
• Dr. Web: High Speed: Was WordPress-Websites wirklich schnell macht – [#3]
• Dr. Web: High Speed: Was WordPress-Websites wirklich schnell macht – [#4]
• Dr. Web: High Speed: Was WordPress-Websites wirklich schnell macht – [#5]

Links zum Beitrag:

• Fast WP: Performance der Permalinks
• Fast WP: Deshalb nutze ich Permalinks mit ID
• WordPress-Plugin Cachify
• Cachify Wiki
• WordPress-Plugin Module Control for Jetpack
• Pingdom Tools – Website Speed Test

(dpe)