Optimización del rendimiento de UI

1) Qué contar «rápido»

TTFB (tiempo hasta el primer byte): respuesta rápida del servidor/CDN.
LCP (Largest Contentful Paint) - el contenido «principal» apareció rápidamente.
INP (Interaction to Next Paint) - Capacidad de respuesta al interactuar.
CLS (Cumulative Layout Shift) - Sin «temblor» de interfaz.
TTI (Time to Interactive) - Cuando ya todo responde.
Puntos de referencia recomendados: LCP ≤ 2. 5 s, INP ≤ 200 ms, CLS ≤ 0. 1 (para el 75 ° percentil de usuarios reales).

2) Proceso: medir → encontrar cuellos de botella → fijar presupuestos

1. Medir: RUM (usuarios reales, percentils por país/redes/dispositivos) + sintética (Lighthouse/exploradores).
2. Encontrar: Performance Performance Perfiler (tareas de larga duración> 50 ms, layout thrashing, renders extra).
3. Fijar: presupuestos (peso JS/CSS/fuentes, LCP/INP) y «líneas rojas» en CI.

3) Red y descarga de recursos

3. 1 HTTP y prioridades

Habilitar HTTP/2/3, compresión Brotli.
'preconnect' a dominios críticos; 'dns-prefetch' para los secundarios.
'preload' para recursos críticos (imagen héroe, fuente principal).
'fetchpriority =' high/low '' y 'priority' pistas donde se mantiene.

3. 2 Almacenamiento en caché

Estática con hash de archivo: 'Cache-Control: public, max-age = 31536000, immutable'.
HTML es un corto TTL + stale-while-revalidate vía CDN.
ETag/Last-Modified y Service Worker para visitas fuera de línea/repetidas.

4) Código: menos, más tarde, «más justo»

4. 1 Conjunto

Tree-shaking, minify (в т.ч. dead-code-elim).
Code-splitting en rutas/widgets, importación dinámica.
Evite los paquetes pesados «globales» en la banda base (moment → Intl/Day. js).

4. 2 Renderizado y envío HTML

SSR/ISR/streaming: dar el marco y el contenido principal primero.
Hydration Parcial/Islands: Hidren sólo las áreas interactivas.
Defer todo es no crítico: '<script type = «module» defer>'.

4. 3 Reacts-specifics (si utilizas Nat)

`React. lazy '+' Suspense 'para widgets perezosos.
'startTransition' y 'useDeferredValue' para filtros/búsquedas pesadas.
RSC (Server Components): cálculo en el servidor, menos JS en el cliente.
Selectores en filete (zustand/redux): firma el componente en fragmentos, no en todo el splor.

5) Render y condición: donde «frena»

5. 1 Aislamiento de Rerenders

Triturar componentes grandes, memoizar ('memo', 'useMemo', 'useCallback').
Las claves de lista son estables; no cree nuevas funciones/objetos en props sin necesidad.
Evite el contexto «global» para los datos que cambian con frecuencia: utilice selectores o bus de evento.

5. 2 Virtualización y grandes listas

Hojas/tablas → virtualización (render window).
Paginación/infinit-scroll con backpressure (no envíe 100k filas directamente).
Inicialización diferida de los widgets pesados fuera del wiport.

5. 3 Layout & paint

content-visibility: auto; para las secciones ocultas (el navegador no renderiza lo invisible).
contain y 'contain-intrinsic-size' para tamaños predecibles.
Evite las lecturas-entradas frecuentes de layout (layout thrashing); agrupe las medidas.
will-change utilice dosificado (de lo contrario, exceso de memoria/capas).

6) Imágenes y gráficos

Formatos: AVIF/WebP (fallback en PNG/JPEG).
Enfoque responsivo: 'srcset' + 'sizes', density-based para retina.
' loading =» lazy»' para imágenes no heroicas; priority/preload - sólo para el candidato LCP.
Playsholder de tamaño fijo → no hay saltos CLS.
Kanvas/charts: offscreen-kanvas y Web Worker para cálculos; batching de los nuevos dibujos.

7) Fuentes y texto

Una o dos fuentes variables en lugar de muchas inscripciones.
'font-display: swap '/' optional', preload para la inscripción principal.
'size-adjust' para reducir el 'salto' al sustituir la fuente.
Fuentes fallback locales con métricas similares.

8) CSS y animaciones

CSS crítico en línea (<14-20 kB), el resto es posponer.
Eliminar estilos no utilizados (Purge/CSSTree).
Animaciones, siempre que sea posible, en transformación/opacity; respetar 'prefers-reduced-motion'.
Evitar las cascadas profundas y los selectores detonadores.

9) Web Workers, flujo y tareas pesadas

Todas las CPUs pesadas están en Worker (Parsing, Ordenaciones, Agregaciones, ML).
API de streaming ('ReadableStream', 'fetch' con hilos) para respuestas largas.
Aplastar tareas en chancas a través de 'requestIdleCallback '/microtascos para mantener la capacidad de respuesta.

10) Estabilidad de diseño (CLS)

Reserve espacio bajo el elemento LCP (imagen/widget).
No inserte banners/cintas sin tamaños fijos.
Tultipos/tostadas asimétricas - no mover el contenido; utilizar capas/portales.

11) Ejemplos de snippets

Fuente crítica e imagen LCP

html
<link rel="preload" href="/fonts/Inter. var. woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" as="image" href="/hero. avif" imagesrcset="/hero. avif 1x, /hero@2x. avif 2x" fetchpriority="high">

Inicialización de widget perezosa y segura

js const Widget = React. lazy(() => import('./Widget'));
function Section() {
const inView = useInViewport('#sec');
return <div id="sec">{inView? <React. Suspense fallback={null}><Widget/></React. Suspense>: null}</div>;
}

Estabilización del diseño

css
.hero {
content-visibility: auto;
contain: layout paint;
contain-intrinsic-size: 720px 320px ;/LCP reserve/
}

12) Control de regresiones y presupuestos

Bundle-budget: JS común ≤ N kB, CSS ≤ M kB, initial-chunk ≤ kB.
Web-Vitals en CI (emulados) + alertas RUM (en percentiles).
Análisis de bandejas: explorador/analizador de mapas de origen en PR.
Características-parámetros de los componentes (renderizado de los elementos 10k, tiempo de reacción).

13) Anti-patrones

Enviar «todo a la vez»: gráficos, editores, mapas en la primera pantalla.
Un enorme state global → rerendars en cascada.
Imágenes a 2-4 × del tamaño deseado, sin 'srcset/sizes'.
Ciclos sincrónicos largos en el hilo principal.
'outline: none' y trucos personalizados sin optimización - interfieren con los indicadores de render.
Animaciones por 'top/left' (rompen el diseño y llaman a reflow).

14) Lista de verificación de pantalla

• LCP ≤ 2. 5 c en el tráfico 3G/mobile, CLS ≤ 0. 1, INP ≤ 200 ms
• Recursos críticos: preload/prioridades; el resto es defer/lazy
• Bandles: code-split, no hay dependencias superfluas
• Virtualización de listas/tablas, inicialización diferida de widgets pesados
• Imágenes: AVIF/WebP, 'srcset/sizes', 'loading =' lazy '
• Fuentes: variable + 'font-display', preload sólo el deseado
• CSS: en línea crítica, Purge, 'content-visibility' y 'contain' cuando corresponda
• Workers/idle para computación pesada
• Presupuestos y Web-Vitals están conectados a dashboards/alertas

15) Plan de implementación (3 iteraciones)

Iteración 1 - Victorias rápidas (1-2 semanas)

Habilitar Brotli/HTTP-2/3, CDN. Recursos CSS críticos y preload LCP.
Llevar los widgets pesados a las importaciones dinámicas.
Imágenes → AVIF/WebP + 'srcset'. Fuentes: 'font-display: swap'.

Iteración 2 - Mejoras estructurales (3-4 semanas)

Code-split a lo largo de las rutas, análisis de pandillas, eliminación de liebs «pesados».
Virtualización de listas, visibilidad de contenido, tamaño contain-intrinsic.
Implementar SSR/streaming/islas (donde sea relevante).
RUM con Web-Vitals, presupuestos en CI.

Iteración 3 - Escala y sostenibilidad (continua)

Workers/offscreen-kanvas, liquidación de batching, startTransition/deferredValue.
Auditoría regular de la performance, autocaravana de regresión, entrenamiento del equipo.

16) Mini preguntas frecuentes

¿Qué es lo que más va a acelerar en mobile?
Reduce el JS original, SSR/streaming y optimiza la imagen LCP.

¿Siempre necesita SSR?
No. Si la página es dinámicamente interactiva y no se almacena en caché - islands/partial hydration puede ser mejor.

¿Por qué el INP es malo con una banda «ligera»?
Probablemente tareas largas (ordenaciones, gráficos) en el hilo principal: lleve a Worker y fraccione las tareas.

Resultado

La IU rápida es un conjunto de disciplinas: prioridades de red y caché, bandas más pequeñas y más tardías, renderizado predecible sin saltos, imágenes y fuentes económicas, y control constante de métricas en el mundo real. Introduzca los presupuestos, automatice las revisiones y enseñe al equipo a pensar en la velocidad en cada paso, por lo que la interfaz se mantendrá rápida hoy y después de un año.