Sådan optimerer du hjemmesidens hastighed

Udgivet: July 17, 2019
Senest opdateret: March 15, 2023

Sådan påvirker hjemmesidens hastighed din virksomhed

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 påvirker din placering på søgeresultater

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.

Hastighed påvirker brugeroplevelsen og konverteringer

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.

Hastighed har indflydelse på, hvor meget du betaler for annoncer

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”.

Hastighed påvirker dine driftsomkostninger

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.

Hastighed påvirker din hjemmesides indeksering

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.

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:

  • Ældre brugere er gerne mere afslappede og oplever flere websites som hurtige, uanset deres faktiske hastighed. Omvendt er yngre brugere (18-24 år) mere krævende angående hurtige indlæsningstider.
  • Når brugerne er anspændte eller har travlt, er de tilbøjelige til at opleve websites som langsommere. Når de er rolige og afslappede, oplever de hastigheden på websitet som værende hurtigere.
  • Oplevelsen afhænger også af situationen. For brugere, der er på farten, opleves websites som værende langsommere, men for brugere, der sidder stille eller er hjemme, opleves websites som værende hurtigere.

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.

Parametre at måle hastighed på

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:

Optimering af mobil hastighed

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.

Gatsby

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:

  1. Gatsby præ-fabrikerer HTML-sider og leverer dem på én gang, når en bruger laver en anmodning, ved at springe den del over hvor webserveren skal læse databasen og først derefter opbygge HTML'en ud fra de forhåndenværende data. Tænk på det som en færdiglavet fastfood ordre med det samme, i forhold til et restaurantmåltid der skal tilberedes fra bunden – bortset fra at med Gatsby er det den samme “mad”- bare serveret hurtigere.
  2. Det er ikke kun den første sideindlæsning, der er hurtig, det er også den efterfølgende navigation. Når du har besøgt en side på en Gatsby-hjemmeside, begynder den også at forudindlæse de andre sider i baggrunden, hvilket gør den overordnede brugeroplevelse mere smooth, fordi skiftet fra side til side sker lynhurtigt.
  3. Performance er indbygget i Gatsby-frameworket. Faktisk er de fleste af de små tips, vi har givet ovenfor, allerede gjort automatisk af Gatsby. Hør det fra Gatsby's grundlægger Kyle Mathews selv, som sagde, at han designede Gatsby "med den målsætning at man, ved at bruge det, vil få virkelig, virkelig svært ved at bygge en langsom hjemmeside."

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.

Brug af headless CMS med Gatsby

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.

AUTHOR

Peter Skouhus

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.