Hvordan diagnosticerer og forbedrer du en langsom LCP?

Question

IT Interview Practice · Accepted Answer

Start med at finde **hvad LCP-elementet er** og **hvorfor det er sent**. LCP bryder ned i fire underdele — ret den største. ## Diagnosticér: de fire LCP-underdele ```text [ TTFB ] ─▶ [ Resource load delay ] ─▶ [ Resource load time ] ─▶ [ Render delay ] server when fetch STARTS download the image paint it ``` Chrome DevTools og PageSpeed Insights viser, hvilken del der dominerer. Almindelige syndere: langsom server (TTFB), LCP-billedet opdaget for sent, eller et render-blocking script/CSS, der forsinker paint. ## Rettelser efter underdel - **Langsom TTFB** → cache HTML ved en CDN, brug SSG/ISR, gør origin/databasen hurtigere. - **Load delay (billede fundet for sent)** → preload det og hæv dets prioritet, så browseren henter det øjeblikkeligt i stedet for efter CSS/JS: ```html

``` - **Load time (billede for stort)** → server AVIF/WebP, dimensioner det rigtigt med `srcset`, komprimér. - **Render delay** → skær render-blocking CSS/JS væk; inline kritisk CSS; `defer` scripts. ## Faldgruber - Lazy-loading af LCP-billedet (eller at skjule det bag JS-hydration) — den #1 selvforskyldte LCP-skade. - Web-fonts, der blokerer LCP-teksten; brug `font-display: swap` og `preload` af fonten. - At optimere lab-LCP, mens reelle brugere på 4G forbliver langsomme — bekræft altid med field-data. ## Hvorfor det betyder noget LCP er den vigtigste indlæsnings-metric og en søgeranking-faktor. At kunne navngive de fire underdele og mappe hver til en konkret rettelse er præcis den strukturerede, evidensdrevne tilgang, interviewere leder efter.

Diagnosticér: de fire LCP-underdele

Rettelser efter underdel

Faldgruber

Hvorfor det betyder noget

Relaterede spørgsmål