Una app rápida no se logra optimizando a ciegas, sino MIDIENDO qué es lento y arreglando la
causa. Angular moderno te da una ventaja enorme: las señales y el modo zoneless hacen que la
detección de cambios sea eficiente por defecto. Hoy consolidas por qué zoneless es rápido,
aprendes a medir con las herramientas del profiler, y entiendes la jerarquía correcta de
optimización —de la causa raíz a los últimos recursos—.
Medir antes de cortar
Por qué zoneless es rápido por defecto
Ya lo viste en el módulo de señales: zone.js revisaba TODO el árbol de componentes en cada
evento; las señales avisan solo a quien depende de ellas. Recapitulemos su impacto en
rendimiento:
El legado: OnPush
Antes de las señales, la forma de acelerar la detección de cambios era la estrategia OnPush:
le decías a un componente "solo revísate si tus @Input() cambian por referencia o disparas un
evento", en vez de en cada ciclo global.
onpush.ts
// ANTES (optimización manual): OnPush reducía las revisiones componente por componente@Component({selector: 'app-lista',changeDetection: ChangeDetectionStrategy.OnPush, // revísate solo si cambian inputs/eventos})export class ListaComponent {}// AHORA: con señales, la detección de cambios ya es de grano fino por defecto.// Los componentes basados en señales se comportan como OnPush automáticamente.
OnPush sigue siendo relevante en código existente, pero con señales obtienes su beneficio (y
más) sin configurarlo componente por componente. Si vienes de Angular viejo, piensa en señales
como "OnPush automático y preciso".
Medir con Angular DevTools
La jerarquía de optimización
El profiler muestra que una lista de 5.000 elementos hace tu app lenta al desplazarse. ¿Cuál es el primer arreglo correcto?
Mini-reto
Para cada síntoma, di cuál nivel de la jerarquía de optimización aplicarías: 1) una tabla de
10.000 gastos se desplaza con tirones; 2) toda la app tarda en arrancar porque carga el código
de páginas que casi nadie visita; 3) un computed de estadísticas recalcula un cálculo pesado
en cada tecla de un input no relacionado (pista: ¿de qué depende realmente?); 4) un componente
se re-renderiza al cambiar un dato que no usa.
Qué sigue
Sabes medir y optimizar con criterio. Una de las herramientas más potentes para el rendimiento
de carga es cargar partes de la vista solo cuando se necesitan. La próxima lección son los
bloques @defer —diferir componentes pesados por viewport, interacción o tiempo—, el
complemento perfecto del lazy loading de rutas.