Old Angular can punish you long before it breaks.
That sounds dramatic, but the punishment is usually rather quiet.
The system still loads. Customers can sign in. Staff can submit forms. There is no obvious disaster, so upgrading it stays somewhere near the bottom of the list.
Then the smaller problems start accumulating.
A click takes a moment longer than it should. A simple change needs several days of testing. One dependency cannot be updated because three others rely on it. Developers learn which parts of the application are best left alone.
The app still works. It has simply become expensive in ways that are difficult to see on an invoice.
INP Has Made One Part of the Problem Easier to Spot
Interaction to Next Paint, usually shortened to INP, measures how quickly a page responds when somebody clicks, taps or types.
Google considers an INP of 200 milliseconds or less to be good. Anything above 500 milliseconds is poor. The measurement is taken from real visits at the 75th percentile, so a fast test on the developer's laptop is not enough. Google explains the measurement in more detail here.
INP replaced First Input Delay as a Core Web Vital in March 2024. It looks at interactions throughout a visit, which makes it much better at exposing applications that load successfully but feel slow once somebody starts using them.
Older Angular applications can be vulnerable to this, particularly large internal systems, customer portals and dashboards that have grown for years.
What Does Angular Have to Do With It?
Traditional Angular applications commonly use Zone.js to detect when something might have changed.
Zone.js monitors asynchronous work in the browser. Angular can then run change detection to work out which parts of the screen need updating.
On a small application, this may be almost impossible to notice. On a large one, a single interaction can cause Angular to check far more of the component tree than the user actually changed.
Add a complicated data grid, a few third-party scripts, large forms and several years of new features, and one click can produce a surprising amount of work.
Angular is not always responsible. Slow event handlers, excessive JavaScript, large page updates and poorly behaved third-party libraries can all damage INP. That is why measuring the real interaction matters before changing the framework.
Angular Has Changed Quite a Lot
Modern Angular handles this differently.
Zoneless change detection became stable in Angular 20.2 and is enabled by default in newer Angular applications. Instead of relying on Zone.js to announce that something might have happened, Angular can schedule updates when signals, event listeners and specific framework APIs say that a view has changed. Angular's zoneless guide explains the requirements.
There is another fairly important point. As of July 2026, Angular 22 is the active release. Angular versions 2 to 19 are no longer officially supported. Angular publishes the current support status here.
Being unsupported does not make an application collapse at midnight. It does mean no further framework fixes, growing compatibility problems and a harder upgrade later.
Zoneless Is Not a Magic Switch
Removing Zone.js will not make every slow application fast.
Existing code may depend on Zone.js behaviour. Some components may need to use signals, AsyncPipe, OnPush change detection or explicitly tell Angular when something has changed. Tests and third-party libraries also need checking.
And a 700 millisecond block of JavaScript is still a 700 millisecond block of JavaScript. Zoneless Angular can reduce unnecessary change detection, but it cannot rescue slow application code by itself.
What We Would Actually Check
For an existing application, we would normally start by:
- Checking real-user INP data rather than relying only on a synthetic speed test
- Reproducing the slow interactions and profiling what the browser is doing
- Separating Angular change-detection work from heavy JavaScript, rendering and third-party code
- Planning framework upgrades one major version at a time
- Testing zoneless change detection where the measurements suggest it will help
Age alone does not decide whether an application needs replacing. Support status, real-user performance and the cost of making ordinary changes tell you much more.
If your Angular system works but every small change now feels strangely expensive, it is probably worth investigating before someone suggests rebuilding the whole thing. Our Angular upgrade and rescue service starts with an audit, so you know whether the sensible answer is tuning, a staged upgrade or replacement.