Suurin sisältöinen maali (LCP)

Suurimman sisällön latautumisnopeus mittaa aikaa sivun latautumisen alkamisesta siihen, kun näkyvissä olevan suurimman sisältöelementin renderöinti päättyy. Se on yksi Googlen Core Web Vitals -mittareista ja toimii mittarina havaitulle latausnopeudelle, koska sivu tuntuu latautuneelta, kun sen pääsisältö tulee näkyviin, eikä vasta, kun kaikki resurssit ovat latautuneet.

Mitattava elementti on tyypillisesti sankarikuva, videojuliste, suureen lohkoon lisätty taustakuva tai huomattavan kokoinen tekstilohko. Se, mikä elementti kelpaa, voi muuttua latauksen aikana sisällön renderöinnin myötä, ja lopullinen raportoitu arvo vastaa suurinta elementtiä siinä vaiheessa, kun käyttäjä on ensimmäisen kerran vuorovaikutuksessa sivuston kanssa tai sivu latautuu loppuun. Googlen julkaisema kynnysarvo käsittelee 2.5 sekuntia tai vähemmän hyvänä, mitattuna todellisten käyttökokemusten 75. persentiilillä, mikä tarkoittaa, että kohderyhmänä ei ole keskivertokävijä, vaan heistä hitaampi neljännes.

Huonojen pisteiden syyt voidaan jakaa muutamaan toistuvaan luokkaan. Hidas palvelimen vasteaika viivästyttää kaikkea latausta, joten korkea ensimmäisen tavun latausaika asettaa alarajan saavutettavalle tulokselle. Renderöintiä estävä CSS ja JavaScript dokumentin otsikossa estävät renderöinnin alkamisen, ennen kuin ne on ladattu ja käsitelty. Suurten, optimoimattomien kuvien siirto ja dekoodaus kestää kauemmin, erityisesti mobiiliyhteyksillä. Myöhässä löydetyt resurssit, kuten CSS:stä viitatut tai JavaScriptin injektoimat kuvat, alkavat latautua vasta sen jälkeen, kun selain olisi voinut aloittaa. Asiakaspuolen renderöinti yhdistää kaikki nämä, koska sisältöä ei voida piirtää ennen kuin paketti on ladattu ja suoritettu.

Korjauskeinot seuraavat suoraan ja ovat enimmäkseen vaatimatonta insinöörityötä. Sopivan kokoisten kuvien näyttäminen nykyaikaisissa muodoissa, joissa on selkeät mitat ja prioriteettivihjeet todennäköisesti suurimmalle elementille, korjaa yleisimmän syyn. Pääkuvan ja kriittisten fonttien esilataus mahdollistaa selaimen käynnistymisen aikaisemmin. Kriittisen CSS:n sisällyttäminen ja lopun lykkääminen poistaa renderöintiä estävän riippuvuuden. Palvelimen vasteajan parantaminen välimuistin ja sisällönjakeluverkon avulla nostaa kaiken muun vaatimustasoa. Palvelinpuolen renderöinti tai staattinen generointi sisältöpainotteisille sivuille välttää JavaScriptin odottamisen kokonaan.

Mittaus vaatii kenttä- ja laboratoriodatan erottamista toisistaan, koska ne vastaavat eri kysymyksiin. Kenttädata oikeilta käyttäjiltä heijastaa todellisia laite- ja verkko-olosuhteita, ja hakukoneiden sijoitusjärjestelmät käyttävät sitä, mutta se on aggregoitu tietyltä ajanjaksolta eikä selitä yksittäisiä syitä. Laboratoriotyökalut tuottavat toistettavissa olevaa diagnostiikkaa kontrolloiduissa olosuhteissa, minkä vuoksi ne ovat hyödyllisiä virheenkorjauksessa, mutta niiden tulokset voivat poiketa huomattavasti todellisten kävijöiden kokemuksista. Molempia tarvitaan: kenttädataa ongelman olemassaolon selvittämiseksi ja laboratoriotyökaluja ongelman syyn selvittämiseksi.

Käytännön varoituksena on, että mittaria voidaan parantaa tavoilla, jotka eivät paranna käyttökokemusta, ja kynnysarvon saavuttamiseksi paineen alla olevat tiimit tekevät joskus juuri niin. Pääkuvan lykkääminen, jotta tekstilohkosta tulee suurin elementti, päävisualisaation koon pienentäminen, jotta eri elementti kelpaa, tai sisällön piilottaminen mittauksen jälkeen kaikki siirtävät numeroa ilman, että sivu tuntuu nopeammalta. Koska mittari on pikemminkin vastine havaitulle latautumiselle kuin itse asialle, parannuksia tulisi verrata todellisen latausjärjestyksen filminauhaan, joka osoittaa, näkeekö kävijä merkityksellistä sisältöä nopeammin vai ainoastaan, täyttyikö mittarin vaatimukset.

Kaupallinen perustelu sen puuttumiselle ei perustu ensisijaisesti hakutulosten sijoitukseen, jossa nopeus on vain yksi signaali monien joukossa. Se perustuu hyvin dokumentoituun latausviiveen ja hylkäämisen väliseen suhteeseen, joka on selkein mobiiliyhteyksillä ja korkean aikomuksen sivuilla, joilla kävijät ovat jo päättäneet toimia. Käytännössä tämä tekee mittauksesta standardin osan verkkosuorituskyky työ, ja sen parannukset näkyvät usein konversiomittauksessa yhtä selvästi kuin mikä tahansa testattu muutos CRO-palvelu ohjelma, minkä vuoksi suorituskyky- ja optimointityöt on parasta suunnitella yhdessä eikä erillisinä osuuksina.