Siirry sisältöön
SilktideOhje

Sivunopeus ja Core Web Vitals

Sivunopeus tarkoittaa nykyaikaisessa hakukoneoptimoinnissa sitä, että sivut tuntuvat nopeilta: pääsisältö näkyy nopeasti, asettelu pysyy vakaana ja vuorovaikutukset reagoivat ilman viivettä. Googlen julkinen nimi kolmelle tätä kokemusta kuvaavalle kenttämittarille on : Largest Contentful Paint (), Interaction to Next Paint () ja Cumulative Layout Shift ().

Oletetaan tällä sivulla, että Fernwoodin hinnoittelusivun, vertailusivujen ja tärkeimpien oppaiden on saavutettava mobiilissa hyväksi määritetyt kynnysarvot – siellä, missä suurin osa uusista kävijöistä ja monet avustajien ohjaamat klikkaukset saapuvat.

Tämä tekniikka ei ole tarkoituksellisesti täydellinen tekninen käsikirja. web.dev tarjoaa jo syvälliset toimintaohjeet. Seuraavassa on päätöksentekokehys: mitä mittarit tarkoittavat, kuinka paljon niillä on merkitystä, miten priorisoida Silktiden avulla ja mistä kehittäjät löytävät korjausohjeet.

Miksi tämä toimii (ja kuinka paljon)

Kaksi yleisöä välittää asiasta:

  • Kävijät. Hidas LCP ja nykivä CLS saavat kävijät poistumaan ennen kuin he näkevät vastauksen tai toimintakehotuksen. Tämä on konversio-ongelma, vaikka sijoitukset olisivat kunnossa.
  • Haku. Google ilmoittaa, että Core Web Vitals -mittareita käytetään sijoitusjärjestelmissä osana sivukokemusta, ja suosittelee hyviä mittariarvoja hakumenestyksen saavuttamiseksi (Understanding Core Web Vitals and Google search results; Understanding page experience). Google kertoo myös, että haku pyrkii edelleen näyttämään osuvinta sisältöä, vaikka sivukokemus olisi heikko. Mittarit ovat siis todellinen signaali, eivät taianomainen sijoitusvipu. Pidä niitä perusvaatimuksena ja tasavahvojen sivujen erottavana tekijänä, ei vastaus ensin -sisällön tai auktoriteetin korvikkeena.

Erityisesti AEO:n kannalta: nopea sivu ei saa avustajaa siteeraamaan sinua. Hidas, asettelua siirtelevä sivu menettää silti näiden sitaattien ohjaamat ihmiset – ja nopeutta heikentävä raskas asiakaspuolen renderöinti heikentää usein myös ilman JavaScriptiä luettavaa sisältöä.

Kolme tärkeää mittaria

Alla olevat kynnysarvot ovat Googlen hyvän tason tavoitteita, jotka arvioidaan todellisilta käyttäjiltä noin 75. persentiilissä (kenttädata). Laboratoriotyökalut diagnosoivat; kenttädata on se, minkä perusteella haku arvioi.

MittariMitä se mittaaHyvä
LCPMilloin pääsisältö tulee näkyviin≤ 2,5 s
INPKuinka nopeasti sivu reagoi klikkauksiin/koskettamisiin≤ 200 ms
CLSKuinka paljon asettelu hyppii latauksen aikana≤ 0,1

Lisätiedot ja vianmääritysoppaat: web.dev Vitals, Optimize LCP, Optimize INP, Optimize CLS.

Ongelman ratkaiseminen (Fernwoodin toimintajärjestys)

1. Valitse tärkeät sivut

Älä yritä ratkaista kaikkea kerralla. Aloita näistä:

  • Paljon liikennettä saavat laskeutumissivut ja etusivu
  • Tuloa tuottavat sivut (hinnoittelu, rekisteröityminen, tärkeät vertailut)
  • Pääoppaat ja tutkimussivut, joihin haluat viitattavan

Keskinkertainen blogiarkisto voi odottaa. Hidas hinnoittelusivu ei voi.

2. Erota laboratoriodiagnoosi kenttätodellisuudesta

  • Laboratorio (Silktiden nopeustestit, Lighthouse, WebPageTest): toistettavissa, sopii syiden löytämiseen tietyllä URL-osoitteella ja laiteprofiililla.
  • Kenttä (Chrome UX Report / Search Consolen Core Web Vitals -raportti, RUM, kuten Silktiden Analytiikka, kun se on käytettävissä): mitä todelliset kävijät kokivat.

Ne voivat olla eri mieltä ilman, että kumpikaan on väärässä – laitteet, maat ja välimuistitilat ovat erilaisia. Korjaa laboratorio-ongelmat, jotka vastaavat selvästi kenttävirheitä. Älä tavoittele laboratorion täydellisyyttä URL-osoitteella, joka jo saavuttaa kenttäkynnysarvot.

Silktiden Nopeus-näyttö yhdistää laboratoriodiagnostiikan todellisten kävijöiden mittauksiin, kun Analytiikka on yhdistetty. Web Vitals -tarkistus kokoaa laboratorion suorituskyvyn; Hitaasti latautuvat sivut ja Asettelusiirtymät erittelevät LCP:n ja CLS:n.

3. Korjaa syyt, älä pisteitä

Kun Silktide (tai Lighthouse) osoittaa syyn, korjaa se:

Yleinen syyTyypillinen mittariSilktide / seuraava vaihe
Valtava hero-kuva, hidas palvelin, renderöinnin estävä CSS/JSLCPHitaasti latautuvat sivut, Esilataa LCP-kuva, kuvien optimointitarkistukset
Kuvat/mainokset/upotukset ilman varattua tilaa; myöhään latautuvat fontitCLSAsettelusiirtymät, Määritä kuville eksplisiittiset koot
Pitkät JavaScript-tehtävät klikkauksen yhteydessäINP / TBTVähennä JavaScriptin suoritusaikaa, Poista renderöinnin estävät resurssit
Liikaa tavuja kokonaisuudessaanKaikkiTarkista tavupaino, nykyaikaiset kuvamuodot, välimuisti

Kehittäjien kannattaa käyttää yllä linkitettyjä web.dev-oppaita toteutuksen yksityiskohtiin – kehyskohtaiset mallit muuttuvat nopeammin kuin tämän sivun pitäisi.

4. Testaa samat URL-osoitteet uudelleen

Korjauksen jälkeen suorita laboratoriotestit uudelleen samalla laiteprofiililla ja odota sitten kenttädatan päivittymistä (CrUX-ikkunat kattavat useita viikkoja). Arvioi onnistumista tärkeiden URL-osoitteiden kenttätilan perusteella, ei esityskalvon pelkän etusivun Lighthouse-kuvakaappauksen perusteella.

Rehelliset rajoitukset

  • Sisältö voittaa edelleen. Nopea tyhjä sivu häviää hitaammalle, kattavalle vastaukselle. Nopeustyö heikoilla sivuilla on viimeistelyä.
  • Kolmannet osapuolet. Tagien hallintajärjestelmät, chat-widgetit ja A/B-työkalut hallitsevat usein INP:tä ja LCP:tä. Varaa vaikutusvaltaa niiden poistamiseen tai lykkäämiseen; oman CSS:n pienentäminen ei pelasta synkroniselta kolmannen osapuolen pommilta.
  • SPA / vain asiakaspuolen renderöinti. Jos Fernwoodin markkinointisivusto toimittaa tyhjän kuoren, saatat kamppailla sekä mittareiden että AI-indeksoijien luettavuuden kanssa. Suosi julkisessa sisällössä SSR:ää/SSG:tä (Ilman JavaScriptiä luettava sisältö).
  • Ylioptimoinnin teatteri. Jo vihreän kenttä-URL-osoitteen laboratorion LCP:n parantaminen 20 ms:llä on harvoin kehittäjän ajan paras käyttö, kun vertailusivuilta puuttuu edelleen näyttölohkoja.

Miten Silktide auttaa

Aiheeseen liittyvää

Viimeksi päivitetty

Oliko tästä sivusta apua?