Siden sidehastighet har blitt en viktig beregning for både SEO og UX gjennom årene, har konseptet med en nettytelsesbudsjett har også kommet i forgrunnen. Det er nå tydeligere at nettytelse er et tema som krever et delt perspektiv på tvers av alle avdelinger, i stedet for bare å prioritere en enkelt avdeling eller enkeltperson.
For å forklare dette med et eksempel: markedsavdelinger vil kanskje implementere konvertering og remarketing/retargeting-koder, sammen med verktøy som Criteo og RTB House, som bruker produktbasert retargeting. De kan også forvente iøynefallende bilder og animasjoner. I mellomtiden kan produktavdelinger be om integrering av verktøy som Hotjar og Klarhet. Programvareavdelinger har derimot som mål å utvikle seg så raskt som mulig både på frontend og backend. Etterspørselen og kostnadene knyttet til disse kravene til sidehastighet er faktisk i balanse. Nettytelsesbudsjettet har dukket opp for å etablere denne balansen effektivt.
Et nettytelsesbudsjett innebærer å sette en målhastighet for plattformen din på en spesifikk plattform og etablere numeriske mål som alle interessenter vil overholde for å oppnå denne hastigheten. Kort sagt, kostnaden ved å være rask er ytelsesbudsjettet på nettet.
Alt starter med et forslag. Du foreslår hvor raskt siden din skal åpne på en bestemt type tilkobling. Noen resultatbudsjettforslag kan for eksempel være:
- Kan hjemmesiden åpnes inn under 2 sekunder på en rask 3G-mobilforbindelse (1.6 Mbps)?
- Kan søkeresultatsiden åpnes inn under 5 sekunder på en treg 3G-tilkobling (780 Kbps)?
Deretter lager du en handlingsplan og underberegninger for å oppnå disse forslagene, og deler det ned i deler.
Bortsett fra forslag, kan det være andre resultatbudsjettmål. For eksempel:
- Øke det mobile fyrtårnet poengsum på detaljsiden over 80
- Reduserer størrelsen på alle bilder på skrivebordssiden til under 500 KB
Resultatbudsjettberegninger
Det er tre forskjellige perspektiver som godtas for å bestemme beregningene for et resultatbudsjett:
Tallbaserte beregninger
- Maksimalt antall fonter / Maksimal skriftstørrelse
- Maksimalt antall bilder / Maksimal bildestørrelse
- Maksimalt antall skript, stiler, videoer, etc. / Maksimalt antall skript, stiler, videoer osv.
- Maksimal HTML-størrelse
- Maksimalt antall HTTP-forespørsler
- Maksimalt antall tredjepartsskript
Tidsbaserte beregninger
- Første Contentful Paint (FCP) tid
- Største Contentful Paint (LCP) tid
- Første inngangsforsinkelse (FID) tid
- Tid til interaktiv (TTI) tid
- Total Blocking Time (TBT) tid
- Cumulative Layout Shift (CLS) poengsum
- Speed Index score
Regelbaserte beregninger
- Lighthouse score
- GTmetrix-poengsum
- Nettsidetestresultat
- Lav poengsum
Når du angir nettytelsesbudsjettet ditt, anbefales det generelt å kombinere alle disse perspektivene i riktig mål i stedet for å velge bare ett. Du kan bruke resultatbudsjettsimulatoren for å finne tallene som trengs for å nå målhastigheten.
Vurder sidetyper separat
Et avgjørende poeng når du skal bestemme resultatbudsjettet, er å ikke basere det på en enkelt side på nettstedet. En vanlig feil er å teste kun hjemmesiden, noe som fører til en ufullstendig evaluering.
Du bør begynne med å undersøke plattformen og identifisere ulike typer sider. Analyser deretter plattformens trafikk for å identifisere sidene som mottar mest trafikk og prioriter dem. Resultatet vil være en tabell som ligner denne:
- Hjemmeside
- Statiske oppføringssider
- Dynamiske oppføringssider
- Detaljsider
- Kassesider
- Søkeresultatsider
- Kampanjesider
- Bloggsider
Du må fokusere på resultatbudsjettene for disse sidetypene separat, basert på prioriteringene.
