Tag to hjemmesider, der sælger det samme. Åbn dem side om side. Den ene indlæses, før din finger har forladt pegefeltet. Den anden bruger fire sekunder, før et eneste element dukker op. Den forskel, du lige har oplevet, har et navn: indlæsningstid. Men det tal, du ser i et værktøj til at teste hastighed, er kun en del af billedet. Indlæsningstid er ikke én måling. Det er en samling af målinger, der hver fanger et forskelligt øjeblik i indlæsningen og fortæller dig noget forskelligt om, hvad en besøgende faktisk oplever. Denne artikel handler om, hvad indlæsningstid måler, hvilke tal der betyder noget, og hvad de fortæller dig, hvorfor mobil og computer er forskellige, og hvordan du læser data om din egen sides hastighed uden at skulle have en udvikler til at oversætte dem.
Indlæsningstid er den tid, der går mellem, at en besøgende beder om en side, og at siden kan bruges fuldt ud i deres browser. Grunden til, at den bliver målt på flere måder, er, at "indlæst" betyder forskellige ting, afhængigt af hvad du vil forstå. En side kan vise indhold, før den er færdig med at indlæse alle elementer. Den kan se ud til at kunne bruges, før den faktisk reagerer på klik. Når du ved, hvilken del af indlæsningen der er langsom, bliver data om hastighed nyttige i stedet for bare alarmerende. Hvis du vil vide, hvorfor det er vigtigt for din virksomhed og dine placeringer i søgning, kan du læse artiklen om hvorfor hastigheden på din hjemmeside er vigtig.
Hvad måler indlæsningstid egentlig?
Udtrykket "indlæsningstid" bliver brugt løst om ét tal, men i praksis er det en tidslinje med flere punkter. Hvert punkt svarer på et forskelligt spørgsmål om, hvad en besøgende oplever, mens siden indlæses.
Forløbet i indlæsningen
- Browseren sender en forespørgsel til din server
- Serveren behandler forespørgslen og sender et svar tilbage
- Browseren begynder at modtage og vise siden
- Tekst og billeder dukker op efterhånden, som de downloades
- Scripts kører, så siden kan bruges
- Det sidste element er færdigt med at indlæse
Forskellige tal fanger forskellige punkter i det forløb. En god score for indlæsningstid afhænger af, hvilke punkter du måler, ikke kun af én samlet tid.
Hvilke bestemte tal bruges til at måle indlæsningstid?
Time to First Byte (TTFB)
- Hvad det måler: hvor længe browseren venter, før den modtager den første byte data fra din server
- God score: under 800 millisekunder
- Hvorfor det er vigtigt: en langsom TTFB forsinker alt, der følger efter. Browseren kan ikke begynde at vise noget, før der kommer data. En langsom TTFB peger som regel på serverens ydeevne, kvaliteten af hosting eller forespørgsler til databasen, der ikke er optimeret
First Contentful Paint (FCP)
- Hvad det måler: det øjeblik, browseren viser det første stykke indhold, uanset om det er tekst, et billede eller en baggrund
- God score: under 1,8 sekunder
- Hvorfor det er vigtigt: det er her, den besøgende først ser, at der sker noget. En hurtig FCP viser, at siden reagerer, selv om den ikke er færdig med at indlæse
Largest Contentful Paint (LCP)
- Hvad det måler: hvornår det største synlige element (som regel et hovedbillede eller en stor overskrift) er helt indlæst
- God score: 2,5 sekunder eller hurtigere
- Hvorfor det er vigtigt: LCP er et af de tre Core Web Vitals, der bruges til at rangere i søgning. Det er det nærmeste, vi kommer på "hvornår føles siden brugbar", fordi det største element som regel er det vigtigste visuelle på siden
Time to Interactive (TTI)
- Hvad det måler: hvornår siden kan bruges fuldt ud og pålideligt reagerer på klik og tastatur
- God score: under 3,8 sekunder
- Hvorfor det er vigtigt: en side kan se indlæst ud, mens JavaScript stadig kører i baggrunden. TTI fanger forskellen mellem, at en side ser klar ud, og at den faktisk er klar
Total Blocking Time (TBT)
- Hvad det måler: den samlede tid, hvor hovedtråden er blokeret og ikke kan svare på input mellem FCP og TTI
- God score: under 200 millisekunder
- Hvorfor det er vigtigt: TBT viser, hvor meget tung behandling af JavaScript der forsinker, at siden kan bruges. En høj TBT betyder, at besøgende klikker på knapper, og der ikke sker noget, og det skader tilliden, selv om siden visuelt ser ud til at være indlæst
Fuld indlæsning af siden
- Hvad det måler: hvornår hver eneste ressource på siden, blandt andet billeder, scripts, skrifttyper og indlejret indhold fra tredjeparter, er helt indlæst
- God score: under 5 sekunder på mobil
- Hvorfor det er vigtigt: det er det tal, de fleste tænker på, når de siger "indlæsningstid". Det er nyttigt til at forstå sidens samlede vægt, men det betyder mindre for oplevelsen end LCP og TTI, fordi besøgende typisk begynder at bruge en side, længe før hvert element er færdigt med at indlæse
Hvorfor er indlæsningstid på mobil anderledes end på computer?
Mobil og computer giver forskellige scores for indlæsningstid for den samme side, selv når indholdet er det samme.
Grundene til, at mobil konsekvent er langsommere
- Forbindelser på mobil er i gennemsnit langsommere end fast bredbånd, selv på 4G- og 5G-net
- Processorer i mobiler er svagere end CPU'er i computere, så JavaScript kører langsommere
- Browsere på mobil har mindre hukommelse til rådighed, og det begrænser, hvor meget de kan gemme mellem sider
- Forholdene på nettet svinger mere på mobil og giver ujævn ydeevne fra besøg til besøg
Hvorfor score på mobil vejer tungere
- Søgemaskiner bruger mobile-first indexing, og det betyder, at de crawler og rangerer sider ud fra mobilversionen
- Score for Core Web Vitals på mobil vejer tungere i rangeringen end score på computer
- Mobil står for størstedelen af trafikken på nettet i hele verden, så hastighed på mobil påvirker den største del af dine besøgende
Kør altid separate tests på mobil og computer. En side, der får en god score på computer, kan stadig have alvorlige problemer på mobil, og det er på mobil, effekten på placeringer er størst.
Hvad giver lang indlæsningstid?
Store billeder, der ikke er komprimeret
- Den mest almindelige årsag til tunge sider og lang indlæsningstid
- Et foto, der er uploadet direkte fra en telefon, kan være 4 til 8 megabyte
- Det samme billede, ordentligt komprimeret, kan være under 100 kilobyte uden forskel i kvaliteten, man kan se
- Hvert billede, der ikke er komprimeret, lægger sekunder til FCP og LCP
Scripts og stilark, der blokerer visningen
- Browsere sætter visningen på pause, når de møder JavaScript- eller CSS-filer, de skal behandle, før de kan fortsætte
- Scripts, der indlæses i dokumentets head, forhindrer siden i at vise noget, til de er færdige
- Hvis du udskyder scripts, der ikke er afgørende, flytter du dem væk fra den kritiske sti og gør FCP og LCP hurtigere
Langsomt svar fra serveren (høj TTFB)
- Hver indlæsning af en side begynder med en forespørgsel til serveren. Hvis serveren er langsom, bliver alt efter den forsinket
- Delt hosting deler CPU og hukommelse mellem mange sider og giver uforudsigelige svartider
- Databaser, der ikke er optimeret, og rendering på serveren uden caching er almindelige bidragydere
For mange scripts fra tredjeparter
- Chatwidgets, sporingspixels og værktøjer til analytics giver hver ekstra forbindelser udadtil
- Hvis en ekstern server svarer langsomt, bliver din side holdt og venter på den
- Scripts fra tredjeparter kan bidrage meget til TBT, fordi de lægger tid til kørsel af JavaScript
Ingen caching
- Uden caching udløser hvert besøg, at serveren bygger siden helt forfra
- Med caching indlæser besøgende, der kommer igen, en gemt version, og det skærer serverens svartid markant ned
- Caching i browseren gør også, at besøgende, der kommer igen, kan springe over at downloade filer, de allerede har indlæst
Hvordan måler du din egen indlæsningstid?
Hvad værktøjer til at teste hastighed måler
- Værktøjer til at teste hastighed simulerer indlæsningen af en side fra et fast sted og en fast forbindelse og giver point for hvert tal ud fra standardgrænser
- De kaldes resultater fra laboratorium: kontrollerede tests, der køres under ens forhold
- Resultater fra laboratorium er nyttige til at finde bestemte problemer, men fanger ikke, hvordan rigtige besøgende på forskellige forbindelser og enheder faktisk oplever din side
Data fra laboratorium eller fra felten
- Data fra laboratorium: simulerede tests i et kontrolleret miljø. Hurtige at køre og gode til at isolere bestemte problemer
- Feltdata: rigtige målinger fra faktiske besøgende på din side, samlet over tid. Det er dem, søgemaskiner bruger til at give point for Core Web Vitals
- En side kan få en god score i en test i laboratorium, men en dårlig i feltdata, hvis forholdene i virkeligheden, langsommere enheder, svagere forbindelser eller lang afstand til din server, giver andre resultater for de faktiske besøgende
Hvad du skal kigge efter, når du læser en rapport om hastighed
- Tjek LCP først: det er det vigtigste tal både for besøgendes oplevelse og for placeringer i søgning
- Se på TTFB for at finde ud af, om problemet ligger hos serveren eller i det, besøgende ser
- Tjek TBT for at finde ud af, om JavaScript blokerer for, at siden kan bruges
- Kør separate tests for mobil og computer
- Sammenlign dine point med de sider, der ligger over dig på dine søgeord, ikke kun med abstrakte mål
Du kan læse en gennemgang af grænserne for Core Web Vitals og af, hvordan søgemaskiner giver point til sider ud fra dem, i artiklen om hvad Core Web Vitals er.
Sådan håndterer WEMASY indlæsningstid
WEMASY's hjemmesidebygger er lavet til at holde indlæsningstiden kort uden teknisk opsætning. Billeder, der uploades gennem platformen, bliver automatisk komprimeret og ændret i størrelse, før de vises. Hostinginfrastruktur er med i alle planer, så sider ikke bliver sat i delte miljøer med uforudsigelige svartider. Caching er slået til som standard, og sider, der er bygget i WEMASY, er opbygget, så ressourcer, der blokerer visningen, holdes på et minimum.
Point for Core Web Vitals, blandt andet LCP, INP og CLS, kan du se direkte i WEMASY's dashboard med feltdata fra rigtige besøgende. Det betyder, at du kan tjekke, hvordan dine sider klarer sig i forhold til de grænser, der betyder noget for placeringer i søgning, uden at køre eksterne tests.
Se, hvad der er med, hos WEMASY hjemmesidebygger, eller se planerne på prissiden.
Ofte stillede spørgsmål
Hvad er en god indlæsningstid?
For Core Web Vitals er den vigtigste grænse Largest Contentful Paint under 2,5 sekunder. I praksis dækker det de fleste situationer at sigte efter fuld brugbarhed inden for tre sekunder på en mobilforbindelse. Fuld indlæsning af siden på under fem sekunder på mobil er en fornuftig standard for de fleste små virksomheders hjemmesider. Med WEMASY's hjemmesidebygger kan du sætte det op direkte på din hjemmeside.
Hvad er forskellen på indlæsningstid og Core Web Vitals?
Indlæsningstid er hele rækken af målinger fra den første forespørgsel til serveren til det sidste element, der indlæses. Core Web Vitals er tre bestemte tal i den række: Largest Contentful Paint, Interaction to Next Paint og Cumulative Layout Shift, som søgemaskiner bruger som signaler om placering. Core Web Vitals er en delmængde af målingerne af indlæsningstid, målrettet de dele af indlæsningen, der betyder mest for de besøgende.
Hvorfor er min indlæsningstid forskellig på mobil og computer?
Mobil og computer giver forskellige scores, fordi mobile enheder har langsommere processorer, bruger forbindelser, der svinger, og har mindre hukommelse end computere. En side, der indlæses på to sekunder på en computer med bredbånd, kan bruge fire sekunder eller mere på en mobil på et gennemsnitligt mobilnet. Søgemaskiner giver point for ydeevne på mobil for sig og lader den veje tungere, fordi størstedelen af trafikken på nettet kommer fra mobile enheder.
Hvad er forskellen på data fra laboratorium og feltdata i tests af hastighed?
Data fra laboratorium kommer fra en simuleret test, der køres under kontrollerede forhold fra et fast sted og en fast enhed. Feltdata kommer fra rigtige besøgende på din side, målt på deres faktiske enheder, steder og forbindelser. Søgemaskiner bruger feltdata til at give point for Core Web Vitals, ikke resultater fra laboratorium. En side kan se hurtig ud i en test i laboratorium, men få dårlige point i feltdata, hvis rigtige besøgende har langsommere forbindelser eller enheder, eller ligger langt fra din server.
Hvad betyder Time to First Byte?
Time to First Byte (TTFB) er den tid, der går mellem, at browseren sender en forespørgsel til din server, og at den får den første byte data tilbage. Det er et mål for serverens svarhastighed. En langsom TTFB forsinker alle de følgende trin i indlæsningen, fordi browseren ikke kan begynde at vise noget, før den begynder at modtage data. En TTFB over 800 millisekunder peger som regel på problemer med serverens ydeevne, langsomme hostingmiljøer eller behandling i backend, der ikke er optimeret.
Påvirker indlæsningstid placeringerne i søgning?
Ja. Søgemaskiner bruger Core Web Vitals, som er hentet fra målinger af indlæsningstid, som signaler om placering. Largest Contentful Paint, Interaction to Next Paint og Cumulative Layout Shift får point ud fra data fra rigtige besøgende og bruges til at vurdere sideoplevelsen. Sider, der får point i det gode område, har en fordel i rangeringen frem for sider med dårlige point, især når sider, der konkurrerer, har samme kvalitet af indholdet.