Prestandaproblem i AngularJS-applikationer uppkommer då och då. Ibland är det kopplat till de begräsningar som finns i ramverket eller dålig arkitektur i applikationen. I korthet kan man säga att de flesta prestandaproblem är kopplade till att man vill uträtta för mycket i en och samma vy. AngularJS har begräsningar i hur många databindningar man kan använda på en gång.
När du placerar ut data i en AngularJS-vy eller binder ett element till en modell registrerar du en eller flera watches. Vid varje digest-cycle, vilket sker vid ett knapp-tryck etc, itereras alla watches och databindningar uppdateras. Finns det fler 1 000 watches i en vy blir det en märkbar fördröjning från ett klick eller tangenttryck. För en snabb och alert applikation bör du sikta på att ha under 500 watches.
Du kan enkelt undersöka hur många watches din applikation har genom att använda Batarang, ett Google Chrome plugin från angularJS-utvecklarna.
Reducera antalet watches för bättre prestanda.
Ett enkelt sätt att minska antalet watches är one-time binding. Detta innebär att din databindning endast uppdateras en gång och ej kommer att utvärderas vid varje digest. I de flesta applikationer kan man byta ut mer än hälften av alla databindningar till att endast utvärderas en gång.
Försök reducera antalet DOM-element som är laddade på en gång. Är antalet element stort och du har en komplicerad HTML-struktur har du antagligen flera prestandatjuvar. Färdiga direktiv från nätet är behändigt, men du har sällan insyn i hur krävande de är. Ett exempel är tabbar som endast kosmetiskt har dolt data, alla element, watches och händelselyssnare finns kvar i bakgrunden.
Du kan minska ner dokumentstorleken genom att exempelvis använda ng-if istället för ng-show. Kom bara ihåg att du kan behöva sätta tillbaka eventlyssnare.
Ett annat angreppssätt är utgå från vad som syns för användaren. Bygg inte layouter som är baserade på att användaren ska scrolla, istället ha fler vyer som användaren navigerar mellan. Likaså ska du inte ha tabeller etc som är större än en sida, paginera istället resultaten.
Om möjligt var pragmatisk och acceptera de begräsningar som finns i ramverket. Introducera extra vyer om du tror att prestanda kan bli ett problem. Lägg inte flera stora dynamiska element på samma vy, utan bryt upp och sprid ut. Utgå till exempel från vad som används mest i applikationen kräv att användaren navigerar med några extra musklick för att hitta det som används mindre ofta.
En spinner löser många prestandaproblem. Ge användaren en upplevelse av att något händer så ökar acceptansen för laddningstider avsevärt.
Till artikeln finns ett enkelt testprojekt du kan använda för att experimentera med Angular Batarang.
