WordPress & Webwork

Die großen Performance-Bremsen im Frontend 1

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 viel

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:

100 KByte für ein paar Buttons

100 KByte für eine handvoll Buttons

Diese Testseite besteht lediglich aus ein paar Buttons: Flattr, Topsy, FeedBurner und Facebook … sonst nichts, ehrlich. Und hier sehe ich ein großes Potential, wenn es darum geht die Performance einer Website zu optimieren.

Klar, am besten wäre es auf all die Buttons zu verzichten, aber das ist ein bisschen unrealistisch, denn an Twitter, Facebook (leider!) & Co. kommt man heute als Webmaster, der die Reichweite seiner Website erhöhen möchte, nicht mehr vorbei.

Daher sollte man sich aber um so mehr überlegen, ob man alle Buttons einbindet, die bei drei nicht auf'm Baum sind oder reichen zum Beispiel Twitter und Google Buzz. Und wenn man die Buttons einbindet, dann sollte man auch schauen ob es nicht effektivere bzw. performantere Alternativen gibt um die Funktionalität der sog. "sozialen Dienste" einzubinden.

So ist zum Beispiel möglich, dass man bei Flattr anstatt einen dynamischen einfach einen statischen Button einbindet. Oder anstatt des Flattr-Plugins kann man auf das Alternativ-Script von Frank Bültge zurückgreifen. Vor einigen Wochen habe ich im Artikel Anzahl der Feed-Leser und Twitter-Folower ausgeben beschrieben wie man die Anzahl der Feed-Leser ausgeben kann, ohne auf den dynamischen Feedbutton von FeedBurner zurückzugreifen, der vergleichsweise viel Performance schluckt.

16 Reaktion(en)

  1. Jens

    sehr guter Hinweis, ich selber verfolge die Strategie schon selber auf meinem Projekten so wenig wie möglich interaktve Buttons einzubinden. Da JS ja nun doch immer meistens die größte Kapazität einnimmt und benötigt.

    Da sollte auch noch was in den nächsten Jahre geschehen.

    LG Jens

  2. Peter

    Warum verzichten wenn man schummeln kann? Bei Facebook-Buttons einfach auf die Option show_faces verzichten, das bringt schon einiges. Andere solcher Widgets (und z.B. auch Gravatare) haben recht unbrauchbare Cache-Headers, die man beeinflussen kann, wenn man die entsprechenden Resourcen durch einen Rewrite-Proxy tunnelt.

    Jedes bisschen hilft!

    1. Perun

      Hallo Peter,

      klar kann man da einiges rausholen, aber

      Bei Facebook-Buttons einfach auf die Option show_faces verzichten

      genau solche Funktionen, sind es die die Besucher zum anklicken animieren. Das habe ich bei dem Flattr- und Topsy-Button bemerkt. Die statischen Varianten werden nicht so oft angeklickt und ich wette mit dir, dass der FB-Button mit den Gesichtern eher angeklickt wird als der ohne.

  3. Peter

    Das ist wohl wahr, aber trotzdem ist der Performance mit dieser Option so dermaßen viel übler, dass man darauf einfach verzichten muss um sich nicht völlig in den Fuß zu schießen. Wenn die Seite so lahm ist, dass sie den User nervt, wird er auch nichts liken/flattrn/whatevern. Jedenfalls ist das nach intensiven Feldversuchen mein Ergebnis gewesen :)

  4. 40_Fieber

    Hallo,

    ich habe, ehrlich gesagt, nicht das Gefühl, daß die Buttons unbedingt in den Blog müssen. Wer twittert hat sowieso den passenden Button in seinem Browser. Unser Blog twittert und facebookt herum, ohne daß ich Buttons hätte. Also für diese zwei Seiten muß man wirklich keine Reklame machen. Die finden die Leute von ganz alleine.

  5. Matthias

    Ich habe die ganzen Buttons auch wieder entfernt, nachdem die Diskussionen um die Ladezeit zugenommen haben und Google es sogar in die Webmastertools aufgenommen hat. Persönlich verstehe ich die kb und Sekunden-Gerangelei zwar nicht so ganz, weil jeder User mit DSL 6.000 aufwärts sollte die 2 oder 3 Buttons mehr oder weniger doch kaum bemerken?

  6. Pingback: Dobschat » Links vom 20. Juni 2010 bis 22. Juni 2010

  7. Haf

    Ich hab vorhin gerade die meisten Buttons aus meinem Blog gekickt, da sie sowieso praktisch nicht genutzt wurden nach meinem Kenntnisstand.
    Ich experimentiere gerade ein wenig an der Performance herum und habe nach einem YSlow-Test festgestellt, dass auf der Startseite ungecached mal locker 280kb in 38 HTTP Requests ablaufen. Jetzt lese ich gerade nach, wie ich CSS Sprites einsetzen kann. :)

  8. Haf

    Danke für die Links, aber ich lese hier regelmäßig mit, die Artikel habe ich schon größtenteils umgesetzt – vorher sah es bei mir noch schlimmer aus. ;)

    Im Frontend sehe ich derzeit v.a. noch die CSS Sprites als Optimierungsmöglichkeit, um die Anzahl der Server-Anfragen zu reduzieren. Zuletzt waren es jetzt 28, 10-15 Stück bekomme ich durch ein gemeinsames Bild für die Hintergrundgrafiken sicher noch raus. Ich bin nur nicht so fit in Sachen CSS, da muss ich erstmal schauen, wie genau ich das CSS-Sprite eigentlich einfügen kann, erzeugt habe ich es mit einem Tool schon, und für die einzelnen Elemente auch einfache CSS Definitionen, die muss ich aber noch in mein richtiges Style Sheet integrieren. Naja, wird kein Hexenwerk sein.

  9. Pingback: Rückblick auf das WordCamp 2010 in Berlin - Weblog - Michael Jendryschik

  10. Pingback: Das WordCamp 2010 in Berlin – ein Rückblick » sebastian-gerth.com

  11. Pingback: Die großen Performance-Bremsen im Frontend 2 | perun.net

  12. Pingback: Rückblick: WordCamp 2010 | Webseiten-Infos.de

  13. Pingback: WordPress: Plugins die ich einsetze | WordPress & Webwork

Die Kommentare in diesem Beitrag sind geschlossen.