web­sei­ten mit GPRS-ge­schwin­dig­keit la­den

das mit der ge­schwin­dig­keit von web­sei­ten, AMP, in­stant ar­tic­les, die­ser web­sei­te und so, hat mich in den letz­ten ta­gen noch­mal in­ter­es­siert. ich habe lan­ge ge­braucht, um zu ver­ste­hen, was das goog­le page speed tool ei­gent­lich von mir will. ich glau­be ich habe es jetzt ein biss­chen bes­ser ver­stan­den und ich habe ei­nen weg ge­fun­den, das re­la­tiv gut nach­voll­zieh­bar zu ma­chen. goog­le chro­me bie­tet mit sei­nen ent­wick­ler­tools (chro­me me­nue → wei­te­re Tools → Ent­wick­ler­tools) ei­nen netz­werk-rei­ter an, mit dem man ei­ner­seits se­hen kann was der brow­ser lädt, aber auch wie schnell und wann. und das tool bie­tet ei­nen dros­se­lungs­mo­dus an, das heisst man kann ver­schie­de­ne netz­werk­ge­schwin­dig­kei­ten tes­ten. von off­line, GPRS, 2G, 3G, 4G, wifi und DSL ist al­les da­bei. lädt man eine sei­te mit ak­ti­vier­ter GPRS-dros­se­lung, kann man ge­nau se­hen, was der brow­ser beim la­den ei­ner sei­te macht — und in wel­cher rei­hen­fol­ge. web­sei­ten-la­den in zeit­lu­pe so­zu­sa­gen.

man sieht re­la­tiv gut, dass es ei­nen ent­schei­den­den zeit­punkt gibt, näm­lich der, an dem der brow­ser an­fängt die sei­te an­zu­zei­gen (ren­de­ring). das ist meist der zeit­punkt den der brow­ser mit DOM con­tent loa­ded an­gibt. eine aus­nah­me ist mög­lich: falls noch fonts ge­la­den wer­den, die für das ren­de­ring be­nö­tigt wer­den, war­tet der brow­ser ca. drei se­kun­den mit der an­zei­ge der schrift, auch wenn der DOM-in­halt be­reits in we­ni­ger als 3 se­kun­den ge­la­den sein soll­te. dau­ert das la­den der fonts län­ger, wird die schrift in ei­ner vor­han­de­nen (sys­tem-) schrift­art an­ge­zeigt und spä­ter mit dem nach­ge­la­de­nen font an­ge­zeigt.

nach dem la­den des DOM-in­halts und dem re­de­ring der sei­te, wer­den dann noch wei­te­re re­sour­cen nach­ge­la­den: bil­der, ja­va­scrip­te, CSS-da­tei­en, noch mehr schrif­ten, etc. ge­nau das ist der ent­schei­den­de zwei­te punkt: je we­ni­ger CSS-da­tei­en und scrip­te für das ren­dern der sei­te ge­la­den wer­den müs­sen, umso bes­ser (schnel­ler) lädt die sei­te. und das ist be­reits das ers­te pro­blem: es galt und gilt als gute pra­xis, CSS und ja­va­script im kopf des HTML-do­ku­ments un­ter­zu­brin­gen. da­mit geht der brow­ser in der re­gel aber da­von aus, dass sie so wich­tig sind, dass sie erst ge­la­den wer­den müs­sen, be­vor der brow­ser die sei­te ren­dert. des­halb soll­te man alle CSS-da­tei­en und ja­va­scrip­te die nicht ent­schei­dend wich­tig sind, asyn­chron oder so spät wie mög­lich la­den.

das ist auch der trick von AMP: die kon­zen­tra­ti­on dar­auf, den ers­ten teil der sei­te so schnell wie mög­lich zu la­den, den rest spä­ter.

das was spä­ter ge­la­den wird, soll­te na­tür­lich auch so op­ti­miert wie mög­lich sein: mög­lichst kom­pri­miert, mög­lichst ein­fach, mit mög­lichst we­nig la­de­vor­gän­gen. und mit den ent­wick­ler­tools und der dros­se­lung kann man dann gut be­ob­ach­ten, wo es mög­li­cher­wei­se klemmt oder was beim la­den pas­siert.

über GPRS lädt die start­sei­te von wir­res.net kom­plett in et­was über vier mi­nu­ten. vier mi­nu­ten um eine sei­te zu la­den ist na­tür­lich irre und ei­gent­lich un­ak­zept­ta­bel. aber im­mer­hin zeigt sich die sei­te be­reits nach knapp 10 se­kun­den, wenn auch ohne bil­der und ohne die bre­via schrift.

ich woll­te na­tür­lich wis­sen, wie mei­ne sei­te so im ver­gleich zu mei­nen lieb­lings­web­sei­ten steht und habe die auch mal ge­mes­sen. ein­mal im chro­me nor­mal ge­la­den, dann auf GPRS ge­dros­selt und dann noch­mal nor­mal. das sind die er­geb­nis­se:

 
dar­ing­fi­re­ball ist die kleins­te sei­te (in ki­lo­byte) und lädt des­halb auch am schnells­ten un­ter GPRS. er­staun­lich schlecht un­op­ti­miert ist die la­de­zeit des DOMS. bei dar­ing fire­ball ste­cken die scrip­te und sti­le of­fen­bar noch alle im kopf. das ist in die­sem fall OK, weil die sei­te ei­ner­seits so klein ist und an­de­rer­seits der ser­ver von dar­ing­fi­re­ball im­mer sehr, sehr schnell ant­wor­tet.

der spie­gel hat sei­ne mo­biel sei­te ki­lo­byte-mäs­sig auch sehr gut op­ti­miert, aber das DOM zu la­den dau­ert un­nö­tig lan­ge.

die start­sei­ten von nerd­core und ueber­me­di­en sind je­weils über 5 me­ga­byte gross. da­mit la­den sie ewig. ich habe das je­weils nach un­ge­fähr 10 mi­nu­ten ab­ge­bro­chen. viel op­ti­mie­rungs­spiel­raum be­steht beim la­den des DOM bei ueber­me­di­en. das ist noch schlech­ter als bei spie­gel-on­line.

was mich wun­dert ist die per­for­mance von an­mut und de­mut. die sei­te sieht ei­gent­lich sehr schlank und mi­ni­ma­lis­tisch aus, aber das DOM lädt nicht in gu­ter ge­schwin­dig­keit und die bil­der schei­nen ex­trem un­op­ti­miert zu sein. ole reiss­mann’s blog lädt mit schnel­ler netz­ver­bin­dung vor­bild­lich, le­dig­lich mit lang­sa­mer netz­werk­ver­bin­dung klemmt es ein biss­chen.

das gilt ei­gent­lich für alle web­sei­ten: fast alle la­den un­ter nor­ma­len be­din­gun­gen kom­plett in un­ter drei se­kun­den, der rest ist spä­tes­tens nach 5 sekd­unen kom­plett da. nerd­core lädt zwar 10 se­kud­nen lang, fühlt sich aber nicht so an.

---

ich weiss dass der test al­les an­de­re als pro­fes­sio­nell und ge­nau ist. um zu­ver­läs­si­ge wer­te zu be­kom­men, müss­te man gan­ze test­rei­hen durch­füh­ren und die wer­te mit­teln. das ist mir aber zu auf­wän­dig. wie schrot­tig un­ter­schied­lich die wer­te aus­fal­len, sieht man auch an den screen­shots oben. ein­mal lädt das DOM von wir­res.net mit GPRS un­ter 10 se­kun­den, auf dem zwei­ten screen­shot hats 14 se­kun­den ge­dau­ert.

wei­te­re ver­zer­run­gen der mess­ergeb­nis­se kön­nen durch das ak­ti­vier­te ghos­tery kom­men. ghos­tery blo­ckiert ein paar wer­be­scrip­te und tra­cker, das heisst ohne ghos­tery könn­ten man­che der sei­ten oben in der ta­bel­le schlech­ter ab­schnei­den.