...
Seleccionar página

React Avanzado

por | May 14, 2025 | Tecnologías

Comparte

Introducción

React y Next.js han impulsado algunos de los proyectos web más ambiciosos de los últimos años. Durante este periodo, los equipos han superado los límites del rendimiento (logrando mejoras drásticas en Core Web Vitals como LCP y la nueva métrica INP ), han equilibrado las compensaciones entre la renderización del lado del servidor y del lado del cliente, han ideado ingeniosos esquemas de almacenamiento en caché y gestión de estado, y han mejorado la experiencia tanto del desarrollador como del usuario.

Este artículo analiza casos prácticos reales de equipos y productos de ingeniería, destacando sus desafíos, soluciones y resultados. Primero, analizamos cada caso en detalle, cada uno ilustrando técnicas avanzadas en aplicaciones de producción de React/Next.js, y luego sintetizamos las conclusiones generales y las mejores prácticas que están moldeando la industria.

Estudios de caso destacados

Para obtener más lecciones sobre cómo crear aplicaciones web a gran escala, puede que le interese Crear aplicaciones web a gran escala | Una guía de campo de React o Éxito a escala .

Vio: creación de perfiles y optimización de INP para una aplicación React

Vio es una plataforma global de reserva de alojamiento que conecta a viajeros con hoteles, alquileres vacacionales y otras opciones de alojamiento en todo el mundo.

Desafío

Al analizar las Core Web Vitals de Vio, el equipo detectó puntuaciones bajas de Interacción con el Next Paint ( INP ), lo que indicaba que las interacciones del usuario tardaban demasiado en procesarse . El valor de INP rondaba los 380 ms, muy por encima del umbral de «bueno» de Google de 200 ms . Este retraso era especialmente notable durante una interacción crucial, el primer clic. Dado que INP se convirtió en un factor de posicionamiento oficial de Google en marzo de 2024, mejorar esta métrica era esencial para la experiencia del usuario y el SEO.

Solución

El equipo identificó y abordó las causas fundamentales del bajo rendimiento del INP mediante un análisis y perfilación minuciosos. Sus soluciones incluyeron:

  • Perfiles y análisis de rendimiento: Utilizando el panel de rendimiento de Chrome DevTools y Lighthouse, determinaron con precisión dónde se invertía el tiempo durante las interacciones. Al añadir marcas de tiempo de usuario personalizadas y analizar commits largos de React, identificaron cuellos de botella clave. Esto identificó que el reflujo del navegador era un problema importante: los recálculos de diseño obligaban al navegador a volver a renderizar demasiada parte de la página.
  • División de código y carga diferida: El paquete inicial incluía código para funciones que no se necesitaban inmediatamente. Al implementar importaciones dinámicas con React.lazy()y Suspense, se redujo la carga útil inicial de JavaScript. Esto significó que el navegador tenía menos código que analizar y ejecutar antes de volverse interactivo.
  • Antirrebote y optimización de eventos: El análisis mostró que ciertos controladores de eventos se activaban con demasiada frecuencia y bloqueaban el hilo principal. Al implementar la antirrebote con un retraso en los controladores de desplazamiento y cambio de tamaño, se evitó la sobrecarga excesiva del diseño. Se optimizaron los controladores de clics mediante la delegación de eventos en lugar de asociar detectores a cada elemento.
  • Mejoras en la gestión de estados: La aplicación rerenderizaba más componentes de lo necesario al cambiar de estado. La implementación React.memo()estratégica y el uso del useMemogancho para cálculos costosos eliminaron rerenderizaciones innecesarias. El estado del componente también se acercó a su estado original, lo que redujo el alcance de las actualizaciones.

Resultados

Estas optimizaciones dieron lugar a mejoras espectaculares:

  • INP mejoró de 380 ms a 175 ms, muy por debajo del umbral “bueno” de Google de 200 ms.
  • La carga útil inicial de JavaScript se redujo en un 60%.
  • Se eliminaron las repeticiones de renderizados innecesarias y el generador de perfiles React muestra menos renderizados desperdiciados.
  • Los comentarios de los usuarios indicaron que la interfaz se sentía notablemente más receptiva.

El caso demostró que el análisis metódico del rendimiento y las optimizaciones específicas podrían mejorar significativamente el INP sin necesidad de una revisión arquitectónica completa.

Más detalles

INP (Interacción con la siguiente pintura) es la métrica de interacción más reciente disponible en la web. Una interacción puede ser un clic, pulsar una tecla o mover el puntero hacia arriba. Se divide en tres fases que ayudan a optimizar los esfuerzos. Vio es una aplicación React de gran tamaño optimizada para INP. Consiguieron que su aplicación fuera un 69 % más rápida.

Su primer gran logro se produjo con la actualización a React 18. La principal ventaja de esta actualización fue el renderizado concurrente, ya que tareas de alta prioridad, como la entrada del usuario, pueden interrumpir el renderizado. Este único cambio mejoró el rendimiento en escritorio en un 46 % y en dispositivos móviles en un 54 %. La clave es que, a veces, los cambios a nivel de framework pueden tener mayor impacto que las optimizaciones locales.

Los eventos de análisis y seguimiento creaban tareas largas que bloqueaban el hilo principal. En lugar de eliminarlas o transferirlas a los service workers, el equipo implementó una solución más sencilla: ceder el paso al hilo principal entre operaciones. Esto dividió las tareas largas de la aplicación y mejoró el INP en un 19 %. La lección clave: a veces, soluciones sencillas que utilizan funciones básicas de JavaScript pueden resolver problemas de rendimiento complejos.

El último paso fue corregir los problemas de renderizado de React. El equipo identificó y resolvió este problema de diferentes maneras, entre ellas:

  • Descomposición de ganchos personalizados complejos en ganchos más pequeños. En el gráfico de llamas anterior, el equipo observó que un gancho complejo se llamaba repetidamente y rerenderizaba los componentes innecesariamente.
  • Reemplazar las API de React Router con window.location cuando sea posible.
  • Mejorando la memorización del selector Redux.
  • Estos cambios combinados le dieron al equipo otra mejora del 45% en INP.
  • En conclusión: la elaboración de perfiles es esencial: los cuellos de botella de rendimiento suelen aparecer en lugares inesperados.

DoorDash: Migración de CSR a Next.js SSR para mayor velocidad y SEO

DoorDash es una plataforma de entrega de alimentos que conecta a los clientes con restaurantes y minoristas para la entrega a pedido de comidas y productos.

Desafío

El frontend web de DoorDash era originalmente una aplicación React de una sola página renderizada del lado del cliente (CSR). Sufría de tiempos de carga lentos, paquetes de JavaScript sobrecargados y un SEO deficiente. A medida que la aplicación crecía, el tamaño de los paquetes se volvió difícil de optimizar y las cargas iniciales mostraban una pantalla en blanco hasta que la aplicación se hidrataba, lo que perjudicaba la experiencia del usuario. Con muchas Core Web Vitals deficientes en Google Search Console, DoorDash necesitaba mejorar la velocidad de las páginas críticas (página de inicio y páginas de la tienda) para mejorar la experiencia de usuario y el posicionamiento en los buscadores .

Solución

El equipo migró páginas a Next.js de forma incremental para la renderización del lado del servidor (SSR). En lugar de una reescritura completa, adoptaron una implementación incremental página a página , ejecutando la antigua aplicación CSR y las nuevas páginas SSR de Next.js en paralelo. Este enfoque les permitió modernizarse gradualmente y minimizar las reescrituras completas, permitiendo la coexistencia de funciones . Las tácticas clave incluyeron:

Resultados

La migración produjo mejoras de rendimiento dramáticas. DoorDash vio tiempos de carga de página entre +12% y +15% más rápidos en páginas clave, y Largest Contentful Paint (LCP) mejoró en un 65% en la página de inicio y un 67% en las páginas de la tienda . La proporción de URL LCP lentas «Deficientes» (>4 s) se desplomó en un 95% ( fuente ). Estas ganancias significaron que los usuarios obtuvieron el contenido mucho más rápido, mejorando directamente la UX y probablemente el SEO (ya que Google recompensa los buenos Core Web Vitals). El equipo enfatiza que adoptar Next.js puede llevar a » enormes mejoras en el rendimiento de la web móvil » cuando se hace correctamente. Igualmente importante, lograron esto sin una reescritura radical: el enfoque incremental mantuvo el sitio estable y a los desarrolladores productivos. En resumen, al pasar de una aplicación CSR pesada a SSR con Next.js, DoorDash aumentó significativamente la velocidad y la experiencia del usuario , mejorando la capacidad de mantenimiento con una arquitectura más modular.

Preply: mejora la capacidad de respuesta de INP sin componentes de servidor React

Preply es un mercado de aprendizaje de idiomas en línea que conecta a estudiantes y tutores.

Desafío

Preply, una plataforma de aprendizaje en línea, se enfrentó a un problema urgente de rendimiento en dos de sus páginas más críticas (aquellas cruciales para la conversión SEO y SEM). En concreto, su interacción con Next Paint (INP) era deficiente. INP, que mide la capacidad de respuesta a la entrada del usuario, fue la peor Core Web Vital para esas páginas , lo que indica que los usuarios experimentaron retrasos después de hacer clic o escribir. Dado que Google se dispone a convertir INP en un factor de posicionamiento oficial en 2024, esto planteó riesgos para el SEO. Además, el equipo estimó que mejorar INP podría ahorrar unos 200.000 dólares al año (probablemente gracias a una mejor conversión de anuncios y unas tasas de rebote más bajas), según sus análisis de ROI. Sin embargo, contaban con menos de 3 meses para implementar las correcciones, y su aplicación aún utilizaba el antiguo Next.js Pages Router (sin componentes de servidor React ni el nuevo App Router), por lo que tuvieron que implementar mejoras dentro de la arquitectura existente.

Solución

Preply formó un equipo de ataque de rendimiento dedicado y abordó el problema desde múltiples frentes, centrándose en minimizar el bloqueo del hilo principal durante las interacciones. Algunas estrategias clave incluyeron:

  • Perfilado y eliminación de cuellos de botella: Los ingenieros recopilaron una gran cantidad de datos de tiempo de ejecución y seguimientos de las páginas de destino. Al medir todo el JavaScript síncrono que se ejecutaba tras una interacción del usuario (lo cual contribuye a la INP), identificaron operaciones costosas. Muchas optimizaciones eran de bajo nivel, por ejemplo, la refactorización de bucles lentos o cálculos pesados, la eliminación de re-renderizados innecesarios y la división de funciones grandes en fragmentos asíncronos más pequeños. Todo lo que se podía aplazar se delegó hasta después del primer pintado tras una interacción.
  • Hidratación selectiva mediante React 18: Dado que la aplicación ya funcionaba con React 18, se aprovecharon las funciones concurrentes de React para mejorar la hidratación y la capacidad de respuesta . Por ejemplo, se delimitaron las partes de la interfaz de usuario no críticas <Suspense>para que la hidratación de dichas partes se volviera no bloqueante . Esto significó que el hilo principal podía responder a un clic sin esperar a que se hidratara toda la página. De hecho, la hidratación selectiva de React 18 permitió que los componentes interactivos se hidrataran primero, mientras que las partes menos urgentes se hidrataban en segundo plano. Esto redujo drásticamente el retardo de entrada.
  • Optimización del manejo de eventos con transiciones: El equipo auditó los controladores de eventos asociados a los elementos de la interfaz de usuario. Para las interacciones que activaban actualizaciones de estado importantes, utilizaron startTransitionla API de concurrencia de React 18 para marcar dichas actualizaciones como de baja prioridad . Esto permite a React retrasar las actualizaciones no urgentes si se produce un evento de alta prioridad (como otra entrada del usuario), manteniendo así la interfaz responsiva. También introdujeron la eliminación de rebotes y la limitación de recursos cuando correspondía para los eventos que se activaban con frecuencia, a fin de evitar el bloqueo del hilo.
  • División de código y carga diferida: Preply identificó partes de su paquete que no eran necesarias inmediatamente para la interacción inicial. Mediante una división de código agresiva, se aseguraron de cargar menos JavaScript al principio. Algunos componentes y bibliotecas se cargaron bajo demanda (después de la interacción del usuario o en la ventana gráfica) para aligerar la carga. Esto se alinea con el lema «cargar solo lo necesario, cuando sea necesario» , un principio crucial para optimizar la INP.
  • Optimizaciones de caché y CDN: Si bien se centraron en el código frontend, no descuidaron las optimizaciones de red. El equipo verificó que su CDN (CloudFront) almacenara en caché los recursos estáticos de forma eficaz y que las respuestas de API para estas páginas fueran almacenables en caché o precargadas. En iniciativas anteriores, Preply había reducido la latencia de 1,5 s a 0,5 s mediante AWS CloudFront y ElastiCache, por lo que se aseguraron de aplicar un almacenamiento en caché similar para cualquier nuevo endpoint de servidor relacionado con estas páginas. Esto garantizó que el navegador no se quedara atascado esperando respuestas de red lentas durante una interacción.

Resultados

En solo unos meses, Preply mejoró drásticamente el INP en las páginas objetivo, llevándolas al cumplimiento del umbral «bueno» de menos de 200 ms . Cualitativamente, las páginas se volvieron mucho más responsivas : los usuarios de prueba informaron que los clics y las entradas se sintieron casi instantáneos, donde antes había un retraso perceptible. Es importante destacar que estas ganancias se tradujeron directamente en métricas comerciales. Con una interfaz más rápida y responsiva, Preply probablemente vio una mayor conversión en esas páginas de destino de SEO (los usuarios no rebotaron debido al retraso). El ahorro estimado de $200k/año de un mejor rendimiento fue una sólida validación del esfuerzo. Quizás lo más impresionante es que Preply logró esto sin adoptar React Server Components o una refactorización completa de App Router , lo que demuestra que incluso los proyectos heredados de Next.js se pueden optimizar significativamente con un esfuerzo enfocado. Este caso subrayó el valor de medir las interacciones reales de los usuarios y hacer lo que sea necesario para que cada clic sea ágil.

La pestaña Rendimiento de Chrome Devtools muestra los Core Web Vitals para la sesión actual, especialmente INP, y la interacción más lenta que la causó.

Su panel interno informa el INP de la página de inicio (~250 ms antes de las optimizaciones, 185 ms después de las optimizaciones) y la página de búsqueda (~250 ms antes de las optimizaciones, 175 ms después de las optimizaciones).

GeekyAnts – Actualización a Next.js 13 y RSC para un sitio web ultrarrápido

GeekyAnts es un estudio de desarrollo de productos y consultoría que brinda servicios de desarrollo de software y consultoría a empresas.

Desafío

GeekyAnts, una consultora tecnológica, quería mejorar el rendimiento y la experiencia de usuario de su sitio web corporativo. Sus páginas de destino, ricas en contenido (imágenes, multimedia e información), presentaban un rendimiento lento, con puntuaciones de Lighthouse cercanas a 50 , claramente subóptimas. La baja velocidad de carga de la página afectaba el posicionamiento SEO y la interacción del usuario. Identificaron grandes cargas útiles de JavaScript del lado del cliente y una carga de datos ineficiente como problemas clave. Para solucionar esto, GeekyAnts decidió tomar una decisión audaz: actualizar su sitio web a Next.js 13 (desde una versión anterior) y aprovechar la nueva función React Server Components (RSC) . Esta fue una decisión innovadora en 2024, destinada a reducir el trabajo del lado del cliente y acelerar la renderización. El reto residía en migrar a una nueva estructura y modelo mental de la aplicación, manteniendo el sitio web funcional y optimizado para SEO.

Solución

El equipo de GeekyAnts realizó una revisión integral, reconstruyendo su sitio web en el App Router de Next 13 con RSC. El proceso incluyó:

  • Adopción de componentes de servidor de React: Con RSC, trasladaron una cantidad significativa de renderizado de interfaz de usuario al servidor. Los componentes que no requerían interactividad se convirtieron en componentes de servidor, lo que significa que el HTML de esas partes se generó en el momento de la solicitud y se envió (sin necesidad de React del lado del cliente). Esto redujo la necesidad de procesamiento del lado del cliente, lo que aceleró la respuesta del sitio , ya que se requería menos JavaScript en el navegador. En la práctica, el equipo descubrió que esto significaba muchos menos bytes de JavaScript enviados, lo que reducía el tiempo de ejecución del hilo principal y permitía que las páginas se volvieran interactivas mucho antes. (En un ejemplo ilustrativo, observaron que con RSC el árbol de componentes de React puede ser selectivo: no todos los elementos se convierten en componentes del lado del cliente , solo aquellos que realmente se necesitan en el cliente).
  • Reestructuración de la obtención de datos al servidor: Anteriormente, ciertos datos de sus páginas podían obtenerse del lado del cliente o mediante API ineficientes. El enrutador de aplicaciones Next 13 impulsó la transición a la obtención de datos del lado del servidor mediante componentes asíncronos o getServerSidePropsequivalentes en RSC. GeekyAnts reorganizó la forma en que sus páginas cargan datos, trasladando las llamadas a la API a los componentes del servidor para que los datos ya estén presentes al enviar el HTML. Esto eliminó los retrasos de ida y vuelta tras la carga inicial. Debían garantizar que sus API o consultas a la base de datos se ejecutaran eficientemente en el servidor, pero la recompensa fue considerable: el usuario percibe una carga más rápida, ya que el contenido llega pre-renderizado.
  • Aprovechando las optimizaciones de rendimiento de Next.js: Al actualizar, se beneficiaron de las opciones predeterminadas de Next.js 13: división automática de código , optimizaciones de imagen mejoradas y las nuevas funciones de enrutamiento y streaming. Utilizaron el componente Image integrado de Next (o técnicas similares) para optimizar las imágenes y mostrarlas en formatos modernos. Probablemente también habilitaron la transmisión SSR , dividiendo el HTML en fragmentos para que el contenido de la mitad superior de la página pudiera transmitirse al navegador, mientras que los componentes más pesados ​​de la mitad inferior de la página se renderizaran un momento después. (Esta función de streaming forma parte del paradigma App Router y RSC, y facilita el tiempo hasta el primer byte y la primera pintura con contenido ).
  • Pruebas y ajustes: Tras la actualización, el equipo no se conformó con «funciona»: midieron Lighthouse, PageSpeed ​​Insights y Core Web Vitals. Ajustaron aspectos como usar la use clientdirectiva solo donde era necesario (para mantener la mayoría de los componentes del lado del servidor) y comprobaron que todas las métricas (CLS, LCP, INP) cumplían con los requisitos. El resultado fue una aplicación Next.js moderna y pulida.

Resultados:

La transformación fue un éxito. GeekyAnts informó que «las puntuaciones de salud alcanzaron 90+» en Lighthouse/PageSpeed ​​después de la implementación, un gran salto desde los ~50 anteriores. Todas las métricas Core Web Vitals ahora pasaron los estándares óptimos . En comparaciones lado a lado, el tiempo de ejecución de JavaScript y el trabajo del hilo principal se redujeron notablemente gracias a RSC (como se muestra en sus gráficos de antes/después). En resumen, el sitio se volvió mucho más rápido e interactivo , con una carga de contenido casi instantánea. El SEO también mejoró: con velocidades más rápidas y contenido mejor estructurado, las puntuaciones de «salud SEO» de los motores de búsqueda de sus páginas también mejoraron. La experiencia del usuario fue más fluida; por ejemplo, las navegaciones en el sitio se sintieron más instantáneas y las páginas pesadas, como su página de destino con mucho contenido multimedia, ahora se cargan sin causar congelamientos prolongados.

Este caso práctico demuestra el impacto real de Next.js 13 y los componentes de servidor de React: al incluir menos JavaScript y trabajar más en el servidor, las aplicaciones pueden lograr mejoras de rendimiento significativas. GeekyAnts indicó que la transición requirió cambios en la gestión de elementos como las llamadas a la API (desplazando parte de la lógica al servidor), pero el resultado justificó el esfuerzo. Para los equipos que buscan una experiencia de usuario ultrarrápida, esto ofrece un modelo a seguir: adopten las últimas funcionalidades del framework para optimizar la ejecución en el navegador y podrán obtener mejoras sustanciales tanto en velocidad como en satisfacción del usuario .

Inngest: Adopción de Next.js App Router para una mejor experiencia de usuario (DX) y una experiencia de usuario (UX) instantánea

Inngest es una plataforma de flujo de trabajo sin servidor que simplifica los trabajos en segundo plano, las funciones impulsadas por eventos y la automatización de los desarrolladores.

Desafío

Inngest, una plataforma SaaS, llevó a cabo un importante rediseño del frontend entre 2023 y 2024. Pasaron de una configuración de Create React App (CRA) + React Router a Next.js 13 con el nuevo App Router. Los objetivos no solo eran el rendimiento, sino también la productividad y la facilidad de mantenimiento de los desarrolladores. Querían eliminar el estado de carga en blanco que mostraba su antigua aplicación CSR al iniciarse, mejorar el enrutamiento y la carga de datos, y aprovechar las funciones modernas de React (componentes de servidor, streaming, etc.). Sin embargo, la adopción temprana de App Router implicó una curva de aprendizaje, especialmente en relación con su nuevo comportamiento de almacenamiento en caché y las convenciones de enrutamiento . El equipo se enfrentó a preguntas como:

  • ¿Cómo se puede gestionar el estado global (por ejemplo, los filtros) en los nuevos diseños?
  • ¿Cómo garantizar que los datos dinámicos se mantengan actualizados con el almacenamiento en caché de Next?
  • ¿Cómo utilizar el streaming sin complicar el código base?

Este caso captura cómo Inngest superó estos desafíos, generando mejoras en la experiencia del usuario (UX) y una experiencia de desarrollador más fluida (DX).

Solución

A medida que reconstruían el panel de Inngest con Next.js 13, el equipo documentó lecciones y técnicas clave:

  • Pre-renderizado estático + Streaming = Experiencia de usuario rápida: Al usar el renderizado estático de Next siempre que es posible, la nueva aplicación ofrece una vista inicial inmediata en lugar de una pantalla en blanco. Incluso en páginas que requieren datos dinámicos, emplearon el SSR de streaming de React . Esto les permitió enviar la estructura de la página (encabezado, navegación, diseño) inmediatamente y luego transmitir las secciones basadas en datos a medida que estén listas. En la práctica, los usuarios verían el marco del panel al instante (quizás con cargadores en las áreas de contenido) en lugar de esperar a que el cliente renderizara por completo. Esto permitió a los usuarios comenzar a interactuar con la página antes , mejorando considerablemente el rendimiento percibido.
  • Diseños anidados y conservación del estado: La función de diseños anidados de App Router permitió a Inngest mantener el estado entre navegaciones de maneras que antes eran difíciles. Podían compartir la interfaz de usuario (como barras de navegación o filtros) en varias páginas sin tener que volver a montarlas, evitando así costosas re-renderizaciones al cambiar de vista. Por ejemplo, el filtro de entorno seleccionado por un usuario podía persistir mientras navegaba por diferentes secciones. Sin embargo, descubrieron una peculiaridad: los parámetros de búsqueda de URL no se pasan automáticamente a los componentes del servidor a nivel de diseño (para evitar valores obsoletos). Su enfoque inicial de poner un filtro ?env=en la URL y leerlo en un diseño no se actualizaba en la navegación. Solucionaron esto cambiando a un parámetro de ruta (por ejemplo, /env/[env]/functions) para que el diseño recogiera los cambios en el entorno como parte de la ruta. Esto aseguró que el estado global de su filtro se mantuviera sincronizado. Este es un gran ejemplo de adaptación de la gestión del estado a la arquitectura de Next: trasladaron el estado a la ruta de la URL, haciéndolo fácilmente accesible y consistente en las transiciones de SSR y del cliente.
  • Comprensión y control del almacenamiento en caché: El nuevo App Router introdujo dos capas de almacenamiento en caché por defecto : una caché del lado del cliente para las transiciones de ruta y una caché del lado del servidor para la obtención de datos. Inngest aprendió a tenerlas en cuenta. Para datos verdaderamente dinámicos (como registros/métricas en tiempo real), optaron por deshabilitar el almacenamiento en caché predeterminado de Next mediante el uso de export const dynamic = "force-dynamic"[nombre del archivo] en esas páginas. Esto les permitió evitar la entrega involuntaria de datos obsoletos de una solicitud anterior. También adoptaron las opciones de Nextcache()revalidate en las recuperaciones cuando fue necesario para ajustar la frescura. Al adoptar gradualmente el almacenamiento en caché (activándolo una vez que lo comprendieron), lograron un equilibrio: navegación rápida y repetida gracias al almacenamiento en caché, pero sin sorpresas de contenido obsoleto para datos que cambian rápidamente.
  • Mejoras en la experiencia del desarrollador: La estructura de archivos y las convenciones de App Router se convirtieron en una ventaja para la experiencia del desarrollador (DX) del equipo. Pudieron colocar componentes, pruebas y estilos con los segmentos de ruta , facilitando la navegación en el proyecto. Los archivos especiales ( layout.js,,,, etc.) les permitieron declarar los límites de React Suspense y los límites de error directamente en el árbol de archivos. Esto dejó claro de inmediato dónde se manejan los estados de carga y dónde se detectan page.jslos errores, con solo mirar las carpetas, una gran mejora con respecto a la configuración anterior, donde dicha lógica estaba enterrada en el código. Los desarrolladores de Inngest descubrieron que esto fomentaba un código más limpio y una mejor separación de preocupaciones. La compatibilidad integrada de Next 13 con elementos como middleware (usado para redirecciones de autenticación) también eliminó el código personalizado y aceleró su flujo de trabajo de desarrollo.loading.jserror.js

Resultados

Tras implementar el nuevo panel de control de Next.js 13, Inngest observó beneficios inmediatos. Los nuevos usuarios podían cargar la aplicación y ver el contenido más rápido (se acabó la pantalla blanca molesta al cargarla por primera vez), y las interacciones se sentían más ágiles gracias a la transmisión y al almacenamiento en caché inteligente. Internamente, el equipo observó que la incorporación de nuevos desarrolladores era más sencilla: el propio diseño del archivo servía como documentación de la estructura de la aplicación, y las convenciones reducían los problemas de «funciona en mi equipo». Aunque no se publicaron las métricas exactas de rendimiento, la experiencia de carga de página mejorada era evidente: partes de cada página (encabezado, navegación) se renderizan instantáneamente y el contenido aparece progresivamente. Combinaron con éxito SSR y CSR para obtener lo mejor de ambos: SSR inicial para una interfaz de usuario y SEO inmediatos, y CSR (con hidratación de React) para que la aplicación se sintiera tan fluida como una SPA. Las decisiones arquitectónicas, como incluir el estado global en los parámetros de ruta, resultaron eficaces; los filtros globales y el contexto persistieron sin problemas en todas las navegaciones. En resumen, al adoptar App Router de Next.js desde el principio , Inngest logró una aplicación más eficiente y fácil de usar , y mejoró la productividad de los desarrolladores gracias a mejores patrones. Las lecciones aprendidas se han convertido en una valiosa guía para otros equipos que migran al nuevo paradigma de Next.js.

Conclusiones agregadas y mejores prácticas (2022-2025)

Cada uno de los estudios de caso que hemos cubierto proporciona información única, pero juntos revelan tendencias claras y mejores prácticas para aplicaciones avanzadas de React y Next.js:

1. La optimización del rendimiento es primordial

Mejorar el rendimiento web ha sido un tema recurrente, con Core Web Vitals (CWV) como referencia. Los equipos que invirtieron en rendimiento obtuvieron mejoras técnicas y beneficios comerciales (mejores posicionamientos SEO, retención de usuarios y tasas de conversión). Las estrategias comunes incluyeron:

  • Optimización de Core Web Vitals: Largest Contentful Paint (LCP) e Interaction to Next Paint (INP) fueron áreas de enfoque clave para 2024. Los proyectos lograron enormes ganancias de CVW a través de técnicas como SSR/SSG para una pintura inicial más rápida y mejoras en la programación del hilo principal para la capacidad de respuesta. Por ejemplo, DoorDash redujo LCP en ~65% y prácticamente eliminó las URL de carga lenta . Preply redujo de manera similar los retrasos de INP, llevando las interacciones por debajo de la marca mágica de 200 ms para una capacidad de respuesta «buena» . Estas mejoras a menudo llevaron a resultados tangibles como un aumento en las impresiones de búsqueda y el tráfico (un sitio vio +35k impresiones mensuales de Google después de corregir CWV ). La conclusión: Medir, apuntar a las peores métricas de CWV y abordarlas metódicamente. Incluso pequeñas reducciones en el tiempo de renderizado o interacción (por ejemplo, afeitar 100-200 ms de INP) pueden mover una página a la zona «buena» y producir beneficios descomunales en la participación del usuario.
  • Reducción de la carga útil de JavaScript: Una práctica recomendada recurrente es minimizar el código JavaScript enviado al navegador: «minimizar el código en el cliente» . Menos script implica un análisis más rápido, menos bloqueos y una interactividad más ágil. Todos nuestros casos prácticos se centraron en esto: el RSC de Next.js 13 ayudó a GeekyAnts a enviar mucho menos código JavaScript (sin necesidad de hidratar contenido que puede ser estático); Preply dividió y podó agresivamente el código no utilizado; DoorDash recortó un paquete SPA sobrecargado migrando partes al servidor. Muchos equipos también adoptaron la optimización del tree-shaking y del bundler. Los gráficos de antes y después suelen mostrar una caída pronunciada en el tiempo de ejecución de JavaScript tras estas refactorizaciones.
  • Trabajo en el hilo principal e INP: Con la priorización de INP por parte de Google en 2024, los equipos aprendieron a fragmentar las tareas largas y a ceder el paso a la entrada del usuario. La concurrencia de React 18 (Transiciones, Suspenso) se ha convertido en una herramienta indispensable, permitiendo que la hidratación y las actualizaciones de estado sean interrumpibles , manteniendo así la interfaz de usuario responsiva. Además, la generación de perfiles suele revelar cuellos de botella inesperados (p. ej., un script de terceros pesado o un bucle ineficiente). Los equipos utilizan habitualmente los Perfiladores de Rendimiento para identificar código lento y optimizarlo o eliminarlo. Surgió un mantra: «Las tareas largas son el enemigo de INP» , así que divídelas, apágalas (p. ej., mediante requestIdleCallbackweb workers) o elimínalas por completo.

2. RSC vs. RSE: Lograr el equilibrio adecuado

El debate entre la renderización del lado del servidor (SSR) y la renderización del lado del cliente (CSR) ha evolucionado hacia enfoques híbridos con matices. No existe una solución universal: la mejor solución suele combinar ambas. Algunas ideas clave son:

  • SSR para carga inicial y SEO: Renderizar el contenido de la página en el servidor (o pregenerarlo estáticamente) es fundamental para la velocidad de carga inicial, el SEO y para garantizar que incluso los usuarios con dispositivos o conexiones lentas accedan rápidamente a la información. Todos los casos prácticos que adoptaron SSR experimentaron una mejor experiencia inicial ( las páginas SSR de DoorDash cargaron significativamente más rápido que las antiguas CSR , e Inngest eliminó la pantalla en blanco renderizándolas en el servidor ). SSR también garantiza que el contenido sea indexable y que los usuarios sin JavaScript o con tecnología de asistencia puedan acceder a la página básica. Generalmente, se utiliza SSR/SSG para puntos de entrada, páginas con mucho contenido o para posicionarse en los motores de búsqueda.
  • CSR para interactividad y una interfaz de usuario enriquecida: La renderización pura del lado del cliente sigue desempeñando un papel importante en las partes altamente interactivas de una aplicación. Especialmente para paneles internos o aplicaciones donde el SEO es irrelevante, la CSR puede proporcionar interacciones más ágiles tras la carga inicial. Se compartió una lección importante en un proyecto donde cambiar ciertas interacciones de SSR a CSR mejoró la experiencia del usuario: tras migrar la obtención de datos de SSR al lado del cliente, la aplicación se percibió con un rendimiento mucho mayor, ya que las pestañas se actualizaban inmediatamente al hacer clic (con un marcador de posición de carga) en lugar de hacer que el usuario esperara un viaje de ida y vuelta al servidor. Esto destaca que la SSR puede introducir latencia en las acciones del usuario si no se gestiona con cuidado. Los equipos utilizan cada vez más la SSR para el shell y los datos iniciales , y luego confían en la CSR para las posteriores actualizaciones o navegaciones dentro de la página (a menudo con APIs llamadas mediante React Query o similares). Este enfoque híbrido proporciona la fluidez «similar a la de una SPA» que esperan los usuarios, a la vez que conserva las ventajas de SEO y de primera carga de la SSR.
  • Hidratación progresiva e islas: Los frameworks modernos (Next y otros como Astro o Qwik) fomentan la idea de la hidratación progresiva: hidratar solo las partes interactivas y hacerlo gradualmente. React Server Components (RSC) lleva esto aún más lejos al ni siquiera enviar código JavaScript para las partes no interactivas. La mejor práctica emergente es identificar «islas» de interactividad y centrar la hidratación/CSR en ellas, dejando el resto renderizado en el servidor y estático. Esto reduce drásticamente el trabajo del cliente. Muchos equipos lo hicieron manualmente de forma eficaz entre 2022 y 2023 (por ejemplo, dividiendo una página en componentes y usando Next dynamic()para cargar algunos de forma diferida en el cliente solo cuando fuera necesario). Para 2024, RSC automatiza gran parte de esto. El resultado es que SSR y CSR trabajan en armonía : SSR proporciona el contenido y la interfaz de usuario base, y CSR los mejora cuando es necesario (por ejemplo, adjuntando controladores de eventos o gestionando actualizaciones en tiempo real).
  • Cuidado con las trampas de SSR: Una desventaja de SSR es el potencial aumento del tiempo hasta el primer byte si el trabajo del servidor es pesado. Los desarrolladores señalan que «SSR no significa lento como las antiguas aplicaciones PHP» si se hace bien, pero puede serlo si se hace mal. DoorDash detectó esto y lo solucionó mediante la carga diferida de componentes no críticos del lado del servidor . El almacenamiento en caché de la salida renderizada en la capa de CDN también puede mitigar la sobrecarga de SSR. Otra trampa es realizar demasiadas llamadas de datos bloqueadas durante SSR, que la nueva useSuspensey la transmisión de Next ayudan a evitar al permitir la renderización parcial. En general, los equipos aprendieron a delegar o paralelizar el trabajo costoso en SSR para aprovechar sus beneficios sin anularlos mediante largos tiempos de procesamiento del servidor.

En resumen: Usa SSR para que funcione (entregar contenido rápidamente, mejorar el SEO), y luego agiliza el proceso ajustando o integrando cuidadosamente CSR donde mejore la experiencia de usuario (UX). Muchos proyectos exitosos usan SSR para la carga de la página y CSR para las interacciones posteriores, logrando un equilibrio ideal.

3. Estrategias de almacenamiento en caché inteligente para mayor velocidad y frescura

El almacenamiento en caché se ha convertido en un componente fundamental para la optimización del rendimiento. Los casos prácticos ilustran el almacenamiento en caché en múltiples niveles (CDN, aplicación y cliente) para acelerar las respuestas y reducir la carga. Las prácticas recomendadas incluyen:

  • Almacenamiento en caché de CDN y Edge: Poner una red de entrega de contenido (CDN) delante de tu app y activos Next.js ahora es estándar. Para activos estáticos (paquetes JS, imágenes, CSS), el almacenamiento en caché de CDN descarga el tráfico de los servidores y acerca el contenido a los usuarios. Incluso las páginas Next dinámicas pueden beneficiarse mediante la regeneración estática incremental (ISR) o estrategias de «obsoleto mientras se revalida» , donde una página se pre-renderiza y se almacena en caché por un corto período. Muchos equipos vieron grandes victorias aquí: el uso de Amazon CloudFront por parte de Preply almacenó en caché el contenido globalmente, reduciendo la latencia de 1.5 segundos a 0.5 segundos y aumentando directamente las conversiones en un 5%getStaticProps . La idea práctica: configura tu CDN y encabezados de almacenamiento en caché con cuidado. Usa o fetchcon Next revalidatepara permitir que las páginas se almacenen en caché y solo se actualicen periódicamente. Sirve páginas almacenables en caché siempre que sea posible y solo recurre a SSR para datos verdaderamente en tiempo real.
  • Caché de Next.js App Router: Next 13+ introdujo una caché automática de datos del lado del servidor para fetch()las llamadas durante la renderización y una caché de navegación del lado del cliente . Esto puede acelerar drásticamente la navegación (evitando la recarga de datos de las páginas visitadas recientemente) y mejorar el rendimiento del servidor. Sin embargo, como descubrió Inngest, es fundamental comprender las reglas de invalidación . De forma predeterminada, fetchen RSC se pueden almacenar en caché los datos indefinidamente a menos que se marque lo contrario. La lección es marcar explícitamente los datos dinámicos ( cache: 'no-store'o dynamic = 'force-dynamic') cuando sea necesario y, a la inversa, permitir el almacenamiento en caché para los puntos finales que no cambian con frecuencia. En la práctica, los equipos combinan el almacenamiento en caché obsoleto mientras se revalida para la mayoría del contenido (lo que garantiza respuestas rápidas) con la revalidación bajo demanda o la desactivación del almacenamiento en caché para datos específicos que siempre deben estar actualizados.
  • Almacenamiento en caché de estado del lado del cliente: En el cliente, el uso de bibliotecas como React Query (TanStack Query) se ha convertido en una práctica recomendada para almacenar en caché las respuestas de la API y evitar solicitudes redundantes. En lugar de que cada componente obtenga los mismos datos, React Query proporciona una caché compartida : las búsquedas de la misma consulta se consolidan y los datos se almacenan para una rápida reutilización. Este enfoque no solo mejora el rendimiento, sino que también simplifica la gestión del estado (la biblioteca gestiona las actualizaciones en segundo plano y la invalidación de la caché). Varios equipos han migrado de la recuperación manual del estado o el uso de Redux para los datos del servidor a React Query o SWR. El resultado son interfaces de usuario más ágiles (ya que los datos suelen estar disponibles instantáneamente desde la caché) y una menor interferencia en la red.
  • Problemas con el almacenamiento en caché: Los desarrolladores han aprendido a ser cautelosos con la coherencia y la obsolescencia de la caché. Un error clásico es almacenar en caché de forma demasiado agresiva y ofrecer información obsoleta. Los casos de estudio muestran medidas de seguridad: por ejemplo, Inngest desactivó el almacenamiento en caché en ciertas rutas hasta que pudieron implementar la revalidación adecuada . La próxima versión de Next.js 15 incluso está ajustando los valores predeterminados para que el almacenamiento en caché sea opcional y así facilitar la previsibilidad . El consejo es comenzar con un almacenamiento en caché simple (quizás incluso ninguno para datos dinámicos) y luego habilitarlo gradualmente a medida que se implementa la monitorización o los enlaces para actualizar el contenido. Además, siempre pruebe con el almacenamiento en caché activado y desactivado para garantizar que la aplicación siga funcionando correctamente (sin dependencias ocultas de datos nuevos).

En resumen, un almacenamiento en caché eficaz puede generar mejoras de rendimiento de magnitud considerable (milisegundos en lugar de segundos). Utilice la CDN y el almacenamiento en caché del servidor para acelerar las entregas globalmente y aproveche las cachés a nivel de aplicación para evitar la recomputación. Recuerde equilibrar la velocidad con la actualización de los datos: los datos obsoletos pueden perjudicar la experiencia de usuario (UX), así que diseñe su estrategia de invalidación (basada en tiempo, eventos, etc.) desde el principio.

4. Gestión de estados en evolución: simplificar y aprovechar los ganchos especializados

La gestión del estado en aplicaciones React de gran tamaño ha experimentado un cambio en los últimos años. Mientras que los proyectos anteriores solían usar bibliotecas pesadas como Redux para el estado global, los estudios de caso de 2022 a 2025 muestran que los equipos están reduciendo el estado global y utilizando soluciones más ligeras y fáciles de mantener . Aprendizajes clave:

  • No sobredimensionar el estado global: Muchos equipos se dieron cuenta de que gran parte del estado puede mantenerse local o gestionarse con React Context básico en lugar de un almacén global complejo. En la práctica, las herramientas propias de React, junto con los ganchos personalizados, suelen ser suficientes para la mayoría de las necesidades. Como se expresó en un comentario: «La API y el estado de React Context deberían cubrir la mayoría de los casos de uso… Durante años, he usado con éxito solo contexto y estado sin biblioteca de estado» . Se debe evitar añadir bibliotecas de estado global a menos que sea realmente necesario. Especialmente para aplicaciones que muestran principalmente datos recuperados (que pueden almacenarse en caché), la necesidad de un objeto de estado de cliente gigante disminuyó.
  • Replanteando Redux: Redux, si bien es potente, conlleva costos en cuanto a complejidad y tamaño del paquete . Para 2023, era común cuestionar si Redux era realmente necesario. «Añadir bibliotecas como Redux… añade complejidad, código repetitivo y tamaño del paquete», señaló un análisis, instando a los desarrolladores a reconsiderar su uso simplemente porque es «genial». Varios casos prácticos siguieron implícitamente este consejo: DoorDash logró implementar un contexto de aplicación para SSR/CSR sin incorporar una biblioteca de estado pesada, y otros equipos utilizaron el enrutamiento de Next.js (como en el caso de Inngest) o contexto para gestionar el estado de la interfaz de usuario, como pestañas y filtros. La tendencia es clara: usar Redux (o similar) solo para estados verdaderamente complejos e intersectoriales que no se puedan gestionar de otra manera, e incluso entonces, considerar alternativas más nuevas.
  • Auge de las bibliotecas de estado especializadas: En lugar de la gestión monolítica del estado, las bibliotecas especializadas han ganado popularidad. React Query (para el estado de los datos del servidor) es un excelente ejemplo. Aborda la obtención, el almacenamiento en caché y la actualización de datos de una sola vez, algo que React por sí solo no gestiona bien . Muchos equipos ahora usan React Query o Apollo Client (para GraphQL) para administrar el estado del servidor en lugar de almacenarlo manualmente en el estado global. Para el estado exclusivo del cliente (como los conmutadores de la interfaz de usuario, los datos de formulario, etc.), bibliotecas como Zustand o Jotai proporcionan un almacén ligero y flexible con mucho menos código repetitivo que Redux. En las discusiones, los desarrolladores a menudo mencionan el uso de Zustand para el estado global simple y React Query para la obtención de datos en lugar de un gran almacén Redux. Este enfoque modular mantiene la aplicación más eficiente: solo pagas (en tamaño del paquete y complejidad) por lo que necesitas.
  • Estado del servidor en Next.js 13: Otro patrón emergente es permitir que el servidor gestione más estado . Con los componentes de servidor de React, se puede ejecutar lógica con estado en el servidor entre solicitudes. Además, las nuevas acciones de servidor de Next.js 13 (una función experimental) permiten gestionar las mutaciones en el servidor sin problemas, lo que reduce la necesidad de un estado complejo del lado del cliente para el seguimiento de los envíos de formularios, etc. Si bien aún es nuevo, esto apunta a un futuro en el que gran parte de lo que consideramos «gestión de estado» en el cliente podría ser gestionado por el framework con la ayuda del servidor. La clave para los desarrolladores es mantenerse al día con estos nuevos patrones, ya que pueden simplificar drásticamente la gestión del estado en el cliente.

En conclusión, la simplicidad suele ser mejor para la gestión de estados. Evalúe qué debe ser realmente global. Utilice las capacidades integradas de React y las bibliotecas específicas para gestionar tipos específicos de estado. La recompensa es doble: mejor rendimiento (menos JavaScript y rerenderizados) y mejor experiencia para el desarrollador (menos carga repetitiva y cognitiva). Un equipo señaló con humor un «problema de habilidad» donde no se necesitaba una solución de estado compleja para resaltar una pestaña activa ; una solución de 10 minutos con context + useState fue suficiente. La lección: siempre hay que preguntarse si existe una solución más sencilla antes de recurrir a herramientas de estado complejas.

5. Experiencia de desarrollador (DX) mejorada y facilidad de mantenimiento

Mantener una gran base de código React puede ser un desafío, pero las innovaciones y prácticas recientes han mejorado notablemente la DX. Los estudios de caso destacan varios enfoques que mantienen a los desarrolladores productivos y las bases de código mantenibles:

  • Estructura y convenciones de la aplicación Next.js: La estructura rígida de Next.js (especialmente con App Router) ha simplificado la creación de aplicaciones por parte de los equipos. Al priorizar las convenciones sobre la configuración , los equipos redujeron las interrupciones en la estructura del proyecto y pueden aprovechar los comportamientos integrados. El enrutamiento basado en archivos, los diseños anidados y los componentes coubicados resultan en un proyecto más intuitivo. En el caso de Inngest, con solo ver la jerarquía de carpetas, se puede saber dónde se gestionan aspectos como los estados de carga . Esta claridad agiliza la incorporación de nuevos desarrolladores y la navegación diaria en el repositorio. El uso de convenciones familiares (como las páginas o, ahora, los directorios de la aplicación) en los proyectos de Next.js también facilita la transferencia de conocimientos entre proyectos.
  • Herramientas para una iteración rápida: El ecosistema React entre 2022 y 2025 ha experimentado importantes mejoras en las herramientas de compilación y desarrollo. Turbopack (el nuevo empaquetador que reemplaza a Webpack en Next.js) alcanzó la estabilidad, ofreciendo actualizaciones de código hasta un 90 % más rápidas durante el desarrollo. Los tiempos de recarga en caliente más rápidos implican que los desarrolladores dedican menos tiempo de espera y más tiempo al flujo de trabajo. Además, las mejores superposiciones de errores y los seguimientos de pila, tanto en Next.js como en CRA, han reducido el tiempo de depuración. Muchos equipos también adoptaron TypeScript , que, si bien no se contempla en nuestros casos, ahora es la norma y reduce drásticamente ciertos tipos de errores de ejecución. El resultado final es una experiencia de desarrollo (DX) más agradable: se puede iterar rápidamente y detectar problemas de forma temprana.
  • Mejoras en CI/CD e implementación: Varios casos prácticos (como el de Preply en AWS) destacan la automatización que mejoró la experiencia de desarrollo (DX); por ejemplo, pasar de implementaciones manuales de 100 horas a automatizadas de 30 minutos . Si bien no es específico de React, contar con CI/CD robusto (con pruebas, presupuestos de rendimiento y análisis de paquetes) ayuda a mantener la calidad a escala. Algunos equipos configuran canales de pruebas de rendimiento (utilizando herramientas como WebPageTest o Lighthouse CI) para detectar regresiones en Core Web Vitals antes de que lleguen a producción. Saber que se aplican los presupuestos de rendimiento brinda a los desarrolladores la confianza para refactorizar sin ralentizar la aplicación accidentalmente.
  • Adopción de primitivas de React (Suspense, Límites de Error): Los patrones más recientes fomentan una mejor arquitectura de código. La suspensión para la obtención de datos lleva a los desarrolladores a gestionar los estados de carga de forma declarativa, lo que resulta en una menor lógica de carga ad hoc dispersa en los componentes. Los límites de error, ahora más fáciles de configurar (por ejemplo, a nivel de diseño en Next 13), fomentan una planificación eficiente de la gestión de errores en lugar de ignorar los fallos. Estos patrones mejoran la mantenibilidad: la aplicación es resistente a redes lentas o excepciones, y el código para estas cuestiones está centralizado.
  • Formación y documentación para desarrolladores: Una tendencia sutil pero importante es que los equipos invierten en aprender y documentar nuevas funcionalidades. Por ejemplo, Inngest escribió sobre sus lecciones con las peculiaridades del almacenamiento en caché y el enrutamiento , documentando eficazmente los problemas para los demás. Esta cultura de compartir conocimientos (a través de blogs de ingeniería o wikis internas) permite que los desarrolladores no repitan los mismos errores y se adapten a las nuevas tecnologías más rápidamente. Las API de Next.js y React, en rápida evolución (como los componentes de servidor), requieren este aprendizaje adaptativo. Los equipos exitosos fomentan un entorno donde los desarrolladores pueden experimentar con funcionalidades experimentales (en una rama o un proyecto pequeño) para comprenderlas antes de implementarlas a gran escala.

Conclusión clave de DX: El desarrollo moderno con React/Next se está volviendo más sencillo en muchos aspectos, no porque la tecnología sea más simple, sino porque los frameworks abstraen más y ofrecen mejores valores predeterminados. Al aprovechar estos valores predeterminados (estructura de archivos, nuevo enrutamiento, etc.) y usar herramientas más rápidas, los equipos entregan más con menos fricción. Una mejor DX a menudo se traduce indirectamente en una mejor experiencia de usuario (UX): los desarrolladores con herramientas eficientes pueden centrarse en pulir la experiencia de usuario en lugar de lidiar con la configuración o compilaciones lentas.

6. Accesibilidad por diseño

Garantizar la accesibilidad de las aplicaciones web a todos los usuarios (incluidas las personas con discapacidad) se ha convertido en un aspecto fundamental de la calidad. Los casos prácticos lo abordaron indirectamente (p. ej., la SSR para SEO también beneficia a los lectores de pantalla), y otras historias del sector ofrecen una guía clara. Entre las mejores prácticas que surgieron se incluyen:

  • HTML semántico y uso correcto de ARIA: Equipos como el grupo de sistemas de diseño de GitHub han hecho hincapié en el uso de los elementos semánticos correctos ; por ejemplo, usar <button>para una interfaz de usuario clicable, no <div>con un onClick, para que las tecnologías de asistencia lo reconozcan como un botón. Cuando se necesitan patrones de interfaz de usuario personalizados (como interfaces con pestañas), añadir roles ARIA adecuados (p. ej., role="tablist"y role="tab") puede transmitir la estructura a los lectores de pantalla. La regla general es construir primero con la semántica y añadir atributos ARIA solo para completar los espacios vacíos, según la Guía de Prácticas de Autoría de ARIA. En la práctica, muchos equipos ahora incluyen la accesibilidad como requisito al crear cualquier componente nuevo.
  • Navegación con el teclado y gestión del foco: Una falla común en las aplicaciones web (especialmente las SPA) es la escasa compatibilidad con el teclado. Estudios de caso sobre la creación de componentes accesibles muestran que los desarrolladores deberían implementar controles de teclado (p. ej., teclas de flecha para navegar entre pestañas, Esc para cerrar ventanas modales) y gestionar el foco explícitamente. Es importante asegurarse de que, al cambiar el contenido o abrir ventanas modales, el foco se dirija a un elemento relevante y que los usuarios puedan navegar por los elementos interactivos en un orden lógico. En nuestra investigación, los expertos recomiendan no eliminar elementos del DOM dinámicamente, de forma que sorprenda a los usuarios de lectores de pantalla . En su lugar, ocúltelos visualmente o con [insertar contexto] aria-hiddensi es necesario, pero manteniendo un DOM consistente para la tecnología de asistencia.
  • Pruebas con tecnología de asistencia: Los equipos han aprendido a probar sus aplicaciones con lectores de pantalla (NVDA, VoiceOver) y el uso exclusivo del teclado como parte del proceso de control de calidad. Las herramientas automatizadas (como las auditorías de accesibilidad de axe-core o Lighthouse) detectan muchos problemas (como la falta de texto alternativo y el bajo contraste de color), pero las pruebas manuales detectan problemas de fluidez y usabilidad. Algunas empresas realizan sesiones de usabilidad con usuarios que dependen de la tecnología de asistencia para obtener retroalimentación real. La tendencia está cambiando a la izquierda: los diseñadores y desarrolladores consideran la accesibilidad en la propia etapa de diseño , en lugar de adaptarla al final. Esto se señaló explícitamente: «La accesibilidad debe considerarse desde el principio de la etapa de diseño… en lugar de intentar añadirla más tarde» .
  • Compatibilidad con frameworks: React y Next.js han implementado medidas para integrar la accesibilidad. Next.js, por ejemplo, garantiza que la gestión y el enrutamiento dinámico no alteren el orden de enfoque predeterminado. La documentación de Next.js destaca las funciones de accesibilidad y fomenta la mejora progresiva. Además, muchas bibliotecas de componentes (Material UI, Chakra UI, etc.) ahora incluyen a11y en mente; los equipos que las utilizan obtienen muchos comportamientos accesibles predeterminados. Sin embargo, los componentes personalizados aún requieren una atención especial (como demostró el equipo de GitHub con sus ejemplos de menús y pestañas personalizados).

En esencia, el desarrollo accesible se ha convertido en una práctica estándar en las aplicaciones React modernas. La recompensa no es solo el cumplimiento normativo o evitar demandas; las aplicaciones accesibles suelen ofrecer una mejor experiencia de usuario (UX) general para todos. Por ejemplo, centrarse en encabezados y puntos de referencia adecuados para los lectores de pantalla también mejora el SEO y la facilidad de búsqueda. Mejorar la navegación con el teclado suele revelar patrones de interacción más intuitivos que benefician a todos los usuarios. Por lo tanto, los equipos líderes consideran las iniciativas de accesibilidad como parte integral de la calidad, al igual que el rendimiento y la seguridad.

7. Mejoras e impacto en la experiencia del usuario

En definitiva, todas las mejoras técnicas contribuyen a un único objetivo: una experiencia de usuario (UX) superior . En estos casos prácticos, observamos varias mejoras centradas en la UX y su impacto:

  • Cargas e interacciones más rápidas = usuarios más satisfechos: No es de extrañar que la velocidad sea una característica clave. Cuando DoorDash aceleró la carga de sus páginas un 65%, los usuarios pudieron empezar a navegar y a realizar pedidos con mucha menos fricción. De igual forma, las interacciones ágiles de Preply probablemente redujeron las bajas en momentos cruciales (como reservar una clase). Existe amplia evidencia de que mejoras de incluso unos pocos cientos de milisegundos pueden aumentar la conversión y la interacción . Los usuarios de hoy esperan respuestas casi instantáneas; los equipos que ofrecieron interacciones inferiores a 100 ms (mediante un minucioso trabajo de rendimiento) se destacaron. Un caso señaló que, tras ajustar el rendimiento, «las pestañas cambiaban inmediatamente al hacer clic» , mientras que antes había una espera notable; esa inmediatez es algo que los usuarios notan y aprecian.
  • Navegación y transiciones fluidas: Más allá de la velocidad pura, la fluidez con la que la aplicación se siente durante la navegación contribuye a la UX. Las características como la precarga de enlaces integrada de Next.js hacen que las transiciones de página a página se sientan casi instantáneas (los recursos a menudo se cargan antes de que el usuario haga clic). Con App Router y la transmisión, los usuarios pueden interactuar con partes de una página mientras otras partes aún se están cargando , como se ve en el ejemplo de Inngest. Esto reduce la percepción de espera y mantiene a los usuarios interesados. Las microinteracciones como las pantallas de esqueleto o los indicadores de carga sutiles (habilitados por los límites de Suspense) también aseguran a los usuarios que las cosas están sucediendo. Las mejores prácticas aquí son evitar recargas de página completa discordantes siempre que sea posible y proporcionar retroalimentación para cualquier acción que tome más de un par de cientos de milisegundos. Muchos equipos ahora usan IU de esqueleto o spinners dentro de los componentes, gracias al mecanismo de respaldo de carga fácil de Suspense. El resultado es una UX donde la obtención de datos se maneja con gracia y no frustra al usuario.
  • Experiencia de usuario (UX) consistente en todos los dispositivos: Las estrategias de SSR garantizan que el contenido esté disponible incluso en dispositivos de gama baja o redes lentas (una gran ventaja para los usuarios móviles). Mientras tanto, las mejoras de CSR garantizaron que las interacciones enriquecidas no se vean limitadas por SSR: los usuarios avanzados en dispositivos modernos obtienen una experiencia fluida similar a la de una aplicación. Por ejemplo, al combinar SSR y CSR, aplicaciones como el panel de Inngest pueden adaptarse a ambos escenarios: una renderización rápida inicial para todos y luego funciones interactivas avanzadas para aquellos que pueden aprovecharlas. Otro aspecto de la UX es la fiabilidad : características como los límites de error garantizan que, si algo sale mal, el usuario vea un mensaje intuitivo o una interfaz de usuario alternativa en lugar de una página rota. Centrarse en estos detalles (a menudo mediante herramientas DX mejoradas) en última instancia produce una experiencia más pulida y sin errores .
  • Comentarios y métricas centradas en el usuario: Varios equipos han comenzado a monitorizar no solo métricas técnicas, sino también métricas centradas en el usuario (como el tiempo de interacción o incluso las puntuaciones de satisfacción del usuario). Al correlacionar las mejoras (por ejemplo, un INP más rápido) con el comportamiento del usuario (mayor duración de la sesión, puntuaciones NPS más altas), fundamentan el trabajo de UX. Por ejemplo, tras optimizar su sitio web, una organización observó un aumento en la conversión y las donaciones , lo que vincula directamente el trabajo de rendimiento con el éxito del usuario. Esta visión holística garantiza que los esfuerzos de rendimiento y accesibilidad se centren en el impacto real en el usuario, no solo en cumplir requisitos.

En resumen, el período de 2022 a 2025 ha demostrado que invertir en el rendimiento y las mejores prácticas de React/Next.js es rentable en términos de experiencia de usuario (UX) . Los usuarios obtienen aplicaciones más rápidas, fluidas y accesibles. A su vez, las empresas experimentan una mayor interacción y conversión. Los casos prácticos presentados aquí son una prueba fehaciente de que la experiencia de usuario (UX) web es un factor diferenciador crucial y que puede mejorarse continuamente aplicando las técnicas y tecnologías adecuadas.

Conclusión y perspectivas prácticas

Los casos prácticos avanzados de 2022 a 2025 destacan una maduración en la creación de aplicaciones React. Los equipos están priorizando el rendimiento, utilizando Next.js y las funciones modernas de React para lograr mejoras sustanciales en Core Web Vitals y la velocidad general. La dicotomía SSR vs. CSR se ha suavizado hasta convertirse en una combinación pragmática de ambas, adaptada al caso de uso: HTML inicial cuando se necesita e interactividad del lado del cliente cuando resulta útil. El almacenamiento en caché se aprovecha en cada capa para ofrecer resultados instantáneos sin sacrificar la frescura de los datos. La gestión de estados se está volviendo más ligera y específica, lo que reduce la complejidad innecesaria. Las mejoras en la experiencia del desarrollador (desde mejores frameworks hasta herramientas más rápidas) permiten que los equipos puedan entregar sus aplicaciones de forma más fiable y fácil de mantener que antes. Fundamentalmente, la accesibilidad y la experiencia de usuario son objetivos prioritarios, no meras ideas, lo que da como resultado aplicaciones inclusivas y fáciles de usar.

Para los líderes de ingeniería y desarrolladores, las conclusiones son claras y prácticas:

  • Mida y optimice lo que importa (por ejemplo, concéntrese en LCP e INP si le están perjudicando; utilice métricas de usuarios reales para guiar los esfuerzos).
  • Adopte las características de Next.js y React 18+ para manejar tareas pesadas (SSR, RSC, Suspense, etc.): pueden mejorar drásticamente el rendimiento y la experiencia de usuario cuando se usan bien.
  • Almacene en caché de forma agresiva pero cuidadosa , y use CDN: acelere las visitas repetidas y el acceso global y, al mismo tiempo, asegúrese de tener una estrategia para actualizar el contenido obsoleto.
  • Mantenga la gestión del estado simple : no recurra a Redux o al estado global a menos que sea necesario; considere React Query o el contexto para la mayoría de los casos.
  • Invierta en herramientas y arquitectura DX : un proyecto bien estructurado (como el directorio de aplicaciones de Next) y ciclos de desarrollo rápidos rendirán dividendos en calidad.
  • Tenga en cuenta la accesibilidad y las consideraciones de experiencia de usuario desde el principio : utilice HTML semántico, pruebe con lectores de pantalla y diseñe estados de carga y estados de error de forma proactiva.

Siguiendo estas prácticas, los equipos pueden lograr resultados como los de nuestros casos prácticos: aplicaciones más rápidas, mayor interacción, mantenimiento más sencillo y usuarios satisfechos. El período que abarca este estudio ha sido de rápida evolución para React y Next.js en producción, y las lecciones aprendidas sentaron las bases para una mayor innovación y excelencia en el desarrollo web en los próximos años. Cada mejora, ya sea un 65 % más rápido en el tiempo de carga o un aumento del 5 % en la conversión, representa una mejor experiencia para los usuarios reales. Y, en definitiva, ese es el verdadero objetivo de cualquier caso práctico de tecnología: aprender a mejorar las cosas para quienes usan nuestro software a diario.

Fuentes

Seraphinite AcceleratorOptimized by Seraphinite Accelerator
Turns on site high speed to be attractive for people and search engines.