Hoe diagnosticeer en verbeter je een trage LCP?

Question

IT Interview Practice · Accepted Answer

Begin met uitvinden **wat het LCP-element is** en **waarom het laat is**. LCP valt uiteen in vier subdelen — fix het grootste. ## Diagnose: de vier LCP-subdelen ```text [ TTFB ] ─▶ [ Resource load delay ] ─▶ [ Resource load time ] ─▶ [ Render delay ] server wanneer fetch START download de afbeelding schilder het ``` Chrome DevTools en PageSpeed Insights tonen welk deel domineert. Veelvoorkomende boosdoeners: trage server (TTFB), de LCP-afbeelding die laat wordt ontdekt, of een render-blocking script/CSS die de paint vertraagt. ## Fixes per subdeel - **Trage TTFB** → cache HTML op een CDN, gebruik SSG/ISR, versnel de origin/database. - **Load delay (afbeelding laat gevonden)** → preload hem en verhoog zijn prioriteit zodat de browser hem onmiddellijk ophaalt in plaats van na CSS/JS: ```html

``` - **Load time (afbeelding te groot)** → serveer AVIF/WebP, dimensioneer hem juist met `srcset`, comprimeer. - **Render delay** → snijd render-blocking CSS/JS weg; inline kritieke CSS; `defer` scripts. ## Valkuilen - De LCP-afbeelding lazy-loaden (of verbergen achter JS-hydratie) — de #1 zelf-toegebrachte LCP-wond. - Web fonts die de LCP-tekst blokkeren; gebruik `font-display: swap` en `preload` het font. - Lab-LCP optimaliseren terwijl echte gebruikers op 4G traag blijven — bevestig altijd met field-data. ## Waarom het belangrijk is LCP is de belangrijkste laadmetric en een factor voor search-ranking. De vier subdelen kunnen benoemen en elk aan een concrete fix koppelen is precies de gestructureerde, bewijs-gedreven aanpak waar interviewers naar zoeken.

Diagnose: de vier LCP-subdelen

Fixes per subdeel

Valkuilen

Waarom het belangrijk is

Gerelateerde vragen