Obsidian.dk – Langsom hjemmeside som andre allerede havde optimeret på.

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”