Google: Ladegeschwindigkeit wird Rankingfaktor

22 Kommentare

Google hat die Ladegeschwindigkeit einer Website zu einem von insgesamt 200 Rankingfaktoren befördert. Das heißt in der Zukunft wird die Position einer Website in Google auch von Ihrer Performance bzw. der Ladegeschwindigkeit abhängen. Mehr zu diesen Thema kann man im Weblog von SISTRIX nachlesen.

Das ist gut, Performance-Optimierung ist nun ein SEO-Faktor und war schon seit eh und jeh ein wichtiger Usability-Faktor: wer wartet schon gerne.

Google Webmaster Tools
Google Webmaster Tools: Performance einer Website

Doch bevor man jetzt alles optimiert was nicht bei drei auf den Bäumen ist sollte man bedenken, dass dieser SEO-Faktor nur einer von 200 ist und das es so sein wird das die anderen Faktoren, wie z. B. die Relevanz des Inhalts, ein größeres Gewicht haben. Daher braucht man nicht zu hoffen, dass man alleine, weil die Website wie Schmitz’ Katze abgeht, in die Top-10 der Suchergebnisse reinkommt.

Aber auch aus Usability-Gründen darf man sich nicht zu Tode optimieren. Ergänzt ein Bild oder Grafik den Text-Inhalt, dann sollte man nicht darauf verzichten. Man kann sich aber überlegen ob man für das Bild das richtige Format gewählt hat und ob man es nicht evtl. noch stärker komprimieren kann.

Beim Fundament beginnen

Schaut man sich so einige der 100.000 Tricks zur Optimierung der Ladegeschwindigkeit von WordPress-Websites, dann bekommt man das Gefühl eine Optimierung besteht lediglich darin eines der tollen Cache-Plugins zu installieren und schon ist alles erledigt.

Aber eine Performance-Optimierung fängt schon bei dem Aufbau des (X)HTML- und CSS-Codes an … so wie allen Websites auch, egal ob statisch oder dynamisch und mal davon unabhängig welches CMS im Hintergrund werkelt. Hier ein kleines Beispiel damit man sieht was ich meine. Zuerst die weniger gute Variante, zuerst das (X)HTML:

<div id="sidebar">
    <div class="klasse1">
        <h3>Überschrift</h3>
    </div>
    <div class="klasse2">
        <ul>
            <li class="klasse2_1">Listenpunkt</li>
        </ul>
    </div>
    <div class="klasse3">
        <p>Text + <span class="klasse4">Hervorhebung</span>.</p>
    </div>
</div>

und das passende CSS dazu:

.klasse1 h3 {...}
.klasse2 ul {...}
.klasse2_1  {...}
.klasse3 p  {...}
.klasse4    {...}

Und hier das bessere Beispiel. Zuerst HTML:

<div id="sidebar">
    <h3>Überschrift</h3>
    <ul>
        <li>Listenpunkt</li>
    </ul>
    <p>Text + <i>Hervorhebung</i>.</p>
</div>

Und dann das CSS:

#sidebar h3 {...}
#sidebar ul {...}
#sidebar li {...}
#sidebar p  {...}
#sidebar i  {...}

In dem man auf unnötige div-Blöcke und unnötige Klassen verzichtet und dann noch dazu die Kurzschreibweise bei CSS (z. B. #000 statt #000000) einsetzt, hat man nicht nur den ersten Schritt bei der Optimierung getan sondern die Dateien auch übersichtlicher und wartbarer gemacht.

Hardcoden vs. Dynamik

Aber auch bei der Erstellung der WordPress-Themes kann man schon von Beginn an optimieren. Setzt man das Theme lediglich bei sich selbst ein – also nicht beim Kunden oder zum freien Download – dann kann man auf einiges in der Dynamik verzichten.

Anstatt <?php bloginfo('stylesheet_url'); ?> einzusetzen kann man den Pfad zu der CSS-Datei auch ausschreiben oder wenn die Website einsprachig ist, dann kann man solche Konstrukte <?php _e("Leave a comment"); ?> auch direkt übersetzen und im Quelltext manuell notieren. Durch solche einfache Maßnahmen spart man sich zusätzliche Anfragen an den Webserver.

Bilder optimieren

Eine weitere grundlegende Optimierung wird häufig vernachlässigt. Zum einen sind die Dateigrößen der Grafiken im Inhalt häufig zu groß und es wird in vielen Fällen das falsche Format gewählt.

Um für den Webeinsatz gut optimierte Grafiken zu bekommen muss man nicht auf Großgewichte wie Photoshop oder GIMP zurückgreifen, auch so einfache Freeware wie IrfanView bietet, erweitert durch Plugins, einen recht ordentlichen Export für Webgrafiken. Und natürlich bieten auch so einfache Tools einen guten Batchmodus, wo man in einem Rutsch mehrere Grafiken optimieren kann. Zum Thema Bilder optimieren schrieb ich auch bereits ein paar Worte: WordPress-Websites beschleunigen 2: Grafiken Optimieren.

Komprimieren und cachen

Wenn man die oberen Schritte beherzigt hat, dann kann man sich imho Gedanken machen wie man die Dateien auf dem Server komprimieren und cachen (zwischenspeichern) kann. Wie ich schon sagte, gibt es alleine für WordPress eine Reihe an Plugins, die Inhalte komprimieren und zwischenspeichern. Aber bevor man sie einsetzt sollte man wissen, dass es mit denen manchmal Probleme geben kann.

Zudem bin ich der Meinung, dass man sich anschauen soll was der Webserver an Maßnahmen zu bieten hat bevor man WordPress-Plugins installiert. Ich bin der Meinung, dass die Mittel die z. B. Apache (oder auch andere Webserver) zur Verfügung stellt doch etwas Leistungsfähiger und Ressourcen-schonender sind, als das was man über den Umweg über PHP (WP-Plugins) erreichen kann. Falls ich hier Blödsinn erzähle, korrigiert mich bitte.

gzip-Kompimierung und besser cachen mit Apache 2

Folgenden Code habe ich schon in diesem Weblog an mehreren Stellen erwähnt. Unter anderem hier: WordPress-Websites beschleunigen 4: ein Zwischenergebnis.

# mod_deflate (gzip) aktivieren
<FilesMatch "\\.(js|css|html|htm|php|xml)$">
SetOutputFilter DEFLATE
</FilesMatch>

# ExpiresHeader: verhindert bedingte GET-Anfragen
<IfModule mod_expires.c>
ExpiresActive on
ExpiresDefault "access plus 35 days"
</IfModule>

Den oberen Code einfach in die .htaccess-Datei eintragen, gilt aber nur für Apache 2.0. Und was macht der Code? Der erste Block komprimiert alle Textdateien (HTML, CSS, Javascript etc.) bei der Übertragung.

Andere Formate würde ich hier nicht einfügen, denn z. B. Bilder sollte man mit einem Grafik-Programm komprimieren. Jede Komprimierung kostet Rechenkraft des Servers und daher sollte man sie nur einsetzen, wenn es auch einen wirklichen Vorteil gibt.

Eine gzip-Komprimierung bei einer Bildergalerie-Website ist daher wenig sinnvoll, die Optimierung der wenigen Textinhalte ist im Ergebnis verschwinden gering wie wenn man die ganzen Grafiken mit einer ordentlichen Bildbearbeitung für Web optimiert.

Der zweite Block erweitert die Caching-Funktion des Browsers in dem zusätzliche Anfragen des Browsers an den Server – “wie lange ist die Grafik in meinem Cache noch gültig?” – verhindert werden. Der zweite Code-Block besagt, dass alle Komponenten der Website im Browsercache noch mind. 35 Tage aktuell sind.

Und weiter?

Die Maßnahmen, die ich beschrieben habe sind nur die Spitze des Eisberges. Aber ich denke, dass sie zu einem ein gutes Fundament darstellen und das im Verhältnis zum Einsatz recht gute Ergebnisse liefern. Reichen diese Maßnahmen nicht, dann kann man so Plugins wie WP Super Cache und /oder CSS-JS-Booster von Christian “Schepp” Schaefer ausprobieren.

Wir arbeiten seit 20 Jahren mit WordPress und bieten diverse Dienst­leistungen rund um das System an. Kontaktiere uns für weitere Informationen oder für ein Angebot.

Verwandte Beiträge:

Über Vladimir

Vladimir Simović arbeitet seit 2000 mit HTML & CSS und seit Januar 2004 mit WordPress. Im Laufe der Jahre hat er diverse Fachbücher und Fachartikel publiziert.

Schlagwörter: , , , , ,

22 Kommentare

  1. Anstatt einzusetzen kann man den Pfad zu der CSS-Datei auch ausschreiben oder wenn die Website einsprachig ist, dann kann man solche Konstrukte auch direkt übersetzen und im Quelltext manuell notieren. Durch solche einfache Maßnahmen spart man sich zusätzliche Anfragen an den Webserver.

    Der Performance-Gewinn durch solche Änderungen geht gegen 0. Der bloginfo()-Call ist nur ein einfacher Array-Key-Lookup, also rasend schnell. Das Übersetzen des Themes zu streichen macht auch nur dann Sinn, wenn man das Laden der Sprachdatei komplett unterbindet (ich weiß nicht, ob WP damit klar kommt, ab Version 3.0 wird ja auch das Default-Theme lokalisiert).

    “Optimierungen” dieser Art, sollte man, wenn es geht, unterlassen. Denn sie schränken dich im Prinzip nur ein und können in Zukunft zu Problemen führen. Premature optimization is the root of all evil.

    Die Frontend-Optimierungen haben da einen viel größeren Effekt und sind auch wesentlich leichter umzusetzen.

  2. Hallo paddaya,

    “Optimierungen” dieser Art, sollte man, wenn es geht, unterlassen. Denn sie schränken dich im Prinzip nur ein und können in Zukunft zu Problemen führen.

    Ich mache dies bei meinen eigenen Projekten schon lange und ich konnte keine Probleme und auch keine Einschränkung feststellen. Welche Probleme sollte es auch geben? Es ist ja nicht so, dass man alle 2 Tage den Pfad der CSS-Datei, den Zeichensatz und die eingesetzte Sprache im Frontend wechselt.

  3. Es ist ja nicht so, dass man alle 2 Tage den Pfad der CSS-Datei, den Zeichensatz und die eingesetzte Sprache im Frontend wechselt.

    Da magst du Recht haben. Trotzdem mag ich das Gefühl nicht, wenn ich weiß, dass ich noch an zig anderen Stellen eine Sache manuell ändern muss, wenn ich irgendwelche Pfade im Laufe der Entwicklung anpasse. Man vergisst dann leicht mal was (bei einem Stylesheet fällt das schnell auf, aber ein kleines JavaScript übersieht man gerne mal).

    Und wenn man das Theme eh nicht “from scratch” aufbaut, steht der Mehraufwand zur Entfernung der Funktionsaufrufe aus der Vorlage nicht wirklich im Verhältnis zum Geschwindigkeitsgewinn (ein Bruchteil einer Millisekunde).

  4. Ich codiere schon lang hart und hab auch noch nie Probleme damit gehabt. Die Sprachdatei fliegt als letzten noch raus, da fehlen noch ein paar Sachen. Aber ich denke ein PHP Ram Verbrauch von 9MB und ein Pingdom Wert von ca. 1Sek. zeigen das dies nicht der falsche Weg ist.

  7. Naja ich sehe dem ganzen etwas kritisch entgegen. Klar sollten sich Ladezeiten gering halten, was aber Themenbedingt manchmal schwer umsetzbar ist.

    Beispiel


    Kinohomepage hält Bilder, Trailer und Infotext muss damit nun einiges laden. Ein div. Blog hat nur den Infotext. Nach Ladezeit gehend wird die höherwertige Seite abgestraft?!

    Also in Zeiten von DSL finde ich Ladezeit als Rankingfaktor eher Rückschritt in Internetmittelalter. Mit meinem alten 56k-Modem hätte ich das in den 90iger Jahren eher sinnvoll gehalten.

  9. danke für den Artikel, da sind für mich auf jeden Fall ein paar Ansatzpunkte drin, ich habe bei meinem Theme versucht die statischen Seiten so klein wie möglich zu halten, mit den Bildern solte man auf jeden Fall aufpassen, da denke ich steckt viel Potential.

    Was den Ranking Faktor anbelangt, denke ich ist der Ansatzpunkt von Google gar nicht so falsch, denn schließlich wollen sie ja auch eine Echtzeitsuche anbieten und da kommt dies schon hin und nur weil es DSL gibt muss man Resourcen nicht verschleudern, was ich leider bei vielen Themes gerade sehe. Was aber noch schlimmer ist, ist der eigentliche Aufbau der Seiten, da kann meiner Meinung nach wesentlich mehr an Rankingfaktoren kaputt gemacht werden, als bei dem bisschen Geschwindigkeit.
    Grüße Victor

    PS: Mein letzter Kommentar ist leider nicht angekommen, lande ich im Spam?

  10. WordPress für sich ist gar nicht sooo langsam, wie gerne behauptet wird.

    Oft sind es eher Plugins oder ein mit Gimmicks vollgestopftes Theme, was als Bremse wirkt. Und auch viele externe Resourcen, wie zig Blog-Listen-Zähler oder Facebook, Xing und was nicht alles für Profile tragen nicht grad zu einer hohen Gesamtperformance der Seite bei.

  11. […] mich ein wenig ärgert, denn ich möchte mindestens 95 % von jeder Statistik Seite bekommen. Einen guten Tipp hat auch Vladimir gegeben und hat das Thema angesprochen. Sehr lesenswerter Artikel, welcher mir […]

  12. Eine kurze Frage. Mein neues Design welches noch im Aufbau ist, also zwar schon online aber noch nicht öffentlich, habe ich bisher 134 Abfragen auf 1.257 sekunden. Ist das viel? Dabei habe ich derartige Links zu zb. CSS Datein und-/oder Navigationen statisch hinterlegt. Aber schon seit ich mit WP arbeite.

    Meine Seite ist relativ umfangreich.

    Danke.

  13. […] wo Google erst einmal nur die Ladegeschwindigkeit der Webseite als einen Rankingfaktor für den Pagerank(R) mit einbezieht, ist die Aufregung in der SEO-Gemeinde groß. Och Gott oh Gott […]

  14. […] ausführlicher kann man den Bericht auf Perun.net verfolgen. Veröffentlicht in Allgemein | Schlagworte: google, ladezeit, performance, […]

  15. […] Google kürzlich angekündigt hatte dass die Ladegeschwindigkeit einer Website als Rankingfaktor einbezogen wird – und damit schnelle Seiten potenziell weiter vorne in den Google […]

  18. Leider kann man keine Kommentare mehr zu dem Thema “WordPress-Websites beschleunigen 4: ein Zwischenergebnis” hinterlassen. Ich habe nach einem Plugin gesucht, welches alle CSS und JS-Dateien zu einer Datei zusammen fassen kann und nichts gefunden. Kennst du eines? Jedenfalls arbeite ich momentan an einem und es sieht bis jetzt relativ gut aus.

  19. […] perun.net gibt es dazu einen Artikel, welcher WordPress behandelt. Mit Tools wie YSlow und Page Speed (Firefox Addons) oder aber auch […]

  20. […] Perun.net Wenn andere diesen Artikel ebenfalls lesen sollten: […]

  21. Ich bin schon der Meinung, dass die Ladegeschwindigkeit einer Website ein Thema ist. Ich selber warte ja auch nicht gerne, bis eine Website komplett aufgebaut ist (am längsten dauern immer die ganzen AdServer & Co.), weil mich das einfach nervt.

    Nur weil Google jetzt die Seitenladezeit als eines von vielen Kriterien für das Ranking hochstilisiert, werde ich mir da kein Bein ausreißen, ich nutze ein gut codiertes Theme (Thesis) und ein einziges Cache-Plugin, mehr werde ich da nicht tun.

    In den Webmastertools von Google kann ich sehen, ob Google ein Problem mit meinem Blog hat (hat es nicht), da schaue ich ab und an mal rein und damit ist das Thema für mich durch.

    Letztendlich zählt doch guter Content und Links deutlich mehr als Ladezeiten.

    Jürgen Schnick

Kommentare sind geschlossen.