Lēnā lapa, kurai ir nozīme, nav mājaslapa

Kopsavilkums

Kad priekšnieks saka, ka vietne ir lēna, pirmais instinkts ir sākt kompresēt attēlus un atvainoties mājaslapai. Noderīgāk ir izlemt, kura lapa patiešām ir vērta paātrināšanai vispirms. Šis raksts aplūko vienu scenāriju: neliela mārketinga komanda saņēma uzdevumu "novērst ātruma problēmas" vidēja izmēra B2B vietnei. Tas aptver Core Web Vitals mērīšanu ar reāliem datiem, lapu izvēli pēc biznesa ietekmes un strukturēto datu pievienošanu tikai pēc lētajiem labojumiem. Rezultāts ir īss un aizstāvams plāns, kas ir saprotams netehniskam priekšniekam.

Jūsu vietnes lēnākā lapa nav tā, kuru norāda PageSpeed Insights. Tā ir lapa, kuru jūsu priekšnieks nekad nav atvēris—tā, kas saistīta ar apmaksātu kampaņu, vai aprakta aizmirstā produktu sadaļā—un tā ir tā, kas patiesībā nosaka, vai šī mēneša budžets rada kaut ko. Kad kāds augstākstāvošs saka "vietne ir lēna, salabo to", viņiem nav vajadzīgs vietnes ātruma projekts. Viņiem ir nepieciešams prioritāšu noteikšanas vingrinājums.

Ņemsim scenāriju, ko daudzi no mums ir piedzīvojuši. Jūs esat visa mārketinga komanda vidēja izmēra B2B programmatūras uzņēmumā. Vietnei ir mājaslapa, emuārs, atbalsta centrs un piecas galvenās lapas, kas saistītas ar konkrētām reklāmas kampaņām. Jūsu priekšnieks izlasīja rakstu par Core Web Vitals vai dzirdēja klienta sūdzību. Norādījums ir skaidrs: padariet to ātrāku.

Tas, kā jūs atbildat nākamajā stundā, nosaka, vai nākamo mēnesi pavadīsit, kompresējot attēlus, vai darot darbu, kas maina svarīgos skaitļus.

Sāciet ar lapu, kas pelna, nevis ar lapu, kas sagādā apkaunojumu

Princips: ātruma darbam ir atdeve, un šī atdeve ir atkarīga no datplūsmas un reklāmguvumu vērtības. Lapa ar zemu datplūsmu, bet augstu reklāmguvumu līmeni biznesam var būt svarīgāka par mājaslapu, pat ja tā ir lēnāka.

Tātad pirmais solis ir izveidot lapu sarakstu no analītikas, nevis no vietnes kartes. Kuras lapas saņem naudu reklāmas klikšķu veidā? Kuras lapas nav tikušas aiztiktas kopš palaišanas? Šajā scenārijā vissvarīgākā galvenā lapa—tā, kas atrodas aiz apmaksātas meklēšanas reklāmas, kas darbojas jau divus mēnešus—tika izveidota ar lieliem, neoptimizētiem ekrānuzņēmumiem. Salīdzinājumam, mājaslapa jau pirms gada tika optimizēta ar aģentūras palīdzību.

Jūs nelabojat mājaslapu pirmo. Jūs labojat lapu, kas pelna naudu. Tā nav tehniska izvēle, bet biznesa izvēle. Ja pilna tehniskā audita veikšana izklausās kā pareizā atbilde, mazliet pretojieties. Auditi veido sarakstu; tie nesaka, ar kuru vienumu sākt. Labi ierobežots tehnisks SEO audits ir lēmumu pieņemšanas rīks, nevis panikas reakcija.

Bieži vien atklājat, ka neliels skaits lapu rada lielāko daļu datplūsmas un reklāmguvumu; pārējās ir informatīvas vai palieku. Tas nav iemesls, lai ignorētu lēnās informatīvās lapas uz visiem laikiem. Tas ir iemesls tās sakārtot pēc lapām, kurām ir tieša saikne ar ieņēmumiem. Mājaslapa var būt lēnākā no visām, bet, ja biznesa mērķis ir potenciālie klienti, mājaslapas apmeklējums ir tikai sākumpunkts—galvenā lapa ir vieta, kur kāds faktiski veic reklāmguvumu.

Sadaliet "ātri" uz "izmērītu" un "jūtamu"

Otrais solis ir atdalīt to, ko veiktspējas testi saka par jūsu lapu, no tā, ko piedzīvo reāli lietotāji. Google Core Web Vitals dokumentācija nosauc trīs rādītājus, kas tiek skaitīti meklēšanas rangā: Largest Contentful Paint (ielāde), Interaction to Next Paint (atbildība) un Cumulative Layout Shift (vizuālā stabilitāte). Tie ir svarīgi, jo tie seko brīžiem, kas ietekmē to, vai kāds patiešām var izmantot lapu.

Scenārijā jūs atverat galveno lapu veiktspējas testētājā un iegūstat saprātīgu rezultātu. Bet, kad salīdzināt to ar reālajiem datiem Google Search Console—kas atspoguļo apmeklētāju reālo pieredzi—lapa izrādās bieži lēna. Tas ir svarīgais signāls. Laboratorijas testi joprojām ir noderīgi pēc izmaiņām, lai salīdzinātu pirms un pēc. Bet reālie dati ir patiesība cilvēkiem, kuri noklikšķināja uz jūsu reklāmas no dažādām ierīcēm un savienojumiem.

Tā vietā	Sāciet ar šo	Kāpēc
PageSpeed rezultāts kā viens skaitlis	Core Web Vitals reālie dati	Reālie dati nāk no reāliem lietotājiem, nevis testa servera
"Vietne ir lēna"	Kuras lapas atbalsta biznesa mērķus	Ātras bezjēdzīgas lapas neģenerē potenciālos klientus
Pārbūvēt CMS	Kompresēt attēlus un sakopt skriptus	Zema riska labojumi sniedz lielāko daļu ieguvumu

Ja vēlaties dziļāku atsauci vēlāk, Core Web Vitals ceļvedis var jūs iepazīstināt ar katru rādītāju. Bet pagaidām jums pietiek ar to, lai izveidotu plānu. Galvenais ir nosaukt, kurš no trim rādītājiem faktiski rada problēmu šajā konkrētajā lapā. Ja teksts parādās vēlu, paskatieties uz attēliem un servera atbildi. Ja pogas šķiet raustītas, paskatieties uz garajiem JavaScript uzdevumiem. Ja izkārtojums lec, paskatieties uz vietām, kas rezervētas reklāmām un iegultiem elementiem. Šī nianse atdala mērķtiecīgu labojumu no nejaušas optimizācijas.

Salabojiet lētās lietas, pirms dārgajām

Trešais princips: neļaujiet veiktspējas projektam izvērsties par pārbūvi. Lielākā daļa uzlabojumu, kas patiešām maina lietotāja pieredzi, ir neizcili un lēti.

Apskatiet galveno lapu un nosauciet acīmredzamos vaininiekus. Attēli ir pilnas izšķirtspējas ekrānuzņēmumi. Lapā ir trešās puses skripts, kuru vairs neviens nevar identificēt. Tīmekļa fonts bloķē teksta attēlošanu. Šīs ir pazīstamas problēmas.

Ideālā pasaulē jūs pavadītu nedēļu, pārrakstot lapu ar modernu ietvaru. Praksē jūs sākat ar pusdienas uzdevumiem: kompresējiet attēlus, atlikiet neizmantoto skriptu, ielādējiet galveno attēlu iepriekš. Šīs izmaiņas varat pārbaudīt pēcpusdienā, un tām nav nepieciešama apstiprinājuma komiteja.

Brīdinājums: ātrums ne vienmēr ir tik vienkāršs. Dažas lapas ir lēnas servera, datubāzes vai trešās puses atkarības dēļ, kuru jūs nekontrolējat. Bet, ja neesat pārbaudījis lētos labojumus, vēl nevarat attaisnot dārgo. Daudzas komandas iztērē budžetu pārbūvei, jo nekad nav kompresējušas ekrānuzņēmumus. Šeit ir vērts paturēt pazemību: veiktspējas rezultāts ir simptoms, nevis diagnoze. Lētie labojumi paši ir diagnostiski. Kad esat kompresējis attēlus, jūs uzzināsit, vai sašaurinājums bija jūsu saturs vai infrastruktūra.

Pievienojiet strukturētos datus, kamēr tik un tā esat kodā

Šis ir slānis, kas pārsteidz priekšnieku. Kad esat veicis lētos labojumus, jūs jau esat lapas iekšpusē. Tas ir īstais brīdis, lai pievienotu kaut ko tādu, kas vispār nav ātrums: strukturētos datus.

Strukturētie dati ir iezīmējums, kas palīdz meklētājprogrammām saprast, ko lapa satur. Tie ir tie paši HTML, kas var nodrošināt bagātinātus meklēšanas rezultātus un labāku redzamību—un tas kļūst arvien aktuālāks, jo meklēšana virzās uz AI ģenerētām atbildēm. Mazai komandai tas ir neizmantota svira, jo nav nepieciešams rakstīt jaunu saturu. Jūs marķējat to, kas jau pastāv.

Scenārijā jūs pievienojat galvenajai lapai pakalpojumu orientētu shēmu. Precīzs veids ir atkarīgs no tā, par ko ir lapa: pakalpojuma lapa, raksts, produkts. Jums nav jāpievieno visi veidi uzreiz. Rūpīgi pievienot vienu ir labāk nekā pavirši pievienot desmit. Nav garantēts neviens rezultāts; Google izlemj, ko rādīt. Bet risks ir zems un potenciālais ieguvums ir reāls. Ja nolemjat iet dziļāk, strukturēto datu ieviešanas ceļvedis aptver praktiskās darbības.

Pārvērtiet labojumus jautājumā "vai tas nesa naudu?"

Grūtākā daļa nav tehniskais darbs. Tā ir veids, kā to pasniegt netehniskam priekšniekam.

Jūsu priekšnieks prasīja vienu: padarīt vietni ātrāku. Ja sakāt "mēs uzlabojām LCP galvenajā lapā", jūs varat saņemt tukšu skatienu. Tā vietā pārvērtiet darbu biznesa sekās.

Šajā scenārijā galvenā lapa ir apmaksātas kampaņas galamērķis. Katra sekunde, ko tā gaida, ir sekunde, kurā apmeklētājs var aiziet, pirms parādās aicinājums veikt darbību. Tātad jūs izskaidrojat: mēs noņēmām acīmredzamos šķēršļus lapā, kur notiek naudas maiņa. Jūs nevarat solīt konkrētu ranga lēcienu—ikviens, kurš to dara, min—bet jūs varat izteikt saprātīgu, godīgu argumentu. Varat to arī saistīt ar budžetu, ko jūsu priekšnieks jau saprot. Tie paši reklāmas tēriņi pērk apmeklējumu; atšķirība ir tā, vai šim apmeklējumam ir iespēja kļūt par potenciālo klientu.

Vienkāršs ikmēneša ziņojums darbojas labāk nekā ar žargonu pārslogots panelis. Parādiet trīs lietas: kuru lapu izvēlējāties, kuru rādītāju mērījāt un ko mainījāt. Ja rādītājs uzlabojas, tā ir apstiprināšana. Ja neuzlabojas, jums joprojām ir skaidrs eksperiments, ko pārvērtēt. Neļaujieties viena rezultāta vajāšanai mēnesi pēc mēneša; Core Web Vitals svārstās atkarībā no datplūsmas sastāva, ierīču veidiem un pat ģeogrāfiskā reģiona. Ziņojiet par tendenci, nevis skaitli.

Ko darīt nākamajā pirmdienā

Mācība no scenārija: jūs nelabojat "vietni". Jūs labojat konkrētu lapu, pamatojoties uz datiem, un beigās iegūstat atkārtojamu procesu, nevis vienreizēju projektu. Kad kāds ar varu saka "padariet to ātrāku", visnoderīgākā atbilde ir viens precizējošs jautājums: kura lapa un kam?

Pēc tam izmēriet reālos datus, salabojiet lētās lietas, pievienojiet strukturētos datus, ja jau esat kodā, un ziņojiet vienkāršā valodā. Rezultāti var nebūt dramatiski. Bet jūs precīzi zināsit, kura lapa kļuva ātrāka, kāpēc izvēlējāties to un ko darīt tālāk. Tas ir labāks rezultāts nekā neskaidrs projekts, kas sākās ar ātruma rezultātu un beidzās ar pārbūvi, kuru neviens nesaprata.