Merkityksellinen hidas sivu ei ole etusivu

Yhteenveto

Kun pomosi sanoo verkkosivuston olevan hidas, vaistosi on alkaa pakata kuvia ja pyydellä anteeksi etusivulta. Hyödyllisempää on päättää, mikä sivu todella kannattaa nopeuttaa ensimmäisenä. Tämä artikkeli käy läpi yhden skenaarion: pieni markkinointitiimi sai tehtäväksi "korjata nopeuden" keskikokoiselle B2B-sivustolle. Se käsittelee Core Web Vitals -mittareiden mittaamista kenttädatalla, sivujen valitsemista liiketoimintavaikutuksen perusteella ja strukturoidun datan lisäämistä vasta halpojen korjausten jälkeen. Lopputuloksena on lyhyt, perusteltavissa oleva suunnitelma, joka on järkevä ei-tekniselle pomolle.

Hidassivu sivustollasi ei ole se, jonka PageSpeed Insights nostaa esiin. Se on sivu, jota pomosi ei ole koskaan avannut — se, joka liittyy maksettuun kampanjaan tai on hautautunut unohdettuun tuoteosioon — ja se on sivu, joka todella ratkaisee, tuottaako tämän kuukauden budjetti mitään. Kun ylempi taho sanoo "sivusto on hidas, korjaa se", he eivät tarvitse verkkosivuston nopeusprojektia. He tarvitsevat priorisointiharjoituksen.

Ota skenaario, jonka monet meistä ovat kokeneet. Olet koko markkinointitiimi keskikokoisessa B2B-ohjelmistoyrityksessä. Sivustolla on etusivu, blogi, tukikeskus ja viisi mainoskampanjoihin liitettyä laskeutumissivua. Pomosi luki artikkelin Core Web Vitals -mittareista tai kuuli asiakkaan valituksen. Ohje on selvä: tee siitä nopeampi.

Se, miten vastaat seuraavan tunnin aikana, ratkaisee, vietätkö seuraavan kuukauden kuvia pakkaamalla vai teetkö työtä, joka muuttaa merkityksellisiä lukuja.

Aloita sivusta, joka tuottaa, älä sivusta, joka hävettää

Periaate: nopeustyöllä on tuotto, ja tuo tuotto riippuu liikenteestä ja konversioarvosta. Sivu, jolla on vähän liikennettä mutta korkea konversio, voi olla yritykselle tärkeämpi kuin etusivu, vaikka se olisi hitaampi.

Ensimmäinen toimenpide on siis laatia sivulista analytiikasta, ei sivukartasta. Mitkä sivut saavat rahaa mainosklikkausten muodossa? Mihin sivuihin ei ole koskettu julkaisun jälkeen? Tässä skenaariossa tärkein laskeutumissivu — se, joka on maksetun hakumainoksen takana ja jota on ajettu kaksi kuukautta — oli rakennettu suurilla, optimoimattomilla kuvakaappauksilla. Etusivu sen sijaan oli toimiston optimoima vuosi sitten.

Et korjaa etusivua ensin. Korjaat sivun, joka tuottaa rahaa. Se ei ole tekninen valinta, vaan liiketoiminnallinen. Jos täydellinen tekninen auditointi kuulostaa oikealta vastaukselta, vastusta hetki. Auditoinnit tuottavat listan; ne eivät kerro, mistä kohdasta aloittaa. Hyvin rajattu tekninen SEO-auditointi on päätöksenteon työkalu, ei paniikkireaktio.

Huomaat usein, että pieni määrä sivuja tuottaa suurimman osan liikenteestä ja konversioista; loput ovat informatiivisia tai jäänteitä. Tämä ei ole syy jättää hitaat informatiiviset sivut huomiotta ikuisesti. Se on syy asettaa ne järjestykseen sivujen jälkeen, joilla on suora yhteys tuloihin. Etusivu voi olla kaikkein hitain, mutta jos liiketoiminnan tavoitteena on liidit, etusivukäynti on vain lähtökohta — laskeutumissivu on se, jolla joku todella konvertoituu.

Jaa "nopea" mitattuun ja koettuun

Toinen vaihe on erottaa toisistaan se, mitä suorituskykytestit sanovat sivustasi, ja se, mitä oikeat käyttäjät kokevat. Googlen Core Web Vitals -dokumentaatio nimeää kolme metriikkaa, jotka vaikuttavat hakusijoituksiin: Largest Contentful Paint (lataus), Interaction to Next Paint (responsiivisuus) ja Cumulative Layout Shift (visuaalinen vakaus). Ne ovat tärkeitä, koska ne seuraavat hetkiä, jotka vaikuttavat siihen, voiko joku todella käyttää sivua.

Skenaariossa avaat laskeutumissivun suorituskykytestissä ja saat kohtuullisen pistemäärän. Mutta kun vertaat sitä Google Search Consulen kenttädataan — joka heijastaa kävijöiden todellisia kokemuksia — sivu osoittautuu usein hitaaksi. Tämä on signaali, jolla on merkitystä. Laboratoriotestit ovat edelleen hyödyllisiä muutoksen jälkeen, kun verrataan ennen ja jälkeen. Kenttädata on kuitenkin perimmäinen totuus ihmisille, jotka klikkasivat mainostasi eri laitteista ja yhteyksistä.

Tämän sijaan	Aloita tästä	Miksi
PageSpeed-pisteet yhtenä numerona	Core Web Vitals -kenttädata	Kenttädata tulee oikeilta käyttäjiltä, ei testipalvelimelta
"Sivusto on hidas"	Mitkä sivut tukevat liiketoimintatavoitteita	Nopeat hyödyttömät sivut eivät tuota liidejä
Rakenna CMS uudelleen	Pakkaa kuvat ja siivoa skriptit	Pienen riskin korjaukset tuottavat suurimman osan hyödystä

Jos haluat myöhemmin syvällisemmän viittauksen, Core Web Vitals -opas käy läpi jokaisen mittarin. Mutta nyt tarvitset vain tarpeeksi suunnitelman rakentamiseen. Tärkeintä on nimetä, mikä kolmesta mittarista aiheuttaa ongelman kyseisellä sivulla. Jos teksti ilmestyy myöhään, tarkista kuvat ja palvelimen vastaus. Jos painikkeet tuntuvat nykiviltä, tarkista pitkät JavaScript-tehtävät. Jos asettelu hyppii, tarkista mainoksille ja upotuksille varatut tilat. Tämä vivahteikkuus erottaa kohdennetun korjauksen satunnaisesta optimoinnista.

Korjaa halvat asiat ennen kalliita

Kolmas periaate: älä anna suorituskykyprojektin paisua uudelleensuunnitteluksi. Suurin osa parannuksista, jotka todella parantavat käyttökokemusta, ovat vaatimattomia ja halpoja.

Katso laskeutumissivua ja nimeä ilmeiset ongelmalliset kohdat. Kuvat ovat täysresoluutioisia kuvakaappauksia. Sivulla on kolmannen osapuolen skripti, jota kukaan ei enää tunnista. Verkkofontti estää tekstin renderöitymisen. Nämä ovat tuttuja ongelmia.

Täydellisessä maailmassa käyttäisit viikon sivun uudelleenkirjoittamiseen modernilla kehyksellä. Käytännössä aloitat puolen päivän tehtävistä: pakkaa kuvat, lykkää käyttämätön skripti, esilataa hero-kuva. Voit testata nämä muutokset iltapäivällä, eivätkä ne vaadi hyväksyntäkomiteaa.

Varoitus: nopeus ei ole aina näin yksinkertaista. Jotkut sivut ovat hitaita palvelimen, tietokannan tai kolmannen osapuolen riippuvuuden vuoksi, jota et hallitse. Mutta jos et ole tarkistanut halpoja korjauksia, et voi vielä perustella kallista. Monet tiimit tuhlaavat budjettia uudelleenrakentamiseen, koska he eivät koskaan pakanneet kuvakaappauksia. Tässä on nöyryys, joka kannattaa säilyttää: suorituskykypistemäärä on oire, ei diagnoosi. Halvat korjaukset ovat itsessään diagnostisia. Kun olet pakannut kuvat, opit, oliko pullonkaula sisältösi vai infrastruktuurisi.

Lisää strukturoitua dataa, kun kerran olet koodissa

Tämä on kerros, joka yllättää pomon. Kun olet tehnyt halvat korjaukset, olet jo sivun sisällä. Se on oikea hetki lisätä jotain, mikä ei liity nopeuteen lainkaan: strukturoitu data.

Strukturoitu data on merkintää, joka auttaa hakukoneita ymmärtämään, mitä sivu sisältää. Se on samaa HTML:ää, joka voi johtaa rikkaampiin hakutuloksiin ja parempaan näkyvyyteen — ja se on yhä relevantimpaa, kun haku siirtyy kohti tekoälyn tuottamia vastauksia. Pienelle tiimille tämä on alikäytetty vipu, koska se ei vaadi uuden sisällön kirjoittamista. Merkitset sitä, mikä jo on olemassa.

Skenaariossa lisäät palvelusuuntautuneen skeeman laskeutumissivulle. Tarkka tyyppi riippuu sivun aiheesta: palvelusivu, artikkeli, tuote. Sinun ei tarvitse lisätä kaikkia tyyppejä kerralla. Yhden huolellinen lisääminen on parempi kuin kymmenen huolimattomasti. Mitään tulosta ei taata; Google päättää, mitä näytetään. Mutta riski on pieni ja mahdollinen hyöty on todellinen. Jos päätät mennä syvemmälle, strukturoidun datan toteutusopas kattaa käytännön vaiheet.

Käännä korjaukset muotoon "tuottiko se rahaa?"

Vaikea osa ei ole tekninen työ. Se on tapa, jolla esität sen ei-tekniselle pomolle.

Pomosi pyysi yhtä asiaa: tee sivustosta nopeampi. Jos sanot "paransimme LCP:tä laskeutumissivulla", saatat saada tyhjän katseen. Sen sijaan käännä työ liiketoiminnallisiksi seurauksiksi.

Tässä skenaariossa laskeutumissivu on maksetun kampanjan kohde. Jokainen odotettu sekunti on sekunti, jonka aikana kävijä voi poistua ennen toimintakehotuksen ilmestymistä. Joten selität: poistimme ilmeisiä kitkatekijöitä sivulta, jolla raha vaihtaa omistajaa. Et voi luvata tiettyä sijoitushyppyä — jokainen, joka lupaa, arvaa — mutta voit esittää kohtuullisen ja rehellisen perustelun. Voit myös yhdistää tämän budjettiin, jonka pomosi jo ymmärtää. Sama mainosbudjetti ostaa käynnin; ero on siinä, onko sillä käynnillä mahdollisuus muuttua liidiksi.

Yksinkertainen kuukausiraportti toimii paremmin kuin täynnä jargonkia oleva kojelauta. Näytä kolme asiaa: minkä sivun valitsit, mitä mittaria mittasit ja mitä muutit. Jos mittari paranee, se on vahvistus. Jos ei, sinulla on silti selkeä kokeilu uudelleenarviointia varten. Älä jahtaa yhtä pistemäärää kuukaudesta toiseen; Core Web Vitals vaihtelevat liikenteen koostumuksen, laiteluokkien ja jopa maantieteellisen alueen mukaan. Raportoi trendi, älä numeroa.

Mitä tehdä ensi maanantaina

Tämän skenaarion opetus: et korjaa "verkkosivustoa". Korjaat tietyn sivun datan perusteella, ja päädyt toistettavaan prosessiin kertaluonteisen projektin sijaan. Kun valtaa omaava henkilö sanoo "tee siitä nopeampi", hyödyllisin vastaus on yksi selventävä kysymys: mikä sivu, ja kenelle?

Mittaa sitten kenttädata, korjaa halvat asiat, lisää strukturoitua dataa, jos olet jo koodissa, ja raportoi selkeällä kielellä. Tulokset eivät välttämättä ole dramaattisia. Mutta tiedät tarkalleen, mikä sivu nopeutui, miksi valitsit sen ja mitä tehdä seuraavaksi. Se on parempi lopputulos kuin epämääräinen projekti, joka alkoi nopeuspisteestä ja päättyi uudelleensuunnitteluun, jota kukaan ei ymmärtänyt.