AngularJS Performance in Large Applications
A lot of the advice involves less separations of concerns in your code ("don't use $watch", "don't use isolated scopes"), but it's a nice summary of what eats time in Angular.
Note that for the purpose of this article "large" mostly mean "large number of watchers/bindings on a single screen". Angular doesn't automatically become large just because you have a lot of screens.
Related cards:
Techniques for authentication in AngularJS applications
Article about implementing authentication (current_user) and authorization (access rights) in AngularJS.
Has an surprising amount of practical and understandable code.
AngularJS 1 Performance: One-time bindings in expressions
In addition to the {{ myValue }} two-way binding syntax, since Angular 1.3 there's a one-time binding syntax, prefixing the value or expression with ::, e.g. {{ ::myValue }}, {{ ::myValue >= 42 }} and {{ ::myExpression(value) | someFilter }}...
How to create giant memory leaks in AngularJS (and other client-side JavaScript)
This guide shows how to create an AngularJS application that consumes more and more memory until, eventually, the browser process crashes on your users.
Although this guide has been written for Angular 1 originally, most of the advice is relevant...
Improving browser rendering performance
As the web is being used for more and more tasks, expectations rise. Not only should web pages offer rich interaction, they must be responsive in both size and interaction.
This imposes a paradoxon that needs to be solved by building performing a...
Best practices: Large data migrations from legacy systems
Migrating data from a legacy into a new system can be a surprisingly large undertaking. We have done this a few times. While there are significant differences from project to project, we do have a list of general suggestions.
Before you start, ta...
Web performance snippets: little scripts that return performance metrics
Use these snippets when you want to measure yourself.
Currently available:
Core Web Vitals
Largest Contentful Paint (LCP)
Largest Contentful Paint Sub-Parts (LCP)
Quick BPP (image entropy) check
Cumulative Layout Shift (CLS)
Loading
Time ...
Using rack-mini-profiler (with Unpoly)
Debugging performance issues in your Rails app can be a tough challenge.
To get more detailed insights consider using the rack-mini-profiler gem.
Setu...
Keeping web applications fast
Our applications not only need to be functional, they need to be fast.
But, to quote Donald Knuth,
premature optimization is the root of all evil (or at least most of it) in programming
The reasoning is that you should not waste your time op...
High Performance Browser Networking: HTTP/2
HTTP/2 will make our applications faster, simpler, and more robust—a rare combination—by allowing us to undo many of the HTTP/1.1 workarounds previously done within our applications and address these concerns within the transport layer itself. Eve...
Rails: Fixing the memory leak / performance issues in prepend_view_path
Recently we detected a memory leak in one of our applications. Hunting it down, we found that the memory leak was located in Rails' #prepend_view_path. It occurs when the instance method prepend_view_path is called in each request, which is a ...