Cum diagnostichezi și îmbunătățești un LCP lent?

Question

IT Interview Practice · Accepted Answer

Începe prin a găsi **care este elementul LCP** și **de ce este întârziat**. LCP se descompune în patru sub-părți — corectează-o pe cea mai mare. ## Diagnostic: cele patru sub-părți ale LCP ```text [ TTFB ] ─▶ [ Resource load delay ] ─▶ [ Resource load time ] ─▶ [ Render delay ] server when fetch STARTS download the image paint it ``` Chrome DevTools și PageSpeed Insights arată care felie domină. Vinovați frecvenți: server lent (TTFB), imaginea LCP descoperită târziu sau un script/CSS render-blocking care întârzie paint-ul. ## Corecturi pe sub-părți - **TTFB lent** → cache pentru HTML la un CDN, folosește SSG/ISR, accelerează origin-ul/baza de date. - **Load delay (imaginea găsită târziu)** → fă-i preload și ridică-i prioritatea, ca browserul să o descarce imediat, nu după CSS/JS: ```html

``` - **Load time (imaginea prea mare)** → servește AVIF/WebP, dimensioneaz-o corect cu `srcset`, comprimă. - **Render delay** → taie CSS/JS render-blocking; include inline CSS-ul critic; `defer` la scripturi. ## Capcane - Lazy-loading la imaginea LCP (sau ascunderea ei în spatele hidratării JS) — rana LCP numărul 1, autoprovocată. - Fonturi web care blochează textul LCP; folosește `font-display: swap` și `preload` la font. - Optimizarea LCP-ului de laborator în timp ce utilizatorii reali pe 4G rămân lenți — confirmă întotdeauna cu date de teren. ## De ce contează LCP este metrica de încărcare principală și un factor de ranking în căutare. Capacitatea de a numi cele patru sub-părți și de a mapa fiecare la o corectură concretă este exact abordarea structurată, bazată pe dovezi, pe care o caută intervievatorii.

Diagnostic: cele patru sub-părți ale LCP

Corecturi pe sub-părți

Capcane

De ce contează

Întrebări conexe