WordPress & Webwork - perun.net

Ich habe vor einigen Tagen die Serie Die großen Performance-Bremsen im Frontend gestartet. Im ersten Teil ging es um die Einbindung diverser externer Dienste und wie diese eine Website aufblähen können. In diesem Artikel widme ich mich den Bildern oder besser gesagt was man den Einsatz von Bildern falsch machen kann und wo Einsparungspotentiale stecken. (weiterlesen…)

Ich werde am kommenden WordCamp am 03. Juli 2010 in Berlin einen kleinen Vortrag (aka Session) zum Thema Performance-Optimierung von (WordPress)-Websites halten. In der dazugehörigen Gruppe wurde die Frage nach den größten Performance-Bremsen gestellt.

Daher dachte ich mir, es könnte nicht schaden wenn ich die großen Performance-Diebe auch hier mal näher vorstelle. Schaue dir mal bitte folgende Abbildung an:

100 KByte ist nicht wirklich viel

Man könnte jetzt sagen: "OK, eine vergleichsweise schlanke Website". Willst du aber genau wissen, welchen Inhalt diese Seite beinhaltet? Dann schaue dir die nächste Abbildung an: (weiterlesen…)

Ich habe heute den Beitrag WordPress: Performance-Problem der besonderen Art verfasst und das Performance-Problem auf dieser Seite beschrieben. Nach mehreren Stunden zusätzlicher Testreihen und vielen konstruktiven Kommentaren: vielen, herzlichen Dank an alle sind wir mittlerweile alle schlauer:

1. Ich und meine Optimierungsmaßnahmen sind nicht das Problem
2. Auch die besten Optimierungsmaßnahmen helfen kaum, wenn das Problem hardwareseitig ist
3. Das Problem liegt doch an irgendeiner Hardware-Komponente von all-inkl

Ich ärgere mich ein bisschen, dass ich nicht selber wie ocean90 und Schepp auf die Idee kam via IP-Reverse (z. B. ServerDNA auch die Websites, der anderen Kunden des gleichen Accounts zu testen. Und siehe da, so bald es mehr als eine handvoll Bilder pro Seite gibt, gibt es auch ähnliche oder gleiche Ausreißer wie bei mir.

Ich bin gespannt, was all-inkl auf die fachmännische E-Mail von Schepp sagt.

Nachtrag: noch einmal, vielen Dank an Schepp. All-inkl hat das Problem behoben, wegen einer DoS-Attacke wurden die Verbindungen pro Sekunde limitiert und man hat diese nicht aufgehoben.

Leute ich habe in den letzten Tagen hier ein Performance-Problem, da würde man am liebsten in die Tischplatte beißen. Das Problem existiert erst seit ein paar Tagen. Uns selber und einigen aufmerksamen Lesern ist aufgefallen, dass unsere Websites langsamer geworden sind.

Trotz guter Werte schlechte Performance

Ich habe daher in den letzten Tagen viele Testreihen und einige Optimierungsmaßnahmen durchgeführt. In vielen Punkten bin ich schlauer, aber das Performance-Problem konnte ich leider nicht vollständig lösen. (weiterlesen…)

So wie es ausschaut sind die Conditional Comments (CC) schlecht für die Performance einer Website. Im Artikel Conditional comments block downloads beschreibt der Autor, wie die Conditional Comments den parallelen Download weiterer Komponenten blocken.

Das heißt, der Browser wartet und tut so lange nichts, bis der Teil, der im CC referenziert bzw. eingebaut ist, abgearbeitet wird … so ähnlich wie bei einem Javascript. Das ist auch der Grund warum man die Javascripte nach Möglichkeit im Fußbereich der Website einbinden soll.

Die Lösung des Problems: man verzichtet auf die CC zu Gunsten von CSS-Hacks oder man baut vor den anderen CC einen leeren CC ein.

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. (weiterlesen…)

In drei Artikeln vorher (hier, hier und hier) habe ich einiges beschrieben, wie man WordPress-Website beschleunigen kann. Das allermeiste ist logischerweise auch für andere Website gültig. Hier so ein kleines Vorher-Nachher-Bild. (weiterlesen…)