El propósito de este informe es analizar datos del mundo real para entender mejor la relación entre la elección de framework, el rendimiento, y la experiencia real del usuario en la web. Intentaremos arrojar luz sobre algunas preguntas clave:
- ¿Cómo se comparan los frameworks web modernos en uso y rendimiento del mundo real?
- ¿La elección de framework influye en los Core Web Vitals de un sitio?
- Qué tan relacionada está la elección de framework con el tamaño del payload de JavaScript, y cuál es el impacto?
Los Datos
Para hacer esto, analizamos tres conjuntos de datos públicamente disponibles diferentes:
- The Chrome User Experience Report (CrUX) proporciona métricas de experiencia de usuario sobre cómo los usuarios reales de Chrome experimentan los destinos populares en la web.
- The HTTP Archive que rastrea e informa el rendimiento de más de 15 millones de sitios web a lo largo del tiempo recopilando regularmente datos de rendimiento de Lighthouse.
- The Core Web Vitals Technology Report que recopila información útil de los dos conjuntos de datos anteriores.
Todos los datos fueron recopilados de conjuntos de datos públicos gestionados de forma independiente. Ningún dato de rendimiento fue medido directamente por el equipo de Astro. Conoce más sobre nuestra metodología en la sección a continuación.
Los Frameworks
Para crear este informe, decidimos analizar seis frameworks web populares basados en JavaScript: Astro, Gatsby, Next.js, Nuxt, Remix, y SvelteKit. También incluimos datos de WordPress cuando es posible, debido a su popularidad y gran cuota de mercado (43.2%) en la web.
Varios frameworks nuevos y emocionantes tuvieron que ser excluidos por no tener suficiente uso en el mundo real en los conjuntos de datos que elegimos, pero esperamos incluir más frameworks en el próximo informe.
Core Web Vitals
Los Core Web Vitals (CWV) de Google son un conjunto de tres métricas estandarizadas que te ayudan a entender cómo los usuarios experimentan una página web. Cada métrica mide un aspecto diferente de la experiencia del usuario — velocidad de carga, responsividad, estabilidad visual — y juntas cuantifican el rendimiento general de un sitio web.
Google Core Web Vitals Assessment es una prueba que analiza los datos de medición de usuarios reales (del conjunto de datos CrUX) en las tres métricas para determinar una calificación general de aprobado/reprobado para cada sitio web. Para que un sitio web apruebe, debe cumplir el umbral asociado de “bueno” en las tres métricas. Si alguna métrica no cumple el umbral, el sitio web reprueba la evaluación.
La evaluación CWV es única en su uso de datos y mediciones de usuarios reales. Esto la hace una reflexión más precisa de cómo los usuarios experimentan realmente un sitio web, especialmente en sesiones más largas. Lighthouse y otras herramientas de pruebas de laboratorio solo pueden medir la primera carga de página, lo que no logra capturar la experiencia completa de usar un sitio web.
Al analizar todos los sitios web conocidos construidos con un determinado framework, Astro y SvelteKit superaron la tasa de aprobación promedio de todos los sitios web probados (40.5%) mientras que el resto de los frameworks no lo hizo. Astro fue el único framework en superar el 50% de sitios web que aprobaron la evaluación CWV de Google. Next.js y Nuxt quedaron al final del grupo con aproximadamente 1 de cada 4 y 1 de cada 5 sitios web aprobando la evaluación, respectivamente.
¿Cuál es la causa más probable de que un sitio web repruebe la evaluación Core Web Vitals de Google? Podemos desglosar los datos por métrica individual para obtener información sobre dónde diferentes frameworks tienen dificultades (y éxitos) cuando se trata de web vitals.
First Input Delay (FID)
First Input Delay (FID) mide el tiempo desde que un usuario interactúa por primera vez con una página hasta que el navegador puede responder a esa interacción. La evaluación CWV de Google busca un FID de 100 milisegundos o menos. Cualquier cosa más lenta se considera que necesita mejoras y reprueba la evaluación.
La mayoría de los frameworks aprueban esta prueba fácilmente, con más del 90% de sitios web aprobando la evaluación. Ningún framework baja de una tasa de aprobación del 80% en esta prueba. Esto significa que la mayoría de los sitios web probados son responsivos a la primera interacción del usuario.
Cumulative Layout Shift (CLS)
Cumulative Layout Shift (CLS) mide la estabilidad visual en la página. Para aprobar esta evaluación, debes reducir el desplazamiento inesperado del layout a casi cero para dar a tus usuarios una experiencia visual confiable.
CLS es una métrica interesante para que Google la incluya como uno de los tres Core Web Vitals porque no está estrictamente relacionada con la velocidad o la responsividad. Su inclusión subraya la importancia de mirar más allá del rendimiento cuando se trata de medir la calidad general de las experiencias de usuario en la web.
Todos los frameworks obtuvieron un 50% o más en esta métrica. Sin embargo, son los frameworks más jóvenes (Astro, SvelteKit, y Remix) los que obtienen las puntuaciones más altas en esta métrica. Los tres superaron el 75% en la evaluación de esta métrica en todos los sitios web probados.
Largest Contentful Paint (LCP)
Largest Contentful Paint (LCP) es el último de los tres Core Web Vitals, y posiblemente el más importante cuando se trata del rendimiento percibido. Mide el punto en el que es probable que el contenido principal de la página se haya cargado. Se requiere un LCP de 2.5 segundos o menos para aprobar la evaluación CWV de Google. Cualquier cosa más lenta se considera que necesita mejoras y reprueba la evaluación.
LCP es la más difícil de las tres métricas de dominar. Solo el 52% de todos los sitios web probados aprueban esta métrica. De nuestros seis frameworks probados, solo Astro y SvelteKit superan este promedio. El resto queda por debajo del promedio.
¿Próximamente? Interaction to Next Paint (INP)
Interaction to Next Paint (INP) es un web vital experimental que evalúa la responsividad general del sitio web, similar a First Input Delay (FID). Donde las dos métricas difieren es que INP observa la latencia de todas las interacciones que un usuario ha realizado con la página, no solo la primera. Un INP bajo significa que la página fue capaz de responder rápidamente a todas—o a la gran mayoría—de las interacciones del usuario de manera consistente.
Aunque INP no es un core web vital oficial hoy en día, el equipo de Chrome ha señalado su esperanza de reemplazar FID con INP como una medida más holística y precisa de la responsividad.
Entonces, ¿Cómo se comparan los frameworks frente a esta nueva métrica de responsividad?
Lo más notable en el gráfico es que una buena medición de INP es en general mucho más difícil de lograr para cada framework que First Input Delay (FID). Mientras que cada framework probado vio una tasa de aprobación del 80%+ en FID, ningún framework pudo ver esa misma tasa del 80% en INP. Astro se acercó más, con un 68.8% de aprobación.
Vale la pena señalar que la tasa de aprobación promedio en todos los sitios web rastreados es un sorprendentemente alto 60.9%. Mientras que Astro y WordPress parecen los éxitos destacados en el gráfico anterior, estos sitios en realidad solo están funcionando modestamente por encima del promedio de la industria. ¿Por qué muchos de los frameworks web probados tienen dificultades con esta métrica?
Una razón podría ser que la arquitectura de Single Page App (SPA) dirige toda la navegación a través de JavaScript como una acción del lado del cliente. Esto crea una oportunidad de retraso de entrada que las Multi-Page Apps (MPA) sin navegación del lado del cliente no tienen. En una MPA, navegar a una nueva página desencadena una carga completa de página desde el servidor que no se categoriza como retraso de entrada. Esto podría ayudar a explicar por qué Astro y WordPress (las dos MPAs en el gráfico) funcionan significativamente mejor en esta métrica que el resto de los frameworks probados (todos SPAs).
Anne Burnes de RebelMouse tiene un excelente artículo sobre la diferencia entre FID e INP:
FID cuantifica la experiencia de un usuario al intentar interactuar con páginas que no responden, pero solo mide la primera interacción. Según Google, INP toma una medición más completa de la responsividad de un sitio al cubrir todo el espectro de interacciones de un sitio, desde el momento en que una página comienza a cargarse hasta que el usuario abandona la página. Esta medición integral hace de INP un indicador más confiable de la responsividad general de un sitio que FID.
La naturaleza holística de INP hace que sea más difícil de resolver que FID, porque tu código tiene que estar implementado de una manera que proteja la responsividad para el usuario durante todo su recorrido, no solo en la primera carga. Como muchas interacciones se hacen a través de JavaScript, significa que tu sitio tiene que cargarse cuidadosamente para un rendimiento optimizado.
Esto es particularmente difícil en móvil. Analizamos un puñado de sitios en toda la industria y dentro de nuestra red de sitios, y descubrimos que en móvil las puntuaciones INP son 35.5% peores que FID en promedio. Al revisar el rendimiento de escritorio en el mismo conjunto de datos, solo hubo una caída del 14.1% en promedio.
– Anne Burnes, RebelMouse
Esta será una métrica interesante de seguir en 2023, y Google continúa considerando agregar INP como un Core Web Vital oficial.
Rendimiento de Lighthouse
Lighthouse es otra herramienta que podemos usar para medir la experiencia de usuario de un sitio web. HTTP Archive ejecuta Lighthouse en condiciones de carga móvil simuladas. Esto ofrece un análisis significativamente más detallado y consistente del rendimiento de carga de páginas, hasta fracciones de 100ms de un segundo. En lugar de mirar grandes umbrales y categorías de “bueno” vs. “malo”, Lighthouse te da una puntuación de rendimiento más detallada medida sobre 100.
Los datos de usuarios reales como Core Web Vitals siguen siendo la mejor medición de la experiencia real del usuario, y puedes ver cómo la experiencia real vs. la experiencia de laboratorio difiere en algunos de los gráficos a continuación. Sin embargo, todavía hay información interesante que se puede aprender de los detalles adicionales que Lighthouse proporciona. Echemos un vistazo a los datos.
En interés de la consistencia, hemos mantenido el orden original de la sección anterior. Sin embargo, notarás que Remix parece mucho más fuerte en rendimiento en Lighthouse de lo que lo fue en la evaluación CWV. Una explicación para esto puede ser el uso de startTransition y requestIdleCallback por parte de Remix para diferir la hidratación de React en la carga de página. Esto podría teóricamente traducirse en mejor rendimiento en algunas situaciones de laboratorio (como Lighthouse) a expensas de un mayor retraso de primera entrada en otras situaciones del mundo real.
Desafortunadamente, la puntuación mediana de rendimiento de Lighthouse es baja en general. La mitad de los frameworks probados tenían un rendimiento mediano considerado “pobre” (49 o menos) mientras que la otra mitad tenía una puntuación mediana que “necesita mejoras” (50-89). Ningún framework alcanzó una puntuación mediana “buena” de 90+.
En todos los sitios web rastreados, la puntuación mediana de rendimiento fue de 34/100. Con ese fin, la mitad de nuestros frameworks probados (Astro, SvelteKit, y Remix) sí quedaron por encima del promedio de internet.
Al desglosar los datos por percentil, podemos empezar a ver números algo más alentadores con Astro y SvelteKit alcanzando una puntuación de 90+ en los percentiles p90 o p95. Sin embargo, los datos muestran claramente que todos los sitios web y frameworks (incluyendo Astro) todavía tienen dificultades para lograr un buen rendimiento en situaciones del mundo real.
El Costo de JavaScript
Lo último que queríamos explorar era la relación entre la elección de framework, el rendimiento, y el tamaño total del payload de JavaScript en uso del mundo real. ¿Los frameworks más rápidos tienden a ser los que también envían la menor cantidad de JavaScript al cliente?
La tendencia en los datos es clara: los sitios que envían menos JavaScript tienden a funcionar mejor. Sin embargo, hay demasiados factores en juego para que podamos vincular confiadamente esta tendencia a la elección del framework web en sí. Podría ser el caso de que algunos frameworks fomenten/desaconsejen JavaScript de manera diferente a otros, pero se necesita más investigación antes de sacar conclusiones.
Metodología y Limitaciones
Este informe fue compilado a partir de varios conjuntos de datos disponibles públicamente. Puedes conocer más sobre estos conjuntos de datos y su metodología aquí: metodología de HTTP Archive, metodología de CrUX, y metodología del CWV Technology Report.
Debido a limitaciones de capacidad, nuestro análisis solo examina las páginas principales de cada sitio web rastreado. Un beneficio de esta limitación es que hay menos varianza en el propósito y caso de uso de cada sitio web analizado. Sin embargo, una desventaja es que esto también significa que las páginas interiores (como las páginas /about y /admin/...) y las tecnologías que utilizan no son analizadas y por lo tanto excluidas de nuestro análisis.
Otra limitación que no se explora en este informe es el impacto de la edad de un framework en el rendimiento web medido. Los frameworks más antiguos medidos aquí (Gatsby, Next.js, Nuxt) tienen una cola más larga de sitios web heredados ejecutando versiones más antiguas de su framework que están incluidos en el conjunto de datos. Esto crea una situación donde solo los frameworks más nuevos (Astro, Remix, SvelteKit) se puede asumir que están ejecutando versiones más modernas de su software de los últimos 1-2 años. Esta es una limitación de los datos que tenemos disponibles, pero es algo que esperamos explorar en futuros informes.