React
Explica cómo preparar aplicaciones React para producción mediante builds optimizados, code splitting, caché, observabilidad, seguridad, compatibilidad y rollback.
Una aplicación React lista para producción necesita más que componentes correctos: build optimizado, configuración segura, observabilidad, compatibilidad y una estrategia de entrega coherente con su forma de renderizado.
El modo desarrollo prioriza feedback y diagnósticos:
El build de producción prioriza tamaño y ejecución:
npm run buildEl comando exacto depende del tooling. Generar archivos no equivale a desplegarlos ni operar un servidor.
src + dependencies
↓ bundler
optimized assets
↓ hosting / server
browserEl output puede incluir:
No edites manualmente el output generado.
El tooling puede:
Estas optimizaciones dependen de módulos estáticos y paquetes correctamente publicados.
Tree shaking intenta excluir exports no utilizados. Puede fallar o ser limitado cuando:
No asumas que importar un único símbolo siempre produce un bundle mínimo. Verifica con bundle analysis.
Divide por rutas y features pesadas:
const AdminDashboard = lazy(() => import("./AdminDashboard"));Revisa:
Una estrategia demasiado fragmentada puede empeorar navegación y caché.
Optimiza:
React no optimiza automáticamente cada asset.
Los assets con hash pueden recibir cache larga:
app.8f3a2.js → immutable
index.html → revalidation cortaUna CDN reduce latencia de archivos estáticos. SSR y APIs necesitan una estrategia distinta según región, caché y datos.
Todo valor incluido en el bundle cliente puede ser inspeccionado:
const apiUrl = import.meta.env.VITE_API_URL;Un prefijo de “public” no protege secretos; indica que se expone al cliente.
Nunca incluyas:
Mantén versiones compatibles y alineadas. Múltiples copias de React pueden producir invalid hook call y contextos separados.
Revisa lockfile, peer dependencies y deduplicación.
Define navegadores objetivo según producto. El bundler puede transformar sintaxis, pero no añade automáticamente todas las APIs faltantes.
Distingue:
No cargues polyfills globales sin evaluar necesidad y coste.
Ayudan a relacionar errores minificados con source code. En producción decide:
Captura errores con contexto útil:
No envíes tokens, contraseñas ni payloads sensibles.
Los console.log dispersos no constituyen observabilidad. Define niveles y eventos relevantes.
En cliente considera:
Observa:
Las métricas técnicas deben relacionarse con experiencia y producto.
Miden aspectos de carga, respuesta y estabilidad. Analiza percentiles y dispositivos, no solo promedios.
React puede influir mediante bundles, hydration y renders, pero imágenes, servidor y CSS también participan.
En aplicaciones SSR, monitorea mismatches y errores de hydration. Prueba:
No silencies warnings sin comprender la diferencia.
Permiten activar cambios gradualmente:
return flags.newCheckout ? <NewCheckout /> : <LegacyCheckout />;Necesitan:
Un flag permanente se convierte en deuda y ramas difíciles de probar.
Un release debe poder revertirse. Considera compatibilidad entre:
No despliegues cliente y backend asumiendo actualización instantánea de todos los usuarios.
Durante un despliegue puede coexistir:
old client + new server
new client + old serverDiseña APIs y datos para una ventana de compatibilidad. Evita eliminar campos inmediatamente cuando clientes cacheados todavía los usan.
Pipeline mínimo según proyecto:
No toda aplicación necesita la misma cantidad de etapas, pero el build debe probarse antes del despliegue.
Inspecciona qué dependencias dominan el JavaScript. Pregunta:
No cambies librerías únicamente por tamaño sin considerar mantenimiento y funcionalidad.
Define límites para:
Un budget convierte regresiones en señales visibles.
Mantén:
No actualices automáticamente a producción sin tests.
Si la aplicación utiliza SSR o Server Components, producción también necesita:
React no define toda esta operación; el framework y plataforma sí.
Una SPA puede publicarse como archivos estáticos, pero routing cliente necesita fallback al documento principal. Configura también:
Un service worker puede cachear assets y permitir offline, pero introduce versiones y actualización diferida.
No añadas uno por defecto. Define:
Verifica con contenido y datos reales:
Un test de componente aislado no cubre toda la aplicación desplegada.
APIs avanzadas, legado y compatibilidad organiza qué capacidades son esenciales, especializadas, dependientes de versión o de framework.