Cómo utilizar Google CrUX para analizar y comparar el rendimiento de JS Frameworks

 

 

 

  • Diseño de arquitectura de componentes de interfaz de usuario y tokens, con Nathan Curtis
  • Patrones de diseño para interfaces de IA, con Vitaly Friedman

  • Índice
    1. Recopilación de elementos básicos de la Web desde el campo
    2. Comparación de CWV de marcos de JavaScript
    3. Comprobando los mejores sitios
    4. Análisis por métrica
    5. Análisis de aspectos adicionales de la página web
    6. El impacto de la RSS y la SSG
    7. Métricas de rendimiento para marcos de aplicaciones web
    8. Resumen

    Google recopila información de rendimiento de millones de navegadores Chrome habilitados en todo el mundo y utiliza esta información como factor de clasificación de rendimiento para su motor de búsqueda. Pero también hace que esta información esté disponible gratuitamente para que cualquiera pueda utilizarla para comprobar el rendimiento real de sitios web individuales. Aún más importante es que es posible segmentar estos datos según las tecnologías utilizadas en los sitios web. En este artículo, Dan Shappir aprovecha esta información para analizar y comparar el rendimiento de los principales marcos de JavaScript. En el camino, descubre comportamientos inesperados y resuelve un misterio sobre el rendimiento web.

     

    En los últimos años, los frameworks se han hecho cargo del desarrollo web y React está a la cabeza. Hoy en día es bastante raro encontrar un nuevo sitio web o aplicación web que no dependa de algún marco o plataforma como un CMS.

    Y aunque el eslogan de React es "una biblioteca de JavaScript para crear interfaces de usuario" en lugar de un marco, creo que el barco ha zarpado: la mayoría de los desarrolladores de React lo consideran un marco y lo utilizan como tal. O lo utilizan como parte de un marco de aplicación más amplio, como NextJS, Gatsby o RemixJS.

    Pero, ¿qué precio pagamos, como desarrolladores web, por la experiencia de desarrollo mejorada que ofrecen dichos marcos? Y, lo que es más importante, ¿qué precio, si corresponde, pagan nuestros usuarios por esta elección que estamos haciendo?

    Recientemente, Noam Rosenthal publicó dos artículos que analizan los beneficios y capacidades comunes que ofrecen varios marcos , y también sus costos asociados. Recomiendo encarecidamente consultar estos artículos. Uno de los costos que menciona Noam es el aumento del tamaño de descarga, especialmente el tamaño de los paquetes de JavaScript, que se deriva del uso de marcos y otras bibliotecas. En particular, el aumento en la cantidad de JavaScript descargado puede tener un impacto directo en el rendimiento del sitio web. Y hay otros aspectos del uso del marco que también pueden afectar el rendimiento.

     

    En este artículo, analizaré el costo de rendimiento asociado con varios marcos, según los datos de campo recopilados por el Informe de experiencia del usuario de Google Chrome , o CrUX para abreviar. Creo que esta información es interesante y útil, en particular dada la amplia variedad de opciones de marcos y plataformas disponibles actualmente para los desarrolladores front-end y fullstack.

    Sin embargo, al revisar estos datos, es importante no combinar correlación y causalidad. El hecho de que las páginas web creadas utilizando un marco en particular a menudo tengan un rendimiento mejor o peor que otro marco no significa que el marco en sí siempre tenga la culpa. Por ejemplo, podría deberse a que ciertos marcos se utilizan más comúnmente para crear sitios web más pesados.

    Dicho esto, estos datos pueden ayudar a tomar decisiones informadas sobre qué marco elegir al implementar proyectos front-end. Cuando sea posible, preferiría marcos que tengan un índice de buen rendimiento más alto.

    Recopilación de elementos básicos de la Web desde el campo

    Como mencioné anteriormente, mi principal fuente de datos para este análisis es Google CrUX. CrUX es una base de datos basada en la nube en la que se recopilan mediciones de usuarios reales (RUM) a partir de sesiones en vivo del navegador Chrome. Si ha optado por sincronizar el historial de navegación, no ha configurado una frase de contraseña de sincronización y tiene habilitados los informes de estadísticas de uso, cada vez que cargue una página web usando Chrome, la información sobre su sesión se informará automáticamente a CrUX. En particular, las mediciones recopiladas incluyen las tres métricas Core Web Vitals medidas para cada sesión.

    En los últimos años, estas métricas se han convertido en la piedra angular del análisis moderno del rendimiento web:

    • Pintura con contenido más grande (LCP) ,
    • Retraso de la primera entrada (FID) ,
    • Cambio de diseño acumulativo (CLS) .

    Para cada una de estas métricas, Google ha definido rangos que pueden considerarse buenos (verde), promedio/necesita mejorar (naranja) y malos (rojo).

    ( Vista previa grande )

    A partir de junio de 2021, estas métricas se han convertido en un factor de clasificación para la búsqueda de Google. Esto también aumenta su importancia.

    Además de recopilar datos de campo para cada sesión, se realizan mediciones sintéticas en los sitios web, utilizando la herramienta WebPageTest . Estas mediciones de laboratorio se recopilan en otro repositorio en línea llamado HTTP Archive . Esto incluye analizar qué tecnologías utiliza una página web, incluidos qué marcos de JavaScript, utilizando el servicio Wappalyzer .

    Google permite ejecutar consultas en ambas colecciones utilizando su proyecto BigQuery. Sin embargo, la forma más sencilla de obtener información a partir de estos datos es utilizar el Informe de tecnología Core Web Vitals creado por Rick Viscomi. (Rick es ingeniero de desarrollo de personal en Google y administra CrUX y HTTP Archive). Este informe proporciona un medio para representar gráficamente de forma interactiva datos relacionados con el rendimiento para varias plataformas y tecnologías basadas en la web y compararlas fácilmente entre sí.

     

    Para este artículo, me baso principalmente en los conocimientos adquiridos al analizar los datos presentados mediante el Informe de tecnología Core Web Vitals.

    Hay algunas advertencias a tener en cuenta al analizar estos datos:

    • Mientras que los datos de campo se recopilan por página, el Informe de tecnología los muestra por origen. El valor de origen es una suma de los valores de todas las páginas para ese origen, calculado como un promedio ponderado basado en el tráfico de la página.
    • Por otro lado, los ratios de buenos orígenes no están ponderados. Esto significa que un origen que tiene relativamente poco tráfico, pero suficiente para ser incluido en el conjunto de datos, se cuenta por igual como un origen muy popular y de alto tráfico. Este aspecto del cálculo se puede mitigar filtrando los orígenes por ranking de popularidad.
    • HTTP Archive solo analiza la página de inicio de cada origen. Esto significa que la determinación del marco solo se realiza para la página de inicio, y todas las demás páginas pertenecientes a ese origen se agregan para ella, independientemente de si la usan o no, o incluso si usan algún otro marco.
    • Los subdominios se miden como orígenes distintos.

    Comparación de CWV de marcos de JavaScript

    Comencemos comparando el rendimiento de varios marcos de JavaScript. Específicamente, la proporción de sitios web creados con cada uno de estos marcos que tienen buenas puntuaciones (verdes) para las tres métricas de CWV del total de sitios creados con ellos. Los sitios que tienen buenos puntajes para las tres métricas de CWV deberían brindar una mejor experiencia de usuario en términos de rendimiento y también son elegibles para el aumento máximo en la clasificación de búsqueda de Google.

    He filtrado los datos para incluir solo sesiones en los EE. UU. con el fin de eliminar el impacto de las diferentes distribuciones geográficas entre los diferentes marcos. La línea TODO en los gráficos se refiere a todos los sitios web en CrUX, no solo a aquellos que usan marcos, y se utiliza como referencia para comparar.

    Porcentaje de sitios web con CWV totalmente verde para marcos y sesiones líderes en dispositivos móviles en EE. UU. ( Vista previa grande )
    Porcentaje de sitios web con CWV completamente verde para marcos líderes y sesiones en computadoras de escritorio en EE. UU. ( Vista previa grande )

    Nota : Móvil en este caso no incluye dispositivos iOS, como el iPhone. Esto se debe a que Chrome en iOS es solo una delgada envoltura alrededor de un núcleo de Safari y no mide ni informa CWV. (Esto es cierto para todos los navegadores en iOS; todos son simplemente Safari por dentro).

     

    En primer lugar, podemos ver que diferentes marcos producen resultados notablemente diferentes. Además, para bien o para mal, estos resultados son en su mayoría estables durante todo el año pasado. (Preact es una excepción a esto y explicaré la causa de esta variación en breve). Esto indica que las puntuaciones son significativas y no casualidades o resultados de anomalías estadísticas.

    Según estas mediciones, como indica el artículo de Noam Rosenthal, el uso de marcos tiene un costo de rendimiento: al compararlo con la línea de base ALL, vemos que los sitios web creados con cualquiera de estos marcos generalmente tienen menos probabilidades de tener un buen CWV que los sitios web creados sin marcos. Si bien algunos marcos como React, Preact y Svelte se acercan al promedio general, es interesante notar que ninguno de los marcos proporciona un rendimiento significativamente mejor que los demás.

    React y Preact están esencialmente codo a codo; algunos pueden sorprenderse por esto dado lo más pequeño que es Preact que React: aproximadamente 4 KB de descarga frente a 32 KB (minificado y comprimido en ambos casos). Aparentemente esa diferencia de descarga de 28 KB no es tan significativa en la mayoría de los casos. Jason Miller, el creador de Preact, dijo recientemente lo siguiente al respecto :

    Preact no está asociado con ningún SSR específico o soluciones de servicio, que dominan el impacto en CWV. Si bien el uso de Preact puede tener cierta correlación con CWV (en realidad solo FID), no es tan directo como las opciones tecnológicas involucradas en la entrega de páginas.

    – Jason Miller ⚛ (@_developit) 11 de febrero de 2022

    Inspeccionaré el impacto de la representación del lado del servidor (SSR) y también de la generación de sitios estáticos (SSG) como opciones de generación/entrega de páginas con más detalle más adelante en este artículo.

    Vue y AngularJS se encuentran en un segundo nivel: aproximadamente entre un 20 y un 25 % menos de probabilidades de obtener un buen CWV en dispositivos móviles y entre un 15 y un 20 % menos de probabilidades en computadoras de escritorio. (Nuevamente, excluyendo iOS). Dicho esto, Vue parece estar ganando terreno y reduciendo lentamente la brecha con React en términos de rendimiento.

    La gran caída en el rendimiento de Preact no está relacionada con ningún cambio en el marco en sí ni en su uso. Más bien tiene que ver con la identificación de Preact por parte de Wappalyzer. Desafortunadamente, este servicio omitió la mayoría de los usos de Preact antes de noviembre de 2021. Como resultado, los resultados anteriores de Preact deben ignorarse por no ser válidos.

    Comprobando los mejores sitios

    Cuando limitamos nuestra vista solo a los 1.000.000 de sitios principales en los EE. UU. (según el tráfico), un cambio interesante es que Vue casi alcanza a React porque la proporción de sitios que tienen buen rendimiento usando Vue aumenta y para React sorprendentemente disminuye:

    Porcentaje de sitios web con CWV totalmente verde para marcos líderes, sesiones en dispositivos móviles en EE. UU. para los 1.000.000 de sitios web principales. ( Vista previa grande )
    Porcentaje de sitios web con CWV totalmente verde para marcos líderes, sesiones en computadoras de escritorio en EE. UU. para los 1.000.000 de sitios web principales. ( Vista previa grande )

     

    Y vemos el mismo comportamiento con los 100.000 sitios principales, con la proporción de React en realidad cayendo, de modo que Vue la supera ligeramente. No intenté limitar aún más los resultados porque las cifras de uso de algunos marcos cayeron tan bajo que ya no eran suficientemente significativas estadísticamente.

    Pero al observar los números que tenemos, el hecho de que el rendimiento de Vue mejore en sitios con mayor tráfico tal vez indica que lograr un buen rendimiento con Vue requiere mayor experiencia en ese marco que simplemente poder usarlo. Esto se debe a que es más probable que los sitios con mayor tráfico sean creados por organizaciones que pueden permitirse contratar desarrolladores con mayor experiencia. Además, las organizaciones más grandes pueden permitirse gastar más en infraestructura optimizada para el rendimiento.

    Por otro lado, los sitios de React en realidad caen al limitar la cantidad de sitios medidos por tráfico.

    ¿Por qué los desarrolladores de React con mayor experiencia aparentemente tienen menos probabilidades de producir sitios web de carga rápida?

    Bueno, ese es un misterio muy interesante que intentaré resolver.

    Análisis por métrica

    Además de examinar el CWV en su conjunto, el Informe de Tecnología también permite examinar cada métrica individualmente. Comencemos mirando FID:

    Porcentaje de sitios web con FID verde para marcos líderes y sesiones en dispositivos móviles en EE. UU. ( Vista previa grande )

    Se podría haber esperado que los sitios web que utilizan frameworks pagaran una penalización en la métrica de capacidad de respuesta, ya que es la que debería verse más afectada por el uso significativo de JavaScript. Pero, en la práctica, este no es el caso. De hecho, la métrica FID esencialmente no tiene sentido, y todos los marcos logran una puntuación casi perfecta.

    Lo mismo ocurre incluso cuando se observa la agregación de todos los sitios web de la colección. Por este motivo, Google está investigando una mejor métrica de capacidad de respuesta y solicita comentarios sobre la métrica experimental que ya están probando . Mejores Opiniones y reviews

    Examinar la métrica LCP es mucho más significativo:

    Porcentaje de sitios web con LCP verde para marcos líderes y sesiones en dispositivos móviles en EE. UU. ( Vista previa grande )

    Curiosamente, los puntajes de LCP son una fuerte coincidencia para CWV en su conjunto, pero están más dispersos: ALL, React, Preact y Svelte son aproximadamente un 10% más altos, mientras que Vue y AngularJS siguen siendo esencialmente los mismos. Pero cuando nos limitamos a los 1.000.000 de sitios principales, vemos que Preact y Svelte mejoran un poco más, pero React no. Como resultado, Vue lo alcanza.

    Porcentaje de sitios web con LCP verde para marcos líderes, sesiones en dispositivos móviles en EE. UU. para los 1.000.000 de sitios web principales. ( Vista previa grande )

     

    Finalmente veamos CLS, comenzando con todos los sitios web:

    Porcentaje de sitios web con CLS verde para marcos líderes y sesiones en dispositivos móviles en EE. UU. ( Vista previa grande )

    Y para los 1.000.000 de sitios web principales:

    Porcentaje de sitios web con CLS verde para marcos líderes, sesiones en dispositivos móviles en EE. UU. para los 1.000.000 de sitios web principales. ( Vista previa grande )

    Aquí vemos que tanto React como Preact, especialmente React, disminuyen sustancialmente, lo que hace que Vue los supere a ambos.

    En otras palabras, para Vue, tanto la proporción de buen LCP como de CLS mejoran cuando revisamos solo los sitios principales. Para React, por otro lado, LCP sigue siendo prácticamente el mismo, mientras que CLS en realidad se degrada.

    Esto podría indicar que una razón de la degradación del rendimiento observada en los principales sitios que utilizan React es un aumento en la cantidad de anuncios en las páginas. Los anuncios a menudo afectan negativamente a CLS porque, cuando aparecen, desplazan otros contenidos hacia abajo. Sin embargo, no creo que ese sea el caso porque no explica la diferencia de comportamiento entre React y los otros frameworks. Además, es de esperar que los anuncios también afecten al LCP, pero vemos que el LCP sigue siendo esencialmente el mismo.

    Para intentar comprender mejor este comportamiento, revisemos otros aspectos de la página web visualizados por el Informe Tecnológico.

    Análisis de aspectos adicionales de la página web

    Además de las puntuaciones de rendimiento, el Informe de tecnología permite el análisis de los tamaños de descarga de recursos. Es bien sabido que la cantidad de JavaScript utilizado por una página puede tener un impacto directo en su rendimiento porque todo el código debe descargarse, analizarse y ejecutarse. Comparemos la cantidad de JavaScript descargado por los distintos marcos:

    Tamaño de descarga de JavaScript en KB para dispositivos móviles en EE. UU. ( Vista previa grande )

    Como era de esperar, los sitios web que utilizan frameworks descargan significativamente más JavaScript que los sitios web en general. Esto se debe a toda la funcionalidad requerida para las aplicaciones de página única (SPA), como el enrutamiento y la representación del lado del cliente.

    Tampoco es sorprendente que los sitios web creados con Svelte descarguen menos JavaScript que cualquier otro de estos marcos . Esto se debe a que el compilador Svelte maneja en tiempo de compilación una gran cantidad de funciones que otros marcos necesitan realizar en tiempo de ejecución. Como resultado, Svelte no necesita implementar el código necesario para dicha funcionalidad. También es posible que los desarrolladores que utilizan Svelte den mayor importancia a la entrega de páginas web sencillas que los desarrolladores que utilizan otras plataformas.

    Dicho esto, la diferencia de 226 KB entre la mediana de los sitios Svelte y los sitios React solo se traduce en un aumento del 2,4 % en la cantidad de sitios que tienen un buen CWV. Esto resalta la sorprendente mejora que los navegadores han podido lograr en el manejo de cargas útiles de JavaScript más grandes, por ejemplo, al analizar el JavaScript del hilo principal, durante la descarga. Supongo que el almacenamiento en caché, tanto en el navegador como en las CDN, también contribuye a esto.

     

    También es interesante notar que los sitios web y las aplicaciones que usan Preact en realidad descargan más JavaScript que aquellos que usan React . Quizás estos sitios eligieron Preact en un esfuerzo por reducir su peso total. En cualquier caso, esto puede explicar por qué no vimos mejoras notables en el rendimiento de Preact sobre React: cualquier beneficio que proporcione Preact se compensa con el código de la aplicación en sí.

    Cuando miramos los 1.000.000 principales vemos que la cantidad de JavaScript aumenta, con la interesante excepción de Vue.

    Tamaño de descarga de JavaScript en KB para dispositivos móviles en EE. UU. para los 1.000.000 de sitios web principales. ( Vista previa grande )

    Esto puede explicar por qué vimos una mejora tan significativa en Vue para los sitios principales, en comparación con otros marcos. En el caso de esos otros marcos, parece que cualquier mayor experiencia que puedan tener los desarrolladores que trabajan en los mejores sitios, no se traduce en tamaños de descarga de JavaScript reducidos. En realidad, ocurre todo lo contrario, tal vez debido a la funcionalidad adicional que ofrecen dichos sitios web.

    Otra comparación muy interesante es la cantidad de datos de imágenes descargados:

    Tamaño de descarga de imágenes en KB para dispositivos móviles en EE. UU. ( Vista previa grande )

    Aquí vemos que los sitios creados con React, Svelte y Angular descargan significativamente menos datos de imágenes que los sitios web en general. Esto puede tener que ver con que dichos sitios aprovechen técnicas modernas para reducir las descargas de imágenes, como la carga diferida y formatos de imagen más nuevos. Curiosamente, los sitios Angular descargan muchos menos datos de imágenes que cualquier otro marco.

    Si analizamos los principales sitios, vemos un aumento significativo en las descargas de imágenes en todos los ámbitos.

    Tamaño de descarga de imágenes en KB para dispositivos móviles en EE. UU. para los 1.000.000 de sitios web principales. ( Vista previa grande )

    Esto puede tener que ver con que los sitios principales sean más ricos en contenido. En particular, es probable que los sitios principales tengan más anuncios, que son principalmente imágenes. Y, como veremos, también hay otras explicaciones posibles.

    El impacto de la RSS y la SSG

    Como afirmó Jason Miller en el tweet que cité anteriormente, las opciones técnicas relacionadas con la entrega de páginas web tienen el mayor impacto en las métricas de CWV, en particular en LCP. Técnicas como la representación del lado del servidor (SSR) y la generación de sitios estáticos (SSG) entregan HTML con contenido al navegador desde el principio, permitiéndole mostrar el contenido inmediatamente tal como llega. Esto suele ocurrir mucho antes de que el contenido visual pueda generarse mediante técnicas de representación del lado del cliente, especialmente cuando el contenido HTML se almacena en caché en una CDN o en el propio navegador. Sin embargo, implementar correctamente la infraestructura requerida para este método de operación puede resultar un desafío cuando se utiliza un marco de JavaScript. Como resultado, en los últimos años hemos sido testigos de la introducción de múltiples marcos de aplicaciones web que brindan esta funcionalidad lista para usar para los principales marcos de JavaScript y bibliotecas de UI.

     

    Teniendo en cuenta todo esto, esperamos que los sitios web creados con estos marcos de aplicaciones web tengan una proporción notablemente mayor de buenas métricas CWV que los sitios web creados utilizando solo marcos o bibliotecas de JavaScript.

    Para determinar si este es realmente el caso, utilicé el Informe de tecnología Core Web Vitals para comparar la proporción de sitios web que tienen un buen CWV para React, Vue y Svelte en general con la misma proporción para los marcos de aplicaciones web líderes que se construyen sobre a ellos:

    Porcentaje de sitios web con todas las sesiones CWV verdes en dispositivos móviles en EE. UU. ( Vista previa grande )

    Inmediatamente notamos que SvelteKit puede proporcionar un rendimiento mucho mayor que todo lo demás. Dicho esto, sólo hay 33 sitios web en este conjunto de datos que utilizan SvelteKit. Este número es demasiado bajo para sacar conclusiones sobre su capacidad para ofrecer un buen rendimiento de forma constante. Pero será interesante ver si su rendimiento se mantiene a medida que aumenta su uso.

    Podemos ver que, si bien el marco de Gatsby proporciona una proporción significativamente mayor de CWV bueno que React en general, este no es el caso de NextJS. Y aunque NuxtJS proporciona una mejor proporción que Vue en general, esa proporción sigue siendo menor que la de React.

    Además, ¿por qué incluí Wix en este gráfico? Después de todo, Wix no es un marco de aplicación web creado sobre un marco de JavaScript. ¿O es eso?

    En realidad, Wix se implementa utilizando React y, como resultado, cada sitio web de Wix también se identifica como un sitio web de React, al igual que Gatsby y NextJS. En otras palabras, aunque no escribes explícitamente código de React cuando usas Wix (después de todo, es un creador de sitios web de arrastrar y soltar), sí genera un sitio web de React para ti. Además, Wix también emplea SSR como Next.js y usa CDN como NextJS y Gatsby. Y tiene un ratio de buen rendimiento más alto que cualquiera de ellos .

    Ahora consideremos la cantidad de sitios web creados utilizando cada una de estas tecnologías:

    Número de sesiones en móvil en EE.UU. ( Vista previa grande )

    Wix no solo supera significativamente a los marcos de aplicaciones web populares, sino que, de hecho, alrededor de un tercio de los sitios web de React en los EE. UU. son en realidad sitios web de Wix .

    Esto es significativo porque, en una proporción tan alta, el rendimiento de Wix impacta notablemente el rendimiento medido para los sitios web de React en su conjunto. Afortunadamente, como vimos en el gráfico de rendimiento, Wix en realidad tiene una proporción más alta de CWV bueno que los sitios React en general. En otras palabras, Wix en realidad aumenta las puntuaciones de rendimiento medidas para React.

    Pero cuando nos limitamos a los 1.000.000 de sitios web principales de EE. UU., las proporciones cambian sustancialmente:

    Número de sesiones en dispositivos móviles en EE. UU. para los 1.000.000 de sitios web principales. ( Vista previa grande )

     

    La proporción de Wix y todos los demás marcos de aplicaciones web del total de sitios web de React cae significativamente cuando se mira solo los 1.000.000 de sitios web principales. En este conjunto de datos, sólo el 14% de los sitios React están creados con Wix. Esto significa que el impacto de Wix en el rendimiento general de React se reduce mucho cuando se mira solo en los sitios principales. Esta es una razón importante por la que el buen índice de rendimiento de React en realidad se degrada cuando se inspeccionan solo los sitios principales, a diferencia de otros marcos de JavaScript.

    En otras palabras, Wix es la solución al misterio del inesperado perfil de rendimiento de React.

    Métricas de rendimiento para marcos de aplicaciones web

    Pero ¿qué pasa con NextJS y NuxtJS? ¿Por qué no brindan los beneficios de rendimiento esperados en todos los ámbitos que vemos con Gatsby (y también con Wix)? El análisis de cada métrica individualmente puede revelar las causas fundamentales de este comportamiento.

    Como antes, la métrica FID esencialmente no tiene ningún impacto en el índice de rendimiento general, ya que todos los marcos logran un buen índice FID superior al 97%.

    Las cosas se ponen más interesantes cuando comparamos los ratios CLS:

    Porcentaje de sitios web con CLS verde, sesiones en dispositivos móviles en EE. UU. ( Vista previa grande )

    Podemos ver que NextJS en realidad supera a React, pero Gatsby todavía está por delante. Además, NuxtJS está justo en el medio entre Vue y React.

    Dado que todos estos marcos tienen esencialmente los mismos buenos índices FID y buenos índices CLS, esto indica que la causa principal de la diferencia entre estos marcos es LCP:

    Porcentaje de sitios web con LCP verde, sesiones en dispositivos móviles en EE. UU. ( Vista previa grande )

    Como era de esperar, vemos que Gatsby está significativamente por delante de React, y también que React en general está por delante de Next.js. Dado que NextJS utiliza SSR/SSG y formatos de imagen modernos, esto es sorprendente. Ciertamente, esto es algo a tener en cuenta al utilizar ese marco.

    NuxtJS ha logrado avances significativos en este sentido en los últimos meses y ha superado a NextJS con creces. LCP, que es esencialmente lo mismo que React en general.

    Veamos si las diferencias de LCP pueden explicarse por los tamaños de descarga de imágenes, ya que las imágenes más grandes suelen ser perjudiciales para LCP:

    Tamaño de descarga de imágenes en KB para dispositivos móviles en EE. UU. ( Vista previa grande )

    Es interesante ver que los sitios web que usan NuxtJS y Vue descargan significativamente más datos de imágenes que los sitios web que usan React, y que NuxtJS es capaz de lograr una relación LCP bastante buena a pesar de esto.

    Gatsby y NextJS son eficientes en términos de la cantidad de datos de imágenes descargados. Esto significa que la buena relación LCP mejorada que proporciona Gatsby no se debe solo a tamaños de imagen reducidos. Para mí, esto indica que es probable que Gatsby pueda iniciar antes la descarga de la imagen más grande y priorizarla mejor frente a otros recursos de la página.

    Curiosamente, la página de inicio de Gatsby usa WebP para imágenes y la página de inicio de NextJS usa AVIF.

    Resumen

    Todos los marcos que revisé en este artículo tienen buenos índices de rendimiento superiores al 0%, lo que significa que puedes crear sitios de carga rápida, según lo medido por CWV, utilizando cualquiera de ellos. Asimismo, todos estos frameworks tienen buenos ratios de rendimiento inferiores al 100%, lo que significa que también puedes crear sitios de carga lenta utilizando cualquiera de ellos.

    Dicho esto, vimos diferencias significativas entre los buenos índices de rendimiento de los distintos marcos. Esto significa que la probabilidad de que un sitio web creado con un marco específico tenga un buen rendimiento puede ser muy diferente a la de otro marco. Ciertamente, esto es algo a considerar al decidir






    Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    Cómo utilizar Google CrUX para analizar y comparar el rendimiento de JS Frameworks

    Cómo utilizar Google CrUX para analizar y comparar el rendimiento de JS Frameworks

    Diseño de arquitectura de componentes de interfaz de usuario y tokens, con Nathan Curtis Patrones de diseño para interfaces de IA, con Vitaly Friedman Ín

    programar

    es

    https://aprendeprogramando.es/static/images/programar-como-utilizar-google-crux-para-analizar-y-comparar-el-rendimiento-de-js-frameworks-1141-0.jpg

    2024-04-04

     

    Cómo utilizar Google CrUX para analizar y comparar el rendimiento de JS Frameworks
    Cómo utilizar Google CrUX para analizar y comparar el rendimiento de JS Frameworks

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Top 20