Page Speed Insight und RapidWeaver.

Egal ob mit oder ohne RapidWeaver erstellt, Ladegeschwindigkeit spielt bei Webseiten eine wichtige Rolle. Einmal ist da der Benutzermehrwert allein aufgrund einer schnell ladenden Webseite...

...denn was nützt eine komplexe Webseite, wenn die Inhalte erst nach unerträglich länger Wartezeit im Browserfenster erscheinen…?

Dann aber ist Ladezeit wichtig aus Sicht der Suchmaschinen:

Google hatte bereits vor einiger Zeit angekündigt, dies zu einem Rankingfaktor zu machen. Ob das wirklich bereits so umgesetzt wird, ist derzeit noch nicht sicher, aber immerhin hat Google ein kleines Tool bereit gestellt, mit dem man die Ladezeit seiner Seiten überprüfen kann. Und man bekommt in diesem Tool auch gleich Hinweise, wie man eine Verbesserung der Ladegeschwindigkeit erreichen kann:

Page Speed Insight

Das Tool wertet im Wesentlichen den Kompressionsgrad verschiedener Website-Dokumente aus, schaut nach den Größen der Bilddateien und verrechnet das zu einem Score.

 

Doch das Tool ist mit Vorsicht zu geniessen:

Der Score wird auf der Grundlage eines Algorithmus berechnet, in welchen Werte eingehen, die den Optimierungsgrad einer Webseite allenfalls ausschnittweise bewerten.

Letztlich untersucht Page Speed Insight (= PSI) gar nicht die Ladezeit einer Webseite, sondern wertet einige Qualitätsmerkmale bestimmter Dokumente im Backend einer Webseite aus, die nur mittelbar mit Ladegeschwindigkeit zusammenhängen. Aber diese Faktoren sind nicht allein ausschlaggebend.

So kann eine durchaus performante Seite einen schlechteren Score haben wie eine Seite, die zwar bescheiden daher kommt, aber deren Javascript- oder CSS-Dokumente den eher theoretischen Anforderungen von PSI entspricht. Was übrigens gar nicht in das Tools eingeht, ist die „subjektive Ladezeit“, also das Empfinden des Nutzers, ob und ab welchem Moment der Inhalt einer Seite für den Seitenbesucher nutzbar ist.

 

Am Bedarf für RapidWeaver vorbei

Für den RapidWeaver-Nutzer hat das Tool ohnehin nur sehr begrenzten Nutzen, denn an vielen Faktoren kann er nichts ändern, weil er innerhalb von RapidWeaver an die entsprechenden Dokumente gar nicht heran kommt.

Und es würde auch nichts nützen, auf dem Server an den bemängelten Dokumenten herumzuschrauben, weil beim nächsten Upload die ganzen Änderungen von RapidWeaver wieder überschrieben werden. Und an externe Server eines CDN, an deren Kompressionsgrad PSI gerne herumkrittelt, kommt der normale Nutzer ohnehin nicht dran.

Ebenso ist der übliche RapidWeaver-Nutzer damit überfordert, die Server-Architektur, die eine Webseite an den Seitenbesucher ausliefert, zu ändern. Sicher mag ein Nginx-Server schneller sein wie ein meistens genutzter Apache-Server - aber wer will sich einen solchen Umzug schon antun…

Schauen wir einmal, wo wir mit den begrenzten Mittel, die einem RapidWeaver-Nutzer zur Verfügung stehen, herumschrauben können:

 

Gzip und Deflate Compression

Für ein komplettes Projekt lässt sich Ladezeit verringern durch eine projektweite serverseitige Kompression von Webdokumenten mit Hilfe der sogenannten „Gzip und Deflate Compression“, die in die .htaccess geschrieben wird:


# Deflate Compression by FileType
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/atom_xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-shockwave-flash
</IfModule>

 

Schrauben an den Bilddateien

PSI bemängelt fast immer auch die Größe von Bilddateien. Gleichzeitig bietet es aber eine praktische Funktion, optimierte Bilddokumente herunterzuladen, mit denen man dann die bereits eingefügten überschreiben kann. Tatsächlich sind die Dateigrößen von Bildern meist auch der größte Bremsklotz für die Ladegeschwindigkeit und hier werden fast durchgehend Fehler gemacht. Aber es macht wenig Sinn, mit großen Aufwand durch Optimierung von Bildern 2% der Dateigröße einsparen zu wollen.

Die von PSI aufbereiteten und heruntergeladenen Bilder landen im Download-Ordner deines Rechners in einem Unterordner „images“. In einem ersten Schritt kannst die optimierten Dateien gegen die auf dem Server abgelegten austauschen - diese liegen im Ordner „resources“ oder seitenbezogen in einem Ordner „files“. Im zweiten Schritt tauschst du die Bilder im RapidWeaver-Projekt aus.

 

Browsercaching

Browsercaching dient der schnelleren Anzeige von Webseiten. Der Browser speichert einzelne Teile deiner Webseite lokal in einem Cache auf dem Rechner des Seitenbesuchers. Wird die Seite (oder ähnliche Seiten) erneut aufgerufen, werden bestimmte Dokumente aus dem Cache geladen und müssen nicht aus dem Internet geholt werden - das spart Ressourcen und Ladezeit.

Dieses Browsercaching kann man mit entsprechenden serverseitigen Vorgaben in der .htaccess steuern, z.B. mit diesem Code, der den Ablauf auf 1 Monat festlegt:

# turns cache on for 1 month
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/css "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType text/html "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 month"
</IfModule>
<ifmodule mod_headers.c>
<filesmatch "\\.(ico|jpe?g|png|gif|swf)$">
Header set Cache-Control "max-age=2592000, public"
</filesmatch>
<filesmatch "\\.(css)$">
Header set Cache-Control "max-age=604800, public"
</filesmatch>
<filesmatch "\\.(js)$">
Header set Cache-Control "max-age=216000, private"
</filesmatch>
</ifmodule>


Verfallsdatum der Webseite

Alternativ kannst du dir auch überlegen, zumindest , mit dem EXPIRES-Meta-Tag die Webseite mit einem ein „Verfallsdatum“ auszuzeichnen. In RapidWeaver kannst du dazu im Page Inspector unter „Meta-Tags & HTML eingeben: expires (linke Spalte) und einen Zeitwert in Sekunden (rechte Spalte) oder als Meta-Code:

<meta name="expires" content="86400" /> 

Diese Angabe steuert ebenfalls das Caching einer Webseite, beim obigen Beispiel wird festgelegt, dass die Webseite für 24 Stunden (= 86400 Sekunden) auf dem Zielrechner zwischengespeichert und beim Neuaufruf aus dem dortigen Cache und nicht aus dem Internet abgerufen werden soll.

 

Geh das Thema entspannt an

Die oben genannten Optimierungsmaßnahmen brauchen keinen allzu großen Aufwand. Alles andere, was in PSI bemängelt wird, kannst du dir als RapidWeaver-Nutzer sparen. Du kommst entweder nicht an die Dokumente heran oder der Aufwand wäre derart groß, dass er wirtschaftlich zu vertreten wäre.

Du brauchst auch keinen PSI-Score von 100/100. Auch eine Seite mit einem deutlich schlechteren Score kann ausreichend gut geladen werden. Und über die Nutzererfahrung oder die Conversion-Rate sagt dieses Tool ohnehin nichts aus. Der Score ist allenfalls ein grober Anhaltswert.

Eine brauchbare Alternative mit deutlich genaueren Werten bieten Pingdom oder noch besser Webpagetest. Ziel sollte sein, die Ladezeit deiner Webseite unter 2 Sekunden zu halten, aber allein das ist oft bereits eine schier unlösbare Aufgabe, wenn man eine nur halbwegs ansprechend gestaltete Seite erstellen will.

Viel wichtiger ist:

  • erstelle eine saubere, gut strukturierte Seite. Beschränke die Features auf ein Minimum - es muss nicht jeder hippe Effekt, den du in irgendeinem Stack gefunden hast, in eine einzige Seite gepackt werden
  • überfrachte deine Seite nicht mit Inhalten, beschränke dich v.a. bei der Verwendung von Bildern und baue nur Bilder in optimierter Pixel-Größe ein; Videos lagerst du am Besten aus und lädt sie von Vimeo oder YouTube (Stacks gibt es dafür genug)
  • schau dir die Ressourcen an, auf welche die von dir genutzten Stacks oder auch das Theme zurückgreifen und reduziere im Einzelfall den Rückgriff auf CDN (Content Delivery Networks)
  • Javascript-Code steht im Quelltext am Besten recht weit unten um das Laden der anderen Inhalte nicht zu behindern. U.U. musst du dazu die index.html des Theme-Packages etwas umstrukturieren (in Foundation geht das mit dem SEO-Helper)

 

Wenn du an weiteren Informationen zum Thema " RapidWeaver und Suchmaschinenoptimierung" interessiert bist, kannst du auch hier vorbeischauen:

RapidWeaver SEO