Počasna stran, ki šteje, ni domača stran

Povzetek

Ko šef reče, da je spletišče počasno, je instinkt začeti stiskati slike in se opravičevati domači strani. Bolj uporaben korak je odločitev, katero stran je dejansko vredno najprej pospešiti. Ta članek obravnava en sam scenarij: majhna marketinška ekipa je dobila nalogo, naj "popravi hitrost" za srednje veliko B2B spletišče. Zajema merjenje Core Web Vitals s terenskimi podatki, izbiro strani glede na poslovni vpliv in dodajanje strukturiranih podatkov šele po poceni popravkih. Rezultat je kratek, utemeljljiv načrt, ki ga razume tudi netehnični šef.

Najpočasnejša stran na vašem spletišču ni tista, ki jo izpostavi PageSpeed Insights. To je stran, ki je šef nikoli ni odprl – tista, povezana s plačano kampanjo ali zakopana v pozabljenem razdelku izdelkov – in tista, ki dejansko določa, ali bo ta mesec proračun sploh kaj prinesel. Ko nekdo na vodstvenem položaju reče "spletišče je počasno, popravi to", ne potrebuje projekta za hitrost spletišča. Potrebuje vajo za določanje prioritet.

Vzemimo scenarij, ki smo ga mnogi že doživeli. Vi ste celotna marketinška ekipa za srednje veliko B2B programsko podjetje. Spletišče ima domačo stran, blog, center pomoči in pet vstopnih strani, povezanih s posebnimi oglaševalskimi kampanjami. Vaš šef je prebral članek o Core Web Vitals ali slišal pritožbo stranke. Navodilo je jasno: pospeši.

Kako se odzovete v naslednji uri, odloča, ali boste naslednji mesec stiskali slike ali delali stvari, ki spremenijo številke, ki štejejo.

Začnite s stranjo, ki prinaša denar, ne s tisto, ki vas spravlja v zadrego

Načelo: delo na hitrosti ima donos, ta donos pa je odvisen od prometa in vrednosti konverzij. Stran z malo prometa, a visoko konverzijo, je lahko za podjetje pomembnejša od domače strani, tudi če je počasnejša.

Torej je prvi korak sestaviti seznam strani iz analitike, ne iz zemljevida spletišča. Katere strani prejemajo denar v obliki klikov na oglase? Katere strani se niso dotaknile od zagona? V tem scenariju je bila najpomembnejša vstopna stran – tista za plačanim iskalnim oglasom, ki teče že dva meseca – zgrajena z velikimi, neoptimiziranimi posnetki zaslona. Domača stran je bila po drugi strani že pred letom dni optimizirana s strani agencije.

Ne popravljate najprej domače strani. Popravite stran, ki prinaša denar. To ni tehnična odločitev, ampak poslovna. Če se zdi popolna tehnična revizija pravi odziv, se za trenutek uprite. Revizije dajo seznam; ne povedo, s katero postavko začeti. Dobro opredeljena tehnična SEO revizija je orodje za odločanje, ne panični odziv.

Pogosto boste ugotovili, da majhno število strani ustvari večino prometa in konverzij; ostale so informativne ali reliktne. To ni razlog, da bi počasne informativne strani za vedno ignorirali. To je razlog, da jih razvrstite za strani, ki imajo neposredno povezavo s prihodki. Domača stran je morda najpočasnejša od vseh, a če je poslovni cilj pridobivanje potencialnih strank, je obisk domače strani le izhodišče – vstopna stran je tista, kjer nekdo dejansko konvertira.

Razdelite "hitro" na "izmerjeno" in "občuteno"

Drugi korak je ločiti, kaj testi zmogljivosti povedo o vaši strani, od tega, kaj dejansko doživljajo uporabniki. Dokumentacija Googlovega Core Web Vitals navaja tri metrike, ki štejejo za uvrstitev v iskalnikih: Largest Contentful Paint (nalaganje), Interaction to Next Paint (odzivnost) in Cumulative Layout Shift (vizualna stabilnost). Pomembne so, ker sledijo trenutkom, ki vplivajo na to, ali lahko nekdo stran dejansko uporablja.

V scenariju odprete vstopno stran v orodju za testiranje zmogljivosti in dobite sprejemljiv rezultat. Toda ko to primerjate s terenskimi podatki v Google Search Console – ki odražajo resnične izkušnje obiskovalcev – se izkaže, da je stran pogosto počasna. To je signal, ki šteje. Laboratorijski testi so še vedno uporabni po spremembi, za primerjavo pred in po. Toda terenski podatki so resnica za ljudi, ki so kliknili vaš oglas z različnih naprav in povezav.

Namesto tega	Začnite s tem	Zakaj
Ocena PageSpeed kot ena številka	Terenski podatki Core Web Vitals	Terenski podatki prihajajo od resničnih uporabnikov, ne s testnega strežnika
"Spletišče je počasno"	Katere strani podpirajo poslovne cilje	Hitre neuporabne strani ne ustvarjajo potencialnih strank
Obnova CMS	Stisnite slike in počistite skripte	Popravki z nizkim tveganjem prinesejo večino koristi

Če želite kasneje bolj poglobljeno referenco, vas vodnik Core Web Vitals lahko popelje skozi vsako metriko. A za zdaj potrebujete le dovolj za izdelavo načrta. Ključno je poimenovati, katera od treh metrik dejansko povzroča težavo na tej določeni strani. Če se besedilo prikaže pozno, preverite slike in odziv strežnika. Če se gumbi zatika, preverite dolge JavaScript naloge. Če se postavitev premika, preverite prostore, rezervirane za oglase in vdelane vsebine. Ta niansa loči ciljno popravilo od naključne optimizacije.

Popravite poceni stvari pred dragimi

Tretje načelo: ne dovolite, da se projekt zmogljivosti razraste v preoblikovanje. Večina izboljšav, ki dejansko premaknejo uporabniško izkušnjo, je neuglednih in poceni.

Poglejte vstopno stran in poimenujte očitne krivce. Slike so posnetki zaslona v polni ločljivosti. Na strani je skripta tretje osebe, ki je nihče več ne prepozna. Spletna pisava blokira prikaz besedila. To so znane težave.

V popolnem svetu bi porabili teden dni za ponovno pisanje strani s sodobnim ogrodjem. V praksi začnete z opravili, ki trajajo pol dneva: stisnite slike, odložite neuporabljeno skripto, prednaložite glavno sliko. Te spremembe lahko preizkusite v enem popoldnevu in ne zahtevajo odobritvenega odbora.

Opozorilo: hitrost ni vedno tako preprosta. Nekatere strani so počasne zaradi strežnika, podatkovne baze ali odvisnosti od tretje osebe, ki je ne obvladujete. Toda če niste preverili poceni popravkov, še ne morete upravičiti dragega. Mnoge ekipe zapravijo proračun za obnovo, ker nikoli niso stisnile posnetkov zaslona. Tukaj je vredna ponižnost: ocena zmogljivosti je simptom, ne diagnoza. Poceni popravki so sami po sebi diagnostični. Ko stisnete slike, izveste, ali je bilo ozko grlo vaša vsebina ali vaša infrastruktura.

Dodajte strukturirane podatke, ko ste že tako v kodi

To je plast, ki preseneti šefa. Ko opravite poceni popravke, ste že v strani. To je pravi trenutek, da dodate nekaj, kar sploh ni hitrost: strukturirane podatke.

Strukturirani podatki so oznake, ki iskalnikom pomagajo razumeti, kaj stran vsebuje. To je ista HTML koda, ki lahko privede do bogatejših rezultatov iskanja in boljše vidnosti – in postaja vse pomembnejša, ko se iskanje premika k odgovorom, ki jih ustvarja umetna inteligenca. Za majhno ekipo je to premalo izkoriščen vzvod, ker ne zahteva pisanja nove vsebine. Označujete tisto, kar že obstaja.

V scenariju vstopni strani dodate shemo, usmerjeno v storitve. Natančna vrsta je odvisna od tega, o čem stran govori: storitvena stran, članek, izdelek. Ni vam treba dodati vseh vrst naenkrat. Bolje je dodati eno skrbno kot deset površno. Noben rezultat ni zagotovljen; Google se odloči, kaj bo prikazal. Toda tveganje je nizko, potencialna korist pa resnična. Če se odločite iti globlje, vodnik za implementacijo strukturiranih podatkov pokriva praktične korake.

Prevedite popravke v "je to prineslo denar?"

Težji del ni tehnično delo. Gre za to, kako to predstavite netehničnemu šefu.

Vaš šef je prosil za eno stvar: pospešite spletišče. Če rečete "izboljšali smo LCP na vstopni strani", boste morda dobili prazen pogled. Namesto tega prevedite delo v poslovne posledice.

V tem scenariju je vstopna stran cilj plačane kampanje. Vsaka sekunda čakanja je sekunda, v kateri lahko obiskovalec odide, preden se prikaže poziv k dejanju. Pojasnite torej: odstranili smo očitna trenja na strani, kjer se pretaka denar. Ne morete obljubiti določenega preskoka uvrstitve – vsak, ki to stori, ugiba – lahko pa podate razumen, iskren argument. To lahko povežete tudi s proračunom, ki ga vaš šef že razume. Enaka poraba za oglase kupi obisk; razlika je v tem, ali ima ta obisk možnost postati potencialna stranka.

Preprosto mesečno poročilo deluje bolje kot armaturna plošča, polna žargona. Pokažite tri stvari: katero stran ste izbrali, katero metriko ste izmerili in kaj ste spremenili. Če se metrika izboljša, je to potrditev. Če se ne, imate še vedno jasen eksperiment za ponovno oceno. Ne lovite ene same ocene iz meseca v mesec; Core Web Vitals niha z mešanico prometa, vrstami naprav in celo geografsko regijo. Poročajte o trendu, ne o številki.

Kaj storiti naslednji ponedeljek

Nauk iz scenarija: ne popravljate "spletišča". Popravite določeno stran na podlagi podatkov in končate s ponovljivim procesom, ne z enkratnim projektom. Ko nekdo z močjo reče "pospeši", je najbolj uporaben odgovor eno samo pojasnjevalno vprašanje: katera stran in za koga?

Nato izmerite terenske podatke, popravite poceni stvari, dodajte strukturirane podatke, če ste že v kodi, in poročajte v preprostem jeziku. Rezultati morda ne bodo dramatični. Toda natančno boste vedeli, katera stran je postala hitrejša, zakaj ste jo izbrali in kaj storiti naprej. To je boljši rezultat kot nejasen projekt, ki se je začel z oceno hitrosti in končal s preoblikovanjem, ki ga nihče ni razumel.