Core/Dash-ulottuvuus: Urls
Eristä ja korjaa Core Web Vitals -suorituskyvyn pullonkaulat tiettyjen Urls-osoitteiden perusteella
Trusted by market leaders
Ulottuvuus: Sivu & Navigaatio: URLs (u)
Elementtityyppi (LCP) -ulottuvuus (lcpet) luokittelee Largest Contentful Paint -solmun yhteen neljästä arkkitehtuuriluokasta: text, image, background-image tai video.
Vaikka Attribution Element -ulottuvuus osoittaa tarkan DOM-solmun, Elementtityyppi-ulottuvuus määrittää korkean tason teknisen strategiasi. LCP on neljän aikavälin summa: TTFB, Load Delay, Load Time ja Render Delay. Elementtityyppi kertoo, mikä näistä aikaväleistä vahingoittaa tulostasi, jolloin voit valita oikean optimointiprotokollan arvailematta.
Core Web Vitals -optimointi LCP-elementtityypin mukaan
Kun olet parantanut TTFB:tä, joka on riippumaton LCP-elementtityypistä, sinun on otettava erilainen lähestymistapa LCP:n optimointiin tarkastelemalla LCP-elementtiäsi.
1. Teksti (Text)
Kun CoreDash raportoi elementtityypiksi tekstin, staattisten verkkoresurssien kaistanleveys on harvoin pullonkaula. Teksti sijaitsee suoraan HTML-dokumentissa, mikä tarkoittaa, että sisältö on saatavilla välittömästi 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 täysin Critical Rendering Pathiin. Raskaat CSS-laskelmat tai synkroninen JavaScript <head>-osiossa estävät todennäköisesti selainta piirtämästä tekstiä. Tarkista lisäksi fonttien latausstrategiasi; jos et käytä font-display: swap- tai optional-asetusta, selain piilottaa tekstin keinotekoisesti (FOIT) odottaessaan fonttitiedoston latautumista.
2. Kuva (<img>)
Tämä tyyppi käynnistää täyden resurssiputken: löytäminen, lataus ja purku. Toisin kuin teksti, kuvan LCP on vahvasti riippuvainen Load Delaysta ja Load Timesta. Taistelet tässä fysiikkaa ja verkon viivettä vastaan, joten tavoitteenasi on tehdä resurssista kevyempi ja nopeammin löydettävä.
Optimointi vaatii tässä tiukkaa resurssien hallintaa. Varmista, että <img>-tagi on olemassa alkuperäisessä HTML-lähteessä (Server-Side Rendering) minimoidaksesi Load Delayn. Lisää fetchpriority="high" ja poista ehdottomasti kaikki loading="lazy"-attribuutit, sillä ne viivästyttävät selaimen pyyntöä. Lopuksi taklaa Load Time tarjoamalla seuraavan sukupolven formaatteja (AVIF/WebP) ja käyttämällä srcset-attribuuttia estääksesi mobiililaitteita lataamasta työpöytäkokoisia tiedostoja.
3. Taustakuva (Background Image)
Tämä luokitus viestii arkkitehtonisesta tehottomuudesta. Koska kuva määritellään CSS:ssä (esim. background-image: url(...)), selain ei voi löytää URL-osoitetta ennen kuin se on ladannut ja jäsennellyt tyylitiedostot kokonaan. Tämä aiheuttaa massiivisen Load Delayn, koska Preload Scanner on käytännössä sokea resurssille.
Ainoa vankka tekninen korjaus on refaktorointi. Siirrä visuaalinen resurssi CSS:stä standardiin HTML <img> -tagiin paljastaaksesi URL-osoitteen selaimelle välittömästi. Jos et voi refaktoroida merkkausta, sinun on käytettävä <link rel="preload"> -tagia dokumentin head-osiossa pakottaaksesi varhaisen löytämisen, vaikka tämä onkin 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 automaattinen toisto on päällä) piirtoajan. Tämä käyttäytyy samankaltaisesti kuin Image-tyyppi, mutta on usein raskaampi videoresurssien tiedostokoon vuoksi.
Käsittele tätä tiukasti kuvan optimointitehtävänä. Varmista, että HTML:ssä on kevyt poster-attribuutti, jotta selaimen ei tarvitse ladata videosegmenttejä ensimmäisen pikselin renderöimiseksi. Pakkaa poster-kuva yhtä aggressiivisesti kuin tavallinen LCP-kuva.
Työnkulku: LCP-ongelmien löytäminen LCP-elementtityypin perusteella
LCP-elementtityyppi ei ole staattinen eikä sama jokaiselle kävijälle. Se muuttuu usein käyttäjän laitteen perusteella paljastaen perustavanlaatuisia virheitä responsiivisessa suunnittelussa.
Käytä CoreDash Device Form Factor -suodatinta vertaillaksesi elementtityyppejä mobiilin ja desktopin välillä. Huomaat usein, että desktop-käyttäjillä on kuva-LCP (esim. Hero Banner), kun taas mobiilikäyttäjillä on teksti-LCP. Tämä vahvistaa, että mobiili-CSS-asettelusi työntää Hero Bannerin "below the fold" -alueelle tai skaalaa sitä niin merkittävästi, että tekstikappaleesta tulee "suurin" (Largest) elementti.
Jos optimoit hero-kuvaa parantaaksesi mobiili-LCP:tä tässä skenaariossa, 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ä huomiosi tekstin renderöinnin (fontit/CSS) optimointiin mobiilikäyttäjille.
