Medición del rendimiento: Lighthouse y Core Web Vitals

Lighthouse es la herramienta estándar para medir el rendimiento web. Ejecútelo en Chrome DevTools (pestaña Lighthouse) o mediante la CLI (npx lighthouse https://yoursite.com). Al evaluar Islands Architecture, ejecute Lighthouse en páginas representativas antes y después de la migración para cuantificar las mejoras de forma objetiva.

LCP mide el momento en que termina de renderizarse el elemento de contenido visible más grande. Islands Architecture mejora el LCP porque el servidor envía inmediatamente HTML completamente renderizado: el navegador no tiene que esperar a que JavaScript renderice el contenido. Una imagen principal o un titular que constituyan el LCP se pintan a partir de la respuesta HTML inicial.

En una SPA de React, el LCP suele retrasarse porque el navegador debe descargar y ejecutar JavaScript antes de que React renderice el elemento LCP. Con Islands Architecture, el contenido del LCP está incluido en el HTML inicial, por lo que la ejecución de JavaScript no bloquea el LCP. Esta es una de las ventajas medibles más importantes.

El tiempo total de bloqueo mide durante cuánto tiempo el hilo principal está bloqueado por tareas de JavaScript que duran más de 50 ms. Hidratar una SPA grande de React puede producir cientos de milisegundos de TBT. La Arquitectura de islas reduce drásticamente el TBT porque el JavaScript que se ejecuta es proporcional al número de islas, no al tamaño de la página.

El cambio acumulado del diseño mide la estabilidad visual: el desplazamiento de los elementos mientras se carga la página. El contenido renderizado con JavaScript puede provocar cambios de diseño cuando React renderiza y modifica las dimensiones. El HTML renderizado en el servidor de la Arquitectura de islas evita los cambios de diseño relacionados con la hidratación, porque el diseño inicial proviene de HTML estático que no cambia durante la hidratación.

El retraso de la primera entrada (First Input Delay, ahora reemplazado por Interaction to Next Paint, INP) mide la rapidez con la que la página responde a las interacciones del usuario. La Arquitectura de islas mejora el INP porque cada isla tiene un paquete de JavaScript pequeño y enfocado. Las interacciones dentro de una isla se ejecutan rápidamente porque no hay un árbol grande de React por el que se deba planificar el trabajo.

Una comparación habitual para una página de blog sería la siguiente: una SPA completa de React podría obtener entre 45 y 65 puntos en Lighthouse para móviles (TBT: 800 ms, LCP: 3,2 s). El mismo contenido como sitio de Astro con una isla de React podría obtener entre 90 y 98 puntos (TBT: 80 ms, LCP: 1,1 s). Las mejoras son más drásticas en páginas con mucho contenido y poca interactividad.

La Arquitectura de islas no es la opción adecuada para aplicaciones muy interactivas, como paneles, editores de código o herramientas colaborativas. Estas aplicaciones tienen componentes que comparten estado constantemente y se vuelven a renderizar juntos; la sobrecarga de la comunicación entre islas eliminaría las mejoras de rendimiento y añadiría complejidad arquitectónica.

La Arquitectura de islas es especialmente eficaz en sitios con mucho contenido y una interactividad dispersa: blogs (leer contenido y, ocasionalmente, indicar que gusta o comentar), documentación (leer documentos y, ocasionalmente, buscar o usar el botón para copiar código), páginas de destino (principalmente estáticas, con una isla para el formulario del boletín) y páginas de productos de comercio electrónico (imágenes y descripción estáticas, con una isla para añadir productos al carrito).

Google utiliza las Core Web Vitals (LCP, INP y CLS) como señales de posicionamiento. Mejorar estas métricas con la Arquitectura de islas beneficia directamente el posicionamiento en los resultados de búsqueda. Un sitio que mejora su puntuación de Lighthouse para móviles de 55 a 92 al adoptar la Arquitectura de islas obtiene simultáneamente beneficios para la experiencia del usuario y el SEO.

Los equipos que migran de una SPA de React con Next.js a Astro para sitios de marketing y documentación informan de patrones constantes: los paquetes de JavaScript se reducen entre un 70 % y un 90 %, las puntuaciones de rendimiento en móviles aumentan entre 20 y 40 puntos y los costes de alojamiento del servidor disminuyen, ya que los archivos estáticos se sirven desde una CDN sin la sobrecarga del renderizado en el servidor en cada solicitud.

¿Por qué la Arquitectura de islas reduce drásticamente el tiempo total de bloqueo (TBT)?

La Arquitectura de islas mejora todas las Core Web Vitals: el LCP se beneficia del HTML renderizado en el servidor, el TBT disminuye porque el JavaScript es proporcional a la interactividad, el CLS se reduce gracias a los diseños estables renderizados en el servidor y el INP mejora con paquetes de islas pequeños y enfocados. Las puntuaciones de Lighthouse de las páginas con mucho contenido mejoran drásticamente. Este patrón no es adecuado para aplicaciones muy interactivas, pero es excelente para blogs, documentación, páginas de destino y comercio electrónico.