aus dem maschinenraum

felix schwenzel, , in über wirres    

ich habe wirres.net ein bisschen schneller genmacht, zumindest laut dem google page speed tool. das scheint jetzt, nach einigen umstellen, einstellen und priorisieren, einigermassen zufrieden mit der leistung meiner seiten zu sein und zeigt die ladegeschwindigkeit meist im grünen bereich an.

die anforderungen des page speed tools zu verstehen, oder genauer, die anforderungen für schnelles seitenladen zu verstehen, ist gar nicht mal so leicht. vieles von dem was google vorschlägt hört sich für meine ohren spanisch an.

JavaScript- und CSS-Ressourcen, die das Rendering blockieren, in Inhalten „above the fold“ (ohne Scrollen sichtbar) beseitigen

woher soll ich wissen, was above the fold ist, oder welche resourcen das rendering blockieren? mit versuch und irrtum habe ich mich dem aber langsam annäheren können. entscheidend ist jedenfalls, neben den grundvoraussetzungen wie einer relativ schnellen seitenauslieferung (zum beispiel durch vorhalten fertig gerenderter seiten) und möglichst (klein) optimierter resourcen (bilder), das enthaltenen CSS- und javascript-gedöns möglichst asynchron (also irgendwann) zu laden, nachdem der hauptseiteninhalt bereits da ist.

ansatzweise hatte ich das schon vor längerer zeit gemacht, so lade ich die zahl der likes und reaktionen und die reaktionen selbst schon länger asynchron (per ajax) nach. aber noch wichtiger scheint es, möglichst viele javascripte (jquery selbst, jquery plugins und den javascript-code selbst) und stylesheets ebenfalls asynchron zu laden — eben damit sie das rendern der seite nicht blockieren.

theoretisch geht das bei javascript ganz einfach, indem man sie mit der option async lädt. dann muss man aber darauf achten, dass die ladereihenfolge passt und nicht irgendein script versucht jquery zu benutzen, obwohl das noch gar nicht geladen ist. irgendwann hatte ich das aber rausgefunden, und jetzt lädt das ganze javascriptgedöns erst dann, wenn der browser es für nötig hält.

was ich seit vielen jahren für wichtig halte und was jetzt wieder sehr befriedigend läuft, ist wirres.net ohne aktiviertes javascript. alle grundsätzlichen funktionen, funktionieren auch ohne javascript. alles was per javascript nachgeladen wird, wie reaktionen oder kommentargedöns, funktioniert dann nicht, aber seitdem ich mich letzte woche von typekit verabschiedet habe und die brevia-schrift bei fontshop (werbelink) lizensiert habe, wird die brevia auch ohne aktiviertes javascript angezeigt. durch das schriftladen per CSS, sehen jetzt auch meine AMP-seiten mehr nach dem original aus (diese seite als AMP laden).

apropos CSS; komplizierter das google page speed tool zu befriedigen, wird es in sachen CSS. auch hier schlägt google vor möglichst viele resourcen asynchron oder zumindest später zu laden. leider gibt es aber keine möglichkeit einem <link rel="stylesheet"> einfach ein async-attribut hinzuzufügen. den CSS-code aufzuteilen und nur das wichtigste in den seitenkopf zu packen und das weniger wichtige ans seitenende zu packen, ist schonmal ein schritt nach vorne, lässt google aber immer noch meckern. es gibt aber einen offiziellen neuen weg, das über <link rel="preload"> zu machen. weil das noch nicht von allen browsern unterstützt wird, hat die filamentgroup mal wieder einen polyfill gebaut: „loadCSS, A function for loading CSS asynchronously

der einbau dieser lösung hat mich am ende dann im google page speed tool in den grünen bereich gebracht.

* * *

die seitenladegeschwindigkeit auf wirres.net fühlt sich jetzt tatsächlich etwas schneller an, ein direkter vergleich mit einer AMP-seite zeigt, das die werte der regulären seiten ganz OK sind. AMP lädt diese seite in knapp einer sekunde (load), bzw. den DOM-content in 293 millisekunden. regulär lädt die seite in 1,29 sekunden (load), bzw. den DOM-content in 594 millisekunden. ich finde das sollte in sachen optimierung erstmal reichen.