Svarbus lėtas puslapis nėra pagrindinis puslapis

Santrauka

Kai viršininkas sako, kad svetainė lėta, instinktyviai pradedama spausti paveikslėlius ir atsiprašinėti pagrindinio puslapio. Naudingesnis žingsnis – nuspręsti, kurį puslapį iš tikrųjų verta paspartinti pirmiausia. Šis straipsnis apžvelgia vieną scenarijų: maža rinkodaros komanda, kuriai paprašyta „sutvarkyti greitį“ vidutinio dydžio B2B svetainėje. Jame aptariama, kaip matuoti Core Web Vitals naudojant lauko duomenis, pasirinkti puslapius pagal verslo poveikį ir pridėti struktūrinius duomenis tik po pigių pataisymų. Rezultatas – trumpas, pagrįstas planas, kuris suprantamas net ir netechniniam viršininkui.

Lėčiausias puslapis jūsų svetainėje nėra tas, kurį pažymi PageSpeed Insights. Tai puslapis, kurio jūsų viršininkas niekada neatidarė – susietas su mokama kampanija arba paslėptas pamirštoje produktų skiltyje – ir būtent jis nustato, ar šio mėnesio biudžetas ką nors duoda. Kai aukštesnės vadovybės atstovas sako „svetainė lėta, sutvarkykite“, jums nereikia svetainės greičio projekto. Jums reikia prioritetų nustatymo pratimo.

Paimkime scenarijų, kurį daugelis esame patyrę. Jūs esate visa rinkodaros komanda vidutinio dydžio B2B programinės įrangos įmonėje. Svetainėje yra pagrindinis puslapis, tinklaraštis, pagalbos centras ir penki nukreipimo puslapiai, susieti su konkrečiomis reklamos kampanijomis. Jūsų viršininkas perskaitė straipsnį apie Core Web Vitals arba išgirdo kliento skundą. Nurodymas aiškus: padarykite greičiau.

Kaip atsakysite per artimiausią valandą, nulems, ar kitą mėnesį praleisite glaudami paveikslėlius, ar dirbdami darbus, kurie pakeičia svarbius skaičius.

Pradėkite nuo puslapio, kuris uždirba, o ne nuo to, kuris gėdina

Principas: greičio darbai turi grąžą, o ta grąža priklauso nuo srauto ir konversijų vertės. Mažai lankomas, bet daug konversijų generuojantis puslapis verslui gali būti svarbesnis nei pagrindinis puslapis, net jei jis lėtesnis.

Taigi pirmas žingsnis – sudaryti puslapių sąrašą iš analitikos, o ne iš svetainės struktūros. Kurie puslapiai gauna pinigus reklamos paspaudimų pavidalu? Kurie puslapiai nebuvo liesti nuo paleidimo? Šiame scenarijuje svarbiausias nukreipimo puslapis – už mokamos paieškos skelbimo, veikiančio du mėnesius, – buvo sukurtas su dideliais, nesuoptimizuotais ekrano vaizdais. Pagrindinis puslapis, palyginimui, prieš metus buvo optimizuotas agentūros.

Jūs netaisote pagrindinio puslapio pirmiausia. Jūs taisote puslapį, kuris uždirba pinigus. Tai ne techninis pasirinkimas, o verslo sprendimas. Jei pilnas techninis auditas atrodo tinkamas atsakymas, trumpam susilaikykite. Auditas pateikia sąrašą; jis nepasako, nuo kurio elemento pradėti. Gerai apibrėžtas techninis SEO auditas yra sprendimo įrankis, o ne panikos atsakas.

Dažnai pastebėsite, kad nedaug puslapių generuoja didžiąją dalį srauto ir konversijų; kiti yra informaciniai arba liekamieji. Tai nereiškia, kad reikia amžinai ignoruoti lėtus informacinius puslapius. Tai reiškia, kad juos reikia įvertinti po puslapių, kurie tiesiogiai susiję su pajamomis. Pagrindinis puslapis gali būti lėčiausias, bet jei verslo tikslas yra potencialūs klientai, apsilankymas pagrindiniame puslapyje yra tik pradžia – nukreipimo puslapis yra ten, kur žmogus realiai konvertuoja.

Padalinkite „greitas“ į „išmatuota“ ir „jaučiama“

Antras žingsnis – atskirti, ką našumo testai sako apie jūsų puslapį, nuo to, ką realiai patiria vartotojai. Google Core Web Vitals dokumentacija įvardija tris metrikas, kurios įskaičiuojamos į paieškos reitingus: didžiausias turinio piešimas (įkėlimas), sąveika iki kito piešimo (reagavimas) ir kaupiamasis išdėstymo poslinkis (vizualinis stabilumas). Jos svarbios, nes stebi momentus, kurie lemia, ar žmogus iš tikrųjų gali naudotis puslapiu.

Scenarijuje atidarote nukreipimo puslapį našumo tikrintuve ir gaunate tinkamą įvertinimą. Tačiau palyginus su lauko duomenimis Google Search Console – kurie atspindi realią lankytojų patirtį – paaiškėja, kad puslapis dažnai būna lėtas. Tai signalas, kuris svarbus. Laboratoriniai testai vis tiek naudingi po pakeitimų, norint palyginti prieš ir po. Tačiau lauko duomenys yra tikroji tiesa žmonėms, kurie spustelėjo jūsų skelbimą iš įvairių įrenginių ir ryšių.

Vietoj to	Pradėkite nuo šito	Kodėl
PageSpeed balas kaip vienas skaičius	Core Web Vitals lauko duomenys	Lauko duomenys gaunami iš realių vartotojų, o ne iš testo serverio
„Svetainė lėta“	Kurie puslapiai palaiko verslo tikslus	Greiti nenaudingi puslapiai negeneruoja potencialių klientų
Atkurti CMS	Suspausti paveikslėlius ir sutvarkyti scenarijus	Mažos rizikos pataisymai duoda didžiąją dalį naudos

Jei norite gilesnės nuorodos vėliau, Core Web Vitals vadovas padės suprasti kiekvieną metriką. Tačiau dabar jums reikia tik tiek, kad sudarytumėte planą. Svarbiausia įvardyti, kuri iš trijų metrikų iš tikrųjų sukelia problemą konkrečiame puslapyje. Jei tekstas atsiranda vėlai, pažiūrėkite į paveikslėlius ir serverio atsakymą. Jei mygtukai jaučiasi trūkčiojantys, pažiūrėkite į ilgas JavaScript užduotis. Jei išdėstymas šokinėja, pažiūrėkite į vietas, rezervuotas reklamoms ir įterpiniams. Šis niuansas atskiria tikslinį pataisymą nuo atsitiktinio optimizavimo.

Iš pradžių sutvarkykite pigius dalykus, o ne brangius

Trečias principas: neleiskite, kad našumo projektas išsipūstų į perkūrimą. Dauguma patobulinimų, kurie iš tikrųjų pagerina vartotojo patirtį, yra nepagražinti ir pigūs.

Pažiūrėkite į nukreipimo puslapį ir įvardykite akivaizdžius kaltininkus. Paveikslėliai yra visos raiškos ekrano vaizdai. Trečiosios šalies scenarijus puslapyje, kurio niekas nebeatpažįsta. Tinklo šriftas blokuoja teksto rodymą. Tai pažįstamos problemos.

Tobulame pasaulyje praleistumėte savaitę perrašydami puslapį naudodami modernų karkasą. Praktiškai pradedate nuo pusės dienos užduočių: suspauskite paveikslėlius, atidėkite nenaudojamą scenarijų, iš anksto įkelkite herojaus paveikslėlį. Šiuos pakeitimus galite išbandyti per popietę, ir jiems nereikia patvirtinimo komiteto.

Įspėjimas: greitis ne visada toks paprastas. Kai kurie puslapiai lėti dėl serverio, duomenų bazės ar trečiosios šalies priklausomybės, kurios jūs nekontroliuojate. Tačiau jei nepatikrinote pigių pataisymų, dar negalite pateisinti brangaus. Daug komandų iššvaisto biudžetą perkūrimui, nes niekada nesuspausdavo ekrano vaizdų. Čia verta išlaikyti kuklumą: našumo įvertinimas yra simptomas, o ne diagnozė. Pigi pataisymai patys savaime yra diagnostiniai. Suspaudę paveikslėlius sužinosite, ar kliūtis buvo jūsų turinys, ar infrastruktūra.

Pridėkite struktūrinius duomenis, kai vis tiek esate kode

Tai sluoksnis, kuris nustebina viršininką. Atlikę pigius pataisymus, jau esate puslapio viduje. Tai tinkamas momentas pridėti tai, kas visai nėra greitis: struktūrinius duomenis.

Struktūriniai duomenys yra žymėjimas, padedantis paieškos sistemoms suprasti, ką puslapyje yra. Tai tas pats HTML, kuris gali lemti turtingesnius paieškos rezultatus ir geresnį matomumą – ir jis tampa vis aktualesnis, nes paieška krypsta į AI generuojamus atsakymus. Mažai komandai tai nepakankamai naudojamas svertas, nes nereikalauja rašyti naujo turinio. Jūs žymite tai, kas jau egzistuoja.

Scenarijuje prie nukreipimo puslapio pridedate paslaugų tipo schemą. Tikslus tipas priklauso nuo to, apie ką puslapis: paslaugos puslapis, straipsnis, produktas. Nereikia pridėti visų tipų iš karto. Geriau atsargiai pridėti vieną, nei neatsargiai dešimt. Rezultatas negarantuojamas; Google sprendžia, ką rodyti. Tačiau rizika maža, o galima nauda reali. Jei nuspręsite eiti giliau, struktūrinių duomenų diegimo vadovas apima praktinius veiksmus.

Išverskite pataisymus į „ar tai uždirbo pinigų?“

Sunkiausia dalis nėra techninis darbas. Tai, kaip pateikiate jį netechniniam viršininkui.

Jūsų viršininkas paprašė vieno dalyko: padaryti svetainę greitesnę. Jei pasakysite „pagerinome LCP nukreipimo puslapyje“, galite sulaukti tuščio žvilgsnio. Vietoj to išverskite darbą į verslo pasekmes.

Šiame scenarijuje nukreipimo puslapis yra mokamos kampanijos paskirties vieta. Kiekviena laukimo sekundė yra sekundė, per kurią lankytojas gali išeiti, kol raginimas veikti net pasirodė. Taigi paaiškinate: pašalinome akivaizdžias kliūtis puslapyje, kuriame keičiami pinigai. Negalite pažadėti konkretaus reitingo šuolio – kiekvienas, kuris tai daro, spėlioja – bet galite pateikti pagrįstą, sąžiningą argumentą. Taip pat galite susieti tai su biudžetu, kurį viršininkas jau supranta. Ta pati reklamos išlaida perka apsilankymą; skirtumas tas, ar tas apsilankymas turi galimybę tapti potencialiu klientu.

Paprasta mėnesio ataskaita veikia geriau nei žargono kupina suvestinė. Parodykite tris dalykus: kurį puslapį pasirinkote, kokią metriką matavote ir ką pakeitėte. Jei metrika pagerėja, tai patvirtinimas. Jei ne, vis tiek turite aiškų eksperimentą, kurį galite įvertinti iš naujo. Nesivaikykite vieno balo kiekvieną mėnesį; Core Web Vitals svyruoja dėl srauto sudėties, įrenginių tipų ir net geografinio regiono. Praneškite apie tendenciją, o ne skaičių.

Ką daryti kitą pirmadienį

Scenarijaus pamoka: jūs netaisote „svetainės“. Jūs taisote konkretų puslapį, remdamiesi duomenimis, ir baigiate pakartojamu procesu, o ne vienkartiniu projektu. Kai valdžią turintis žmogus sako „padaryk greičiau“, naudingiausias atsakymas yra vienas patikslinantis klausimas: kurį puslapį ir kam?

Tada išmatuokite lauko duomenis, sutvarkykite pigius dalykus, pridėkite struktūrinius duomenis, jei jau esate kode, ir praneškite paprasta kalba. Rezultatai gali būti nedramatiški. Bet jūs tiksliai žinosite, kuris puslapis tapo greitesnis, kodėl jį pasirinkote ir ką daryti toliau. Tai geresnis rezultatas nei miglotas projektas, kuris prasidėjo greičio balu ir baigėsi niekam nesuprastu perkūrimu.