Need for Speed: Webseiten-Performance beschleunigen

Nicht nur für SEOs: Beschleunigung von Webseiten

Es bleibt aktuell: Markus Ostertag (ehemals moviemaze.de) hat auf einem Vortrag das Thema „Need for Speed“ sehr umfassend zusammen gefasst. Dieser Beitrag entstand mit seiner Zusammenarbeit und hat an Aktualität nichts verloren. Einzige die Google Page-Speed-Services wurden in der Zwischenzeit mächtig ausgebaut – und können jetzt noch besser für die Performance-Optimierung von Webseiten verwendet werden.

Noch ein kurzer Sitestep: Ist die Performance – also die Geschwindigkeit einer Webseite – denn überhaupt ein SEO-Thema? Wenn man Google glaubt, auf jeden Fall. Denn Matt Cutts hat ja im vergangenen Jahr darauf hingewiesen, dass die Performance ein Ranking-Faktor ist. Viele Kollegen auf der SEO-Campix sind allerdings gar nicht dieser Meinung und wir sehen tatsächlich reichlich lahme Sites, die trotzdem super ranken. Also was jetzt?

Es gibt sicherlich mindestens drei Gründe, die für eine schnelle Site sprechen: Erstens ermöglicht eine hohe Crawlinggeschwindigkeit, dass ggf. mehr Seiten in den Index wandern. Zweitens werden viele User bei Ladezeiten von mehreren Sekunden sicher entnervt auf die Suchergebnisse zurück-klicken – und das wirkt sich via Bouncerate negativ aufs Ranking aus. Und schließlich ist eine schnelle Seite immer gut für mehr Klicks und bessere Conversions. Das ist streng genommen kein SEO-Thema. Aber irgendwie schon.

Die Optimierung der Performance einer Site lässt sich unter drei Überschriften vornehmen:

Also zur Sache: Size does matter!

Hier die drei zusammen gefassten Tipps von Markus, vermischelt und erweitert mit den Erfahrungen anderen Teilnehmer und mir:

  • Bilder sollten auf die notwendige Größe reduziert werden. Es muss nicht immer ein JPEG mit 100% Qualität und ein PNG24 sein. 70 % JPEG und PNG 8 reichen meist. Aber das sollte dann wohl von Bild zu Bild entschieden werden. Also sollte ausprobiert werden, ob es hierfür einen vernünftigen Workflow geben kann…
  • Wer auf dem Server die gzip-Komprimierung nicht einschaltet, ist selber schuld. Diese kann 60 % der übertragenen Daten reduzieren. Natürlich abgesehen von den eh schon komprimierten Bildern.
  • Mit „Minify“ werden Leerzeilen, Leerzeichen und Kommentare aus dem Code heraus gepuhlt. Dafür gibt es fertige Scripte wie z.B. Google ModSpeed. Aber Obacht: Das sollte nur mit Vorsicht getan werden. Denn das Weglassen der falschen Zeilenschaltungen oder Leerzeichen kann ein Script schließlich töten (Leerzeilen und Kommentare können natürlich immer raus). Außerdem ist der Code ohne diesen „Ballast“ schwerer zu lesen. Deshalb sollte  mindestens im CMS immer die „normale“ Version gehalten werden und erst beim Publizieren eine Minify-Version auf die Webserver gespielt werden. So kann man immer wieder zurück auf die Original-Version.

Next: Schauen wir auf die Connections

  • Browser bauen jeweils nur eine bestimmte Zahl von Connections gleichzeitig zu einem Host auf (IE7 2, IE8, ff3 15, Chrome 6, Safari 8.) Idealerweise werden bei einer hohen Bandbreite des Users aber so viele Daten wie möglich gleichzeitig geladen. So kann es eine kluge Lösung sein, die Dateien über mehrere Hosts zu laden. z.B. manche Bilder nicht über www.domain.de sondern auf www2.domain.de. Noch besser ist, dies auf einer ganz eigenen Domain zu machen, die keine Cookies wirft, deshalb ist www.domain2.de aus Performance-Gründen noch besser. Obacht aber für Bilder-SEOs: Ein Teilnehmer hatte dieses Problem schon mit Martin Mißfeld diskutiert und sie haben sich darauf geeinigt, dass große Bilder (die ranken sollen) auf die eigene Domain gepackt werden – und alles andere auf eine andere, cookieless Domain. So schön können Workshops das Wissen vieler verdichten!
  • Und doch rudern wir wieder ein bisschen zurück: Da der Verbindungsaufbau zu jedem Host wegen des DNS Lookup auch wieder Zeit kostet, sollte man die Parallelisieren auch etwas begrenzen. Hier ist das Bauchgefühl eines erfahrenen Webmasters gefragt. Markus meint, dass 10 unterschiedliche Domains sicherlich zu viel, und 3-5 wohl eine gute Zahl sind.
  • Das Javascript muss seriell abgearbeitet werden. Eine Aussage, die meine technische Kompentenz übersteigt, aber dazu führt, dass das Auslagern auf andere Hosts keinen Vorteil bringt. Deshalb: Packt möglichst viel davon in eine einzige Javascriptdatei. Das lässt sich nicht immer machen – aber es ist die richtige Zielvorstellung.
  • Für bestimmte Javascript-Dateien – die sehr häufig auch von anderen Seiten verwendet werden –  können die Dateien z.B auch über Google Code geladen werden. Das spart eigene Bandbreite und außerdem liegen sie dann möglicherweise auch schon im Cache vieler User. Achtung: Das funktioniert lt. eines Teilnehmer mit manchen AdServern nicht. Dann muss doch wieder selbst gehostet werden.
  • Höchste Prio: Da das CSS für das Rendering der Seite notwendig ist, sollte es möglichst optimal, gerne auch komprimiert aber natürlich auch in einer Datei vom Server in den Browser geschoben werden. Noch ein Tipp hierzu: Manche Seiten haben gigantische CSS-Files, die für alle Unterseiten (von Home bis hin zur Gallerie) alles detailliert definieren – egal, ob es grad gebraucht wird oder nicht. Da macht es Sinn, nur jeweils das auzuliefern, was gerade gebraucht wird. Also keine Homepage-Formatierungen auf der Galerie und anders herum. Das gilt übrigens auch für die Javascript-Dateien…
  • Wer mit HTTP1.1. unterwegs ist, schicke bitte immer „KeepAlive“ mit (was wohl die Grundeinstellung ist). Es gibt wohl keinen Grund das auszuschalten… (äh, gibt es hier Widerspruch?)

Finaly: Caching!

Wie lange sollte man die Daten im Cache halten? Auch hier muss jeder seine passende Balance finden. Zwei Gedanken dazu:

  • Wer hier viele Monate oder Jahre einstellt, muss wissen, dass die User dann die Datei auch ewig so sehen. Zum Beispiel ein neues Logo muss dann mit einem neuen Dateinamen eingebaut werden.
  • Außerdem sollte das natürlich auch rechtlich beurteilt werden. Hat man einen abmahnfähigen Artikel publiziert und ändert diesen nach dem bösen Schreiben eines Anwalts, wird dieser die Seite (bzw. z.B. das Bild darauf) erst dann neu sehen, wenn der Cache abgelaufen ist. In der Zwischenzeit wird der Abmahnanwalt begeistert Screeshots schießen…

Also Obacht – aber ansonsten möglichst lange Cache-Zeiten. Gell?

Tools: Und womit mache ich das?

Übersicht bei webpagetest.org

Zwei Tipps für Web-Tools sind wepagetest.org und site-perf.com. Viel erreichen kann man bekanntlich auch mit Googles PageSpeed und Yahoos Yslow. Die meisten haben schon regelmäßig mit Webpagetest gearbeitet – und das kann ich auch allen stark empfehlen. Es gibt auch weitere Tools, die zu verwenden sind, aber die genannten beiden sind definitiv nicht nur ein guter Start sondern helfen viel weiter.

Und jetzt los!

GD Star Rating
loading...
Need for Speed: Webseiten-Performance beschleunigen, 3.7 out of 5 based on 3 ratings

Eric Kubitz

Eric Kubitz ist einer der Chefs der CONTENTmanufaktur GmbH . Außerdem ist er Redner auf Konferenzen, Dozent bei Hochschulen, schreibt über SEO (und über andere Dinge) und ist der Chefredakteur des SEO-Book.

More Posts - Website - Twitter - Facebook - LinkedIn - Google Plus

Kommentare (10)

  1. Pingback: Recap zur SEO Campixx 2011 « mindshape Blog

  2. Pingback: Vorträge und Slides der SEO Campixx 2011 « mindshape Blog

  3. Pingback: Campixx 2011 – alle RECAPS auf einen Blick | Seobrause

  4. Pingback: SEO Campixx 2011 Recap + Präsentationssammlung » Links, Präsentationen, Campixx, Google, OnPage, Analytics » nordse(e)o.de

  5. Pingback: SEO Campixx 2011 – Recap @ Daily Online

  6. Pingback: SEO Longtail KPI Vortrag & Campixx 2011 Recap | Ideenkrieger

  7. Cujo

    Sehr guter Artikel 🙂

    Hast du vielleicht einen Link unter dem ich das mit der seriellen Abarbeitung von Javascript nachlesen kann?

    Google hat mir leider nicht weitergeholfen 🙁

  8. Eric Kubitz (Beitrag Autor)

    Hallo Cujo,
    wie ich schon geschrieben habe: Das übersteigt meine technische Kompetenz. Da müsstest du dich vielleicht an Markus Ostertag von moviemaze.de wenden, der hatte ja das Panel gemacht. Und der weiß sicher Rat…
    eric

  9. Markus Ostertag

    Hallo zusammen,

    das mit dem JS ist eigentlich schnell erklärt: Durch die Tatsache, dass Du Variablen in JS definieren kannst, die in einem (späteren) Teil des Codes dann auch definiert richtig sein müssen, ist JS also dem Entwickler quasi verpflichtet seriell ab zu arbeiten.
    Wäre das nämlich nicht der Fall hättest Du unvorhersehbare Effekte bei solchen Konstrukten (mal wäre die Variable definiert, mal nicht, mal falsch etc.).
    Am schönsten kann man dieses Verhalten hiermit aufzeigen:
    http://stevesouders.com/cuzillion/?c0=hj1hfff0_1_f&c1=hj1hfff0_1_f&c2=hj1hfff0_1_f&c3=hj1hfff0_1_f&t=1303984330520 (Achtung lädt mehrere Sekunden – mit Absicht!)
    Auch ohne das Wait von einer Sekunde in den JS-Skripten würde man sehen, dass die Dateien hintereinander angefragt werden.

    Hoffe das reicht Dir an Infos, ansonsten kannst Du Dich gerne per EMail bei mir melden.

    Gruß Markus

  10. Pingback: rewiring a house

Kommentare sind geschlossen.