Kā izveidot veiktspējas budžetus, kas patiešām tiek ievēroti katram klientam

Kopsavilkums

Veiktspējas budžeti ir rakstiskas vienošanās par to, cik ātrai jābūt vietnei, ko noslēdz aģentūra un tās klients. Tie novērš ļoti izplatīto modeli, kad lapa tiek optimizēta palaišanas brīdī, bet pēc tam tā lēnām pasliktinās, jo tiek pievienoti jauni skripti un funkcijas. Šī raksta ietvars sniedz atkārtojamu procesu šo budžetu izveidei, komunikācijai un ieviešanai visos kontos. Jūs uzzināsiet, kā izvēlēties uz lietotāju orientētus rādītājus, kas patiešām atspoguļo apmeklētāju pieredzi, noteikt sliekšņus, pamatojoties uz reāliem apstākļiem, nevis vispārējiem kontrolsarakstiem, un pārvērst budžetu redzamā līgumā. Rakstā ir arī aprakstīts, kā budžetu iekļaut piegādes darba plūsmā, risināt pārkāpumus bez konfrontējošām sarunām un pārskatīt budžetu reizi ceturksnī. Gala rezultāts ir tāds, ka lapas ātrums vairs nav ikmēneša panikas avots, bet kļūst par iezīmi, ko jūsu aģentūra pārvalda apzināti.

Cik reižu esat nodevis klientam ātri ielādējamu lapu, lai vēlāk redzētu, kā tā lēnām pārvēršas par gausu, ar skriptiem pārslogotu savu ēnu? Ja strādājat aģentūrā, atbilde, iespējams, ir "biežāk, nekā es vēlētos." Modelis vienmēr ir tāds pats: jūs optimizējat mājaslapu, svinat zaļo rezultātu, un pēc trim mēnešiem klienta mārketinga komanda pievieno jaunu tērzēšanas robota skriptu, kas ievērojami palēnina darbību. Pēkšņi jūs atkal esat pie telefona un skaidrojat, kāpēc vietne šķiet lēna, lai gan jūs to jau esat salabojis.

Tā nav tehniska kļūme; tā ir pārvaldības kļūme. Veiktspēja tiek uzskatīta par vienreizēju palaišanas uzdevumu, nevis pastāvīgu vienošanos. Risinājums ir veiktspējas budžets: rakstisks, saskaņots ierobežojums tam, cik smaga vai lēna lapa drīkst kļūt, pirms tā tiek uzskatīta par neatbilstošu. Bet pats budžets ir tikai puse vērtības; patiesā vērtība ir tā, ka tas liek jums un jūsu klientam skaidri definēt kompromisus — pirms tiek pievienots jauns skripts, spraudnis vai funkcija.

Turpmākajās darbībās es aprakstīšu, kā izveidot, komunicēt un ieviest veiktspējas budžetus vairākiem klientiem, katru reizi neizgudrojot riteni no jauna.

1. darbība: Izvēlieties rādītājus, kas atspoguļo lietotāja pieredzi

Veiktspējas budžets ir noderīgs tikai tad, ja skaitļi, kurus ierobežojat, atbilst tam, ko jūt jūsu klienta lietotāji. Pārāk daudzas aģentūras nosaka budžetu, pamatojoties uz vienu laboratorijas rādītāju, piemēram, laiku līdz pirmajam baitam, kuram nav tiešas korelācijas ar to, vai lapa šķiet ātra. Google pašas ieteikumi ir virzījušies uz lietotāju orientētiem rādītājiem, tāpēc Core Web Vitals ir veidoti ap tādiem aspektiem kā, cik ilgi nepieciešams, lai parādītos galvenais saturs. Saskaņā ar Google SEO Starter Guide, lapas ātrums ir ranžēšanas faktors; saskaņā ar web.dev, Core Web Vitals mēra lietotāja pieredzi. Šie avoti liek izvēlēties rādītājus, kas atspoguļo lietotāja ceļu, ne tikai servera atbildes laiku.

Lielākajai daļai klientu vietņu sāciet ar Core Web Vitals un aptuvenu lapas svara budžetu. Neizsekojiet visiem rādītājiem katrā lapā. Mārketinga vietne var koncentrēties uz largest contentful paint, jo tas ir brīdis, kad parādās hero attēls; tīmekļa lietotne var vairāk rūpēties par interaction to next paint, jo interaktivitāte ir viss tās bizness. Ja nepieciešams atsvaidzināt zināšanas par šiem rādītājiem, mūsu soli pa solim sniegtais ceļvedis Core Web Vitals optimizēšanai to detalizēti apraksta.

2. darbība: Nosakiet budžetu, pamatojoties uz reāliem apstākļiem, nevis etaloniem

Iedomājieties klientu, kurš pārdod ar rokām darinātas mēbeles. Viņu auditorija pārsvarā ir vecāka par 40 gadiem, iepērkas no planšetdatora, izmantojot lauku pieslēgumu. Ja kopēsiet "ieteiktos" sliekšņus no vispārējā audita kontrolsaraksta, jūs noteiksiet skaitļus, kas neatspoguļo šo realitāti. Mērķis, kas der pilsētas profesionālim 5G tīklā, var būt neiespējams cilvēkam ar DSL līniju. Budžetam ir jābūt jēgpilnam cilvēkiem, kuri vietni faktiski izmanto.

Sāciet ar klienta lēnāko svarīgo lapu kā bāzes līniju. Izmēriet to ar aparatūru un tīklu, kāds, visticamāk, ir jūsu klienta lietotājiem. Pēc tam nosakiet mērķi, kas ir ievērojami labāks par pašreizējo stāvokli, bet ne tik agresīvs, ka prasa pilnīgu pārbūvi. Un sadaliet budžetu pēc veidnes veida: norēķinu plūsmai jābūt ar stingrāku budžetu nekā "Par mums" lapai, jo lēns norēķinu process tieši samazina ieņēmumus.

3. darbība: Padariet budžetu redzamu un saņemiet apstiprinājumu

Paņemiet saskaņoto budžetu un pārvērtiet to vienas lapas dokumentā. Vienā pusē uzskaitiet rādītājus un noteiktos sliekšņus. Otrā pusē tulkojiet šos sliekšņus vienkāršas valodas aprakstos: zaļš nozīmē, ka lapa ielādējas pietiekami ātri, lai cilvēki neaizietu; sarkans nozīmē, ka nepieciešami būtiski uzlabojumi. Prezentējiet to klientam kā prasību, nevis ieteikumu. Saņemiet apstiprinājumu no lēmumu pieņēmēja, ne tikai no kontaktpersonas.

Noderīga pieeja ir parādīt, cik lietotāja uzmanības katrs rādītājs maksā. Tā vietā, lai teiktu "mūsu LCP ir slikts," sakiet: "galvenā satura ielāde prasa tik ilgu laiku, ka daudzi apmeklētāji padodas." Tagad klients saprot, kas ir uz spēles. Kad kāds vēlāk vēlas pievienot skriptu, kas iestumj lapu sarkanajā zonā, varat norādīt uz parakstīto budžetu un jautāt, ko viņi vēlētos samazināt. Tas vairs nav personiski — tā ir vienošanās, ko noslēdzāt kopā.

4. darbība: Iestrādājiet budžetu savā piegādes procesā

Budžets, kas pastāv tikai prezentācijā, nav budžets. Tam ir jābūt iestrādātam tajā, kā veidojat, testējat un pārskatāt lapas. Pievienojiet veiktspējas pārbaudi savam QA procesam: pirms jebkura lapa tiek izlaista, veiciet mērījumu un salīdziniet to ar budžetu. Ja tas ir pārsniegts, lapa netiek izlaista, kamēr kāds neveic kompromisu.

Praksē tas nozīmē katrai lapai piešķirt fiksētu svara apjomu. Attēli un video parasti ir lielākie vaininieki, tāpēc izveidojiet politiku: katrs attēls ir jāsaspiež, katram videoklipam jāpiemēro lazy-load, un katrs trešās puses skripts ir jāauditē pirms tā pievienošanas. Klienta mārketinga komandai, iespējams, nepatiks dzirdēt, ka viņu jaunajam izsekošanas skriptam ir jāgaida, bet, ja tas pārkāpj budžetu, vairs nav jautājums par "jā" vai "nē"; tas ir kompromiss. Šeit budžets kļūst par jūsu parastās darba plūsmas daļu — un, ja jūsu aģentūrai ir atkārtojama SEO veiktspējas darba plūsma, budžets tajā dabiski iekļaujas.

5. darbība: Rīkojieties ar pārkāpumiem bez vainošanas

Iedomājieties, ka klienta IT komanda pievieno jaunu analītikas komplektu, kas ievērojami palielina katras lapas svaru. Budžets tagad ir sarkans. Sliktākais, ko varat darīt, ir nosūtīt apsūdzošu e-pastu. Tā vietā uzskatiet budžetu par neitrālu šķīrējtiesnesi. Jūs viņiem nesakāt "nē"; jūs sakāt "budžets saka nē." Tas novirza sarunu no personīgās izvēles uz objektīvu mērījumu. Tagad uzdevums kļūst: ko mēs samazinām, lai atkal būtu zem budžeta? Varbūt jauno analītikas komplektu var konfigurēt tā, lai tas ielādētos pēc aizkaves, vai varbūt varat noņemt vecāku lieku skriptu.

Praksē jums ir nepieciešams vienkāršs prioritizēšanas process budžeta pārkāpumiem: noskaidrojiet, kas ir mainījies, novērtējiet ietekmi un jautājiet klientam, vai viņi vēlas paturēt jauno funkciju vai ievērot budžetu. Ja viņi izvēlas funkciju, viņi oficiāli nolemj atteikties no budžeta. Tā ir vērtīga informācija, jo tā parāda, kur ir viņu patiesās prioritātes.

6. darbība: Pārskatiet un atjauniniet reizi ceturksnī

Iestatiet kalendāra atgādinājumu, lai katru ceturksni pārskatītu katra klienta budžetu. Tīmeklis mainās, jūsu klienta bizness mainās un jūsu mērījumu dati mainās. Budžets, kas pirms gada bija neiespējams, tagad var būt viegls, vai otrādi. Izmantojiet reālus lietotāju datus no analītikas un laboratorijas testiem, lai to pielāgotu. Šīs pārskatīšanas ietvaros padomājiet, kuru lapu prioritizēt nākamo; lēnā lapa, kam ir nozīme, nav mājaslapa.

Bet neļaujiet pārskatīšanai kļūt par attaisnojumu budžeta atvieglošanai ikreiz, kad kāds vēlas pievienot funkciju. Pārskatīšanai jābalstās uz datiem par lietotāja pieredzi, nevis uz klienta pretestību. Ir vilinoši teikt: "ja viņiem nerūp ātrums, kāpēc lai mums rūp?" Taču pētījumi ir skaidri: Google ir apstiprinājis, ka lapas ātrums ir ranžēšanas faktors, un Core Web Vitals ir ranžēšanas faktors. Jūsu kā aģentūras uzdevums ir turēt šo faktu uzmanības centrā.

Secinājums

Veiktspējas budžeti nav par noteikumu diktēšanu; tie ir par kompromisu skaidru noteikšanu. Kad nosakāt budžetu, jūs savam klientam sniedzat vienkāršu veidu, kā saprast viņu digitālo lēmumu izmaksas. Kad jūs nodrošināt tā ievērošanu, jūs pasargājat sevi no bezgalīgiem "kāpēc tā atkal ir lēna" e-pastiem. Un, kad jūs to pārskatāt, jūs saglabājat vietni saskaņotu ar to, kas patiesi nepieciešams lietotājiem.

Sāciet ar vienu klientu. Pielietojiet darbības, uzziniet, kas darbojas, un pēc tam iekļaujiet budžetu savā standarta onboarding paketē. Pēc dažiem mēnešiem jums būs paredzams, atkārtojams process, kas darbojas visos kontos — un lapas ātrums vairs nebūs ikmēneša krīze, bet kļūs par iezīmi, ko jūsu aģentūra pārvalda apzināti.