Obsidian.dk – Langsom hjemmeside som andre allerede havde optimeret på.
Obsidian kontaktede mig i maj 2017 for at høre om der var noget jeg kunne gøre for at optimere hastigheden på deres wordpress hjemmeside obsidian.dk. Jeg sagde selvfølgelig er der noget jeg kan gøre. De troede ikke rigtig på mig da de forinden havde fået at vide af flere, at hastigheden ikke kunne blive bedre end den var. Jeg testede hjemmesiden og sagde, ja jeg kan da godt se at der er blevet gjort noget, og at hjemmesiden faktisk er fint hurtig, men at det ikke er det samme som at der ikke kan blive gjort mere.
Jeg sagde også at jeg med 100% sikkerhed vil kunne forbedre hastigheden og at det med høj sandsynlighed vil kunne blive forbedret med ca 50%.
Hvordan kan jeg være så sikker?
Jo det er egentlig lidt enkelt, hvis man ser på hastighedsmålingerne, så er førbilledet faktisk ikke så dårligt, de score rent faktisk grøn både på mobil og computer via Google Pagespeed insights, og de har en RUM speed Index på 567. Men det der slår ud i mine øjne, er at fully loaded time er på 3.5 sekunder, ikke at det er langsomt, for det kan være så meget, også at der er ting der loader i baggrunden da GT Metrix også tester hvad der sker på hjemmesiden efter Onload. Men der er samtidig en Onload hastighed på 3.3 sekunder. Og i samme øjemed er der ca 1.4 sekunders forskel på DOM int og DOM loaded – Ja jeg ved godt det kan blive lidt nørdet, men prøver at holde det simpelt.
Kort fortalt, betyder den høje onload og den store forskel på de to DOM målinger, at der er noget der blokerer for at Onload og DOM Loaded kan blive hurtigt færdige.
Hvorfor var deres wordpress hjemmeside langsom?
Jo, de havde en langsom hjemmeside fordi mange scripts blandt andet var blokerende, og dette var de på trods af at mange var flyttet under folden, hvilket jo er positivt. Og det er der flere grunde til. Det kræver selvfølgelig den rette viden lige at finde ud af hvorfor og hvad der gør hjemmesiden langsom, og den viden har jeg selvfølgelig.
Javascripts blokerede for rendering
Først og fremmest er det, som jeg også beskriver i et andet indlæg om blokerende javascript, at det ikke er nok bare at flytte scripts under folden, de skal også loades asynkront.
Dernæst skal man virkelig holde øje med hvordan siden renderer. For hvis hjemmesiden rendere langsomt, kan det også være på grund af at siden skal læses flere gange for at gengive indholdet 100%. Og dette gør altså at scripts pludselig er blokerende igen.
Yderligere er det total No-go set i forhold til at det netop giver en langsom hjemmeside visuelt, men også set i forhold til rendering og prioriter synligt indhold, at ændre på design over folden via javascript. Også dette kan få siden til at blive læst flere gange, og dermed trykke en blokering af renderingen frem.
Komprimering af billeder
Det er vigtigt at komprimere billeder korrekt. Og ikke mindst vise billeder der svarer til det brugeren har brug for at se. Ellers får man her også en langsom hjemmeside. Dette er især vigtigt med baggrundsbilleder, da disse ret sjældent er mulige at lazyloade.
Alt det andet
der var selvfølgelig en masse andre småting som blev rettet, såsom optimering af css, fjernelse af ubrugt css og meget mere.
Resultatet af hastighedsoptimeringen
Resultatet taler lidt for sig selv. Ikke nok med at jeg mere end halverede den fulde loadtid, så blev onload mere end 5 gange hurtigere og DOM loadet blev 3 gange hurtigere. Yderligere gik sitet fra en Google Pagespeed score som allerede var god på mobil fra 94 til nu 96 , og på computer fra 85 til nu 93. Samtidig var der også forbedringer på RUM Speed Index som jo før var 567 men nu 324. Og ja så var der selvfølgelig også en forbedring på størrelsen af sitet og antallet af filer der skulle hentes af brugeren.
Så hvad kan man lærer af det? Jo der er altid noget man kan gøre for hastigheden, især når man har erfaringen til både at optimere i dybden, på performance og på serverniveau. Jeg optimere aldrig overfladisk som langt de fleste gør, og derfor vil jeg i langt de fleste tilfælde kunne gøre noget mere for hastigheden. Sagt på en anden måde, har endnu ikke prøvet at måtte sige “Jeg kan ikke gøre jeres hjemmeside hurtigere”
Interessant – kendte ikke til DOM int og DOM loaded forskellen.
Hvordan identificerer du ubrugte dele af css? Mange temaer har jo kilometerlange css definitioner.
Der er også mere i det end som så. Men i udgangspunktet kan man sige det som jeg skriver 🙂
Jeg benytter forskellige værktøjer til at identificerer ubrugt css og js kode. Men det primære værktøj jeg bruger er chrome browseren og dens udemærkede værktøj til netop det formål – Coverage https://developers.google.com/web/updates/2017/04/devtools-release-notes. Derudover har jeg udviklet min egen søger/tester til chrome som også gør det samme, det var dog før coverage kom til 🙂