Prestationsbudget

En prestandabudget är en uppsättning explicita gränser för de egenskaper som avgör hur snabbt en sida laddas och svarar, vilka överenskommits i förväg och tillämpas som en del av utvecklingsprocessen. Budgetar uttrycks vanligtvis som tröskelvärden för mätvärden som Största innehållsrika färg, för kvantiteter som total JavaScript-storlek eller för regler som antalet tillåtna tredjepartsförfrågningar.

Problemet den åtgärdar är regression snarare än optimering. Webbplatser blir inte långsamma genom ett enda beslut; de ackumulerar vikt genom många individuellt rimliga tillägg, vart och ett för litet för att orsaka oro. En ny funktion, ett ytterligare spårningsskript, en större huvudbild, en annan teckensnittsvikt och en uppgradering av komponentbiblioteket lägger var och en till en bråkdels sekund, och efter två år är webbplatsen betydligt långsammare utan någon identifierbar orsak. En budget gör att varje tillägg ställs inför en gräns.

Budgetar fungerar eftersom de omvandlar en abstrakt preferens för hastighet till en begränsning som måste åtgärdas när ett beslut fattas. Utan en sådan sker diskussionen om huruvida ett manus är värt sin kostnad i efterhand, om alls, och den person som föreslår tillägget har ingen anledning att överväga det. Med en sådan innebär tillägg att antingen hålla sig inom gränsen eller uttryckligen ta bort något annat, vilket är den avvägning som borde ske ändå.

Att fastställa siffrorna kräver bevis snarare än ambitioner. Användbara ankare inkluderar nuvarande prestanda, så att budgeten förhindrar försämring; konkurrentmätningar, så att målet återspeglar den marknad som webbplatsen konkurrerar på; och tröskelvärdena som är kopplade till de mätvärden som är viktiga för sökning och användarupplevelse. Budgetar som sätts på nivåer som webbplatsen för närvarande inte kan uppfylla är användbara som mål men måste särskiljas från begränsningar som tillämpas på nytt arbete, annars misslyckas varje byggprocess och kontrollen inaktiveras.

Tillämpning inom automatiserad verktygshantering är det som skiljer en budget från ett dokument. Att integrera kontrollen i byggprocessen, så att en ändring som överskrider gränsen misslyckas eller kräver uttryckligt godkännande, är den mekanism som producerar beteendet. Budgetar som registrerats i en specifikation och kontrolleras regelbundet av en intresserad ingenjör överskrids rutinmässigt, eftersom när någon märker att arbetet har levererats överstiger kostnaden för återföring kostnaden för att acceptera det.

Granulariteten bör matcha hur webbplatsen är byggd. Olika mallar har olika egenskaper, och en enda webbplatsomfattande budget begränsar antingen en enkel sida i onödan eller tillåter en interaktiv sida att expandera okontrollerat. Att sätta budgetar per mall, med de mest krävande gränserna för de mest värdefulla sökvägarna, såsom landnings- och kassasidor, styr begränsningen dit den spelar mest roll.

Undantag behöver en definierad process snarare än att vara antingen förbjudna eller informella. Legitima fall uppstår där en funktion verkligen motiverar extra vikt, och en budget utan undantagsväg antingen kringgås eller blockerar värdefullt arbete. Att kräva att undantaget begärs, godkänns av någon som ansvarar för prestanda och registreras med ett utgångsdatum gör att mekanismen hålls trovärdig samtidigt som den tillåter genuina fall att passera.

Eftersom budgetar begränsar beslut som fattas inom teknik, design och marknadsföring, kräver de överenskommelse utanför teamet som mäter prestanda. I praktiken sätts gränserna genom webbprestanda arbete, verkställighet är inbyggd i processen genom produktutveckling, och de kommersiella argumenten för begränsningen görs vanligtvis genom att koppla prestanda till konvertering med hjälp av den analys som upprätthålls genom uppgifter analytics.