Aeglane leht, mis loeb, ei ole avaleht

Kokkuvõte

Kui teie ülemus ütleb, et veebisait on aeglane, on esimene instinkt hakata pilte tihendama ja avalehe ees vabandama. Kasulikum samm on otsustada, millist lehte tasub kõigepealt kiirendada. See artikkel käsitleb ühte stsenaariumit: väike turundusmeeskond paluti "kiirust parandada" keskmise suurusega B2B saidil. See hõlmab Core Web Vitals mõõtmist väljandmetega, lehtede valimist ärimõju järgi ja struktureeritud andmete lisamist alles pärast odavaid parandusi. Tulemuseks on lühike, kaitstav plaan, mis on arusaadav ka mittetehnilisele ülemusele.

Teie veebisaidi kõige aeglasem leht ei ole see, millele PageSpeed Insights osutab. See on leht, mida teie ülemus pole kunagi avanud – see, mis on seotud tasulise kampaaniaga või peidetud unustatud tooteosasse – ja see on see, mis tegelikult määrab, kas selle kuu eelarve toob midagi. Kui keegi juhtkonnast ütleb "sait on aeglane, paranda ära", ei vaja nad veebisaidi kiiruse projekti. Nad vajavad prioriseerimise harjutust.

Võtke stsenaarium, mida paljud meist on kogenud. Olete kogu turundusmeeskond keskmise suurusega B2B tarkvaraettevõttes. Saidil on avaleht, ajaveeb, abikeskus ja viis sihtlehte, mis on seotud konkreetsete reklaamikampaaniatega. Teie ülemus luges artiklit Core Web Vitalsist või kuulis kliendi kaebust. Juhis on selge: tee see kiiremaks.

Kuidas te järgmise tunni jooksul reageerite, määrab, kas veedate järgmise kuu pilte tihendades või tehes tööd, mis muudab olulisi numbreid.

Alusta lehest, mis teenib, mitte sellest, mis teeb piinlikuks

Põhimõte: kiirustööl on tasuvus ja see tasuvus sõltub liiklusest ja konversiooni väärtusest. Vähese liiklusega, kuid kõrge konversioonimääraga leht võib ettevõttele rohkem tähendada kui avaleht, isegi kui see on aeglasem.

Seega on esimene samm teha lehtede loend analüütikast, mitte saidikaardist. Millised lehed saavad raha reklaamiklikkide kujul? Milliseid lehti pole käivitamisest saati puudutatud? Selles stsenaariumis on kõige olulisem sihtleht – see, mis on olnud kaks kuud tasulise otsingureklaami taga – loodud suurte, optimeerimata ekraanipiltidega. Avaleht oli seevastu aasta tagasi juba agentuuri poolt optimeeritud.

Te ei paranda kõigepealt avalehte. Te parandate lehte, mis toob raha. See ei ole tehniline valik, vaid äriline. Kui täielik tehniline audit tundub õige vastus, siis pidage hetke vastu. Audid annavad nimekirja; nad ei ütle, millise üksusega alustada. Hästi piiritletud tehniline SEO audit on otsuste tegemise tööriist, mitte paanikareaktsioon.

Sageli leiate, et väike arv lehti genereerib suurema osa liiklusest ja konversioonidest; ülejäänud on informatiivsed või jäänukid. See ei ole põhjus ignoreerida aeglasi informatiivseid lehti igavesti. See on põhjus järjestada need pärast lehti, millel on otsene seos tuluga. Avaleht võib olla kõigist kõige aeglasem, kuid kui äriline eesmärk on müügivihjed, on avalehe külastus vaid lähtepunkt – sihtleht on koht, kus keegi tegelikult konverteerib.

Jaga "kiire" mõisteteks "mõõdetud" ja "tajutud"

Teine samm on eraldada see, mida jõudlustestid teie lehe kohta ütlevad, sellest, mida tegelikud kasutajad kogevad. Google'i Core Web Vitals dokumentatsioon nimetab kolm mõõdikut, mis loevad otsingureitingu jaoks: Largest Contentful Paint (laadimine), Interaction to Next Paint (reageerimisvõime) ja Cumulative Layout Shift (visuaalne stabiilsus). Need loevad, sest nad jälgivad hetki, mis mõjutavad seda, kas keegi suudab lehte tegelikult kasutada.

Stsenaariumis avate sihtlehe jõudlusetesteris ja saate mõistliku tulemuse. Kuid kui võrrelda seda Google Search Console'i väljandmetega – mis kajastavad külastajate tegelikke kogemusi – osutub leht sageli aeglaseks. See on signaal, mis loeb. Laboritestid on pärast muudatust endiselt kasulikud, et võrrelda enne ja pärast. Kuid väljandmed on tõde inimestele, kes klõpsasid teie reklaamile erinevatest seadmetest ja ühendustest.

Selle asemel	Alusta sellega	Miks
PageSpeed skoor ühe numbrina	Core Web Vitalsi väljandmed	Väljandmed pärinevad reaalsetelt kasutajatelt, mitte testiserverist
"Sait on aeglane"	Millised lehed toetavad ärilisi eesmärke	Kiired kasutud lehed ei genereeri müügivihjeid
CMS-i ümberehitamine	Piltide tihendamine ja skriptide puhastamine	Madala riskiga parandused annavad suurema osa kasust

Kui soovite hiljem põhjalikumat viidet, võib Core Web Vitalsi juhend viia teid iga mõõdikuni. Kuid praegu piisab, et plaan üles ehitada. Oluline on nimetada, milline kolmest mõõdikust tegelikult probleemi põhjustab just sellel lehel. Kui tekst ilmub hilja, vaadake pilte ja serveri vastust. Kui nupud tunduvad tõmblevad, vaadake pikki JavaScripti ülesandeid. Kui paigutus hüppab, vaadake reklaamidele ja manustustele reserveeritud ruume. See nüanss eristab suunatud parandust juhuslikust optimeerimisest.

Paranda odavad asjad enne kalleid asju

Kolmas põhimõte: ära lase jõudlusprojektil muutuda ümberkujunduseks. Enamik parandusi, mis tegelikult kasutajakogemust mõjutavad, on ebameeldivad ja odavad.

Vaadake sihtlehte ja nimetage ilmsed süüdlased. Pildid on täiseraldusvõimega ekraanipildid. Lehel on kolmanda osapoole skript, mida keegi enam tuvastada ei oska. Veebifont blokeerib teksti kuvamist. Need on tuttavad probleemid.

Ideaalses maailmas kulutaksite nädala lehe ümberkirjutamisele kaasaegse raamistikuga. Praktikas alustate poolepäevaste ülesannetega: tihendage pilte, lükake kasutamata skript edasi, laadige kangelane eelnevalt. Saate neid muudatusi testida ühe pärastlõunaga ja need ei vaja heakskiitmise komiteed.

Hoiatus: kiirus ei ole alati nii lihtne. Mõned lehed on aeglased serveri, andmebaasi või kolmanda osapoole sõltuvuse tõttu, mida te ei kontrolli. Kuid kui te pole odavaid parandusi kontrollinud, ei saa te veel kallist õigustada. Paljud meeskonnad raiskavad eelarve ümberehitusele, sest nad ei tihendanud kunagi ekraanipilte. Siin tasub säilitada alandlikkus: jõudluse skoor on sümptom, mitte diagnoos. Odavad parandused on ise diagnostilised. Pärast piltide tihendamist saate teada, kas pudelikael oli teie sisu või teie infrastruktuur.

Lisa struktureeritud andmed, kui oled niikuinii koodis

See on kiht, mis üllatab ülemust. Pärast odavate paranduste tegemist olete juba lehe sees. See on õige hetk lisada midagi, mis pole üldse kiirus: struktureeritud andmed.

Struktureeritud andmed on märgistus, mis aitab otsingumootoritel mõista, mida leht sisaldab. See on sama HTML, mis võib viia rikkalikumate otsingutulemuste ja parema nähtavuseni – ja see muutub järjest olulisemaks, kui otsing liigub AI loodud vastuste suunas. Väikese meeskonna jaoks on see alakasutatud hoob, sest see ei nõua uue sisu kirjutamist. Te märgistate seda, mis juba olemas on.

Stsenaariumis lisate sihtlehele teenusekeskse skeemi. Täpne tüüp sõltub sellest, millest leht räägib: teenuseleht, artikkel, toode. Te ei pea korraga lisama iga tüüpi. Ühe hoolikalt lisamine on parem kui kümne lohakalt lisamine. Tulemus pole garanteeritud; Google otsustab, mida kuvada. Kuid risk on madal ja potentsiaalne kasu on reaalne. Kui otsustate süvitsi minna, hõlmab struktureeritud andmete juhend praktilisi samme.

Tõlgi parandused küsimuseks "kas see tõi raha?"

Raske osa pole tehniline töö. See on viis, kuidas seda mittetehnilisele ülemusele esitate.

Teie ülemus küsis ühte asja: tee sait kiiremaks. Kui ütlete "parandasime sihtlehe LCP-d", võite saada tühja pilgu. Selle asemel tõlkige töö ärilisteks tagajärgedeks.

Selles stsenaariumis on sihtleht tasulise kampaania sihtkoht. Iga ootamise sekund on sekund, mille jooksul külastaja võib lahkuda enne üleskutse ilmumist. Seega selgitate: eemaldasime lehel ilmsed hõõrdumised, kus raha liigub. Te ei saa lubada konkreetset reitinguhüpet – igaüks, kes seda teeb, arvab –, kuid saate teha mõistliku, ausa argumendi. Saate selle ühendada ka eelarvega, mida teie ülemus juba mõistab. Sama reklaamikulu ostab külastuse; erinevus on selles, kas sellel külastusel on võimalus saada müügivihjeks.

Lihtne igakuine aruanne töötab paremini kui žargoonirohke armatuurlaud. Näidake kolme asja: millise lehe valisite, millist mõõdikut mõõtsite ja mida muutsite. Kui mõõdik paraneb, on see kinnitus. Kui ei, on teil siiski selge eksperiment ümberhindamiseks. Ärge jälitage ühte skoori kuust kuusse; Core Web Vitals kõigub liikluse segu, seadmete tüüpide ja isegi geograafilise piirkonnaga. Raporteerige trendi, mitte numbrit.

Mida teha järgmisel esmaspäeval

Stsenaariumi õppetund: te ei paranda "veebisaiti". Te parandate konkreetset lehte andmete põhjal ja lõpetate korratava protsessi, mitte ühekordse projektiga. Kui keegi võimupositsioonil ütleb "tee kiiremaks", on kõige kasulikum vastus üks täpsustav küsimus: milline leht ja kellele?

Seejärel mõõtke väljandmeid, parandage odavad asjad, lisage struktureeritud andmed, kui olete juba koodis, ja raporteerige lihtsas keeles. Tulemused ei pruugi olla dramaatilised. Kuid te teate täpselt, milline leht muutus kiiremaks, miks te selle valisite ja mida edasi teha. See on parem väljund kui ebamäärane projekt, mis algas kiirusskooriga ja lõppes ümberkujundusega, millest keegi aru ei saanud.