Mister du trafik fordi din hjemmeside er for langsom?

Faktisk kan du miste op til 40%* af din trafik, hvis du ikke har fokus på dette! Alt sammen fordi din hjemmeside er langsommere end 1,2, … 3 sekunder.

Så derfor er du nød til at gøre noget! I denne artikel fremviser jeg én praktisk taktik du kan bruge for, at gøre din hjemmeside meget hurtigere allerede i dag.

… Faktisk har denne taktik gjort denne artikel 56,04 % hurtigere!

According to the most recent data, 40% of consumers will leave a page that takes longer than three seconds to load

Google

Du ved allerede at hastigheden er vigtig, og at 40% forsvinder hvis din hjemmeside loader >3 sekunder. Det er således lige meget om der er tale om WordPress eller Magento hastighed, besøgende vil have hurtigere hjemmesider og vil ikke længere vente på dem.

Taktikken går kort og godt ud på – igennem korrekt størrelse & komprimering af billeder – at nedbringe størrelsen på den samlede URL.

Direkte i Googles egen browser – Chrome – kan du nemt få et overblik over hastigheden af din hjemmeside.

Som det ses i ovenstående, så VAR hastigheden på dette blogindlæg 2,02 inden, jeg påbegyndte en WordPress hastighedsoptimering med denne taktik. Efter optimeringen kom hastigheden ned på på 888 ms. Der er således tale om en forbedring på 56,04%.

Direkte igennem DevTool fra Chrome, fås nemt et overblik over hvilke elementer som siden loader. Hertil knyttes vigtige oplysninger omkring status, type, størrelse og tid brugt på at loade det specifikke element.

Som det fremgår, så er det tydeligt, at billederne fylder meget af den totale størrelse. Det vil derfor give en mærkbar effekt, at sikre at disse billeder kun fylder det absolut mindste de kan.

Særligt kan størrelsen af billeder i dette indlæg optimeres, da de blot er for at fremvise et tool el.lign. Derfor kan vi tillade os at gå efter den mindst mulige størrelse.

Det som jeg ofte oplever er, at folk hurtigt stiller sig tilfredse med størrelsen på billederne – f.eks. hvis de blot er under 100 kB. Dette er dog sjældent en særlig god grænse at gå efter.

Step 1: rette størrelse

Inden du påbegynder nogen form for komprimering af billederne, så skal du sikre dig at størrelsen er 100% den du agter at bruge på hjemmesiden.

Så længe at billedet blot er 1% mindre/større, end den størrelse som designet agter at fremvise dette i, så har du problemer. Problemet opstår grundet det arbejde, der udføres med at loade det totale billede og efterfølgende tilpasse størrelsen til designet.

Selve designet fastsætter den faktiske størrelse du skal anvende. Vær ekstra opmærksom hvis f.eks. designet er responsiv (el.lign.) og hvordan billederne agerer når browservinduet skifter størrelse.

Afslutningsvist kan du – eks. igennem Photoshop – gøre brug af ”save for web”. Her har du muligheden for at arbejde med kvaliteten o.lign.

Step 2: Billedekomprimering

Når billedet har den korrekte størrelse, kan du påbegynde en omfattende komprimering af billedet for at opnå ønskede størrelse. Dette kan gøres igennem Googles eget tool Squoosh.app.

Det er antageligt at Googles eget tool leverer den bedste performance på markedet, da det er i deres største interesse at gøre hjemmesider hurtigere. Herunder er der dog også TinyPNG som alternativ.

Formålet skal være, at opnå billeder med en størrelse på omkring 10-15 kB. Når du dette niveau, og stadig med brugbare billeder, så vil du antageligt opnår en kraftig forbedring af din load hastighed.

Resultatet

Billede nr. 1 i denne artikel har indledningsvist en størrelse på 441.718 byte. Igennem arbejdet med Photoshop opnår jeg en størrelse på 36.988 byte. Efter arbejdet igennem Squoosh.app opnår jeg en størrelse på 13.971 byte.

Det er dog vigtigt at pointere, at screenshots kan miste muligheden for at læse disse, når man kommer så langt ned i størrelse. Dog er dette ikke noget problem i dette tilfælde, da formålet med billede 1 var, at fremvise toolet overordnet. Billedet nr. 3 er vi endt på under 9.964 byte, og grundet type af billedet, er dette nemmere at læse dette, da det er vores ønske hermed.

Samlet er hastigheden gået fra 2,02 sekunder til 888 ms. Der er således tale om en forbedring på 56,04%.

Afsluttende bemærkninger

Jeg gør i denne artikel brug af hastigheden målt direkte i din browser for, at få det mest brugbare og korrekte resultat. Der er dog flere tools som ligeså kan oplyse denne – dog med diverse fordele og ulemper tilknyttet. Eksempler herpå er WebPageTest og PingdomTools.

Måles hastigheden f.eks. med WebPageTest, oplever jeg før optimeringen en hastighed på 3,651 sek og en hastighed efter på 1,801 sekunder. PingdomTools måler 615 ms før og 472 ms. Der er således en forbedring begge steder, men dog meget forskellige resultater.

*Kilde: https://www.thinkwithgoogle.com/marketing-resources/experience-design/mobile-page-speed-load-time/