Angular projects getting slower: Should you optimize change detection or split modules first in 2026?

Poor performance in Angular projects is rarely caused by a single factor but rather by the combined effect of change detection strategy and module splitting. Based on 2026 project delivery experience, first determine whether the bottleneck lies in runtime or bundle size: interaction lag points to change detection, slow initial load points to lazy loading and module splitting. The key criterion is whether performance can be noticeably improved by adjusting detection strategy or code splitting without changing business logic. The three-step verification method below suits long-term maintained admin systems.

First distinguish whether the bottleneck is in rendering or loading

Angular performance issues fall into two categories: interaction lag and initialization wait. The former is usually related to change detection, the latter to module bundling. Mixing them up wastes time in the wrong direction.

Based on 2026 delivery experience, a common mistake is repeatedly optimizing component change detection when the initial load is slow. The correct approach is to open the Network panel and bundle analysis tools to confirm the main bundle size and chunk count.

• Change detection: affects responsiveness during clicks, scrolling, and input. Default strategy checks the entire component tree on every async event.
• Module splitting: affects the amount of code downloaded on initial load. Without route-based splitting, all page code enters the initial bundle.

Judgment criterion: Slow initial load → check bundle size; interaction lag → check detection scope.

Three-step verification: from change detection to module splitting

We break performance troubleshooting into three steps, each with acceptance criteria, suitable for development phase or legacy project optimization.

1. Explicitly set OnPush detection strategy: For pure presentational components, declare changeDetection: ChangeDetectionStrategy.OnPush in @Component to avoid default dirty checking. Acceptance: all pure presentational components explicitly declare it.
2. Ensure data updates create new references: OnPush compares references only. Directly modifying this.list[0].name won't trigger updates. Use the spread operator, immutable structures, or BehaviorSubject. Acceptance: input property references change on every update.
3. Implement route-based lazy loading: Use loadChildren or equivalent in route config to split child pages into separate chunks, avoiding shared modules referencing heavy libraries used only by one page. Acceptance: independent page chunks visible in webpack-bundle-analyzer.

Reason for the order: the first step reduces unnecessary checks, the second ensures changes are detectable, and the third reduces initial code. Note that OnPush is not a silver bullet. If the team is unfamiliar with immutable data, consider starting with module splitting for more stable gains. In practice, run the existing project first to record baseline metrics, then apply the three steps one by one, comparing after each step. This clearly shows which step yields the most benefit.

Delivery scenarios: common rework cases and experience range

Based on enterprise delivery experience, performance issues often stem from "not defining acceptance metrics upfront." For example, delivering a dashboard project with budget only for CSR and a 4-second initial load requirement. We first used route lazy loading and OnPush to bring initial load down to around 3 seconds, but later found the chart library was fully imported, costing an extra day or two to convert to on-demand loading, finally stabilizing under 3 seconds. If bundle analysis had been done initially, this rework could have been avoided.

Another common scenario during integration: the API returns deeply nested data, templates call methods frequently, and list scrolling stutters. This is solved by splitting components and adding OnPush to child components. Such issues only surface when data volume increases.

Experience range: for small-to-medium admin projects, a full round of three-step verification typically takes 1-3 days. If the project already has many fully imported third-party libraries, module splitting usually requires an extra 2-4 days. We define performance metrics during requirements review, such as "time to interactive on 3G network no more than 5 seconds" or "list scroll frame rate not below 50fps," using Lighthouse and Performance panel for baseline recording; otherwise, there's no quantifiable comparison post-launch.

Applicable scenarios and boundaries: when to investigate, when not to bother

This three-step method suits: Angular projects with obvious lag or slow initial load; teams unfamiliar with change detection; projects planned for long-term maintenance, like B-end admin or middle-office systems. For one-off campaign pages or prototype demos, just use CDN and simple compression—don't optimize for the sake of optimization.

Non-applicable cases:

• Slow loading due to poor network conditions—use CDN or optimize APIs, not a frontend-only fix.
• Backend API returns large data volumes; rendering isn't the bottleneck—virtual scrolling is more effective than changing detection strategy.
• System version is too old, and upgrade costs outweigh benefits—first conduct architecture review.

Another boundary is SSR. If your business relies on natural traffic from Google or Baidu and page content needs to be indexed by crawlers, SSR or static prerendering is common practice in 2026. However, SSR increases server costs and deployment complexity; it's usually unnecessary for admin systems.

Compare the two approaches:

• Pure CSR: Low development cost, simple deployment, but possibly long white screen and poor SEO. Suitable for admin or post-login systems.
• SSR/Prerendering: Better initial load and SEO, but requires Node server or build-time prerendering, increasing server resource usage. Suitable for content marketing pages, blogs, and public product pages.

Judgment criterion: If search engine traffic accounts for more than 30%, SSR is reasonable; if mostly direct access, CSR suffices. Also, if the project is still in a period of frequent requirement changes, premature optimization may be offset by subsequent changes. It's recommended to wait until features stabilize before conducting a performance cleanup.

FAQ

For a slow Angular project, should I upgrade the Angular version first or refactor code first?

Usually take a baseline measurement first, using the Performance panel or bundle analysis to identify bottlenecks. Upgrading may introduce breaking changes. Unless a patch explicitly fixes a known performance issue, optimizing code first is more controllable.

Why doesn't the page update after using OnPush?

Usually because object properties or array items are modified directly—OnPush compares references only. Use spread operators or immutable updates, or manually call markForCheck.

How do I tell if lazy loading isn't working in an Angular project?

Open the Network panel to see if JS files are split into multiple chunks. If it's still one bundle, the route isn't using loadChildren or a component is strongly referenced; check the import method in the routing module.

Does Angular SEO require SSR?

Not necessarily. Crawlers often can't see content rendered for post-login interfaces. Only content-heavy sites are worth using SSR or prerendering; admin systems don't need it.

Is Angular always worse in performance compared to React/Vue?

Default strategy has higher change detection overhead in Angular, but with OnPush and module splitting, it can be comparable in experience. Ultimately it depends on team familiarity and project complexity; the framework isn't the deciding factor.

It's recommended to agree on performance acceptance metrics before starting an Angular project, and run a three-step check. If the system is already live and issues are not prominent, there's no need to force a refactor. Suitable for systems with slow initial load, interaction lag, and long-term maintenance. When unsure, start by adding OnPush and route lazy loading, observe for two weeks, then decide.