Sådan optimerer du hjemmesidens hastighed
Udgivet: July 17, 2019
Senest opdateret: March 15, 2023
Udgivet: July 17, 2019
Senest opdateret: March 15, 2023
Estimeret læsetid: 53 minutter
Lær hvordan hastighed påvirker din virksomhed og få praktiske tips til at gøre din hjemmeside hurtigere.
Siden 2009 har Google sagt, at hastighed er vigtig! Mere end ti år efter er hastighed vigtigere end nogensinde før, fordi webhastighed er gået fra at være en konkurrencemæssig fordel i forhold til andre hjemmesider i samme branche, til at være den helt gængse oplevelse som forventes af brugere hver dag, og som desuden kan øge eller hæmme konverteringsfrekvensen.
Heldigvis er det ikke svært at få din hjemmeside til at loade hurtigt. I hvert fald det meste mest af tiden.
Løsningerne er mange og let tilgængelige. De kommer i form af hastighedstest og overvågningsværktøjer, website-plugins der automatiserer optimering samt flere andre teknologier og teknikker. Nogle hastighedsoptimeringstricks kræver ikke engang værktøjer, men bare opmærksomhed og handling. Men hvor starter du?
I denne serie dykker vi ned i forskellige emner for at hjælpe dig med at komme i gang med at øge hastigheden på din hjemmeside. Hvis du allerede er forbi "begynderstadiet”, hjælper vi dig med at holde processen kørende.
Bemærk dog, at dette ikke er tænkt som en udtømmende liste over hver eneste ting, du har brug for at vide om hastighedsoptimering. Selvom vi ganske vist løber forskellige tiltag igennem, så går vi ikke så dybt ind i de meget tekniske tiltag, så en person, der ikke ved, hvordan man koder, vil alligevel kunne følge med. Dette er en vejledning til den virksomhedsejer, som ønsker at gøre noget ved hastigheden på deres website, og ønsker at lære hvordan man gør det.
Når det så er sagt, uanset hvilket stadie du er på - om du lige er ved at tage det første, spæde skridt eller er dér, hvor du har gjort det grundlæggende, og er klar til at gå videre – er hér materiale, der kan hjælpe dig til at:
Denne serie blev senest opdateret den 17. July 2019. Best practices vedr. hastighedsoptimering ændrer sig konstant, og selvom vi gør vores bedste for, at oplysningerne altid er nøjagtige, bør du altid betragte fakta hér som gældende i forhold til datoen for den seneste revision.
Dét, at hastighed er vigtigt, er ikke ligefrem en stor åbenbaring.
Selvom man ser bort fra statistikker og casestudier, der påviser dette, er det stadig ret indlysende, hvorfor hastighed betyder noget: Tænk tilbage på sidste gang, du forlod en hjemmeside, fordi siden loadede for langsomt. Det er ikke lige dén oplevelse, du gerne vil have, at dine besøgende - altså dine potentielle kunder - skal have, vel?
Men at vide, at hastighed er vigtigt, er ikke ensbetydende med, at man også gør noget ved det.
For eksempel sagde 73% af marketingfolk, adspurgt af Unbounce i 2018, at forbedring af hjemmesidens hastighed var enten "ret presserende" eller "meget presserende". Alligevel viste den samme undersøgelse, at kun 3% af marketingfolkene har hurtigere loadtider på websites som deres førsteprioritet i 2019. Hvad skyldes dét?
Marketingfolk prioriterede anderledes, og det samme er sandsynligvis tilfældet for dig som virksomhedsejer.
Med mange andre presserende ting at tage dig af, hvordan afgør du så præcis, hvor højt prioriteret hastighedsoptimering bør være på listen?
Nøglen er først at forstå, hvordan hastigheden overhovedet kan påvirke din virksomhed til at starte med.
Hastighed er vigtigt for Google. Medmindre du ikke er ude efter at få din hjemmeside så højt op på Googles søgeresultatsider som muligt, bør du lægge vægt på alt, hvad Google lægger vægt på.
Googles medstifter Larry Page fremlagde en vision om at “være i stand til at gå fra webside til webside så hurtigt som at bladre i et ugeblad", hvilket førte til Googles “Let’s make the web faster”-initiativ i 2009.
Teknikgiganten har lige siden agiteret for hastighed. Websitehastighed har været en faktor i rangeringen af desktop-søgeresultater siden 2010, og sidste år meddelte Google, at sidehastighed også vil blive brugt i rangeringen af søgeresultater for mobile enheder.
Udover at være en officiel rangeringsfaktor påvirker sidehastighed også din afvisningsfrekvens eller den procentdel af besøg, hvor en bruger forlader din hjemmeside efter at have besøgt en enkelt side.
Afvisningsfrekvensen er en vigtig indikator for, hvor relevant din hjemmeside er, hvilket igen er en faktor, som Google tager i betragtning, når der vises søgeresultater.
En lav afvisningsfrekvens fortæller Google, at din hjemmeside må være relevant nok, når brugere udforsker flere sider og ikke straks klikker væk, når de lander på den. Omvendt tyder en høj afvisningsfrekvens på, at brugere ikke finder hjemmesidens indhold relevant for de emner, de har søgt på.
Ofte skyldes det dog ikke manglen på relevans, men langsomme loadtider. Når en side loades for langsomt, trykker de fleste bare på tilbage-knappen og går videre til det næste søgeresultat. Hvis loadtiden øges fra 1 sekund til blot 3 sekunder, øges sansynligheden for afvisning ifølge Google med 32%.
Men eftehånden, som indlæsningstider falder, øges antallet af sider som brugerne normalt besøger i en session også. I 2017 kunne det påvises, at brugere gennemsnitligt besøger 5,6 sider mere, når sidens indlæsningstid er 2 sekunder i forhold til 8 sekunder.
Hvis din hjemmeside er for langsom, risikerer du at blive vist længere nede (eller slet ikke at blive vist) i søgeresultater. Google baserer præsentationen af de mest relevante sider baseret på éns søgning, men selv den mest relevante side vil ikke være til nogen nytte for en bruger, som ikke alene ønsker at finde svar på sit spørgsmål, men ønsker at få det hurtigt.
Brugere kan ikke lide en sløv hjemmeside. Ingen har rigtig tålmodighed til at vente på en langsomt loadende hjemmeside, når hundredvis af andre lignende websites kan findes på nettet. Faktisk vil den gennemsnitlige bruger hellere bruge flere minutter på at kigge en hurtig, men irrelevant, hjemmeside igennem, end vente på at en relevant, men langsom, bliver loadet.
Hastighed er en vigtig faktor i brugeroplevelsen, fordi din bruger jo rent teknisk set ikke kan opleve noget på din hjemmeside, før det er loadet.
I 2018 fandt Google, at mere end halvdelen af mobile besøgende forlader sider, når de loader i mere end 3 sekunder.
Hvis din hjemmeside er langsom, mister du et betydeligt antal potentielle besøgende. Og ikke kun dét. Du mister også potentielle konverteringer.
I Unbounces Page Speed Report fra 2019 sagde 45,4% af de adspurgte brugere, at de er mindre tilbøjelige til at købe fra en hjemmeside, der loader langsommere end forventet. Endnu værre er det, at 36,8% er mindre tilbøjelige til at vende tilbage, mens 11,9% vil være tilbøjelige til at fortælle en ven om oplevelsen.
Omvendt rapporterer Google, at forbrugere i gennemsnit er 10% mere villige til at anbefale en webshop, når loadtiden falder fra 13 sekunder til kun 10 sekunder. Og efterhånden som loadtiden blev reduceret yderligere fra 13 til 3 sekunder, steg sandsynligheden for videreanbefaling fra forbrugere også til 26 %.
Brugeroplevelsen har indflydelse på, hvor sandsynligt det er, at dine besøgende vil konvertere, og denne sandsynlighed mindskes bare yderligere, hvis brugerne forlader din hjemmeside igen, før de overhovedet ser, hvad du kan tilbyde.
Vigtigere endnu er det, at gode brugeroplevelser skaber loyale kunder, der dermed bliver ambassadører for dit brand. Og god brugeroplevelse starter med en hurtigt loadende hjemmeside.
Søgeannoncer koster mere, hvis du har langsomme landing pages.
Hvis du kører med pay-per-click-annoncer (PPC) på Google, er du måske bekendt med Kvalitetsresultat-oversigten, der er en vurdering af kvaliteten af dine annoncer, søgeord og landingsside. Den er også afgørende for, hvor meget du bliver opkrævet for hvert klik, du får på dine annoncer. Jo højere dit kvalitetsresultat er, desto mindre skal du i bund og grund betale.
Ikke overraskende er hjemmesidens hastighed en af de faktorer, der påvirker, hvordan Google afgør dit kvalitetsresultat.
Når nogen klikker på din annonce, og din landingsside loader for langsomt, anser Google det for en dårlig brugeroplevelse, hvilket formentlig mindsker annoncens samlede kvalitetsresultat.
Som følge heraf kommer dine annoncer i fare for at få færre visninger eller endda slet ingen, og oven i købet betaler du også mere for de klik, du trods alt får. Ingen bryder sig om en såkaldt “lose-lose situation”.
En langsom hjemmeside skyldes ofte "unødvendige" ressourcer, der optager for meget plads på serveren. At skære ned på disse ressourcer forbedrer ikke kun din hjemmesides indlæsningstid, men hjælper dig også med at reducere driftsomkostningerne.
Almindeligvis leveres hostingplaner med en vis mængde tildelte ressourcer. Nogle planer tilbyder faste omkostninger uanset hvor mange ressourcer du bruger på serveren, men hos de fleste koster det mere, eller de kræver, at du opgraderer, når dine ressourcer overstiger et bestemt niveau.
Den ideelle løsning er imidlertid ikke altid at opgradere til en større server, men blot at fjerne unødvendige ressourcer fra din nuværende.
Dette frigør plads, der giver dig mulighed for beholde din nuværende plan, og gør det muligt at håndtere mere trafik på din hjemmeside uden at måtte investere i mere hardware. I nogle tilfælde kan dette endda gøre dig i stand til at vælge en billigere plan. Uanset, hvad er slutresultatet en hurtigere hjemmeside med en relativt lavere driftsomkostning.
Google og andre søgemaskiner crawler muligvis ikke din hjemmeside så ofte, hvis det er langsomt.
Googles crawlere har et såkaldt "tildelt crawl budget".
Dette budget består af to faktorer: Crawl efterspørgsel, hvilket er dine siders efterspørgsel baseret på deres popularitet og relevansen af dit indhold, og Crawl Rate Limit, der begrænser den maksimale crawl-frekvens for din hjemmeside, eller antallet af sider, som crawlerne kan "ringe til" på samme tid og ventetiden mellem sådanne opkald.
Hvis din hjemmeside reagerer hurtigt på hentninger, kan Googles crawlere gennemgå flere sider. Men hvis siden loader langsomt eller sender mange connection timeouts, sænkes budgettets Crawl Rate Limit, og Google kan helt holde op med at indeksere.
Google har bekræftet, at dette ikke er et problem for de fleste små websites, men hvis du har en stor hjemmeside med mere end et par tusinde sider, så kan for langsom loadtid påvirke din hjemmesides indeksering.
En langsomt loadende hjemmeside er ikke bare en frustration. Det er et reelt problem, der kan påvirke din forretning, så det kan mærkes helt nede på bundlinjen.
Og selvom graden af påvirkning varierer fra virksomhed til virksomhed, er der ingen tvivl om, at website-hastighed er et vigtigt aspekt af din virksomhed, som du er nødt til at holde øje med.
Det er også vigtigt at huske, at hastighedsoptimering ikke er noget, du gør én gang og så ellers glemmer derefter.
Det er en løbende proces, og bør derfor være et fast punkt på din liste over prioriteter. Hvis ikke det er dét, er det måske på tide at gøre lidt op med vanerne.
Nu, hvor du er opmærksom på, hvordan din hjemmesides hastighed påvirker din virksomhed, er det tid til at forstå hastighedsoptimering som koncept.
Det handler selvfølgelig om at optimere din hjemmeside med hastighed for øje. Men denne definition kræver i sig selv nogle præciseringer:
For det første, hvad er hastighed, og hvordan måles den?
For det andet, hvordan optimerer du den? Og er der en acceptabel hastighed, man bør forsøge at ramme?
Vi har alle en idé om, hvad hurtigt er, men hvis vi skal være konkrete, hvor mange sekunder er det så egentlig?
Hastighed er en målelig størrelse, men om end et nøjagtigt tal er nyttigt at sigte mod som et specifikt mål, registrerer en enkelt måling ikke rigtig alle de andre faktorer, der har indvirkning på, hvor hurtigt en bruger oplever din hjemmeside.
Brugerne tæller jo ikke sekunderne, mens en webside indlæses. De besøger en side af en årsag, som f.eks. at få oplysninger eller købe et produkt, så hvad der dybest set betyder noget for dem er, hvor hurtigt de kan komme til at gøre dét, de ønsker at gøre på hjemmesiden. Hvor hurtigt den første side loader er kun ét aspekt.
Forestil dig en online shopper, der går ind i en webshop med en klar ide om, hvad hun vil købe.
Denne bruger vil sandsynligvis kigge efter søgefeltet eller produktmenuen først.
Hvis siden indlæser søgebjælken, og brugeren straks kan skrive produktnavnet og søge efter det, oplever hun sandsynligvis hjemmesiden som værende "hurtig", selvom resten af sidens elementer teknisk set stadig ikke er indlæst.
Omvendt, selvom søgebjælken måtte være indlæst på et øjeblik, men brugeren ikke kan bruge den, før alt sidens indhold er indlæst (hvilket varede flere sekunder), vil hun sandsynligvis opleve det som at webshoppen er "langsom".
Dette er illusionen om hastighed, og hele nøglen til det er at forstå brugeroplevelse.
Ofte er det øjeblikkelig respons, der får en side til at forekomme “hurtig”for en bruger.
Når en bruger navigerer fra én side til en anden, f.eks. fra en Google-søgeresultatside til en anden webside, er den første indikation på hastighed for brugeren, om navigationen gik igang som ønsket, og derefter hvor hurtigt sidens indhold vises, og om hun kan begynde at interagere (dvs. klikke, swipe, skrive) med elementerne eller ej.
Google fandt, at de webshops, der prioriterer indlæsningen af above-the-fold-indholdet (området på skærmen som bliver synligt for brugeren først, uden at der er behov for at scrolle), opleves som værende hurtigere end sidens faktisk målte hastighed, sandsynligvis fordi den del, der umiddelbart er synlig for brugeren, allerede er tilgængelig, selvom resten af siden (dvs. delen "under folden") stadig indlæses.
Men det handler ikke kun om, hvor hurtigt (og let) brugeren kan interagere med sidens elementer.
I samme undersøgelse undersøgte Google også andre faktorer, der påvirker en brugers oplevelse af en hjemmesides hastighed eller ydeevne. Deres forskning klarlagde at:
Så selvom sekunder altså gør en forskel – så vil en side, der loader i 30 lange sekunder, formentlig opleves som værende langsom uanset omstændighederne. Husk også på, at flere andre eksterne faktorer har indlydelse på brugerens oplevelse af hastighed.
Dybest set er det brugerens oplevelse af tiden, mens din side loades, der skal have fokus, når du optimerer din hjemmeside.
Hvis hastighed er mere end blot et enkelt tal, hvordan måler du den så effektivt? Forskellige faktorer vedr. hastighed og oplevelse kræver forskellige målemetoder. Her er nogle af de mest almindeligt anvendte og populære værktøjer til hastighedstest.
Page Speed – (Sidehastighed) henviser normalt til enten den tid det tager for alt indhold på siden at blive helt indlæst, eller den tid det tager for browseren at modtage den første byte af information fra webserveren.
DOM Ready Time – DOM eller Document Object Model, henviser til sidens kildedokument og omfatter sidens indhold såsom tekst, billeder og andre filer. “DOM Ready Time” er den tid, det tager, før den komplette HTML-kode er tilgængelig for browseren.
DOMContentLoaded – er, når alt indhold fra DOM'en er helt indlæst af browseren.
Speed Index – (Hastighedsindeks) er den tid, det tager for indholdet “over folden” at blive vist. Forskellige enheder har forskellige skærmstørrelser, så hastighedsindekset varierer afhængigt af størrelsen på skærmen, hvor siden vises.
First Paint – er, når skærmen viser noget visuelt anderledes end det foregående skærmbillede, som f.eks. en ændring i baggrundsfarven.
First Contentful Paint – er, når det første indhold vises på siden, som f.eks. tekst, et billede eller canvas-element.
First Meaningful Paint – er, når det første primære brugbare indhold er indlæst. Brugbart kan betyde forskellige ting for forskellige websites. Det kan være et billede, hvis det er en produktside, eller en overskrift og noget tekst i en nyhedsartikel.
First CPU Idle – er det tidspunkt, hvor siden kun lige akkurat er interaktiv, eller hvor brugeren kan interagere med siden første gang.
Time to Interactive – er den tid, det tager før indhold bliver vist og er brugbart for brugeren - Ligesom i "søgelinje”-eksemplet ovenfor.
Time to First Byte – er den tid, det tager for browseren at modtage den første “byte” eller stykke data fra webserveren - hvad der sommetider også henvises til, når der tales om “sidehastighed”.
First Input Delay – er tiden mellem brugerens første interaktion med siden, og det tidspunkt hvor browseren reagerer. Det ligner meget Time to Interactive, men First Input Delay måler faktiske besøgssessions, hvor Time to Interactive kan måles uden deltagelse af egentlige brugere.
Nogle af disse måleparametre er ret tekniske, mens andre er mere fokuseret på brugeroplevelsen. Ved hastighedsmåling er det god praksis at få målinger med fra begge slags.
Parametre som Dom Ready Time eller Speed Index er nyttige til rapportering og at holde styr på fremskridt i din optimeringsproces, mens de mere brugerfokuserede ydelsessmålinger vil hjælpe dig til at optimere med din gennemsnitsbruger i tankerne.
For eksempel vil First Meaningful Paint hjælpe dig med at prioritere hvilke dele eller elementer på din side, der skal indlæses først, afhængigt af hvilken del af siden der er mest relevant for din bruger.
Hvis du vil gå i dybden med detaljerne for alle måleparametrene og lære mere om andre parametre, der kan være nyttige i dine målinger, kan du tjekke Googles officielle guides:
Du hører sikkert sikkert hele tiden om at skabe en omnichannel-oplevelse, der handler om at møde dine kunder, hvor de er - og derfor ofte på mobiltelefonen.
De fleste virksomheder imødekommer allerede denne kendsgerning og har tilegnet sig en mobilstrategi i en eller anden retning. Imidlertid er mobil tilstedeværelse alene ikke længere nok til at imødekomme kunders voksende forventninger.
I 2018 var den gennemsnitlige loadtid for en mobilside 15 sekunder.
Dette blev rapporteret i den samme undersøgelse fra Google, som viste at 53% af mobile besøgende forlader sider, der loader i over 3 sekunder.
Dette store modsætningsforhold viser med al tydelighed, at alt for få virksomheder gør nok for at optimere deres mobilsites.
Men hvorfor skal du optimere specifikt til mobil?
Først og fremmest rangeres søgeresultater forskelligt for mobile og stationære enheder.
Vi har tidligere nævnt, at Google officielt gjorde sidehastighed til en rangeringsfaktor for mobilsøgningsresultater i januar 2018. Dette betyder, at Google specifikt kigger på din side, når den indlæses på mobilen og evaluerer dén uafhængigt af desktopversionen af din hjemmeside.
Så selvom du ligger øverst i resultatet for et bestemt søgeord på desktops, kan du stadig rangere betydeligt lavere i en mobilsøgning, hvis dit mobilsite er for langsomt. Og hvis du ikke er opmærksom på din hastighed på moble enheder, kan du gå glip af de potentielle kunder, der primært bruger deres telefoner.
Dernæst handler det hele om brugerforventning.
Smartphones betyder nem tilgængelighed og forbindelser på farten, så set i dét lys giver det meget god mening, at brugerne forventer hurtige oplevelser på deres mobiltelefoner.
Faktisk forventer kun 42% af brugerne, ifølge en undersøgelse fra Akamai i 2017, at indlæsningstiderne er enten "lidt langsommere" eller "meget langsommere" på deres telefoner end på deres desktops. Derimod forventer mere end halvdelen af deltagerne, at mobilhastigheden enten er den samme som eller hurtigere end på desktop.
Det eneste virksomheder kan gøre, er at holde trit.
For at finde løsningen skal du først finde årsagen til problemet.
Ryan, 1902 Softwares WordPress projektleder, ser ofte kunder bruge meget store billeder på deres hjemmesider, uvidende om, at det kan påvirke sidens hastighed. “Det er en almindelig ting, som folk ikke er klar over sløver deres hjemmeside. Oftest er det æstetik fremfor hastighed.”
“Et andet almindeligt problem, der opstår for brugere af CMS [Content Management System], især WordPress, er installation af plugins, der kun er tiltænkt én bestemt side,” tilføjer Ryan.
“Plugins er som standard aktiveret globalt (dvs. for hele hjemmesiden), så et plugins JavaScript og CSS-filer loades på alle sider på hjemmesiden, uanset om dette plugin faktisk bruges, eller overhovedet er nødvendigt på disse sider.”
Som resultat påvirker dette ekstra JavaScript og CSS indlæsningshastigheden for sådanne sider, selvom de faktisk ikke har noget at gøre med sidens indhold eller funktionaliteter.
Disse er blot nogle af de mere gængse udfordringer, og nogle gange er det relativt enkle forhold som disse - problemer der stammer fra hjemmesidens ejer, redaktør eller marketingfolk uvidende om hvad man gør, og hvad man ikke gør, når det gælder hastighed - der forårsager den sløje indlæsningstid for en side.
Andre gange kan problemet ligge dybere i hjemmesidens kode og kræver teknisk vejledning for at blive løst.
Men fællesnævneren for disse udfordringer er, at medmindre du er opmærksom på dem, vil du ikke kunne tage dig af dem.
Hvad der forårsager en langsom indlæsningstid er ikke altid indlysende - hvis det var, så ville du have gjort noget ved det nu. Især for mere komplekse problemer der ligger i koden, kan du få brug for udviklere til at kigge på dit website og afgøre, hvad der ikke virker og forårsager problemer.
Til mere "generel diagnose" vil de fleste testværktøjer af hastighed og ydelse imidlertid give indsigt i og forslag til, hvad der er årsagen til, at din hjemmeside loades langsomt. Her er nogle, som vi har fundet gavnlige i vores egne projekter:
1. Lighthouse – Dette er et testværktøj, der kan køres som en Chrome-udvidelse eller direkte i Chrome DevTools (dvs. dét sæt af webudviklerværktøjer indbygget i Google Chrome-browseren, der normalt er tilgængelige, når du højreklikker og inspicerer en hjemmeside).
Lighthouse bedømmer en side i forskellige kategorier: Ydeevne, progressive webapp, tilgængelighed, best practices og SEO.
Ydeevnen bedømmes på forskellige parametre: First Contentful Paint, First Meaningful Paint, Speed Index, First CPU Idle, Time to Interactive og Estimated Input Latency.
Udover selve bedømmelsen orienterer Lighthouse også om mulige årsager til din sides nedsatte hastighed og giver konkrete forslag til forbedring af sidens performance og deraf følgende nedbringelse af indlæsningstid.
2. Page Speed Insights – Dette giver indsigt i din sides hastighed på både desktop og mobil.
Page Speed Insights bruger stort set Lighthouse-data til hastighedstest og rapporterer derfor på de samme parametre, som Lighthouse bruger. Det er dog værd at bemærke, at Page Speed Insights og Lighthouse (tilgået inde fra Chrome DevTools) i nogle tilfælde kan give forskellige resultater. (Dette er vores observation fra vores egne tests, men generelt burde resultaterne ligge inden for samme margin).
Udover de laboratoriedata der er analyseret af Lighthouse, præsenterer den også reelle data fra brugeroplevelser via CrUX, når de er tilgængelige for hjemmesiden.
3. WebPageTest – Dette giver dig mulighed for at simulere, hvordan din side indlæses et bestemt sted og i en bestemt browser, så dette er især ideelt for virksomheder med kunder fra forskellige regioner, for at få bedre overblik over hvordan dine sider indlæses til din målgruppe.
Bortset fra placeringen lader WebPageTest dig også vælge browseren og mange andre avancerede indstillinger, der kan hjælpe dig med yderligere analyse af din hjemmesides performance.
4. GTmetrix – GTmetrix er en pakke af forskellige funktioner, der fokuserer på at forbedre web-performance, og kommer i både en gratis og en betalt version.
Det analyserer en hjemmeside baseret på indikatorer fastlagt af Google og Yahoo, og rapporterer på forskellige parametre som sideindlæsningstid, sidestørrelse og antal anmodninger. GTmetrix lader dig også afspille videoer af sideindlæsninger for et nærmere kig på mulige indlæsningsproblemer eller en trin-for-trin-visning af sideindlæsning i realtid.
Der er også mulighed for at oprette automatisk overvågning af sider og advarsler om forskellige forhold, der tyder på dårlig side-performance, som f.eks. langsom indlæsningstid eller en betydelig stigning i den samlede sidestørrelse.
5. Pingdom – Ligesom GTmetrix tilbyder også Pingdom forskellige funktioner til overvågning af din hjemmesides hastighed og performance.
De har et værktøj til hastighedstest, som lader dig teste indlæsningstiden fra en bestemt lokation, og pro-udgaven indeholder endda en funktion til at overvåge faktiske brugere, der besøger din hjemmeside. Dette hjælper dig når du skal identificere reelle flaskehalse som brugere kan opleve, når din hjemmeside indlæses.
Som det gælder for alle tiltag vil også hastighedsoptimering være mest effektiv, når først du forstår, hvad du arbejder med - f.eks. din aktuelle hastighed, de ressourcer og elementer du har (brug for) osv. - og får gravet dig helt ned til hvad årsagen til den langsomme indlæsningstid er.
Vejen til en hurtigere hjemmeside er ikke en lige linje.
Hastighedsoptimering er ikke en engangsforteelse, så der er nogle procedurer, du skal vende tilbage til igen og igen for at sikre, at du holder trit.
Nogle kan du dog helt springe over, for i sidste ende har alle hjemmesider forskellige slags indhold og forskellige problemstillinger at optimere på.
Når du har testet din hjemmesides hastighed og har en klar retning på, eller i det mindste en ide om, hvad der sløver den, er hér forskellige teknikker til forbedring af hastigheden, i rækkefølge fra den letteste til den sværeste implementering:
Vi ønsker alle et visuelt appellerende hjemmeside-design til at lokke kunderne ind, og stærke billeder er ofte den bedste måde at få det på. Imidlertid vil disse billeder ikke være til megen nytte, hvis brugerne ikke kan se dem, fordi de tager for lang tid at loade.
Desuden fokuserer forbrugere for tiden mere på hastighed end det visuelle.
Ifølge Unbounces undersøgelse er et betydeligt antal brugere villige til at undvære animationer (56,6%), videoer (52,8%) og billeder (24,1%) på en side, hvis det betyder, at siden vil indlæses meget hurtigere.
Meget store billeder er kendt som værende de "største syndere" på langsomme sider, så hvad kan du gøre med dem?
Tip nr. 1: Fjern alt unødvendigt.
“Det mest optimerede billede er det ikke-eksisterende billede,” siger Google i deres mobilhastighedsoptimeringsguide.
Det første, du skal overveje, er om alle de fancy billeder og videoer, der er lagt ind på din hjemmeside, også virkelig er nødvendige.
Hvis budskabet bragt af disse elementer lige så godt kan bringes med lidt kreativ brug af CSS (Cascading Style Sheets - et sprog, der bruges til at definere stilarter, former og effekter), så er det nok bedre at fjerne sådanne billeder helt og reducere tyngden af dine sider.
Tip nr. 2: Komprimér billeder.
Sørg for, at de billeder og videoer, du uploader til din hjemmeside, har den faktiske størrelse, som de fylder på siden.
Husk også at komprimere billeder ved at køre dem gennem værktøjer som TinyPNG.com. Komprimering af dine billeder reducerer deres filstørrelse betydeligt, samtidig med at deres kvalitet bevares.
Tip nr. 3: Brug det korrekte format.
Google foreslår, at billederne skal være i WebP, et billedformat, der er 30% mere komprimeret end det sædvanlige JPEG. For billeder med gennemsigtige baggrunde, brug PNG; For skalérbare ikoner og figurer, brug SVG.
Vi har tidligere talt om, hvordan brugere sommetider oplever sider som hurtigere end deres faktiske hastighed på grund af forskellige faktorer, herunder relevansen af det indhold, der først indlæses og sidens interaktivitet.
Brug denne illusion om hastighed til din fordel ved at optimere din hjemmeside specifikt til din målgruppe og ikke bare med en generisk målsætning for øje.
Der er intet galt med konkrete mål, som en fastsat indlæsningstid eller tyngde af en side.
Indlæsningstiden vil dog aldrig følge samme standard på tværs af alle brugere med adgang til din hjemmeside. Nogle af dem kan have de hurtigste forbindelser, mens andre måske browser på ringe netforbindelser.
Optimering af din hjemmeside med brugeren in mente hjælper dig til også at optimere for i hvert fald nogle af disse flaskehalse i den virkelige verden.
Tip nr. 4: Prioritér indlæsning af “above-the-fold”-indhold.
Selvom det er ideelt, at alt indhold på din side indlæses hurtigt, så er det vigtigere at sørge for, at above-the-fold-indholdet indlæses hurtigere.
Overvej at bruge “Lazy Loading”-teknikken, hvor billeder kun indlæses, når brugeren ruller eller kommer ind i området, hvor de er placeret. Det får din side til at blive vist hurtigere, fordi elementer kun vises efter behov.
Tip nr. 5: Sørg for at dit indhold straks er interaktivt.
Synligt loadet indhold er måske ikke særlig brugbart for en bruger, hvis hun ikke kan bruge eller interagere med det samme.
For det meste er synderen bag de synlige, men ikke-interaktive, elementer JavaScript og CSS, som blokerer for renderingen. Det er opgaver, der holder browseren travlt optaget, hvilket gør, at den ikke reagerer på brugerens input eller interaktion.
Bed din udvikler om at fjerne, eller i det mindste udsætte, indlæsningen af disse renderings-blokerende ressourcer for at forbedre din “Time to Interactive”.
Tip nr. 6: Vis pladsholdere, mens dit indhold stadig indlæses.
Når en bruger forlader en hjemmeside, fordi den er “for langsom”, skyldes det normalt, at der ikke sker noget under indlæsningstiden for at holde brugeren engageret. Som hvis brugeren f.eks. kun får en blank hvid side vist på skærmen.
Men hvis der vises noget respons til brugeren, selv når en side loader langsomt, er brugeren ofte mere villig til at vente, da der er et synligt signal om, at der sker noget.
Facebook bruger f.eks. pladsholdere, mens den indlæser indlæg i nyhedsfeedet. Disse er egentlig bare rammer til indlæg, bestående af figurer, der vikarierer for elementer som profilbillede, navn og selve indlægget, indtil det faktiske indhold er loadet.
Tip nr. 7: Minimér tap- eller klikforsinkelse.
Oplevelsen af hastighed er ikke begrænset til at handle om den umiddelbare indlæsningstid.
Selvom din side blev indlæst hurtigt, vil brugeren forlade den med en dårlig oplevelse, hvis elementer ikke er umiddelbart interaktive (som omtalt ovenfor), og hvis der er for meget forsinkelse efter et klik eller tap.
Google anbefaler, at den traditionelle 300-350 ms forsinkelse mellem touchend og klik bør elimineres for at skabe hurtigere interaktion for brugeren.
Tip nr. 8: Benyt dig af Optimistic Actions.
Optimistic Actions sender øjeblikkelig feedback til brugeren, der gør, at det virker, som om en handling er udført, selvom serveren i virkeligheden stadig behandler den i baggrunden.
Et godt eksempel på dette er Instagrams Like/Hjerte-action i dets app. Når en bruger dobbeltklikker på et billede, vises brugeren straks et hjerte, selvom handlingen endnu ikke er blevet helt udført for Instagrams vedkommende. Eller besked-apps hvor meddelelsen ser ud til at være "sendt" med det samme (dvs. meddelelsen forlader tekstfeltet og overføres til chatboksen), mens den faktisk stadig sender.
Tænk over de gange hvor du selv har forladt en side, fordi den loadede for langsomt, sammenholdt med de gange hvor du ventede på en side, selvom den ikke blev indlæst på et øjeblik. Disse sider kan have haft mere eller mindre samme indlæsningstider i sekunder, men forskellen er sandsynligvis, at sidstnævnte gruppe holdt dig engageret nok med konstant feedback.
Altså – det handler dybest set om, hvordan dine brugeres oplevelse af din hjemmeside skaber indtrykket hos dem af, hvor hurtig eller langsom, den er. Optimering på brugerorienterede parametre er i virkeligheden en win-win. Du kan optimere din hjemmeside "selektivt", men på en måde som faktisk opfylder dine brugers behov og forventninger bedre.
Bortset fra disse to hovedfokusområder er hér andre hastighedsoptimeringsteknikker, som du nemt kan implementere:
Tip nr. 9: Udnyt browseres caching.
Når en bruger besøger din hjemmeside for første gang, skal browseren downloade alt indholdet for at kunne vise siden korrekt. Det inkluderer HTML, JavaScript, CSS og billeder.
Browseren kan gemme eller “cache” disse elementer lokalt, så når brugeren vender tilbage, behøver den ikke at downloade alle filerne igen, og kan derved forkorte indlæsningstiden.
Udnyt denne funktion ved at markere dine sider, eller specifikke elementer på dine sider, med det interval, hvor du ønsker browseren skal opdatere eller genindlæse sådanne elementer. Egentlig fortæller du browseren, at nogle elementer på din side formentlig ikke opdateres regelmæssigt, så den kan cache disse elementer i længere tid, hvilket reducerer den mængde ressourcer, den skal genindlæse, hver gang brugeren vender tilbage til din hjemmeside.
Tip nr. 10: Brug et Content Delivery Network (CDN).
Et CDN er et netværk af servere, der er placeret forskellige strategiske steder rundt om i verden. Det fungerer som et forbindelsesled mellem brugeren og den server, din hjemmeside oprindeligt ligger på og hjælper meget med at forbedre sidens hastighed ved:
Vores projektledere anbefaler Cloudflare and StackPath (tidligere MaxCDN).
Tip nr. 11: Fjern ubrugte eller unødvendige plugins.
Med mange ting at vedligeholde på en hjemmeside kan deaktiverede eller ubrugte plugins ophobe sig og tynge websitet.
Kontrollér om alle de plugins, du har installeret i øjeblikket, er nogle du stadig bruger, og fjern de unødvendige for at reducere tyngden af din side.
Tip nr. 12: Opgradér til den seneste version.
Hvis du bruger et CMS (som WordPress eller Umbraco) eller en webshop (som Magento), kan bare dét at opgradere til den seneste version hjælpe med at forbedre sidens hastighed.
Det er selvfølgelig ikke altid tilfældet, at en opgradering er den bedste løsning - især for meget nye versionsopgraderinger, der stadig er ustabile.
Det er dog godt at holde dig på forkant med de seneste opdateringer til dit CMS, for at udnytte de nye funktioner og forbedringer de medfører, for ikke at nævne de nye sikkerhedsopdateringer, som vil bidrage til at beskytte websitet bedre.
Tip nr. 13: Opgradér til en større server.
Fjernelse, minifying og komprimering af ressourcer kan kun hjælpe til en vis grænse. Hvis din hjemmeside vokser, og du får mere trafik, kan det være på tide at opgradere eller opskalere til en større server. Du vil formentlig gerne konsultere din udvikler angående dette, da opskalering til en større server ikke er noget, der bør tages let på.
Marcelo, en af vores Magento-projektledere, siger, at sammenlægning af JS- og CSS-filer er et relativt simpelt hastighedsoptimerings-trick, som kan gøre en stor forskel for en sides indlæsningstid. Retfærdigvist bør det dog siges, at det er et relativt simpelt trick for en udvikler, men næppe for en ikke-teknisk person.
Her er nogle flere tips, som du kan gå over med dit udviklingsteam:
Tip nr. 14: Minify ressourcer (CSS, JS og HTML)
ved at “rydde op” i koden, dvs. fjerne ekstra mellemrum, kommaer eller andre unødvendige tegn såvel som formatering og ubrugt kode.
Tip nr. 15: Aktivér komprimering
af CSS, JS og HTML-filer, der er større end 150 bytes ved brug af gzip.
Tip nr. 16: Begræns antallet af 301 redirects
for at reducere yderligere ventetid ved HTTP-anmodninger.
AMP er et open source framework, som Google er spydspids for i sit forsøg på at skubbe i retning af bedre web-oplevelse på mobile enheder. AMP består af websider, der giver oplevelse af næsten øjeblikkelig indlæsning på mobile enheder, med komponenter hvor performance allerede er optimeret.
AMP er generelt lettere på grund af de snævre regler, som det håndhæver.
For eksempel tillader det ikke brugen af JavaScript og visse HTML-elementer. Selv om dette kan virke begrænsende for nogle hjemmesider, er det disse restriktioner, der ultimativt gør AMP hurtigere end ikke-AMP-sider.
Udover dette tilvejebringer AMP også en CDN-komponent. Som standard henter og cacher AMP-indholdet, så det kan benyttes hurtigere.
(For at lære mere om AMP kan du besøge den officielle hjemmeside).
På trods af de fordele AMP tilbyder er der ikke mange online virksomheder, der har taget det til sig.
Kun 12% af marketingfolk adspurgt af Unbounce hævder at have god forståelse af AMP, hvor resten kun har begrænset forståelse eller ingen viden om AMP overhovedet.
Spørgsmål, om hvorfor de ikke tager AMP til sig, afslører den gennemgående årsag som værende enten mangel på forståelse af teknologien eller mangel på udviklerkapacitet til at implementere den.
Hvis dette også gør sig gældende i din virksomhed, kan du begynde at tage AMP til dig ved at bruge værktøjer som Unbounce, som lader dig oprette AMP-destinationssider på en nem måde. Dette kan blidt introducere dig for ideen, og er en god måde for dig at opleve fordelene ved AMP ved selvsyn.
Men til en komplet implementering af AMP på hele din hjemmeside har du brug for et dedikeret udviklingshold til at hjælpe dig.
Vores in-house udviklingsteam har gennemført mange AMP-projekter. Faktisk var vores eget mobile site bygget med AMP, indtil vi skiftede over til et headless CMS setup.
PWA har eksisteret siden 2015, men for nylig er det dukket op som en ny trend i mobiloptimering, på grund af den hurtige oplevelse det leverer til brugere.
Det er dybest set en webapp, der er tilgængelig via en browser ligesom enhver anden hjemmeside, men fungerer som en mobilapp, hvad angår indlæsningshastighed, navigation og interaktioner.
PWA giver dig også mulighed for at gøre din hjemmeside "installérbar" ved at vise en “Tilføj til startskærm”-knap til brugere, når de besøger din hjemmeside og endda aktivere push-notification for at gen-engagere dine brugere. Disse er valgfrie muligheder, hvis du gerne vil have din hjemmeside til at være mere “app-agtig”.
Men bortset fra disse funktioner er hovedformålet med en PWA at forbedre hjemmesidens performance og tilvejebringe tilgængelighed uanset forbindelsens beskaffenhed. En PWA, der er tilføjet til startskærmen, kan tilgås på selv meget sløje netværk eller endda offline.
Du kan tjekke PWA stats for at lære mere om case-studier fra den virkelige verden vedrørende fordelene ved PWA.
Almindeligvis er dette, hvad der sker bag kulisserne, når en bruger besøger en af siderne på din hjemmeside: Brugeren foretager en "anmodning" ved enten at klikke på et link til din side eller direkte indtaste din sides URL i browseren. Anmodningen sendes til din webserver, som derefter opbygger en HTML-side ud af indholdet i din database og serverer da en HTML-side til browseren, hvor din bruger kan se og interagere med den.
Static Site Generatoren klargører HTML-siden, før en besøgende loader den (når de besøger siden i deres browser). Siden klargøres faktisk, når nyt indhold gemmes. Det gør, at siden loader lynhurtigt, når brugeren tilgår den, fordi serveren ikke skal bruge tid på at klargøre HTML-siden.
Der er mange site generatorer på markedet i dag, hvoraf de mest populære er Hugo, Jekyll, og Gatsby.
Vi vil fokusere på at tale om Gatsby, men du kan også tjekke disse andre muligheder for at lære mere.
Gatsby er en gratis og open source Static Site Generator bygget på React, et JavaScript-bibliotek til opbygning af brugergrænseflader i applikationer.
React er kendt for at bygge hurtige og effektive sites, men det er også kendt for at udgøre et problem for SEO.
Da det genererer JavaScript-indhold, kan Google og andre søgemaskiner på nettet ikke altid læse det egentlige indhold, som de ville kunne med en almindelig HTML-side. Husk på at tags som titel og tildels metabeskrivelse læses af crawlere, og har derfor indflydelse på din hjemmesides indeksering og rangering i søgeresultater.
Gatsby fremstår som det gode kompromis ved at give den samme performance-gevinst som React, men også ved at eliminere problemet med indeksering.
Grundlæggende bruger Gatsby React til at oprette “komponenter” (dvs. de byggesten der udgør sektionerne i en React-side) ud fra dine data, og opbygger derefter statiske HTML/CSS/JS-filer fra komponenterne, så din side bliver “læsbar” for crawlere.
Gatsby har kun eksisteret i omkring fire år, og alligevel er den kun lige begyndt at blive populær det seneste års tid.
Nu er det et nyt buzzword inden for webudvikling, fordi måden hjemmesider bygges på ved hjælp af Gatsby, gør dem lynende. Her er årsagen:
I sig selv har Gatsby ikke et interface til styring af indhold.
I stedet bygger det sider baseret på data trukket fra en anden kilde, hvor indholdet allerede er lagt ind og styret som f.eks. Content Management Systemer (CMS), produktinformationsstyrings-systemer (PIM), Markdown-filer, CSV, JSON, databaser, API'er og så videre.
Faktisk kan du i virkeligheden have dine data i en simpel Excel-fil og lægge den op som en hjemmeside ved hjælp af Gatsby.
Selvfølgelig er der konfigurationer, der skal sættes op, og den egentlige brugergrænseflade skal designes, men den grundlæggende idé er, at Gatsby kan trække data fra hvor som helst og hjælpe dig med hurtigt at levere det til dine brugere.
Da Gatsby i sig selv ikke har nogen nævneværdig “backend” eller et sted, hvor du kan tilføje og redigere dine data, kan du overveje at bruge et “headless” CMS til at udføre det job.
Helt essentielt fjerner et headless CMS frontend-laget (dvs. “hovedet”) og efterlader kun backend-teknologien (dermed ordet “headless”).
Dette står i kontrast til måden, et CMS normalt er sat op på, hvor systemet giver en platform til administration af dit indhold (dvs. backend) og tager sig af, hvordan indholdet vises til dine slutbrugere (dvs. frontend).
Når du vælger headless-metoden, bruger du sådan set bare CMS som et sted, hvor du administrerer og redigerer dit indhold, men udgivelsen sker via en anden tjeneste eller platform - i dette tilfælde site generatorer som Gatsby.
De fleste populære CMS, som WordPress og Umbraco, kan “konverteres” til headless så at sige, og bruges sammen med Gatsby ved at der udvikles et Application Programming Interface (API), der integrerer dets backend i Gatsby.
Dette “omdirigerer” udgivelsen af data, så i stedet for at blive leveret af CMS frontend-komponent, sendes det i stedet til Gatsby, som på magisk vis sørger for, at indholdet kan leveres på et øjeblik.
(Umbraco Heartcore er Umbracos headless version. Til WordPress er der plugins som dette, der hjælper med at konvertere det til et headless CMS).
Derudover er der også CMS-alternativer, der er udviklet som headless. De er bygget uden en frontend og er designet til let at kunne integreres med Static Site Generatorer og andre udgivere, uden den yderligere udvikling der ligger i at konvertere et traditionelt CMS til headless. Nogle eksempler er Contentful, Storyblok, Butter CMS og Contentstack.
Udover alle performancegevinsterne tilføjer Gatsby og/eller et headless CMS også et ekstra sikkerhedsniveau for dine data, fordi HTML-siderne på frontend er adskilt fra dine data i backend.
Hvis du er et omnichannel-brand, gør headless det også lettere at udgive til hvilke som helst platforme ved kun at bruge ét CMS til at levere indhold - Ikke kun til din hjemmeside men også til andre platforme, som f.eks. mobilapps, smartwatches og Internet of Things (IoT).
Den anden vej gør Gatsby det også lettere at offentliggøre data fra alle datakilder, du måtte have ved siden af dit CMS.
Mak, en af vores projektledere for Umbraco, havde kun gode ting at sige om hans erfaring med brug af Gatsby og headless Umbraco. “Den største fordel er, at du kan koncentrere din udviklingstid på vigtigere ting og ikke bekymre dig så meget om performance, fordi Gatsby tager sig af det for dig. Da Gatsby er bygget med React, er der også tonsvis af værktøjer og et omfattende bibliotek til rådighed for os udviklere at bruge af, samt en enorm support fra communitiet.”
Ja ja, Gatsby er fantastisk og så videre, men du spekulerer nok på, hvor meget udviklingstid det vil koste.
For hjemmesider bygget fra grunden har Mak bemærket, at projektets varighed ligner projekter bygget ved hjælp af traditionelt CMS. Forudsat naturligvis at din udvikler allerede har erfaring med at bruge React og/eller Gatsby og ikke behøver at lære systemet og teknologien at kende først.
Men når en eksisterende CMS-baseret hjemmeside skal omdannes til Gatsby, kommer mange faktorer i spil, som gør det svært at give et præcist tidsestimat.
“Det første, der skal overvejes, er, om CMS [klienten], der bruges i øjeblikket overhovedet kan vendes, for hvis ikke, så er frontenden det eneste vi kan bruge, og da udelukkende som reference. Det vil grundlæggende være som at starte fra bunden,” siger Mak. “En anden faktor er kompleksiteten af frontend-funktionerne. Alt afhænger dybest set af hver individuelle hjemmeside, og hvordan den er tilpasset.”
At tage headless + Gatsby-ruten er noget, som du vil få brug for et dedikeret udviklingshold til, og implementeringen er helt bestemt ikke noget, der kan gøres i et snuptag. Igen, alt afhængig af din hjemmeside, kan det sagtens vise sig at være et reelt udviklingsprojekt.
Alligevel er denne mulighed værd at overveje med alle de performance-gevinster, det kan medføre for din hjemmeside.
Som vi har nævnt flere gange, bør hastighedsoptimering ikke være en engangsforteelse.
Praksis, som at komprimere og optimere dine billeder eller at minimere ressourcer, skal udføres løbende, især hvis din hjemmeside opdateres ret ofte, for at sikre at din optimerede sideindlæsningstid ikke forringes over tid.
Den mest effektive måde at opretholde hastigheden på er at opstille et performancebudget.
Et performancebudget er et sæt måleparametre, hvor du vil have, at din hjemmeside konsekvent holder sig inde for en vis margin. Dette online værktøj giver dig mulighed for at beregne et performance-budget baseret på dit mål om en vis sideindlæsningstid på en bestemt forbindelse.
Hvis du f.eks. sætter et mål på 3 sekunders loadtid på en hurtig 3G-forbindelse, får du et budget på 600 KB.
Dette er den maksimale tyngde, du kan tildele til din side.
Det giver også en oversigt over almindeligt anvendte elementer og det tilsvarende antal kilobytes, du kan tildele dem. Du kan flytte rundt på disse tildelinger for at justere, hvilke elementer du vil tildele flest ressourcer.
Selvfølgelig vil et performancebudget kun fungere, når du følger det.
Når du vil føje et element til din side, der sandsynligvis vil resultere i, at du overskrider budgettet, kan du enten: a) fjerne et eksisterende element, for at gøre plads til det du vil tilføje, b) undlade at tilføje det nye element overhovedet eller c) justere dit performancebudget, men vær forberedt på eventuelle konsekvenser for din sidehastighed.
I sidste ende er et performancebudget stadig en rettesnor og ikke en fast regel.
Det tjener blot som en reference, men der kommer ingen god strategi ud af at afvise forbedringer af hjemmesiden, bare fordi de ikke passer ind i budgettet.
Hastighedsoptimering som praksis udvikler sig konstant. Mange nye faktorer vil uundgåeligt opstå i fremtiden, og selv brugeroplevelse og -forventning vil ikke altid være, som den er i dag. En god partner i webudvikling vil hjælpe dig med at holde dig på forkant med disse mange forandringer, og samtidig sørge for at du rent faktisk holder trit.
Hvis du lider under en langsom hjemmeside, eller bare vil sikre dig, at din indlæsningstid forbliver så hurtig, som den kan for dine brugere, så kontakt os, og vi vil med glæde sørge for en løsning til dig.
AUTHOR
Peter Skouhus
En dansk iværksætter, der ejer 1902 Software Development, et it-selskab på Filippinerne, hvor han har boet siden 1998. Peter har stor erfaring inden for IT-udvikling, strategisk it-ledelse og salg.