LCP forklaret: Sådan optimerer du den til SEO

LCP er en kritisk brugeroplevelsesmetrik og en Google-rangeringsfaktor. Når en bruger går ind på din side, er det ikke den samlede indlæsningstid, de er interesseret i. De vil vide, hvornår de kan se hovedindholdet og begynde at læse eller interagere. LCP måler netop det øjeblik: når det største indholdselement bliver synligt. Får du LCP rigtigt, føles din side hurtig. Får du den forkert, føles din side langsom, selv hvis de andre målinger er i orden.

Optimering af LCP kræver en tredelt tilgang: forbedring af serverens svartid (TTFB), fjernelse af render-blokerende ressourcer og optimering af billeder. Hver tilgang tackler forskellige flaskehalse i LCP. Kombinationen giver markante forbedringer.

Hvad LCP er, og hvordan den måles

Largest Contentful Paint (LCP) er renderingstiden for det største synlige indholdselement på din side. Det kan være et stort billede, en video, en overskrift eller et tekstafsnit. LCP måler fra det øjeblik, brugeren går ind på siden, og indtil elementet bliver synligt. Googles dokumentation om LCP giver detaljeret teknisk information og optimeringsstrategier.

LCP er ikke en binær bestået/ikke bestået-måling. Det er en kontinuerlig score. Google har fastlagt, at en LCP under 2,5 sekunder er »god«, at en LCP mellem 2,5-4 sekunder skal forbedres, og at en LCP over 4 sekunder er dårlig. Brugerne opfatter sider med LCP under 2 sekunder som meget hurtige. Sider med en LCP på 3-4 sekunder føles mærkbart langsommere. Sider med en LCP over 5 sekunder bliver ofte forladt.

LCP ændrer sig under sideindlæsningen, efterhånden som større indholdselementer dukker op. Hvis et stort billede indlæses ved 3-sekundersmærket, springer LCP fra 1 sekund til 3 sekunder. Det er vigtigt: du kan ikke bare optimere tidspunktet for den første visning. Du skal sikre, at alle store indholdselementer indlæses hurtigt.

Forståelse af Time to First Byte (TTFB)

Time to First Byte (TTFB) er tiden fra navigationens start, indtil serveren returnerer den første byte af HTML-dokumentet. TTFB sætter gulvet for LCP. Hvis TTFB er 2 sekunder, kan LCP ikke blive bedre end 2 sekunder, fordi browseren ikke engang har modtaget HTML'en endnu. Reduktion af TTFB er en forudsætning for at reducere LCP.

God TTFB er under 600 millisekunder. TTFB mellem 600-1800ms skal forbedres. TTFB over 1800ms er dårlig. Hvis din TTFB er langsom, så fokusér først på serveroptimering. Ingen mængde frontend-optimering kan opveje en langsom server.

Typiske årsager til langsom TTFB: ineffektiv backendkode, databaseforespørgsler eller overbelastning af serveren. Langsom hosting giver også høj TTFB. Delt hosting er ofte ekstremt langsom. Opgrader til VPS eller cloud-hosting for bedre ydelse. Brug et CDN til at reducere TTFB ved at levere indhold fra servere tæt på dine brugere.

PageSpeed Insights viser din TTFB i afsnittet »Serverens svartid«. Hvis TTFB er en flaskehals, bliver den fremhævet som en prioritet.

Identificering af det største indholdselement

LCP afhænger af, hvad det største indholdselement på din side er. På et blogindlæg kan det største element være et stort hovedbillede. På en produktside kan det være et produktfoto. På et nyhedssite kan det være en artikeloverskrift. At identificere LCP-elementet er første skridt til at optimere det.

Brug Chrome DevTools til at finde LCP-elementet. Åbn DevTools, gå til fanen Performance, start optagelsen og genindlæs siden. I optagelsen af ydelsen skal du lede efter markeringen »Largest Contentful Paint«. Hold musen over den for at se, hvilket element der udløste LCP. Når du kender elementet, optimerer du det.

LCP-elementet er ofte et billede. Billeder er store og indlæses, efter HTML'en er parset. Optimering af billedindlæsningen har den største effekt på LCP for de fleste sites. Billeder under folden kan indlæses lazy, hvilket fremskynder LCP for indholdet over folden.

Forudindlæsning af kritiske ressourcer

Forudindlæsning fortæller browseren at begynde at hente en ressource tidligt, før den er nødvendig for rendering. Forudindlæs dit LCP-billede eller andre kritiske ressourcer med `` tags i HTML'ens head. Det fortæller browseren »start med at hente denne ressource med det samme«.

Eksempel: `` fortæller browseren at begynde at hente hovedbilledet med det samme, uden at vente på, at CSS bliver parset. Det kan reducere LCP med 100-500ms afhængigt af ressourcens størrelse.

Vær forsigtig med forudindlæsning. For mange forudindlæste ressourcer spilder båndbredde. Forudindlæs kun de mest kritiske ressourcer (hovedbillede, kritiske skrifttyper, essentiel CSS). Googles optimeringsguide til Core Web Vitals forklarer bedste praksis for forudindlæsning.

Billedoptimering for LCP

Hvis dit LCP-element er et billede, så optimér billedets filstørrelse og indlæsningsstrategi. Tre taktikker:

Komprimér billedet. Brug værktøjer som TinyPNG, ImageOptim eller Squoosh til at komprimere uden at miste kvalitet. JPEG-komprimering kan reducere filstørrelsen 10-40x. Hver 100KB billedstørrelse tilføjer 100-200ms til LCP på 4G-net. Komprimering er en af de mest rentable investeringer.

Brug moderne formater. WebP er 25-35% mindre end JPEG. AVIF er endnu mindre. Brug HTML-elementet `` til at levere WebP til moderne browsere og JPEG til ældre browsere for bagudkompatibilitet. Valg af format alene kan forbedre LCP med 200-400ms.

Angiv billeddimensioner. At inkludere bredde- og højdeattributter forhindrer layoutforskydning og gør det muligt for browseren at reservere plads, før billedet indlæses. Det forbedrer ikke direkte LCP, men det forbedrer Cumulative Layout Shift (CLS), en anden Core Web Vitals-måling.

Render-blokerende CSS og JavaScript

Render-blokerende CSS forhindrer browseren i at rendere siden, før CSS er hentet og parset. Store CSS-filer forsinker renderingen. Minimér render-blokerende CSS ved at indlejre kritisk CSS og udskyde resten.

Kritisk CSS er den CSS, der er nødvendig for indhold over folden. Indlejr denne CSS i `