Hurtigere hjemmeside – 10 gode råd til en hurtig hjemmeside

Hvordan får man egentlig en hurtigere hjemmeside? det er egentlig ikke så svært, du skal bare følge disse 10 gode råd til en hurtigere hjemmeside, og så er du godt på vej. En hurtigere hjemmeside vil både være godt for dine besøgende og dine placeringer i Google. Og yderligere vil en hurtigere hjemmeside gøre så din hjemmeside konverterer langt bedre.

HTML Caching / Output Caching

Hjemmesider er i dag typisk lavet i et serversidescript som fx PHP eller .NET / ASP. Det betyder at, før hjemmesiden er klar til visning over for dig som bruger, skal Serveren hvor hjemmesiden ligger, lige fortolke denne serversidekode, og derefter sende din browser HTML koden, som browseren så skal fortolke for så at vise dig hjemmesiden.

På mange servere, og med mange systemer, er dette en krævende proces som kan tage alt fra 500ms – 1500ms. I nogle tilfælde helt op over 2 sekunder. Det er derfor også et sted hvor man bør starte da man kan hente så meget tid på dette punkt, og dermed gøre hjemmesiden hurtigere.

Hvad er HTML Caching / Output Caching?

I grunden kan man sige at det er lidt ligesom I gamle dage, hvor man sad og lavede helt almindelige og statiske hjemmesider. Dengang sad man og lavede en html fil pr side, fx index.html for forsiden, man uploade så denne fil til sin server, og man kunne så se hjemmesiden. Langsommeligt at arbejde med for de fleste, men det kræver utrolig lidt af en server og derfor loader det også utrolig hurtigt.

Det er selvfølgelig ikke det du skal gøre, men du skal i grunden prøve at ramme det samme resultat med din hjemmesideløsning. Altså lægge/gemme nogle HTML filer på din server, som så bliver sendt til brugeren i stedet for at serversidescriptet skal køre hver gang en bruger besøger din hjemmeside. Hvordan man når det resultat er meget forskelligt fra hjemmeside til hjemmeside, hvilket gør det umuligt at komme med den helt rigtige løsning.

Skær ned på antallet af grafik og billedfiler

Jo flere filer en bruger skal hente når de besøger din hjemmeside, jo dårligere er det. Det er sådan at når du besøger en hjemmeside, skal alle grafikfiler og billeder hentes ned på din computer, så de kan blive vist på hjemmesiden. I gennemsnit tager det mellem 15-20ms pr. fil der skal hentes, dette tal er taget ud fra tests på en række sites. Og da der typisk bliver hentet mellem 30-70 billed- og grafik filer, skal der ikke meget hovedregning til for at kunne se, at det rent faktisk kan betale sig at gå op i at have så få filer som muligt.

Hvad bør man gøre for at skære ned på antallet af grafik?

• Se efter om der er grafik som kan erstattes af helt almindelig CSS kode, mange bruger stadig grafikfiler, selvom der rent faktisk kun er tale om en enkelt farve, fx på en baggrund. Yderligere er der også flere muligheder med CSS3 hvor man kan lave runde hjørner, skygger, gradienter mm. Dog skal man være opmærksom på at ikke alle browsere understøtter alt i CSS3, men det er bestemt værd at se på og vurdere om man skal bruge.
• Der hvor man ikke kan erstatte det med CSS, skal du sammenlægge filerne til CSS sprites, du skal tænke dig lidt om når du gør det, både fordi selvom det er godt med så få filer som muligt, kan du fx også risikere at siden loader visuelt langsomt hvis du kun har 1 billedfil til al din grafik.
• Kør billeder gennem smush.it, som er et komprimeringsværktøj som komprimerer filerne til det yderste uden at tabe kvalitet, bedre end Photoshops ”save for web” underligt nok.
• Husk altid at tjekke om siden stadig loader visuelt hurtigt eller om den evt. hakker for meget.

Sammenlæg CSS filer og JavaScript filer

Ligesom med grafikfiler, er det vigtigt at du sammenlægger CSS og JavaScript filer til så få filer som muligt. Nogen gange er dette en af hver, andre gange er det lidt flere JavaScript filer. Det der i grunden bestemmer det, er hvordan hjemmesiden visuelt loader. Men start ud med at sammenlægge til 1 CSS fil og 1 JavaScript fil og tag den derfra, loader den hurtigt og uden nogen visuelle irritationer, så er det jo helt fint.

Sørg samtidig også for at CSS filen står før JavaScript filen i html koden, og placer helst JavaScript filen til aller sidst i dokumentet, altså før det afsluttende Body tag, og endnu bedre så load det asynkront så det ikke blokere for at andre filer såsom billeder bliver hentet.

Prøv yderligere også at få inline CSS og inline JavaScript med i de filer, eventuelt til sidst i filerne. Da sådan noget ikke hører hjemme i Mark-up koden (html koden), Det er kun i de tilfælde at CSS er genereret af noget JavaScript som køre, at der må være inline CSS.

Browser Caching

Browser Caching, er det at man fortæller browserne at de skal gemme på filerne, og hvor lang tid de skal gemme på dem og ja hvad de ellers skal gøre i forhold til filerne. Her tænker jeg især på JavaScript, CSS og billedfiler.

Opsætter man det rigtigt, minimerer det antallet af overførsler fra serveren, og dermed også belastningen af serveren. Det betyder i grunden at når en bruger første gang besøger din hjemmeside, får browseren af vide den lige skal gemme på de her filer i dens cache, og når brugeren så skifter side, eller besøger hjemmesiden på et senere tidspunkt. Tjekker browseren lige om der er kommet en nyere version, og er der ikke det, hentes filen fra browserens cache i stedet for fra serveren.

Eksempel på brugen af browsercaching af jpg billeder (skal stå i htaccess)

AddType image/jpeg .jpg .jpeg .jpe

ExpiresActive On
 
ExpiresByType image/jpeg A31536000 #tallet er angivet i sekunder

<FilesMatch ".(jpg|jpeg|jpe)$">
 
Header set Pragma "public"
 
Header set Cache-Control "public, must-revalidate, proxy-revalidate"
FileETag MTime Size
 
</FilesMatch>
Header set Vary *

Lad være med at loade de samme grafikfiler, JavaScript filer mm. Som i grunden er samme, lidt mindre eller en ældre udgave af filen.

Jeg ser tit når jeg optimere hjemmesiders hastighed, at der bliver loadet de samme eller næsten de samme filer flere gange. Selvom det typisk ses i Open Source løsninger som fx WordPress, fordi de forskellige plug-ins tager brug af det, og samtidig har der siddet en koder og indsat det direkte i templaten.

Men i mange andre tilfælde er det ren og skær en fejl fra udviklerens side, fordi de ikke har tænkt sig om da de lavede hjemmesiden. Et godt eksempel er Amino.dk som stadig har det problem, at de på forsiden loader 2 forskellige billeder under ”Hyperaktive Amino’er” og ”Nye ekspertblog-indlæg”, og den eneste forskel på de to er at det ene er 45x45pixel og det andet er 48x48pixel, hvilket ikke ligefrem er den helt store forskel, og dermed ville jeg mene at det næsten er den samme fil.
I stedet bør de gå ind og sige at de begge fx er 46x46pixel, da det så gør at billedet kun skal loades en gang, og samtidig er i en ordentlig størrelse. Husk på de selv samme billeder bliver også loadet i 60×60, 80×80 og 300×300 pixel.

Et andet eksempel er at mange hjemmesider loader både en gammel og en ny version af jQuery.

Minimer brugen af rewrites i htaccess

Htaccess er en eller flere filer som du kan gemme på webhotellet, for at lave indstillinger på serveren, redirecte, omskrive og meget mere. Den er meget god hvis ikke der er andre alternativer til at opnå det resultat. Grunden til at man skal minimere brugen af htaccess, er fordi hver gang noget bliver efterspurgt på serveren, bliver htaccess filen læst linje for linje hver gang. Det vil sige, hurtigt skitseret, har du på din hjemmeside 70 requests, bliver htaccess filen læst 70 gange, uanset hvilken type fil der bliver efterspurgt, og står der samtidig mange linjer tager det så ekstra tid. Det siger sig selv at dette vil gøre en hjemmeside langsommere, og belaste serveren mere.

Mange systemer bruger endda også htaccess på flere niveauer, altså også nede i mapperne på serveren, hvilket betyder at når filer eller mapper i den pågældende mappe bliver læst, læses både den fil der er i mappen, men også den fil der typisk ligger i roden af sitet, og er der flere på dens vej fra mappen og tilbage til roden, bliver de også læst.

Bedre alternativer

Typisk findes der faktisk bedre alternativer og bedre brug af htaccess filen, mest fordi de fleste som laver hjemmesider, eller administrere hjemmesider, ikke har så stor kendskab til htaccess, hvilket gør at der bliver brugt det forkerte i forskellige situationer.

Et godt eksempel er at rigtig mange laver redirects ved brug af mod_rewrite (modul til Apache), hvor de i de fleste tilfælde skulle have brugt redirect eller redirectMatch som er betydeligt hurtigere og skaber færre linjer i htaccess filen.

Jeg oplevede for ikke ret lang tid siden, at der var nogen som havde lavet over 300 redirects ved brug af Rewrite i stedet for RedirectMatch, hvilket resulterede i 300+ linjer i htaccess filen. Dette kunne koges ned til 3 linjer.

De ville gerne redirecte næsten alle htm og html sider til samme mappestrukur, men uden en filendelse og med slash for enden af urlen.

Dårlig kode:

RewriteEngine On
RewriteRule ^gammel1.htm$ /gammel1/ [R=301,L]
 
RewriteRule ^gammel2.htm$ /gammel2/ [R=301,L]
 
RewriteRule ^gammel3.htm$ /gammel3/ [R=301,L]
 
RewriteRule ^gammel4.htm$ /gammel4/ [R=301,L]
 
RewriteRule ^gammel5.htm$ /gammel5/ [R=301,L]
…… 
 
…

Og så videre op imod 300 sider blev omdirigeret på denne måde
Yderligere var der nogle få som blev omdirigeret til forsiden og andre til en anden underside på eksakt samme måde som ovenfor.

God og omskrevet kode:

RedirectMatch 301 (underside1|underside2|underside3|underside4).(htm|html)$ http://www.kim-tetzlaff.dk/underside/
RedirectMatch 301 (side1|side2|side3|side4).(htm|html)$ http://www.kim-tetzlaff.dk/

RedirectMatch 301 ^(.*).(htm|html)$ http://www.kim-tetzlaff.dk$1/

Ovenstående kode er god, både fordi den kun fylder 3 linjer, men også fordi den slet ikke bruger mod_rewrite, men derimod mod_alias, som reelt set er det man bør bruge i ovenstående tilfælde, da den er så meget hurtigere, og dermed belaster serveren mindre. Mod_rewrite er lavet til noget mere avancerede omdirigeringer og omskrivninger, mens mod_alias er lavet til omdirigeringer.

Så alt i alt tænk dig om når du bruger htaccess.

Et andet og endnu bedre alternativ er slet ikke at bruge htaccess, men i mange tilfælde kræver det at man har adgang til vHost og kan skrive det direkte i Apache Direktiverne. Det er en meget bedre løsning da det der står der kun bliver læst 1 gang.

Skriv ordentlig og minifiseret kode

Jeg kan kun anbefale at man minificere sin kode, hvad enten det er html, CSS eller JavaScript kode. Det man gør, er at fjerne alt White Space fra filerne, fjerner eller omskriver kode som kan forbedres mm. Og det man spare er på filens størrelse. Ja et mellemrum gør også at filen fylder mere.

Et eksempel er amino.dk som godt nok har gjort noget ved det efter jeg har anbefalet dem det, men alligevel har de ikke gjort nok. For besøger man fx https://www.amino.dk/kim-tetzlaff-speed er der 74.129 tegn, men med fjernelse af al White Space samt optimering af koden, kan de 11.420 tegn blive fjernet. Hvilket svare til ca. 11kb. Hvilket i praksis betyder at den html side kunne blive hentet 17ms hurtigere på en 5 Mbit forbindelse Dette tal er selvfølgelig noget højere på deres forumsider.

Så det kan bestemt betale sig at gøre noget ved det også.

Yderligere er det vigtigt at du skriver ordentlig kode, og at denne lever op til standarderne. Grunden er at det gør det nemmere for browsere at fortolke koden, og dermed også hurtigere, hvilket også resulterer i en lidt hurtigere hjemmeside. En så simpel ting som at huske at skrive bredde og højde på et img tag, gør altså noget for hastigheden, da browseren ikke selv skal finde ud af hvor stort billedet er.

Minimer brugen af plug-ins

Det er altid godt at tænke over hvilke plugins man bruger og om det er nødvendigt for at få den funktionalitet man gerne vil have. I mange tilfælde installeres plugins som har samme funktioner, men med en lille ændring, i andre tilfælde er plugins så store at du kun bruger under 10% af funktionaliteten i det.

Husk det er ikke antallet af plugins der gør hjemmesiden langsom, men derimod kvaliteten og størrelsen på de plugins.

Det jeg også ser ofte er brugen af content buildere som Elementor, Visual Composer og DIVI. Men i virkeligheden skulle du se ind i at WordPress allerede har en content builder indbygget, som måske bare lige skal udvides lidt så du får den funktionalitet du gerne vil have. Med det mener jeg, så dig ind i de muligheder der er, lær dem at kende og vælg så ud fra det. Mit bud er, Gutenberg er mindst lige så nemt og med lige så gode muligheder for design som de 3 andre. Og så er det bare 1000 gange hurtigere.

Se på hvordan hjemmesiden loader

Ja vi kommer ikke uden om det at du skal se på din hjemmeside, jeg har skrevet det i et tidligere indlæg om hastighed, men jeg skriver det alligevel igen.

Se på din hjemmeside, loader den hurtigt, er der noget der hakker, er der noget som kommer senere eller er der andet som gør at det virker som om hjemmesiden loader langsomt. Der hvor jeg typisk ser at det hakker/hopper, er ved blandt andet billeder, video, ikoner, sociale medie ikoner, tekster etc. Så du skal være lidt obs når du kigger siden igennem.

I dag kalder google dette Cumulative layout Shift (CLS). Men Kim Tetzlaff har altid arbejdet ud fra denne filosofi.

Måden du skal teste på er ved at huske at slette ”temporery internet files” hver gang du tester, så du agerer en helt ny bruger. Og har du muligheden for at nedsætte din internet hastighed, så gør det. Muligheden findes i Google Chrome, der kan du både nedsætte CPU og Internet hastigheden. og du kan også automatisk undlade at bruge browseren cache.

Test din hjemmeside og forskellige ressourcer

Det er vigtigt at du før, under og bagefter optimering tester dit websites, da du ellers ikke ved om de ting du gør, kan gøres endnu bedre. Her er nogle af de værktøjer og services jeg bruger til hverdag.

Pingdom Tools (https://tools.pingdom.com/)
Et godt allround værktøj, som kan vise dig forskellige ting om din hjemmeside, både hvor lange ventetider der er, men også hvor lang tid det tager et hente filer mm. Yderligere kan du teste fra 3 forskellige lokationer, jeg bruger typisk Amsterdam.

K6 ( før Load Impact) (https://k6.io/)
Godt til at teste performance på hjemmesiden, typisk til at teste hvor mange brugere man kan have på samme tid på hjemmesiden, uden at det belaster serveren for meget. Man skal dog lige lære det at kende og vide hvad man skal kigge efter, og hvad der er overdrevet og måske irrelevant. Men ellers et godt værktøj.

Google Chrome (https://www.google.com/chrome/?hl=da)

Ja det er en browser, men der er så mange muligheder for at teste forskellige ting på hjemmesiden, fx hvordan ting loader og køre, samt det at bruge yslow og Google Page Speed mm. Det er en god browser til udviklere og folk som gerne vil teste forskellige ting.

Apache Serveren

Apache har også et testværktøj (AB), som benchmarker din hjemmeside, altså tester fx belastninger mm. Men dette er kun muligt når man har egen server enten dedikeret eller virtuel server, samt har adgang til SSH. Men det er utrolig godt og har du muligheden så brug det. Prøv fx som en lille ting at lave en enkelt html fil på din server, som indeholder de samme ting og elementer som din forside. Og test så din hjemmesides forside med værktøjet og derefter den html fil. Så skal du se løjer. Du vil finde ud af at din server pludselig kan håndtere så mange flere brugere på en gang.