CoreDash-ulottuvuus: Elementin tyyppi (LCP)
Korjaa Largest Contentful Paint suodattamalla liikennettä arkkitehtonisen elementin tyypin perusteella.
Trusted by market leaders · Client results
Ulottuvuus: Resurssi: Element Type LCP (lcpet)
Element Type (LCP) -ulottuvuus (lcpet) luokittelee Largest Contentful Paint -solmun yhteen neljästä arkkitehtonisesta luokasta: text, image, background-image tai video.
Vaikka Attribuutioelementti (Attribution Element) -ulottuvuus paikantaa tarkan DOM-solmun, Element Type -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ää tulostasi, mikä mahdollistaa oikean optimointiprotokollan valitsemisen ilman arvailua.
Core Web Vitals -metriikoiden optimointi LCP-elementin tyypin mukaan
Kun olet parantanut TTFB-arvoa, joka on riippumaton LCP-elementin tyypistä, sinun on otettava erilainen lähestymistapa LCP:n optimointiin tarkastelemalla LCP-elementtisi tyyppiä.
1. Teksti
Kun CoreDash ilmoittaa elementin tyypiksi tekstin, staattisten verkkoresurssien kaistanleveys on harvoin pullonkaula. Teksti sijaitsee suoraan HTML-dokumentissa, mikä tarkoittaa, että sisältö on saatavilla heti alkuperäisen palvelinvastauksen (TTFB) jälkeen. Jos LCP on tässä hidas, ongelma on lähes yksinomaan Render Delay.
Korjataksesi tämän, keskity täysin 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ämisen, lataamisen ja purkamisen. Toisin kuin teksti, kuva-LCP on vahvasti riippuvainen Load Delay- ja Load Time -viiveistä. Taistelet tässä fysiikkaa ja verkon viivettä vastaan, joten tavoitteesi on tehdä resurssista kevyempi ja nopeammin löydettävä.
Tämän optimointi vaatii tiukkaa resurssien hallintaa. Varmista, että <img>-tunniste on olemassa alkuperäisessä HTML-lähdekoodissa (Server-Side Rendering) Load Delay -viiveen minimoimiseksi. Lisää fetchpriority="high" ja poista ehdottomasti kaikki loading="lazy"-määritteet, sillä ne viivästyttävät selaimen pyyntöä. Taklaa lopuksi Load Time tarjoamalla uuden 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 merkintäkieltä, sinun on käytettävä <link rel="preload"> -tunnistetta dokumentin head-osiossa pakottaaksesi varhaisen löytämisen, vaikka tämä on usein ylläpitotaakka verrattuna natiivin kuvaelementin käyttöön.
4. Video
Kun LCP-elementti on video, selain mittaa poster-kuvan tai ensimmäisen ruudun (jos automaattitoisto on käytössä) piirtoajan. Tämä käyttäytyy samalla tavalla kuin kuva-tyyppi, mutta on usein raskaampi videoresurssien tiedostokoon vuoksi.
Käsittele tätä tiukasti kuvan optimointitehtävänä. Varmista, että kevyt poster-määrite on läsnä HTML:ssä, jotta selaimen ei tarvitse ladata videosegmenttejä renderöidäkseen ensimmäisen pikselin. Pakkaa poster-kuva yhtä aggressiivisesti kuin tekisit tavalliselle LCP-kuvalle.
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 mukaan paljastaen perustavanlaatuisia puutteita responsiivisessa suunnittelussa.
Käytä CoreDash Device Form Factor -suodatinta vertaillaksesi elementtityyppejä mobiilin ja työpöydän välillä. Huomaat usein, että työpöytäkäyttäjät saavat kuva-LCP:n (esim. Hero-banneri), kun taas mobiilikäyttäjät saavat teksti-LCP:n. Tämä vahvistaa, että mobiili CSS-asettelusi työntää Hero-bannerin sivun taitoksen alapuolelle tai skaalaa sitä alaspäin niin merkittävästi, että tekstikappaleesta tulee "suurin" (Largest) elementti.
Jos optimoit hero-kuvaa parantaaksesi mobiili-LCP:tä tässä skenaariossa, haaskaat vaivaasi. Selain ei edes laske kuvaa mukaan. Sinun on joko säädettävä asettelua tuodaksesi kuvan takaisin ensisijaiseen näkymään tai siirrettävä huomiosi tekstin renderöinnin (fontit/CSS) optimointiin mobiilikäyttäjille.
