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.
Sværhedsgrad på custom hjemmesider
Kræver en del PHP viden, især om det at læse HTML’en på en hjemmeside, og gemme dem i en fil på din server, som ligger i samme struktur som URL’erne på hjemmesiden. Samtidig kræver det også kendskab til det at lave rewrites via fx htaccess.
men hvis du som udvikler bare tænker:
- Hvordan får jeg fat i det HTML output som bliver genereret af PHP og sendt til brugeren
- Hvordan gemmer jeg den på serveren, hvis ikke den allerede er gemt på serveren
- Hvordan henter jeg den gemte/cachede HTML fil når en bruger efterspørger en bestemt side
HTML caching i wordpress
Det kræver ikke lige så meget viden at implementere denne del i WordPress, men det kræver alligevel lidt viden om htaccess, serveren og hvilke plugins der er gode til formålet, fx WP Rocket
Resultat: Det er meget forskelligt hvilket resultat man får ud af at implementere html caching, men en ting er sikkert at det giver typisk enormt meget, og derfor er det også en af de ting du bør implementere først.
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.
Sværhedsgrad på custom hjemmesider
Det kræver en del kendskab til CSS og CSS3, samt kendskab til Photoshop eller et andet billedbehandlingsprogram, hvor du kan sammenlægge grafikfiler til færre filer. Derudover skal du se på din hjemmeside i en browser som fx Google Chrome, da du der har muligheden for at køre et plug-in som hedder Yslow, der kan du køre billederne igennem smush.it. Alternativt er at programmere en løsning som gør det direkte på serveren, så så kræver endnu mere.
Sværhedsgrad på wordpress hjemmesider
Sværhedsgrad WordPress: Ud over ovenstående og generelle sværhedsgrad, vil du i WordPress kunne installere et plug-in som køre billeder gennem Smush.it, hvilket vil sige at du til den del ikke behøver så stor kendskab. Dog skal du have kendskab til hvad pluginet gør, da du kan ende ud i at den ikke vil som du vil.
Resultat: Hvor stort udbytte du får af dette, kommer i den grad an på hvor mange filer der var tale om fra start, men udbyttet er forholdsvis stort, så det er bestemt et sted jeg ville anbefale man gør noget ved.
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.
Sværhedsgrad Generelt: Det kræver noget kendskab til de forskellige JavaScript filer samt hvornår de behøver at loade. Ellers er det bare enten at lave et script som automatisk sammenlægger de forskellige filer, eller også skal du i gang med at kopiere og sætte ind. Den sidste er nemmest til en start, men kan skabe nogle problemer i forhold til når JavaScript filerne skal opdateres.
Sværhedsgrad WordPress: Sværhedsgraden er den samme, om end pluginet W3TC (W3 Total Cache), også har denne mulighed indbygget.
Resultat: Også her kommer det an på antallet af filer der var til en start, havde du kun 2 af hver før, vil det ikke give lige så meget som hvis du før have 10 af hver.
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 *Sværhedsgrad Generelt: Det kræver rimeligt kendskab til mime-typer samt htaccess at implementere dette. Yderligere kræver det også kendskab til hvor lang tid forskellige typer filer, bør blive gemt i browserens cache, samt hvilke situationer en fil helst ikke skal gemmes i for lang tid mm.
Sværhedsgrad WordPress: Sværhedsgraden er den samme, om end pluginet W3TC (W3 Total Cache), også har denne mulighed indbygget. Men dette er dog en meget standardiseret måde at gøre det på, hvilket ikke altid tilgodeser den enkelte WordPress hjemmeside.
Resultat: Selvom det ikke påvirker førstegangsbesøgende så meget, så kan man alligevel sige at det indirekte har en indflydelse for førstegangsbesøgende. Og en endnu større påvirkning for dem der allerede har været på din hjemmeside. Netop fordi serveren bliver belastet mindre, køre serveren også hurtigere og kan derfor behandle det der er nødvendigt, hurtigere.
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.
Sværhedsgrad Generelt: Det kræver a du sætter dig ind i din hjemmeside og ved hvilke størrelser, hvilke filer mm. Der bliver hentet. Og derfra er det så bare at lave det om, eller bede din udvikler om at lave det om.
Sværhedsgrad WordPress: Der er ikke den store forskel fra en normal hjemmeside til en WordPress hjemmeside. Dog kan der være andre måder at gøre det på hvis det er et plug-in som laver billedstørrelserne.
Resultat: Hvor meget du kan opnå kommer helt an på hvor grelt det står til, er der mange filer som er de samme eller næsten de samme, så kan det gøre en mellemstor forskel, i Aminos tilfælde taler vi omkring 100ms, hvilket ikke er meget, men alligevel noget som jeg personligt ville forfølge og rette.
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.
Sværhedsgrad Generelt: Det kræver indgående kendskab til htaccess/vHost, Apache og de forskellige moduler. Uden den kendskab, når du ikke langt og kan ikke udnytte serveren til fulde uden at det belaster alt for meget.
Sværhedsgrad WordPress: Den er lidt sværere i WordPress, forstået på den måde at WordPress og de plug-ins man kan installerer, absolut og i den grad tager brug af htaccess, og på flere niveauer endda.
Resultat: Det varierer rigtig meget. Og selvom man ikke vinder så vanvittigt meget på hjemmesidens hastighed direkte, så skal det i hvert fald være meget slemt og meget dårligt, så vinder man alligevel indirekte en helt del. Optimere man sin htaccess, og har man muligheden for slet ikke at bruge htaccess, vil man vinde utrolig meget på performance siden. Din server vil kunne håndtere flere brugere på samme tid, uden at den bliver belastet, hvilket også, indirekte, har en indflydelse på hjemmesidens hastighed og stabilitet.
Et eksempel fra den virkelige verden: jeg havde en kunde som havde skrevet rigtig mange linjer i sin htaccess, der var både redirects, rewrites og meget mere, men ved at optimere den kode, samt flytte meget af den fra htaccess til vHost, gav dette et performanceboost på hele 4000 %. Så det siger vidst det hele.
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.
Sværhedsgrad Generelt: Det kræver indgående kendskab til HTML, JavaScript og CSS. Og vil du minificere on the fly som KTJ-Media.dk gør det, så skal du også have en del kendskab til PHP og kodning i det hele taget.
Sværhedsgrad WordPress: I WordPress er det lidt nemmere, dog skal du være opmærksom på at der tit sker fejl med JavaScript, og derfor kan du typisk kun fjerne lidt af den kode. Yderligere bruger WordPress også tit inline JavaScript i deres plug-ins, hvilket også gør at der kan ske fejl der.
Resultat: Dette varierer fra bruger til bruger, da det kommer meget an på deres internets hastighed, men selvfølgelig også serverens hastighed.
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.
Sværhedsgrad Generelt: Det kræver viden om CSS i de fleste tilfælde.
Sværhedsgrad WordPress: Ingen tilføjelser i forhold til den generelle sværhedsgrad.
Resultat: Det giver intet på hastigheden af hjemmesiden, men den synes hurtigere for dine besøgende, og samtidig kan du også skabe positivt fokus på forskellige områder
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.
Gratis analyse af din hjemmesides hastighed
Få foretaget en hastighedsanalyse af din hjemmeside, og få samtidig et uforpligtende tilbud på hastighedsoptimering.
