In a previous job I had to declare war against google tag manager (tool that let marketers inject random crap in your web application without developer input). Burned some bridges and didn't win, performance is still crap.
After those things it is the heavy libs that cause performance problems, like maps and charts, usually some clever lazy loading fixes that. Some things I personally ran into:
- QR code scanning lib and Map lib being loaded at startup when it was actually just really small features on the application
- ALL internationalisation strings being loaded at startup as a waterfall request before any other JS ran. Never managed to get this one fixed...
- Zendesk just completely destroys your page performance, mandated through upper-management, all I could do was add a delay to load it
After that then it comes just badly designed code triggering too many DOM elements and/or rerenders and/or waterfall requests.
After that comes app-level code size, some lazy loading also fixes this, but it is usually not necessary until your application is massive.
After those things it is the heavy libs that cause performance problems, like maps and charts, usually some clever lazy loading fixes that. Some things I personally ran into: - QR code scanning lib and Map lib being loaded at startup when it was actually just really small features on the application - ALL internationalisation strings being loaded at startup as a waterfall request before any other JS ran. Never managed to get this one fixed... - Zendesk just completely destroys your page performance, mandated through upper-management, all I could do was add a delay to load it
After that then it comes just badly designed code triggering too many DOM elements and/or rerenders and/or waterfall requests.
After that comes app-level code size, some lazy loading also fixes this, but it is usually not necessary until your application is massive.