CoreDash-ulottuvuus: Elementin tyyppi (LCP)
Korjaa Largest Contentful Paint suodattamalla liikennettä arkkitehtonisen elementin tyypin perusteella.
Trusted by market leaders · Client results
Ulottuvuus: Resurssi: Elementin tyyppi LCP (lcpet)
Elementin tyyppi (LCP) -ulottuvuus (lcpet) luokittelee Largest Contentful Paint -solmun yhteen neljästä arkkitehtonisesta luokasta: text, image, background-image tai video.
Vaikka Attribution Element -ulottuvuus osoittaa tarkan DOM-solmun, elementin tyyppi -ulottuvuus sanelee korkean tason suunnittelustrategiasi. LCP on neljän aikavälin summa: TTFB, Load Delay, Load Time ja Render Delay. Elementin tyyppi kertoo, mikä näistä aikaväleistä heikentää pisteitäsi, jolloin voit valita oikean optimointiprotokollan arvailematta.
Core Web Vitals -arvojen optimointi LCP-elementin tyypin mukaan
Parannettuasi TTFB-arvoa, joka on riippumaton LCP-elementin tyypistä, sinun tulisi omaksua erilainen lähestymistapa LCP-arvon optimointiin tarkastelemalla LCP-elementin tyyppiä.
1. Teksti
Kun CoreDash raportoi elementin tyypiksi tekstin, staattisten verkkoresurssien kaistanleveys on harvoin pullonkaula. Teksti sijaitsee suoraan HTML-dokumentissa, mikä tarkoittaa, että sisältö on saatavilla heti palvelimen alkuperäisen vastauksen (TTFB) jälkeen. Jos LCP on tässä hidas, ongelma on lähes yksinomaan Render Delay.
Korjataksesi tämän keskity kokonaan kriittiseen renderöintipolkuun (Critical Rendering Path). Raskaat CSS-laskennat tai synkroninen JavaScript <head>-osiossa todennäköisesti estävät selainta piirtämästä tekstiä. Tarkista lisäksi fonttien latausstrategiasi; jos et käytä font-display: swap- tai optional -määritettä, selain piilottaa tekstin keinotekoisesti (FOIT) odottaessaan fonttitiedoston latautumista.
2. Kuva (<img>)
Tämä tyyppi käynnistää koko resurssiputken: löytäminen, lataaminen ja purkaminen. Toisin kuin teksti, kuvan LCP on vahvasti riippuvainen Load Delay- ja Load Time -viiveistä. Tässä taistelet fysiikkaa ja verkon viiveitä vastaan, joten tavoitteenasi on tehdä resurssista kevyempi ja nopeammin löydettävä.
Optimointi tässä vaatii tiukkaa resurssien hallintaa. Varmista, että <img>-tunniste on olemassa alkuperäisessä HTML-lähdekoodissa (Server-Side Rendering) minimoidaksesi Load Delay -viiveen. Lisää fetchpriority="high" ja poista ehdottomasti kaikki loading="lazy" -määritteet, sillä ne viivästyttävät selaimen pyyntöä. Taklaa lopuksi Load Time -viive tarjoamalla seuraavan sukupolven formaatteja (AVIF/WebP) ja käyttämällä srcset-määritettä estääksesi mobiililaitteita lataamasta työpöytäkokoisia tiedostoja.
3. Taustakuva
Tämä luokittelu on merkki arkkitehtonisesta tehottomuudesta. Koska kuva on määritelty CSS:ssä (esim. background-image: url(...)), selain ei voi löytää URL-osoitetta ennen kuin se on täysin ladannut ja jäsentänyt tyylitiedostosi. Tämä luo massiivisen Load Delay -viiveen, koska Preload Scanner on käytännössä sokea tälle resurssille.
Ainoa kestävä tekninen korjaus on refaktorointi. Siirrä visuaalinen resurssi CSS:stä standardiin HTML:n <img>-tunnisteeseen paljastaaksesi URL-osoitteen selaimelle välittömästi. Jos et voi refaktoroida merkkausta, sinun on käytettävä <link rel="preload"> -tunnistetta dokumentin head-osiossa pakottaaksesi varhaisen löytämisen, vaikka tämä on usein ylläpidollinen taakka verrattuna natiivin kuvaelementin käyttöön.
4. Video
Kun LCP-elementti on video, selain mittaa poster-kuvan tai ensimmäisen ruudun (jos automaattinen toisto on päällä) piirtoajan. Tämä käyttäytyy samankaltaisesti kuin kuvatyyppi, mutta on usein raskaampi videoresurssien tiedostokoon vuoksi.
Käsittele tätä tiukasti kuvan optimointitehtävänä. Varmista, että HTML-koodissa on kevyt poster-määrite, jotta selaimen ei tarvitse ladata videosegmenttejä ensimmäisen pikselin renderöimiseksi. Pakkaa poster-kuva yhtä aggressiivisesti kuin pakkaisit tavallisen LCP-kuvan.
Työnkulku: LCP-ongelmien löytäminen LCP-elementin tyypin perusteella
LCP-elementin tyyppi ei ole staattinen eikä sama jokaiselle vierailijalle. Se muuttuu usein käyttäjän laitteen perusteella, mikä paljastaa perustavanlaatuisia puutteita responsiivisessa suunnittelussa.
Käytä CoreDashin Device Form Factor -suodatinta vertaillaksesi elementtien tyyppejä mobiilin ja työpöydän välillä. Huomaat usein, että työpöytäkäyttäjät saavat LCP-kuvan (esim. Hero Banner), kun taas mobiilikäyttäjät saavat LCP-tekstin. Tämä vahvistaa, että mobiililaitteiden CSS-asettelu työntää Hero Bannerin taitteen alapuolelle tai skaalaa sen niin merkittävästi alaspäin, että tekstikappaleesta tulee "suurin" elementti.
Jos tässä skenaariossa optimoit hero-kuvaa parantaaksesi mobiilin LCP-arvoa, tuhlaat vaivaa. Selain ei edes laske kuvaa mukaan. Sinun on joko säädettävä asettelua tuodaksesi kuvan takaisin ensisijaiseen näkymään tai siirrettävä fokuksesi tekstin renderöinnin (fontit/CSS) optimointiin mobiilikäyttäjille.
