Google stellt mit PageSpeed Insights einen schönen „Geschwindigkeits“-Test für Websites zur Verfügung. Doch es ist oft gar nicht so erstrebenswert, 100 / 100 Punkte zu bekommen, denn: das würde dem eigentlichen Ziel zuwider laufen. Warum?

PageSpeed testet gar nicht die Geschwindigkeit einer Seite

Zunächst muss man sich klar machen, dass Google PageSpeed Insights gar kein Geschwindigkeitstest ist. Es ist vielmehr ein Test, bei der die meisten Parameter etwas mit der Seitengeschwindigkeit zu tun haben. Hat man einen guten PageSpeed-Wert, kann man trotzdem noch eine für Benutzer unfassbar langsame Website haben.

Der einzige echte Geschwindigkeitstest ist unter dem Punkt „Antwortzeit des Servers reduzieren“ zu finden. Hat man dort eine zu hohe Zeit, ist das ein direkter Hinweis auf eine zu langsame Reaktion des Servers. Andere Probleme wie langsame AJAX Requests, wie live generierte (und damit langsame) CSS- oder JS-Dateien sind auf PageSpeed nicht sichtbar. Um diese zu finden, kann man das Network-Tab von Firebug oder auch Online-Tools wie den Pingdom Website Speed Test nutzen.

Wie man hohe PageSpeed-Werte erreicht

Google PageSpeed ist am Ende eine Anzeige, wie sauber das Theme und Plugins programmiert wurden. Diese Seite hier ist ein schönes Beispiel dafür: Ich habe genau nichts extra dafür gemacht, nur um den PageSpeed zu erhöhen. Überhaupt habe ich nur zwei Kleinigkeiten gemacht, die den PageSpeed erhöhen. Einerseits sorge ich mit dem folgenden Snippet dafür, dass jQuery im Footer geladen wird (was WordPress von alleine nicht macht):

add_action( 'wp_enqueue_scripts', function() {
  global $wp_version;
  wp_deregister_script( 'jquery' );
  wp_deregister_script( 'jquery-migrate' );
  wp_register_script( 'jquery', includes_url( '/js/jquery/jquery.js' ), false, (string)$wp_version, true );
  wp_register_script( 'jquery-migrate', includes_url( '/js/jquery/jquery-migrate.min.js' ), array('jquery'), (string)$wp_version, true );
  wp_enqueue_script( 'jquery' );
  wp_enqueue_script( 'jquery-migrate' );
});

Und andererseits sorge ich dafür, dass Contact Form 7 seine CSS-Datein nicht lädt, weil ich die eh mit Bootstrap-eigenen CSS-Regeln überschreibe:

add_filter( 'wpcf7_load_css', '__return_false' );

Der Rest ist die Standard-Konfiguration meines Webservers

• eine Reihe an Nginx-Regeln (vergleichbar mit .htaccess Regeln) kümmert sich um die korrekte Auslieferung der Dateien (z.B. gzip)
• Nginx FCGI Caching liefert ein extrem schnelles Seitenausgabe-Caching
• CSS- und JS-Dateien wurden bereits bei der Theme-Entwicklung zusammengefasst und minifiziert
• Die Bildergrößen sind eh schon richtig, weil ich als Entwickler des Themes auch von vorne herein wusste, welche Größen ich brauche.

Im Ergebnis gibt es bei mir mobil 85 / 100 Punkte und auf dem Desktop 95 / 100 Punkte, ganz ohne jede Optimierung.

Übrigens: natürlich ist es deutlich schwerer, mit Multi-Purpose-Themes und einer riesigen Menge Plugins derartige Werte einfach so zu erreichen. Aber genau das ist ja auch der Punkt: aus technischer Sicht sind viele dieser Themes und Plugins einfach schlecht programmiert, und manche Fehler liegen auch in der Natur der Sache: wenn Du jede Bildgröße in einer ultraflexiblen Zusammenstellung erlauben willst, dann kannst Du vorher nun mal nicht die korrekte Bildgröße kennen, und dann musst Du zwangsweise zu große Bilder verwenden.

Kurzum: mit sauberem Code bekommt man ganz automatisch recht gute Werte. Aber wieso eigentlich nicht 100 / 100 Punkten?

Rendering blockende Dateien

Um zu verstehen, warum wir keine 100 Punkte erreichen wollen, müssen wir uns mit dem konkreten technischen Grund für die Herabstufung beschäftigen. Dieser lautet:

JavaScript- und CSS-Ressourcen, die das Rendering blockieren, in Inhalten „above the fold“ (ohne Scrollen sichtbar) beseitigen

Es ist übrigens immer hilfreich, die konkret von PageSpeed aufgelisteten Probleme zu betrachten, da die Punktezahl selbst einem nicht bei der Behebung der Probleme helfen kann. In diesem Fall sind es rendering-blockierende Dateien. Aber was ist das eigentlich? Dafür müssen wir uns einmal kurz die Struktur der Seite anschauen:

<!DOCTYPE html>
<html>
  <head>
    <title>Mein toller Titel</title>
    [...]
    <link rel='stylesheet' href='https://binary-butterfly.de/mein/tolles/stylesheet.css' type='text/css' media='all' />
  </head>
  <body>
    <div>
      Meine Inhalte
    </div>
    <script type='text/javascript' src='https://binary-butterfly.de/mein/tolles/javascript.js'>
  </body>
</html>

Der Browser liest das HTML von oben nach unten. Bereits während er die Datei liest, beginnt der Browser zu rendern, lies: die einzelnen HTML-Teile zu der nachher sichtbaren Seite zusammenzusetzen. Stößt er auf eine eingebundene Datei wie im obrigen Beispiel das stylesheet.css, muss er diese erst vollständig laden, um weitermachen zu können. Das stylesheet blockt also das Rendern – daher der Name.

Das Script javascript.js wird dagegen erst nach dem Inhalt geladen. Der Browser kann also den gesamten Inhalt rendern und so dem Nutzer schnell anzeigen, bevor der Browser das JavaScript laden muss. Das javascript.js ist daher nicht Rendering-blockierend.

flash of unstyled content

Eine der Lösungen für Rendering-blockierende Ressourcen ist, die Ressourcen einfach nach unten zu schieben. Das wurde in dem Beispiel mit dem JavaScript gemacht – und mit Scripten funktioniert das (sauberer Code vorausgesetzt) auch sehr gut, da diese eh eine fertig geladene Website-Struktur brauchen, um zu funktionieren.

Bei CSS-Dateien ist das dagegen keine besonders gute Idee. Modifizieren wir unser Beispiel ein wenig:

<!DOCTYPE html>
<html>
  <head>
    <title>Mein toller Titel</title>
    [...]    
  </head>
  <body>
    <div>
      Meine Inhalte
    </div>
    <link rel='stylesheet' href='https://binary-butterfly.de/mein/tolles/stylesheet.css' type='text/css' media='all' />
    <script type='text/javascript' src='https://binary-butterfly.de/mein/tolles/javascript.js'>
  </body>
</html>

Jetzt kann der Browser sämtliche Inhalte anzeigen, ohne auf irgendwelche Ressourcen zu warten. Stattdessen sieht man aber ganz kurz die Inhalte der Website ohne jedes Design aufblitzen. Warum?

In der CSS-Datei (Style-Sheet) befinden sich die Regeln für das Aussehen der Website. Der Browser geht wie immer von oben nach unten und rendert live mit. Das bedeutet, dass der Browser erst mal die Inhalte komplett ohne Design darstellt, von den Design-Regeln erfährt er ja erst ganz am Ende. Da die Inhalte ohne Design-Regeln recht hässlich sind, fällt das auch hässlich auf. Daher auch der Name: es flashed kurz der unstyled Content auf, bis eben die CSS-Datei geladen wird. Wenn man ein wenig Wert auf Ästhetik legt, ist das also keine Option (außerdem ist es widersinnig, da es ja darum geht, die Seite möglichst schnell benutzbar zu machen – und eine ungestylte Seite ist nun sicherlich nicht nutzbar.

Sämtliche CSS-Regeln inline

Viele Caching-Plugins sind mittlerweile dazu übergegangen, einfach sämtliche CSS-Regeln inline im <head>-Bereich einzubinden, statt sie aus einer externen Datei zu laden. Das sieht dann in etwa so aus:

<!DOCTYPE html>
<html>
  <head>
    <title>Mein toller Titel</title>
    <style>
      [...] Meine kompletten CSS-Regeln [...]
    </style>
    [...]    
  </head>
  <body>
    <div>
      Meine Inhalte
    </div>
    <script type='text/javascript' src='https://binary-butterfly.de/mein/tolles/javascript.js'>
  </body>
</html>

Der PageSpeed-Test ist damit glücklich: der Browser muss nicht mehr auf eine Datei warten. Auch der Nutzer ist zunächst glücklich: er bekommt alle Inhalte ohne flash of unstyled content angezeigt. Also alles super?

Nein. Das zentrale Problem liegt an der Menge der CSS-Regeln, und genau dadurch macht man am Ende seine Seite eher langsamer als schneller. Denn: so eine CSS-Datei ist ganz schön groß – hier mal als Beispiel die noch recht kleine CSS-Datei dieser Seite hier. All diese CSS-Regeln müssen nun in den HTML-Kopfbereich. Dadurch kommt sehr sehr viel CSS auf sehr, sehr wenige Inhalte – das Verhältnis zwischen Inhalten und helfenden Elementen wie HTML-Tags oder eben CSS ist nicht mehr gewahrt. Das kreidet manch ein SEO-Tool zu Recht an.

Wenn ein Besucher nun weiter auf der Seite bleibt, ist dieses Verfahren sogar zum Geschwindigkeits-Nachteil: da die CSS-Regeln im Header sind, müssen die CSS-Regeln bei jeder einzelnen aufgerufenen Seite mit ausgeliefert werden. Damit muss man am Ende viel mehr Daten übertragen, als es eigentlich notwendig ist. Die externe CSS-Datei würde nämlich nur ein einziges mal geladen werden, bei allen weiteren Seitenabrufen wäre sie im Browser-Cache und daher sofort verfügbar.

Der Königsweg: CSS aufsplitten

Die Empfehlung von Google lautet daher, die CSS-Regeln aufzusplitten. Das sähe dann so aus:

<!DOCTYPE html>
<html>
  <head>
    <title>Mein toller Titel</title>
    <style>
      [...]Meine wichtigen CSS-Regeln[...]
    </style>
    [...]    
  </head>
  <body>
    <div>
      Meine Inhalte
    </div>
    <link rel='stylesheet' href='https://binary-butterfly.de/mein/tolles/stylesheet.css' type='text/css' media='all' />
    <script type='text/javascript' src='https://binary-butterfly.de/mein/tolles/javascript.js'>
  </body>
</html>

Dies wäre der perfekte Weg: einerseits hat der Browser ganz am Anfang schon die wichtigen CSS-Regeln, um den gerenderten Inhalten von Anfang an eine Struktur und ein recht brauchbares Aussehen zu geben, andererseits muss der Browser nichts warten, da die Detail-Regeln erst nach den Inhalten geladen werden.

Das Problem an diesem Weg ist nur: auf modernen, komplexeren Seiten lassen sich wichtige und unwichtige CSS-Regeln nicht voneinander trennen. Das gilt erst Recht für CMS oder Blog-Systeme wie WordPress. Daher:

Der pragmatische, sinnvolle Weg

Der pragmatische Weg versehentliches Reduzieren der Geschwindigkeit durch massenhaften Inline-Code ist daher die ganz am Anfang vorgestellte Variante: CSS als externe Datei in den Kopfbereich, JavaScript in den Fußbereich. Um dies zu erreichen, machen Plugins wie Autoptimize Sinn, ebenso wie die in umfangreichen Caching-Plugins wie W3 Total Cache oder WP Rocket integrierten Minification-Funktionalitäten Sinn machen.

Wichtig ist nur, dass man die CSS im HTML Head behält; beachtet man dies, ist das Zusammenfassen von CSS-Dateien recht gefahrenlos. Die Scripte kann man getrost in den Fussbereich schieben, dort muss man nur aufpassen, dass es zu keinen JavaScript-Fehlern kommt. Anfänger sollten daher von der JavaScript-Minification Abstand nehmen. [UPDATE]Alternativ können Scripte natürlich auch asynchron geladen werden, das hat am Ende denselben Effekt. In manchen, sehr, sehr seltenen Fällen ist das asynchrone Laden sogar vorteilhaft, wie z.B. bei Analytics, wenn einem die Anzahl der abgebrochenen Seiten-Ladevorgänge wichtig ist.[/UPDATE]

Am Ende bedeutet das, dass man auf einige PageSpeed-Punkte verzichten muss, wenn man den technisch sinnvollen Weg gehen will. Aber das sollte es einem Wert sein, schließlich möchte man seinem Nutzer ja eine gute Seite bieten, nicht Google. Zumal Google auch einfach keine Fleißbienchen-Punkte verteilt, nur weil man jeden einzelnen Punkt in PageSpeed erfüllt hat. Wenn es technisch sinnvoll ist, dann kann man durchaus auch einen vermeintlichen Fehler drin lassen.

Dies gilt im übrigen für jede Form von Tools: hört auf, Euch panisch zu machen wegen irgendwelcher automatisierten Analysen. Automatik-Analysen haben ihre Grenzen. Das heisst nicht, dass derartige Automatik-Analyse-Tools sinnlos sind. Aber Ihr seid es, die die Ergebnisse interpretieren müsst. Euer Kopf muss das verstehen, die dahinter liegenden Probleme (sofern vorhanden) identifizieren und beseitigen. Das kann nur ein menschlicher Kopf machen. Das Tool hilft euch nur, mehr Daten für eine gute Entscheidung zu bekommen. Mehr nicht.