Fastställa prestandabudgetar

Precis som ekonomiska budgetar sätter prestandabudgetar gränser som hjälper er att hålla webbplatsen snabb och effektiv.

De är specifika och mätbara gränsvärden för olika prestandamätvärden. Se dem som skyddsräcken som förhindrar att webbplatsen blir långsam med tiden.

Utan budgetar kan prestandan gradvis försämras när nya funktioner eller nytt innehåll läggs till. Detta kallas "prestandaregression".

• Förhindra regressioner: Upptäck prestandaförsämringar tidigt.
• Bevara användarupplevelsen: Säkerställ en konsekvent snabb användarupplevelse.
• Samordna teamet: Ge utvecklarna tydliga prestandamål.
• Affärspåverkan: Skydda konverteringsgrader och SEO-placeringar.

Prestandabudgetar kan sättas för olika delar av webbplatsen. Genom att förstå dessa kategorier kan ni välja rätt fokus.

Vanliga typer är budgetar för resursstorlek, laddningstider, antal förfrågningar och även övergripande prestandapoäng.

Den här typen av budget begränsar den totala storleken på de resurser som sidan laddar. Större filer innebär längre nedladdningstider, särskilt i långsammare nätverk.

• JavaScript: till exempel högst 150 KB (gzip-komprimerat) för kritisk JS.
• CSS: till exempel högst 50 KB (gzip-komprimerat).
• Bilder: till exempel högst 1 MB totalt för alla bilder på en sida.

Dessa budgetar hjälper er att hålla sidans totala storlek under kontroll.

Dessa budgetar fokuserar på hur snabbt specifika delar av sidan laddas och blir interaktiva. De påverkar direkt användarnas uppfattning av snabbhet.

• First Contentful Paint (FCP): till exempel under 1,8 sekunder.
• Largest Contentful Paint (LCP): till exempel under 2,5 sekunder.
• Time to Interactive (TTI): till exempel under 3,8 sekunder.

Dessa är ofta kopplade till Core Web Vitals.

Ibland kan antalet objekt eller förfrågningar påverka prestandan, även om de enskilda objekten är små. Färre förfrågningar innebär ofta snabbare laddning.

• HTTP-förfrågningar: till exempel högst 30 förfrågningar per sidladdning.
• Webbfonter: till exempel högst 2 teckensnittsfamiljer.
• Tredjepartsskript: till exempel högst 5 externa skript.

Detta hjälper till att minska belastningen på nätverket och vid bearbetning.

Ni kan också basera budgetar på övergripande prestandapoäng från verktyg som Google Lighthouse. Det ger ett helhetsinriktat mål för webbplatsens hälsa.

Ni kan till exempel sikta på en lägsta Lighthouse Performance Score på 90 för mobil. Det kombinerar många mätvärden till ett enda lättöverskådligt tal.

Innan ni sätter budgetar behöver ni känna till den aktuella prestandan. Den här "baslinjen" hjälper er att definiera realistiska mål som gör verklig skillnad.

• Granska webbplatsen: Använd Lighthouse eller andra verktyg för att mäta aktuella mätvärden.
• Analysera konkurrenter: Se hur webbplatsen står sig mot branschledande webbplatser.
• Förstå användardata: Kontrollera analysdata för verklig användarprestanda (RUM-data).

Målen för prestandabudgeten bör vara ambitiösa men uppnåeliga. Ta hänsyn till användarnas förväntningar, verksamhetens mål och tekniska begränsningar.

Börja med några viktiga mätvärden och iterera. Det är bättre att konsekvent nå några få viktiga mål än att missa många alltför aggressiva mål.

Vi har lärt oss att prestandabudgetar är avgörande för att hålla en webbplats snabb över tid. De fungerar som gränser för olika mätvärden.

Ni kan skapa budgetar utifrån resursstorlek, laddningstid, antal förfrågningar eller övergripande prestandapoäng. Fastställ alltid en baslinje innan ni sätter realistiska och uppnåeliga mål.