WordPress & Webwork - perun.net

Ich habe Mitte Dezember beschrieben, wie ich die dynamischen Social-Buttons von Facebook, Twitter und Google+ durch statische ersetzt habe. Im ersten Artikel habe ich beschrieben wieso ich das mache und ich habe auch ein paar Performance-Statistiken geliefert. Im zweiten Artikel habe ich dann konkret beschrieben, wie ich die Buttons umgesetzt habe.

Nun habe ich einen Blick in die Webmaster Tools von Google reingeworfen und folgende Grafik gesehen:

Wie man sieht geht der Peak steil herunter nach dem Ausbau der dynamischen Buttons. Und auch wenn man diesen hohen Peak ignoriert, erkennt man an den von mir gezeichneten Hilfslinien, dass es auch vorher langsamer war und dies führe ich auf die dynamischen Buttons zurück, da ich nach dem Ausbau der dynamischen Buttons keine weiteren Optimierungsmaßnahmen durchgeführt habe und unsere Websites, so weit ich informiert bin, immer noch auf dem gleichen Server gehostet werden.

Aktuell zeigt Google einen durchschnittlichen Wert von 2,1 Sekunden (Zitat Google: schneller als 66 % der Websites), der Peak erreichte einen Maximum von 12,5 Sekunden und vor dem Peak lag der Durchschnitt bei ca. 4,5 Sekunden.

Ich will hier keinem die dynamischen Buttons madig machen, aber man soll ich schon bewusst sein, dass man mit denen u. U. seine Website stark verlangsamt. Hier muss man dann abwägen, was einem wichtiger ist.

Auf dev4press.com gibt es eine sehr interessante Messung verschiedener WordPress-Versionen. Der Autor hat die Datenbank mit 50 Artikeln, 5 Seiten, 5 Kategorien, 20 Tags und 5 Autoren-Accounts gefüttert und WordPress 3.0.6, 3.1.4, 3.2.1 und 3.3 gegeneinander antreten lassen.

Herausgekommen ist ein interessantes Ergebnis. Auch wenn WordPress 3.3 gegenüber 3.0.x und 3.1.x in vielen Bereichen im Vorteil ist, so hat er gegenüber 3.2.1 in der Performance ein gutes Stück eingebüßt. Das Ergebnis des Test deckt sich mit meinen wenigen Beobachtungen. Das backend verbraucht gegenüber 3.2.1 so 5-6% mehr als vorher und die Anzahl der der Datenbankfragen ist deutlich gestiegen.

Ich hoffe, dass sich die Entwickler wieder der Optimierung widmen, schließlich hat deren Arbeit in diesem Bereich in der Version 3.2.1 auch recht gute Ergebnisse geliefert.

Ich habe vor einigen Tagen darüber berichtet, dass sich mittlerweile die obersten Datenschützer der Bundesländer darauf geeinigt haben, dass das Einbinden von den social Plugins von Facebook, Google und Twitter unzulässig sei.

Auch die 2-Klick-Lösungen und Aufklärungsboxen helfen nicht, da die Webmaster in aller Regel nicht wissen was, wie und wann übertragen wird. Die Datenschützer sehen hier auf jeden Fall die Betreiber der Websites in Verantwortung.

Aus diesem Grund hat sich ZDNet entschieden die "dynamischen Buttons" zu entfernen und diese durch die statischen Buttons zu ersetzen. (weiterlesen…)

Mit Google Analytics kann man auch die Ladezeiten der einzelnen Unterseiten messen. Dafür muss man den Code-Fragment um folgende Zeile ergänzen:

_gaq.push(['_trackPageLoadTime']);

Im "Komplettpaket" schaut es dann folgendermaßen aus:

<script type="text/javascript">
    var _gaq = _gaq || [];
    _gaq.push(['_setAccount', 'UA-deine-id']);
    _gaq.push(['_gat._anonymizeIp']);
    _gaq.push(['_trackPageview']);
    _gaq.push(['_trackPageLoadTime']);
    (function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
    })();
</script>

In der vierten Zeile ist dir evtl. _gaq.push(['_gat._anonymizeIp']); aufgefallen, damit anonymisiert man die übertragenen IPs und das ist eine der Voraussetzungen um Google Analytics in Deutschland zu betreiben … aber das nur am Rande, siehe auch Google Analytics: IP-Übertragung anonymisieren. (weiterlesen…)

Mit Page Speed Online bietet Google ein webbasiertes Tool um Optimierungsmöglichkeiten für eine Website zu bekommen. Einfach die URL der zu prüfenden Website eingeben und anschließend bekommt man die Anzahl der Punkte. Hier sind es 87 von 100.

Auf der linken Seite bekommt man dann Optimierungstipps, die nach drei Stufen sortiert sind: (weiterlesen…)

Ich erzähle schon seit längerer Zeit, dass die beste Performance-Optimierung einer Website darin besteht gewisse Elemente erst gar nicht erst einzubauen. Das ist viel effektiver, als hinterher zu versuchen das eingebaute Element mit diversen Maßnahmen zu optimieren.

Aber ganz einfach ist das natürlich nicht. Komplett auf die Einbindung von sozialen Netzwerken zu verzichten ist auch keine Alternative. Man muss hier das Kosten-Nutzen-Verhältnis analysieren. Hier ein Beispiel.

Ich habe im November 2010 hier auf perun.net die Like-Box von Facebook in die Sidebar eingebaut um auf den Facebook-Account von der perun.net webwork gmbh zu verweisen. (weiterlesen…)

Zum Thema Performance-Optimierung von Websites habe ich hier auf perun.net schon einige Artikel verfasst. Dabei habe ich auch Tools wie z. B. YSlow erwähnt, die einem hilfreich zu Seite stehen.

Ein sehr wichtiges (und imho auch wenig beachtetes) Tool mit dem Namen "Netzwerk" befindet sich mittlerweile in allen modernen Browsern. Bei Mozilla Firefox muss man es mit Firebug nachrüsten, aber bei Opera, Google Chrome und Internet Explorer gehört es zum Lieferumfang der Entwicklerwerkzeuge. Somit hätte ich schon den ersten Vorteil dieser Funktion genannt.

Wenn man sich begibt die Performance einer Website zu verbessern, dann gehört, wenn nicht der erste, dann zumindest der zweite oder dritte Blick in die Netzwerk-Funktion.

Vor allem hier sieht man sehr detailliert und genau welche Komponente(n) den Aufbau einer Website ausbremsen. Somit ergänzt sich diese Information sehr gut mit den Infos, die man zum Beispiel durch YSlow oder Page Speed gewinnt und man kann sich so ein viel besseres Bild machen und dadurch einfacher entscheiden ob und welche Maßnahmen unternommen werden sollen.

Übrigens: wenn man die Cache-Plugins für WordPress testet, dann sollte man sich aus der jeweiligen Installationen auch ausloggen. Zumindest bei Hyper Cache werden die Seiten für Admin nicht aus dem Cache gezogen.