Miten diagnosoit ja parannat hidasta LCP:tä?

Question

IT Interview Practice · Accepted Answer

Aloita selvittämällä, **mikä LCP-elementti on** ja **miksi se on myöhässä**. LCP jakautuu neljään alaosaan — korjaa suurin niistä. ## Diagnoosi: LCP:n neljä alaosaa ```text [ TTFB ] ─▶ [ Resurssin latausviive ] ─▶ [ Resurssin latausaika ] ─▶ [ Renderöintiviive ] palvelin milloin haku ALKAA lataa kuva maalaa se ``` Chrome DevTools ja PageSpeed Insights näyttävät, mikä viipale hallitsee. Yleisiä syyllisiä: hidas palvelin (TTFB), myöhään löydetty LCP-kuva, tai render-blocking-skripti/CSS, joka viivyttää maalausta. ## Korjaukset alaosittain - **Hidas TTFB** → välimuistita HTML CDN:ssä, käytä SSG/ISR:ää, nopeuta alkuperää/tietokantaa. - **Latausviive (kuva löytyy myöhään)** → preloadaa se ja nosta sen prioriteettia, jotta selain hakee sen välittömästi CSS:n/JS:n jälkeen sijaan: ```html

``` - **Latausaika (kuva liian iso)** → tarjoile AVIF/WebP, mitoita se oikein `srcset`illä, pakkaa. - **Renderöintiviive** → karsi render-blocking CSS/JS; sisällytä kriittinen CSS inline; `defer`-skriptit. ## Sudenkuopat - LCP-kuvan lazy-lataus (tai sen piilottaminen JS-hydraation taakse) — ykkönen itse aiheutettu LCP-haava. - Web-fontit tukkivat LCP-tekstin; käytä `font-display: swap`ia ja `preload`aa fontti. - Lab-LCP:n optimointi, kun todelliset 4G-käyttäjät pysyvät hitaina — vahvista aina kenttädatalla. ## Miksi se on tärkeää LCP on latauksen päämittari ja hakusijoituksen tekijä. Kyky nimetä neljä alaosaa ja kuvata kukin konkreettiseen korjaukseen on juuri se strukturoitu, näyttöön perustuva lähestymistapa, jota haastattelijat etsivät.

Diagnoosi: LCP:n neljä alaosaa

Korjaukset alaosittain

Sudenkuopat

Miksi se on tärkeää

Aiheeseen liittyvät kysymykset