Hallo Facebook-Like-Button, good bye kurze Ladezeiten
[An dieser Stelle würden Sie einen Facebook-„Gefällt mir“-Button sehen – wenn Deutschland nicht das Land der ausufernden Datenschutz-Paranioia wäre.]
Probieren geht über Studieren. Ab jetzt prangt auf (fast) jeder Seite von michael-van-laar.de der neue Facebook-Like-Button. Ob es sich lohnen wird? Ich bin gespannt. Immerhin ruinieren ich mir mit diesem kleinen Stück Code meine bisher gut optimierten Ladezeiten.
Der Einfachheit halber habe ich mich für die iframe-Variante entschieden. Besonders viele Konfigurationsmöglichkeiten hat man auf der Facebook-Plugin-Seite nicht gerade. Und ganz ehrlich: Hübsch sieht auch irgendwie anders aus. Aber was soll’s. Orange Box drumherum und ab damit in die Seitenspalte. Wenn jetzt bitte alle Blogbesucher überall kräftig auf die kleinen blauen Buttons klicken würden … ;-) Danke sehr!
Immer langsam mit den jungen Buttons
Das erste, was mir zum neuen Facebook-Button in den Sinn kam, war die Frage, wie sich dieser Fremdkörper auf die Website-Ladezeit auswirkt. Der direkte Vergleich mithilfe des Dienstes WebPagetest offenbart das Ausmaß der Ausbremsung.
Vor dem Einbau des Buttons schlug die Blog-Startseite im für den Test verwendeten IE7 (klingt komisch, is’ aber bei WebPagetest so) mit 57 KB und 12 HTTP-Requests zu Buche. Mit der 1,5-MBit-Testleitung ergab dies eine Ladezeit von 2,8 Sekunden. Passt!
Nach dem Einbau des iframe-Codes für den Like-Button bringt die Seite 141 KB auf die virtuelle Waage. Das ist das Zweieinhalbfache der ursprünglichen Datenmenge. Mit nun 26 HTTP-Requests hat sich deren Anzahl mehr als verdoppelt. Zum Glück ist die Ladezeit nicht im gleichen Maß in die Höhe geschossen. Um 30 Prozent erhöht sich die Ladezeit laut den Testergebnissen. Das ergibt 3,7 Sekunden.
Doch er bemüht sich redlich, …
… der kleine Like-Button. Was man beim Vergleich der beiden Testergebnisse klar sieht, ist neben der Erhöhung der Gesamtdatenmenge die deutliche Erhöhung der Element-Anzahl. Das ist natürlich zunächst einmal nicht so schön. Denn gerade durch viele Serveranfragen kann man sich die Ladezeit-Bilanz schnell verhageln.
Positiv fällt in der Detailanalyse jedoch auf, dass Facebook allles versucht, um die neu hinzugekommen Elemente optimal auszuliefern. Gzip, ordentliche Expires Headers, minifiziertes JavaScript sowie Cookie- und auch ETag-Losigkeit lassen kaum Wünsche offen.
Fazit
Kurze Ladezeiten sind wichtig für eine gute Usability und gute Suchmaschinen-Rankings, auch wenn noch niemand so genau weiß, wie viel Gewicht Google diesem Kriterium denn nun tatsächlich beimisst. So gesehen ist der neue Facebook-Like-Button genau so „schädlich“ wie andere externe JavaScript- und iframe-Einbindungsspielereien. Doch wenn die einfachere Facebook-Vernetzung tatsächlich etwas bringt, ist der Like-Button aufgrund der Ladezeitminimierungsbemühungen von Facebook gerade noch akzeptierbar. Ein paar JavaScript-Dateien weniger wären jedoch wünschenswert.
Update
Zum Vergleich habe ich nun auch die XFBML-Version des Facebook-Like-Buttons getestet. Hierfür muss man zunächst eine Application ID für die eigene Website anlegen. Danach muss das JavaScript SDK eingebunden werden. Wer möchte, kann dabei den von Facebook bereitgestellten Javascript-Schnipsel vorher noch einmal durch einen Minifizierer jagen. Schließlich baut man an der Stelle, an der der Like-Button angezeit werden soll, den <fb:like>-Code ein.
Ergebnis: Eine deutlich geringere Gesamtdatenmente (89 KB) sowie deutlich weniger HTTP-Requests (16 Stück) sowie eine etwas geringere Ladezeit (3,6 Sekunden). Das sagen zumindest die WebPagetest-Ergebnisse. YSlow hingegen gibt 138 KB und 26 HTTP-Requests an. Gefühlt im eigenen Browser geht das Laden des XFBML-Like-Buttons auf jeden Fall wesentlich zügiger voran als bei der iframe-Version.
