Kaip sukurti našumo biudžetus, kurie tikrai prigyja kiekvienam klientui

Santrauka

Našumo biudžetai yra rašytiniai susitarimai dėl to, koks greitas turi būti tinklalapis, sudaryti tarp agentūros ir jos kliento. Jie apsaugo nuo labai dažno modelio, kai puslapis optimizuojamas paleidimo metu, o paskui stebima, kaip jis pamažu blogėja, kai pridedami nauji scenarijai ir funkcijos. Šiame straipsnyje pateikta sistema suteikia pakartojamą procesą, kaip kurti, perteikti ir įgyvendinti šiuos biudžetus kiekviename projekte. Sužinosite, kaip pasirinkti į vartotoją orientuotas metrikas, kurios iš tikrųjų atspindi lankytojų patirtį, nustatyti ribas pagal realias sąlygas, o ne pagal bendruosius sąrašus, ir paversti biudžetą matoma sutartimi. Straipsnyje taip pat aptariama, kaip įterpti biudžetą į savo pristatymo darbo eigą, kaip spręsti pažeidimus be konfrontacijų ir kaip kas ketvirtį peržiūrėti biudžetą. Galutinis rezultatas – puslapio greitis nebėra mėnesinės panikos šaltinis, o tampa funkcija, kurią jūsų agentūra valdo apgalvotai.

Kiek kartų pristatėte klientui greitai įkraunamą puslapį, o paskui stebėjote, kaip jis pamažu vėl tampa lėtu, scenarijais perkrautu savo pačio šešėliu? Jei dirbate agentūroje, atsakymas tikriausiai yra „dažniau, nei norėčiau". Modelis visada tas pats: optimizuojate pagrindinį puslapį, džiaugiatės žaliu balu, o po trijų mėnesių kliento rinkodaros komanda įdeda naują pokalbio roboto scenarijų, kuris sukelia pastebimą vėlavimą. Ir štai vėl kalbate telefonu, aiškindami, kodėl svetainė atrodo lėta, nors jau tai ištaisėte.

Tai nėra techninė nesėkmė; tai valdymo nesėkmė. Našumas traktuojamas kaip vienkartinė paleidimo užduotis, o ne kaip nuolatinis susitarimas. Sprendimas – našumo biudžetas: rašytinis, abipusiai sutartas limitas, kiek puslapis gali būti sunkus ar lėtas, kol jis laikomas neatitinkančiu reikalavimų. Tačiau pats biudžetas yra tik pusė vertės; tikroji vertė yra tai, kad jis priverčia jus ir klientą aiškiai įvardinti kompromisus – prieš pridedant naują scenarijų, papildinį ar funkciją.

Tolesniuose žingsniuose parodysiu, kaip kurti, perteikti ir įgyvendinti našumo biudžetus keliems klientams, kiekvieną kartą neišrandant dviračio iš naujo.

1 žingsnis: pasirinkite metrikas, atspindinčias vartotojo patirtį

Našumo biudžetas naudingas tik tada, kai skaičiai, kuriuos ribojate, atitinka tai, ką jaučia jūsų kliento vartotojai. Per daug agentūrų nustato biudžetą pagal vieną laboratorijos metriką, pavyzdžiui, laiką iki pirmojo baito, kuri neturi tiesioginės sąsajos su tuo, ar puslapis atrodo greitas. Pati Google perėjo prie į vartotoją orientuotų metrikų, todėl Core Web Vitals yra pagrįstos tokiais dalykais kaip laikas, per kurį pasirodo pagrindinis turinys. Pasak Google SEO pradedančiųjų vadovo, puslapio greitis yra reitingavimo veiksnys; pasak web.dev, Core Web Vitals matuoja vartotojo patirtį. Šie šaltiniai sako, kad reikia rinktis metrikas, atspindinčias vartotojo kelią, o ne tik serverio atsako laiką.

Daugeliui klientų svetainių pradėkite nuo Core Web Vitals ir apytikslio puslapio svorio biudžeto. Nestebėkite visų jų kiekviename puslapyje. Rinkodaros svetainė gali sutelkti dėmesį į didžiausio turinio atvaizdavimą (LCP), nes tada pasirodo herojaus paveikslėlis; žiniatinklio programėlei svarbiau gali būti sąveika iki kito atvaizdavimo (INP), nes sąveika yra visas jos verslas. Jei norite atnaujinti šių metrikų žinias, mūsų žingsnis po žingsnio vadovas, kaip optimizuoti Core Web Vitals, išsamiai tai aptaria.

2 žingsnis: nustatykite biudžetą pagal realias sąlygas, o ne pagal etalonus

Įsivaizduokite klientą, kuris parduoda rankų darbo baldus. Jo auditorija daugiausia vyresnė nei 40 metų, perka iš planšetinio kompiuterio naudodama kaimo ryšį. Jei nukopijuosite „rekomenduojamas" ribas iš bendro audito sąrašo, nustatysite skaičius, neatspindinčius realybės. Tikslas, kuris tinka miesto profesionalui naudojant 5G, gali būti neįmanomas žmogui su DSL linija. Biudžetas turi būti prasmingas žmonėms, kurie iš tikrųjų naudojasi svetaine.

Pradėkite nuo lėčiausio kliento svarbaus puslapio kaip atskaitos taško. Išmatuokite jį naudodami aparatinę įrangą ir tinklą, kuriuos greičiausiai naudoja jūsų kliento vartotojai. Tada nustatykite tikslą, kuris yra pastebimai geresnis nei dabartinė būsena, bet ne toks agresyvus, kad reikėtų visiškai perdaryti svetainę. Taip pat suskirstykite biudžetą pagal šablonų tipą: mokėjimo procesas turėtų turėti griežtesnį biudžetą nei puslapis „Apie", nes lėtas mokėjimas tiesiogiai mažina pajamas.

3 žingsnis: padarykite biudžetą matomą ir gaukite patvirtinimą

Paimkite sutartą biudžetą ir paverskite jį vieno puslapio dokumentu. Vienoje pusėje išvardykite nustatytas metrikas ir ribas. Kitoje pusėje paaiškinkite tas ribas paprasta kalba: žalia reiškia, kad puslapis įkeliamas pakankamai greitai, kad žmonės neišeitų; raudona reiškia, kad reikia didelių patobulinimų. Pateikite jį klientui kaip reikalavimą, o ne pasiūlymą. Gaukite patvirtinimą iš sprendimus priimančio asmens, o ne tik iš kontaktinio asmens.

Vienas naudingas būdas – parodyti, kiek vartotojo dėmesio kainuoja kiekviena metrika. Vietoj „mūsų LCP prastas" sakykite „pagrindinis turinys įkeliamas taip ilgai, kad daugelis lankytojų pasiduos". Dabar klientas supranta, kas gresia. Kai vėliau kas nors norės pridėti scenarijų, kuris nustums puslapį į raudoną zoną, galėsite parodyti pasirašytą biudžetą ir paklausti, ką jie norėtų pašalinti. Tai nebe asmeniška – tai susitarimas, kurį sudarėte kartu.

4 žingsnis: įterpkite biudžetą į savo pristatymo procesą

Biudžetas, kuris egzistuoja tik pristatymo skaidrėse, nėra biudžetas. Jis turi būti įterptas į tai, kaip kuriate, testuojate ir peržiūrite puslapius. Į savo kokybės užtikrinimo procesą įtraukite našumo patikrą: prieš išleidžiant bet kurį puslapį, atlikite matavimą ir palyginkite jį su biudžetu. Jei jis viršijamas, puslapis neišleidžiamas, kol kas nors nepadaro kompromiso.

Praktiškai tai reiškia, kad kiekvienam puslapiui skiriamas fiksuotas svoris. Paprastai didžiausi kaltininkai yra vaizdai ir vaizdo įrašai, todėl nustatykite politiką: kiekvienas paveikslėlis turi būti suspaustas, kiekvienas vaizdo įrašas turi būti įkeliamas vėluojant (lazy-load), o kiekvienas trečiosios šalies scenarijus turi būti audituojamas prieš jį pridedant. Kliento rinkodaros komandai gali nepatikti žinia, kad jų naujas stebėjimo scenarijus turi palaukti, bet jei jis pažeidžia biudžetą, tai nebėra klausimas „taip ar ne"; tai kompromisas. Čia biudžetas tampa įprastos darbo eigos dalimi – ir jei jūsų agentūra turi pakartojamą SEO našumo darbo eigą, biudžetas į ją natūraliai įsilieja.

5 žingsnis: spręskite pažeidimus be kaltinimų

Įsivaizduokite, kad kliento IT komanda prideda naują analitikos rinkinį, kuris žymiai padidina kiekvieno puslapio svorį. Biudžetas dabar raudonas. Blogiausia, ką galite padaryti, tai išsiųsti kaltinantį el. laišką. Vietoj to vertinkite biudžetą kaip neutralų teisėją. Jūs nesakote jiems „ne"; jūs sakote „biudžetas sako ne". Tai perkelia pokalbį nuo asmeninių pageidavimų prie objektyvaus matavimo. Dabar užduotis tampa: ką pašalinti, kad grįžtume į leistinas ribas? Galbūt naują analitikos rinkinį galima sukonfigūruoti taip, kad jis įsikeltų su vėlavimu, arba galite pašalinti senesnį scenarijų, kuris yra nereikalingas.

Praktiškai jums reikia paprasto triažo proceso biudžeto pažeidimams nustatyti: nustatykite, kas pasikeitė, įvertinkite poveikį ir paklauskite kliento, ar jie nori išlaikyti naują funkciją, ar laikytis biudžeto. Jei jie pasirenka funkciją, jie oficialiai nusprendžia atsisakyti biudžeto. Tai vertinga informacija, nes parodo, kur yra tikrieji jų prioritetai.

6 žingsnis: peržiūrėkite ir atnaujinkite kas ketvirtį

Nusistatykite kalendoriaus priminimą kas ketvirtį peržiūrėti kiekvieno kliento biudžetą. Žiniatinklis keičiasi, jūsų kliento verslas keičiasi, o jūsų matavimo duomenys taip pat keičiasi. Biudžetas, kuris prieš metus buvo neįmanomas, dabar gali būti lengvai pasiekiamas, arba atvirkščiai. Naudokite realius vartotojų duomenis iš analitikos ir laboratorinių testų, kad atliktumėte pakeitimus. Per tą peržiūrą pagalvokite, kurį puslapį prioritizuoti toliau; lėtas puslapis, kuris turi reikšmės, nėra pagrindinis puslapis.

Tačiau neleiskite, kad peržiūra taptų pasiteisinimu kiekvieną kartą atlaisvinti biudžetą, kai kas nors nori pridėti funkciją. Peržiūra turėtų būti pagrįsta duomenimis apie vartotojo patirtį, o ne kliento pasipriešinimu. Gali kilti pagunda sakyti: „Na, jei jiems nerūpi greitis, kodėl turėtų rūpėti mums?" Tačiau tyrimai aiškūs: Google patvirtino, kad puslapio greitis yra reitingavimo veiksnys, o Core Web Vitals taip pat yra reitingavimo veiksnys. Jūsų, kaip agentūros, darbas yra nepamiršti šio fakto.

Išvada

Našumo biudžetai nėra skirti nurodinėti; jie skirti aiškiai įvardyti kompromisus. Kai nustatote biudžetą, suteikiate klientui paprastą būdą suprasti savo skaitmeninių sprendimų kainą. Kai jį įgyvendinate, apsisaugote nuo begalinių el. laiškų „kodėl vėl lėta". O kai jį peržiūrite, išlaikote svetainę atitinkančią realius vartotojų poreikius.

Pradėkite nuo vieno kliento. Taikykite žingsnius, sužinokite, kas veikia, ir įtraukite biudžetą į savo standartinį įvedimo paketą. Po kelių mėnesių turėsite nuspėjamą, pakartojamą procesą, kuris veiks kiekviename projekte – ir puslapio greitis nebebus mėnesinė krizė, o taps funkcija, kurią jūsų agentūra valdo apgalvotai.