das mit der geschwindigkeit von webseiten, AMP, instant articles, dieser webseite und so, hat mich in den letzten tagen nochmal interessiert. ich habe lange gebraucht, um zu verstehen, was das google page speed tool eigentlich von mir will. ich glaube ich habe es jetzt ein bisschen besser verstanden und ich habe einen weg gefunden, das relativ gut nachvollziehbar zu machen. google chrome bietet mit seinen entwicklertools (chrome menue → weitere Tools → Entwicklertools) einen netzwerk-reiter an, mit dem man einerseits sehen kann was der browser lädt, aber auch wie schnell und wann. und das tool bietet einen drosselungsmodus an, das heisst man kann verschiedene netzwerkgeschwindigkeiten testen. von offline, GPRS, 2G, 3G, 4G, wifi und DSL ist alles dabei. lädt man eine seite mit aktivierter GPRS-drosselung, kann man genau sehen, was der browser beim laden einer seite macht — und in welcher reihenfolge. webseiten-laden in zeitlupe sozusagen.

man sieht relativ gut, dass es einen entscheidenden zeitpunkt gibt, nämlich der, an dem der browser anfängt die seite anzuzeigen (rendering). das ist meist der zeitpunkt den der browser mit DOM content loaded angibt. eine ausnahme ist möglich: falls noch fonts geladen werden, die für das rendering benötigt werden, wartet der browser ca. drei sekunden mit der anzeige der schrift, auch wenn der DOM-inhalt bereits in weniger als 3 sekunden geladen sein sollte. dauert das laden der fonts länger, wird die schrift in einer vorhandenen (system-) schriftart angezeigt und später mit dem nachgeladenen font angezeigt.

nach dem laden des DOM-inhalts und dem redering der seite, werden dann noch weitere resourcen nachgeladen: bilder, javascripte, CSS-dateien, noch mehr schriften, etc. genau das ist der entscheidende zweite punkt: je weniger CSS-dateien und scripte für das rendern der seite geladen werden müssen, umso besser (schneller) lädt die seite. und das ist bereits das erste problem: es galt und gilt als gute praxis, CSS und javascript im kopf des HTML-dokuments unterzubringen. damit geht der browser in der regel aber davon aus, dass sie so wichtig sind, dass sie erst geladen werden müssen, bevor der browser die seite rendert. deshalb sollte man alle CSS-dateien und javascripte die nicht entscheidend wichtig sind, asynchron oder so spät wie möglich laden.

das ist auch der trick von AMP: die konzentration darauf, den ersten teil der seite so schnell wie möglich zu laden, den rest später.

das was später geladen wird, sollte natürlich auch so optimiert wie möglich sein: möglichst komprimiert, möglichst einfach, mit möglichst wenig ladevorgängen. und mit den entwicklertools und der drosselung kann man dann gut beobachten, wo es möglicherweise klemmt oder was beim laden passiert.

über GPRS lädt die startseite von wirres.net komplett in etwas über vier minuten. vier minuten um eine seite zu laden ist natürlich irre und eigentlich unakzepttabel. aber immerhin zeigt sich die seite bereits nach knapp 10 sekunden, wenn auch ohne bilder und ohne die brevia schrift.

ich wollte natürlich wissen, wie meine seite so im vergleich zu meinen lieblingswebseiten steht und habe die auch mal gemessen. einmal im chrome normal geladen, dann auf GPRS gedrosselt und dann nochmal normal. das sind die ergebnisse:

site	dom (s)	load (s)	finish (s)	grösse (mb)
wirres.net GPRS	9,82	252,00	252,00	1,50
wirres.net DSL	1,33	3,09	3,51	1,50
daringfireball.net GPRS	10,18	22,34	24,90	0,13
daringfireball.net DSL	1,80	3,53	3,95	0,13
m.spiegel.de GPRS	25,88	114,00	114,00	0,65
m.spiegel.de DSL	1,10	1,41	1,32	0,65
knuspermagier.de GPRS	15,68	378,00	378,00	2,30
knuspermagier.de DSL	1,02	1,85	1,85	2,90
nerdcore.de GPRS	17,18	+600,00	+600,00	4,00
nerdcore.de DSL	2,58	10,25	10,26	6,80
uebermedien.de GPRS	42,91	+702,00	+702,00	4,20
uebermedien.de DSL	2,54	3,95	5,27	5,20
anmutunddemut.de GPRS	21,50	+600,00	+600,00	3,90
anmutunddemut.de DSL	2,10	4,28	4,39	3,70
olereissmann.de GPRS	20,63	228,00	228,00	1,40
olereissmann.de DSL	1,41	2,21	2,56	1,40

 
daringfireball ist die kleinste seite (in kilobyte) und lädt deshalb auch am schnellsten unter GPRS. erstaunlich schlecht unoptimiert ist die ladezeit des DOMS. bei daring fireball stecken die scripte und stile offenbar noch alle im kopf. das ist in diesem fall OK, weil die seite einerseits so klein ist und andererseits der server von daringfireball immer sehr, sehr schnell antwortet.

der spiegel hat seine mobiel seite kilobyte-mässig auch sehr gut optimiert, aber das DOM zu laden dauert unnötig lange.

die startseiten von nerdcore und uebermedien sind jeweils über 5 megabyte gross. damit laden sie ewig. ich habe das jeweils nach ungefähr 10 minuten abgebrochen. viel optimierungsspielraum besteht beim laden des DOM bei uebermedien. das ist noch schlechter als bei spiegel-online.

was mich wundert ist die performance von anmut und demut. die seite sieht eigentlich sehr schlank und minimalistisch aus, aber das DOM lädt nicht in guter geschwindigkeit und die bilder scheinen extrem unoptimiert zu sein. ole reissmann’s blog lädt mit schneller netzverbindung vorbildlich, lediglich mit langsamer netzwerkverbindung klemmt es ein bisschen.

das gilt eigentlich für alle webseiten: fast alle laden unter normalen bedingungen komplett in unter drei sekunden, der rest ist spätestens nach 5 sekdunen komplett da. nerdcore lädt zwar 10 sekudnen lang, fühlt sich aber nicht so an.

* * *

ich weiss dass der test alles andere als professionell und genau ist. um zuverlässige werte zu bekommen, müsste man ganze testreihen durchführen und die werte mitteln. das ist mir aber zu aufwändig. wie schrottig unterschiedlich die werte ausfallen, sieht man auch an den screenshots oben. einmal lädt das DOM von wirres.net mit GPRS unter 10 sekunden, auf dem zweiten screenshot hats 14 sekunden gedauert.

weitere verzerrungen der messergebnisse können durch das aktivierte ghostery kommen. ghostery blockiert ein paar werbescripte und tracker, das heisst ohne ghostery könnten manche der seiten oben in der tabelle schlechter abschneiden.