Parece que Lighthouse 6 introduce algunas métricas nuevas y elimina otras de la versión 5, por lo que es probable que haya un cambio en la puntuación. Este artículo explica lo que ha cambiado:

https://web.dev/lighthouse-whats-new-6.0/

También hay un enlace al final a una calculadora de puntuación que es realmente útil para desglosar la puntuación y comprender qué factores contribuyen más.

https://googlechrome.github.io/lighthouse/scorecalc

Tengo la impresión de que hay más enfoque en la interactividad del hilo principal en la v6, por lo que si su sitio incluye grandes paquetes de JS, probablemente sea un factor significativo.

Sí @shanekenney , lo sé, pero realmente no sé cómo reducirlo aparte de eliminar partes del sitio para ver qué partes están provocando esto.

¿Ves también el impacto en los sitios gaysbyjs y theme-ui? Tengo curiosidad / me encantaría saber qué optimizaciones en su sitio pueden estar pensando o si han detectado alguna causa específica.

Este problema es excelente, por lo que podemos discutir los puntajes generales de Lighthouse / PageSpeed ​​Insights y las posibles regresiones que estamos viendo con v6.

@kuworking, algo que vale la pena señalar es que lighthouse-metrics.com parece usar _ "Emulated Nexus 5X" _ para 5.6 y _ "Emulated Moto G4" _ para 6.0, lo que también podría agregar algo de ruido a la comparación.

Este punto de referencia sobre 922 sitios afirma en v5 que la puntuación media de rendimiento para un sitio de Gatsby es 75 . Intentaré hacer una vista rápida utilizando soluciones alojadas para evitar que mi red local sea otro factor de variabilidad.

Actualmente (con Lighthouse v5.6 / PageSpeed ​​Insights)

PSI se ejecuta en un Moto G4 en "Fast 3G". Fuente

Ciertos sitios "marcados" creados con Gatsby no tienen un gran rendimiento en PageSpeed ​​Insights (que todavía usa Lighthouse v5.6, supongo, sujeto a la variabilidad estándar en cada ejecución, posiblemente ejecutando 3x o 5x y el promedio pesaría en métricas más confiables ) .

• gatsbyjs.org (Mobile 72/100, TTI 9s) Fuente
• reactjs.org (Mobile 62/100, TTI 9.5s) Fuente
• gatsbyjs.com (Mobile 77/100, TTI 6.6s) Fuente

Sin embargo, algunos otros sitios (y la mayoría de los principiantes) están funcionando muy bien en PageSpeed ​​Insights:

• store.gatsbyjs.org (Mobile 99/100, TTI 2.5s) Fuente
• thirdandgrove.com (Mobile 91/100, TTI 4.0s) Fuente

El TTI promedio es notable, y aunque v6 cambia el peso general de TTI del 33% al 15% y disminuyó la Primera CPU inactiva, agrega TBT con un peso del 25%, lo que posiblemente podría explicar una regresión de las puntuaciones en términos generales solo debido a análisis y ejecución generales de JS.

Lighthouse v6 (con WebPageTest.org )

• Esto ejecutó WPT en _Moto G (gen 4), Moto G4 - Chrome_ con una conexión de _3G Fast (1.6mbps / 768kbps 150ms RTT) _. Esto parece ser lo más parecido a una coincidencia de dispositivo / red que podemos obtener antes de que PSI actualice su versión de faro subyacente.
• Asegúrese de consultar _Capture Lighthouse Report_ en _Chromium_. He desactivado la vista repetida para mantener el alcance en un visitante por primera vez, la primera carga de la página.

Aquí están los resultados, puede ver el informe de Lighthouse haciendo clic en su número. Extraigo los valores de ese informe.

• gatsbyjs.org (72 -> 67/100, TTI 7.5s, TBT 2150ms) Fuente
• reactjs.org (62 -> 66/100, TTI 7.8s, TBT 3520ms) Fuente
• gatsbyjs.com (77 -> 66/100, TTI 8.4s, TBT 2440ms) Fuente

Sin embargo, observe la regresión en los dos sitios siguientes:

• store.gatsbyjs.org ( 99 -> 54/100 , TTI 6.8s, TBT 1300ms) Fuente
• thirdandgrove.com ( 91 -> 63/100 , TTI 14s !, TBT 1330ms) Fuente

Algunas de las preguntas abiertas que tengo.

1. ¿El TTI (y TBT) general se explica por el análisis sintáctico + la ejecución de JS, o hay otros factores que dañan la interactividad?
2. Si es así, ¿podríamos ser más agresivos (ya sea en Gatsby de forma predeterminada, como los cambios más recientes, como habilitar fragmentos granulares , o bajo alguna bandera experimental) al construir los fragmentos para _sólo_ enviar lo que necesita esa primera carga (es decir, evitar la aplicación- [hash] .js por tener exceso)? También podría ser simplemente documentar formas de jugar con la extensión de la configuración del paquete web con más orientación.
3. ¿Podrían los patrones como Module / nomodule ayudar a disminuir los fragmentos? ¿Recomendar / documentar el uso de @ loadable / components? ¿ Rehidratación parcial ?
4. Este puede ser un segundo paso para impulsar puntajes altos, pero dado que FMP ya no es un factor, ¿LQIP en gatsby-image ayuda o perjudica cuando se trata de LCP? ¡El LCP de store.gatsby.org en la ejecución anterior fue de 4.7 s!

(Estoy usando los enlaces anteriores solo como ejemplos; si alguien quisiera que se elimine un enlace determinado, con gusto puedo editar el mensaje)

Mi sitio (https://matthewmiller.dev/) parece haber mejorado (~ 92 a ~ 95), pero algunas de las nuevas pruebas revelan algunas cosas que probablemente podrían mejorarse.

La prueba de JavaScript innecesaria, por ejemplo,
(La primera columna es el tamaño, la segunda columna es la cantidad que no es necesaria)

Supongo que esto se debe a que aquí se incluyen elementos necesarios para otras páginas, por lo que el uso de componentes cargables podría ayudar un poco.

Para mí, estoy teniendo grandes dificultades para entender Largest Contentful Paint , en el sentido de que obtengo valores muy grandes sin saber por qué, y veo una discrepancia entre el valor en el informe (por ejemplo, 7,4 sy el LCP etiqueta que aparece en la pestaña Performance - ViewTrace (~ 800 ms)

Puedo ver que algo similar parece suceder en el motor de arranque https://parmsang.github.io/gatsby-starter-ecommerce/

Como actualización, parece que PageSpeed ​​Insights lanzó la actualización para ejecutar Lighthouse v6 (es posible que aún no esté en todas las regiones).

Enlace para probar https://gatsbyjs.org/ . Actualmente se obtienen resultados que varían desde bajos 60 hasta mediados de los 80, principalmente dependiendo de los valores de TBT y TTI.

@kuworking puede haber un problema con Lighthouse v6 reconociendo gatsby-image.

Según webdev

Para los elementos de imagen que han cambiado de tamaño de su tamaño intrínseco, el tamaño que se informa es el tamaño visible o el tamaño intrínseco, el que sea menor.

En mi caso, creo que Lighthouse no está respetando el tamaño de la vista.

Y aquí está la imagen en cuestión

Podría tener en cuenta el tamaño intrínseco que es de 3000 píxeles, por lo tanto, el LCP de 13 s para mí.

@ daydream05 También tenía teorías y hallazgos similares, así que probé mis páginas sin imágenes y todavía tenía un LCP largo y loco (10-12 segundos). Tengo muchas cosas en marcha en mi proyecto, por lo que también podrían ser otras variables, pero tengo curiosidad por saber si has probado una página con contenido de texto y sin imágenes todavía.

Bajó de 100 a 79 ~ https://dougsilkstone.com/ recientemente. Salta hasta 90 cuando se eliminan Google Tag Manager (y Google Analytics).

Informaré sobre más hallazgos mientras pruebo cosas.

Editar: Golpee 100 cuando elimine la fuente cargada typekit de gatsby-plugin-web-font-loader (también usando el caché de preload-fonts).

GTM en general está afectando un poco mi proyecto, pero no es un cambio tan drástico cuando lo elimino (5-10 puntos como máximo en las puntuaciones por debajo de los 50 después de LH6). Todavía necesito hacer más pruebas, pero solo quería tirar eso por ahí.

@Jimmydalecleveland ¡interesante! También tengo otro sitio en el que la pantalla es sólo un mensaje de texto y se culpa al texto del héroe como la causa principal de LCP. Y LCP solo tiene en cuenta lo que está a la vista, lo que no tiene sentido. ¿Cómo puede ser un texto un problema tan grande?

@dougwithseismic También uso typekit y definitivamente es uno de los principales culpables de las puntuaciones de faro más bajas. Desearía que hubiera una manera de arreglar typekit ya que no admiten la visualización de fuentes

Creo que Lighthouse v6 es realmente difícil con los frameworks JS porque cambiaron la ponderación de las puntuaciones. (Más enfoque en el tiempo de bloqueo) Y los sitios de Gatsby tienen puntajes históricamente bajos de evaluación de scripts / hilo principal debido a la rehidratación y otras cosas.

@dougwithseismic ¿cómo vinculó la fuente typekit sin usar la hoja de estilo?

Estoy teniendo una experiencia similar, con Lighthouse 5.7.1 mi puntaje de desempeño fue de 91, sin embargo, Lighthouse 6 ha reducido drásticamente mi puntaje de desempeño a aproximadamente 60.

Bajó de 100 a 79 ~ https://dougsilkstone.com/ recientemente. Salta hasta 90 cuando se eliminan Google Tag Manager (y Google Analytics).

Informaré sobre más hallazgos mientras pruebo cosas.

Editar: Golpee 100 cuando elimine la fuente cargada typekit de gatsby-plugin-web-font-loader (también usando el caché de preload-fonts).

Ni siquiera tengo estos complementos instalados, pero mi puntaje móvil bajó de 90+ a 60 ~ 70+

Igual que aquí. Descenso masivo de 90 a 60 en varios sitios.

+1 caída de aproximadamente 30+ puntos

¿Alguien está abordando esto? Parece que no tiene sentido usar Gatsby en lugar de Next si no ofrece mejores puntajes de inmediato.

¿Alguien está abordando esto? Parece que no tiene sentido usar Gatsby en lugar de Next si no ofrece mejores puntajes de inmediato.

¿Tiene números de Next?

Me pregunto si estos puntajes son la nueva normalidad para las web rápidas (que no son estáticas, sin JS y probablemente sin imágenes)

¿Tiene números de Next?

https://nextjs.org/ tiene un puntaje de 85, siendo los principales infractores tanto la pintura con contenido más grande (3.8) como la primera pintura con contenido (2.8). También tiene un montón de "JS sin usar". Eso es menos de ~ 95 en Lighthouse 5.7.1. Es "sólo" una caída de alrededor de 10 puntos, mientras que los sitios de gatsby parecen perder el doble de puntos.

Soy bastante nuevo en este mundo, pero sigo este problema después de que mi sitio de gatsby perdió alrededor de 25 puntos cuando se probó con lighthouse 6.0.0 de npm. Curiosamente, si estoy usando la información de la velocidad de la página en lugar de npm lighthouse, mi sitio vuelve a alrededor de ~ 99. Mientras que gatsbyjs.org obtiene ~ 70 en información sobre la velocidad de la página, pero ~ 84 con npm lighthouse. Probablemente se esté modificando algo en alguna parte, supongo. Todos ellos reciben advertencias de 'JS sin usar' aunque

¿Alguien está abordando esto? Parece que no tiene sentido usar Gatsby en lugar de Next si no ofrece mejores puntajes de inmediato.

¿Tiene números de Next?
Me pregunto si estos puntajes son la nueva normalidad para las web rápidas (que no son estáticas, sin JS y probablemente sin imágenes)

Un sitio web de Next.js -> https://masteringnextjs.com/ 77 puntaje móvil. Mucho "JS sin usar".

Veo mejores puntuaciones con lighthouse-metrics https://lighthouse-metrics.com/one-time-tests/5edfbbb1cf858500080125f7

Pero tampoco veo imágenes allí, y en mi experiencia, las imágenes parecen tener un impacto alto (y legítimo en mi opinión)

Sin embargo, gatsbyjs.org tampoco tiene imágenes y su puntuación es (relativamente) mala https://lighthouse-metrics.com/one-time-tests/5edfbc58cf858500080125ff (en comparación con el ejemplo de @cbdp )

Veamos qué piensan los desarrolladores de gatsby sobre esto

Con algunos ajustes, el sitio vuelve a las mejores puntuaciones.

Me parece un caso en el que Google mueve las publicaciones de los objetivos para que sean más
estricto en cuanto al rendimiento, en particular FCP.

Nuestros sitios no son lentos de ninguna manera, sino que simplemente son juzgados con diferentes
criterios. Ayudaré en este ✌️

El martes 9 de junio de 2020 a las 18:48 kuworking, [email protected] escribió:

¿Alguien está abordando esto? Parece que no tiene sentido usar a Gatsby
A continuación, si no ofrece mejores puntuaciones de forma inmediata.

¿Tiene números de Next?
Me pregunto si estas puntuaciones son la nueva normalidad para las web rápidas (que
no son estáticos, libres de JS y probablemente también libres de imágenes)

Un sitio web de Next.js -> https://masteringnextjs.com/ 77 puntaje móvil. Mucho
de "JS no utilizado".

Veo mejores puntuaciones con Lighthouse-Metrics
https://lighthouse-metrics.com/one-time-tests/5edfbbb1cf858500080125f7

Pero tampoco veo imágenes allí, y en mi experiencia, las imágenes parecen
tener un impacto alto (y legítimo en mi opinión)

Sin embargo, gatsbyjs.org tampoco tiene imágenes y su puntuación es (relativamente) mala
https://lighthouse-metrics.com/one-time-tests/5edfbc58cf858500080125ff
(en comparación con el ejemplo de @cbdp https://github.com/cbdp )

Veamos qué piensan los desarrolladores de gatsby sobre esto

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-641433463 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/ALSIKRH4G74CRN2FNCUO4NDRVZRVNANCNFSM4NHP7XCA
.

Solo quería dejar caer esta útil calculadora para comparar los resultados de v6 con v5: https://googlechrome.github.io/lighthouse/scorecalc/

Los puntajes Lighthouse generalmente varían mucho, incluso cuando se usa a través de PageSpeed ​​Insights. Por ejemplo, para https://www.gatsbyjs.org/ recibí todo, desde 64 a 88 rendimiento móvil después de 5 ejecuciones. Por lo tanto, para rastrear este problema, la calculadora puede ser útil para ver las consecuencias de diferentes pesos en la misma ejecución (nota: como las métricas son un poco diferentes, algunos valores como FMP deben asumirse usando mediciones anteriores).

PD: Aquí tengo una comparación de dos ejecuciones de PageSpeed ​​Insights para gatsbyjs.org:
Ejecutar 1 - v6: 67 - v5: 85
Ejecutar 2 - v6: 78 - v5: 87
El mayor impacto lo causa la nueva métrica "Tiempo total de bloqueo", que está por debajo de una puntuación de 70 en ambas ejecuciones y también tiene un peso del 25%.

Sí, para agregar a @Pyrax : LCP (pintura con contenido más grande) y TBT pesan un 25% cada uno en Lighthouse v6. Así que concentramos nuestros esfuerzos en abordarlos. Encontramos:

LCP

• Eliminando cualquier animación que pudiera activarse al cargar (por ejemplo, cookie 💩 banner).
• Cambiar a tracedSVG gatsby-img pareció ayudar un poco, ya que tenemos grandes imágenes de héroes en la mayoría de las páginas. (No estoy seguro de por qué, sin más investigación. La UX también mejora un poco).

TBT

• Por mucho, Unused JS del paquete de Gatsby parece ser el cuplrit más grande (con una copia de seguridad de los documentos de web.dev ), por mucho. ¿El temblor de árboles a nivel de página seguramente podría mejorarse aquí?

Esta reciente actualización de Lighthouse parece haber arruinado los puntajes de rendimiento de todos, incluido el suyo:

El único sitio de gatsby mío que realmente no ha sido borrado es un sitio que es básicamente una sola página y como 99% html. Pero incluso ese cayó entre 5 y 10 puntos.

Sin embargo, veo lo contrario de la mayoría de las personas, es decir, Lighthouse en el navegador Chrome todavía muestra buenos puntajes para mi sitio, pero cuando se ejecuta en PageSpeed ​​Insights, reduce el puntaje de rendimiento de 20 a 30 puntos ... tal vez mi versión de Chrome Lighthouse ¿está detrás? Chrome es el último, no estoy seguro de cómo verificar la versión integrada de Lighthouse ...

Esta reciente actualización de Lighthouse parece haber arruinado los puntajes de rendimiento de todos, incluido el suyo:

El único sitio de gatsby mío que realmente no ha sido borrado es un sitio que es básicamente una sola página y como 99% html. Pero incluso ese cayó entre 5 y 10 puntos.

Sin embargo, veo lo contrario de la mayoría de las personas, es decir, Lighthouse en el navegador Chrome todavía muestra buenos puntajes para mi sitio, pero cuando se ejecuta en PageSpeed ​​Insights, reduce el puntaje de rendimiento de 20 a 30 puntos ... tal vez mi versión de Chrome Lighthouse ¿está detrás? Chrome es el último, no estoy seguro de cómo verificar la versión integrada de Lighthouse ...

La versión Lighthouse se muestra en la parte inferior de la auditoría.

@dylanblokhuis ah, sí, ahí está. Estoy en 5.7.1, ¿la v6 aún no se envió en Chrome?

@dylanblokhuis ah, sí, ahí está. Estoy en 5.7.1, ¿la v6 aún no se envió en Chrome?

No lo es. No todavía, de todos modos. Si desea lo último, puede instalarlo desde npm y luego ejecutar lighthouse https://yoursite.com --view y obtendrá su puntaje en el mismo formato al que está acostumbrado con la auditoría de Chrome :)

Para cualquier otra persona que haya tenido un gran impacto en las puntuaciones, el # 24866 también podría ser relevante. Ha habido un cambio aparentemente bastante significativo en la forma en que Gatsby maneja los fragmentos. Si bien el cambio definitivamente parece tener mucho sentido, al menos para nosotros, este cambio ha dado como resultado que el código que se distribuyó en fragmentos se concentrara en fragmentos commons y app . Lo que significa una carga / análisis de js significativamente mayor.

Lo más preocupante aquí es que estas métricas comenzarán a afectar el Page Rank relativamente pronto.

He eliminado todas las solicitudes de terceros (Tag Manager / Typekit / Pixel / Analytics / ReCaptcha) y eso solo brinda un aumento de puntaje relativamente pequeño, por lo que hay algo más en juego.

Además, para cualquiera que busque ejecutar Lighthouse 6 localmente, ya está disponible en Chrome Canary y está programado para enviarse a Chrome en julio.

Primero: me puse en contacto con un ingeniero de Google que trabaja en web.dev y le pregunté sobre esto. No estoy seguro de si eso dará lugar a una explicación mayor, pero parecen estar decididos a ayudar. Haré un seguimiento cuando haya podido charlar con ellos.

Mis puntuaciones de rendimiento pasaron de 94-99 a 40-55. 😢

La pintura con contenido más grande para mi sitio web se aplica principalmente en páginas con imágenes grandes. Por alguna razón, dice que las imágenes están tardando como 14 segundos en cargarse.

Si abre cualquiera de los sitios de inicio mínimos de

Aquí están los dos primeros entrantes que vi con muchas imágenes:

ghost.gatsby.org :

gcn.netlify.app :

Sin embargo, el blog de inicio de Gatsby tiene un rendimiento de 98 (concedido, es una página súper mínima con solo algo de texto):

gatsbyjs.com :

Compara puntuaciones antiguas con puntuaciones nuevas en Chrome

Aún puede comparar las puntuaciones del método Lighthouse antiguo con el nuevo sin usar la CLI. Encuentro útil ver qué ha cambiado.

Ver pruebas antiguas de Lighthouse

Para ver las puntuaciones antiguas de Lighthouse, ejecute la extensión Lighthouse Chrome desde sus herramientas de desarrollo de Chrome, en lugar de la barra de herramientas del navegador.

Ver nuevas pruebas de Lighthouse

Haga clic en el icono de la barra de extensiones de Chrome.

Mi página cambia

Estas son las dos puntuaciones que tengo para exactamente la misma página:

Faro antiguo (a través de las herramientas de desarrollo de Chrome)

Nuevo faro (a través de la extensión de Chrome en la barra de direcciones)

🤷‍♂️

@nandorojo mi impresión con las imágenes es que la emulación se realiza con una conexión muy lenta y allí, las imágenes tardan mucho en renderizarse

Dado que la opción de eliminar imágenes no siempre es posible, quizás estas puntuaciones de los 70 sean las normales para este tipo de páginas

Y, la opción de retrasar su carga para que el usuario pueda iniciar su interacción antes, no parece funcionar (en mi caso)

Oye, perdón por la respuesta tardía. He trabajado en Lighthouse, intentaré explicarlo lo mejor que pueda.

Los desarrolladores de Chrome han publicado "Web Vitals", métricas esenciales para un sitio saludable. Contiene muchas métricas, pero las principales son la pintura con contenido más grande (LCP) , el retardo de primera entrada (FID) y el cambio de diseño acumulativo (CLS) . Para herramientas como Lighthouse, el FID se intercambia con el tiempo de bloqueo total (TBT) .

Lighthouse v6 también tiene en cuenta estas métricas y ha cambiado. Esto no significa que Gatsby sea lento. Puede ser que sean necesarias algunas optimizaciones diferentes.

Así es como cambiaron las cosas:

Si desea saber más sobre LCP, consulte https://www.youtube.com/watch?v=diAc65p15ag.

Así que hablemos de Gatsby. Gatsby en sí sigue siendo bastante rápido y lo estamos mejorando aún más. Estamos creando nuevas API para que los creadores de páginas como MDX, el texto enriquecido de Contentful, ... también puedan optimizar el paquete. Se puede hacer mucho optimizando su LCP. Asegúrese de que cuando utilice fuentes e imágenes, no se carguen de forma perezosa y se carguen lo antes posible. Estos activos deben cargarse desde el mismo origen que su sitio, no deben cargarse desde un CDN.

Lamentablemente, TBT es un problema difícil de resolver y es algo para lo que React no optimiza. Si desea eliminar TBT, debe pagar preact . Preact tiene la misma API que React pero tiene una huella de javascript más pequeña. Hacen las cosas de manera diferente, pero los componentes de React son compatibles. Lo instala ejecutando gatsby recipes preact .

Algo que noté al perfilar gatsbyjs.com y gatsbyjs.org es que deberíamos cargar Google Analytics, etc. un poco más tarde de lo que lo hacemos ahora para asegurarnos de que no se convierta en parte de TBT.

Si miramos .com posponiendo el análisis y GTM y asegurándonos de que las fuentes se carguen más rápido, ya podemos ver una mejora de +17. Si agregamos preact a la mezcla, vemos +6.

Podemos hacer lo mismo con .org, comenzamos con una puntuación de 63. Con alguna optimización de LCP y TBT podemos llegar a 75.

No estoy seguro de qué deberíamos hacer con este problema. Siento que podemos cerrarlo ya que no hay mucho más que podamos hacer aquí. ¿Qué piensan todos ustedes?

@wardpeet Ty para obtener información adicional.

Hemos estado investigando mucho este asunto en un gran proyecto de Gatsby que tenemos que usa Contentful y se usará en múltiples sitios para nosotros (los temas de Gatsby son increíbles). Compartiré algunos hallazgos en caso de que sean útiles para cualquier otra persona que esté mirando esto.

1. Tenemos una situación que puede no ser muy común, pero la he visto lo suficiente como para creer que tampoco es tan única, donde tuvimos que usar useStaticQuery para capturar imágenes provenientes de Contentful y .find uno por el identificador. Siempre supimos que esto estaba mal, pero no fuimos castigados notablemente por ello hasta que la escala del sitio creció hasta tener más de 300 imágenes y LH6 apareció y nos golpeó.

La razón de esto es porque las imágenes son parte de incrustaciones de texto enriquecido, y no podemos graficarlas para ellas en el nivel de consulta de la página (es esencialmente un campo json que Contentful tiene paquetes para analizar). Cuando usamos el analizador de paquetes Webpack, notamos un archivo JSON masivo (alrededor de 720 KB) y lo rastreamos para ser los datos de esa consulta, que se agruparon en una plantilla que usamos para la mayoría de las páginas por Webpack. Esto significaba que cada usuario que visitaba nuestro sitio lo descargaba como parte del fragmento de la plantilla de página completa, independientemente de que la página usara imágenes o no.

Gran sorpresa de nuestra parte, pero si alguien más está haciendo consultas estáticas grandes (a las que, por supuesto, no puede pasar parámetros para reducir el tamaño), asegúrese de estar atento a esas situaciones y vigilar los fragmentos de su paquete.

1. Tuvimos algo de éxito hoy mismo al usar el accesorio loading para la imagen de Gatsby en las imágenes que están en la parte superior del pliegue (imágenes Hero para nosotros). Hemos estado intentando trabajar en la pintura más grande con contenido y esto ha dado buenos resultados en algunas pruebas iniciales. Hay una parte importante que casi me pierdo de esto: si configura loading="eager" para su imagen superior, es posible que desee configurar fadeIn={false} también para esa imagen porque la transición entre base64 y completamente cargada la imagen toma tiempo, lo que retrasa el LCP.

Aquí está la documentación de accesorios a la que me refiero y la nota sobre fadeIn está en la parte inferior: https://www.gatsbyjs.org/packages/gatsby-image/#gatsby -image-props

Me gustaría compartir capturas de pantalla pero no sé si puedo hacerlo, lo siento. Si usa herramientas de desarrollo de Chrome y observa el panel de rendimiento, se le dan pequeñas etiquetas agradables debajo de la fila "tiempos" para FP, FCP, FMP y LCP. Cuando cambiamos a cargar críticamente la primera imagen, no solo vimos un aumento en el puntaje de rendimiento de ~ 8-10, sino que puede ver que la etiqueta LCP se carga inmediatamente después de FMP en lugar de un segundo más tarde en mi caso.

Espero que ayude a cualquiera a solucionar este problema y gracias a todos los que han respondido hasta ahora.

Algo que noté al perfilar gatsbyjs.com y gatsbyjs.org es que deberíamos cargar Google Analytics, etc. un poco más tarde de lo que sabemos para asegurarnos de que no se convierta en parte de TBT.

@wardpeet ¿cómo

@wardpeet gracias por tu respuesta. Es útil. Quizás el mejor resultado de este problema sería alguna documentación que describa cómo optimizar para cada una de las métricas en el nuevo Lighthouse. Estoy seguro de que nuestro sitio se siente rápido para los usuarios y que Gatsby mismo está haciendo un gran trabajo optimizando el sitio para usuarios reales. Sin embargo, si los elementos vitales de la web de Google van a comenzar a informar el rango de la página, obtener una buena puntuación de faro se convertirá en una misión crítica para la mayoría de los sitios.

@Jimmydalecleveland tuvimos un problema similar en el que teníamos que cargar todos los elementos de un recurso para que pudiéramos usar datos desde dentro de markdown para configurar un filtro (es decir, no pudimos filtrar usando GraphQL) y optimizarlo usando diferentes fragmentos (un subconjunto de campos mucho más pequeño) cuando se carga un recurso completo que cuando se cargan todos los recursos para el filtrado. Esto redujo en gran medida nuestro por JSON y, por lo tanto, nuestro tamaño de paquete.

@treyles , debe tener cuidado al retrasar la carga de Analytics, ya que puede significar que sus estadísticas están incompletas. Por ejemplo, puede significar que su tasa de rebote informado no es precisa. Hay algunos scripts que el marketing no nos permitiría retrasar (pixel, analytics, hotjar y por lo tanto tag manager), pero otros, por ejemplo, Intercom, están bien y son una optimización que vale la pena. En términos de cómo retrasar estos scripts, los scripts proporcionados por terceros generalmente se cargan de forma asincrónica, pero esto por sí solo no es suficiente. Lo que probablemente tendrá que hacer es reemplazar estos scripts por los suyos. Escuche window.load, luego active la descarga. Sin embargo, debe tener cuidado, ya que algunos scripts se basan en window.load para inicializarse, y si lo ha utilizado para cargar el script, no se activará nuevamente, por lo que debe inicializarlos manualmente. Por ejemplo, con Intercom nosotros:

• eliminado el degault <script>...</script> proporcionado por Intercom.
• agregó un oyente por window.load
• agregó un breve retraso dentro de este oyente
• activó una versión modificada del script predeterminado de Intercom que cargó su lib async.
• sondeo para ver cuándo se cargó el script (Intercom no proporciona un evento confiable)
• Inicializó manualmente su secuencia de comandos (que se hizo en page.load por su secuencia de comandos predeterminada).

@wardpeet ¡ gracias por la información tan útil!

Respecto a esta solución:

Asegúrese de que cuando utilice fuentes e imágenes, no se carguen de forma perezosa y se carguen lo antes posible. Estos activos deben cargarse desde el mismo origen que su sitio, no deben cargarse desde un CDN.

¿No iría esto en contra de cómo funciona la imagen de Gatsby? Además, la mayoría de los CMS manejan la transformación de imágenes en el servidor y se alojan en su propia CDN. (Lo cual es bueno, en mi opinión). Pero si lo alojamos en nuestro propio sitio, ¿no sería esto contraproducente también?

Agregando a lo que dijo @Undistraction , Gatsby es rápido, pero si no es rápido según los ojos de Google, se vuelve problemático. Especialmente porque incluirán esto en la actualización del ranking de la

@Jimmydalecleveland Encontré una manera de trabajar con la imagen de Gatsby dentro del texto enriquecido de Contentful sin ese truco de consulta Aquí está la esencia . El código fue copiado y pegado de gatsby-source-contentful . Básicamente, puede generar el contenido fluido o los accesorios fijos fuera de GQL. Lo cual es perfecto para el texto enriquecido de Contentful.

También creé una solicitud de extracción para que podamos acceder a las API directamente desde gatsby-source-contentful .

Algo simplemente no cuadra para mí. Construí un sitio web muy simplista con aproximadamente una imagen por página, estoy usando SVG para imágenes sin gatsby-image, también intenté eliminar Google Analytics y eso no hizo mucha diferencia, mi puntaje fue de 50 a 60 para el rendimiento.

Algo que me desconcierta es que solo la página de inicio (index.js) obtiene una puntuación muy baja, mientras que otras páginas como la página de servicios o la página de contacto obtienen una puntuación de ~ 80. Construí este sitio de manera bastante consistente, por lo que no hay una gran diferencia entre las páginas y, sin embargo, por alguna razón, la página de inicio tiene una puntuación de ~ 50, mientras que las páginas de servicios tienen una puntuación de ~ 80.

Como mencioné anteriormente, con Lighthouse v5, la puntuación fue ~ 90, simplemente no tiene ningún sentido que un sitio simple como este ahora tenga una puntuación baja de ~ 50.

Por cierto, ¿alguno de ustedes ha intentado configurar la imagen de la mitad superior de la página como eager ?
Esto deshabilita la carga diferida y puede aumentar la puntuación. El desenfoque o svg
Los efectos de carga pueden confundir a Lighthouse (que si ese es el caso es
un defecto en su algoritmo).

El sábado 13 de junio de 2020 a las 10:48 a.m., t2ca [email protected] escribió:

Algo simplemente no cuadra para mí. Creé un sitio web muy simplista
con aproximadamente una imagen por página, estoy usando SVG para imágenes sin gatsby-image,
También intenté eliminar Google Analytics y eso no hizo mucho
diferencia, mi puntuación fue de 50 a 60 para el rendimiento.

Algo que me desconcierta es que solo la página de inicio
(index.js) obtiene una puntuación muy baja, mientras que otras páginas como la
La página de servicios o la página de contacto obtienen una puntuación de ~ 80. Construi esto
sitio bastante consistente, por lo que no hay una gran diferencia entre
páginas y, sin embargo, por alguna razón, la página de inicio tiene una puntuación de ~ 50 mientras que
páginas de servicios tiene una puntuación de ~ 80.

Como mencioné anteriormente, con Lighthouse v5, el puntaje fue ~ 90, simplemente
no tiene ningún sentido que un sitio simple como este tenga ahora un bajo
puntuación de ~ 50.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-643648423 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAARLB2Q2IVSNVKGGBZ3ZPDRWOUU5ANCNFSM4NHP7XCA
.

@KyleAMathews Lo hemos hecho, y logró un aumento significativo en la puntuación de rendimiento y las primeras pinturas. Es lo que describí como punto 2 en mi extenso comentario anterior. Cancelar el fadeIn es lo que finalmente hizo feliz a LH.

Editar : Probablemente, por ignorancia, siento que el enfoque en LCP no es el enfoque correcto para tomar universalmente con preocupación por las imágenes. Obviamente es anecdótico, pero creo que un sitio web se siente mucho más rápido cuando todo el contenido está cargado y las imágenes se difuminan en las palabras posteriores, a menos que la imagen sea crucial para el contenido.

Un ejemplo común sería un artículo mediano. Claro, se podría decir que es un defecto de diseño, pero la mayoría de los artículos de Medium (y muchos otros blogs) comienzan con una gran imagen antigua en la parte superior que es solo para la creación del estado de ánimo o el escenario y no me importa si se carga en .

Por cierto, ¿alguno de ustedes ha intentado configurar la imagen de la mitad superior de la página como eager ? Esto deshabilita la carga diferida y puede aumentar la puntuación. Los efectos de desenfoque o de carga de svg pueden confundir a Lighthouse (que si ese es el caso es una falla en su algoritmo).
...

Intentaré esto ahora.

Creo que hice un buen progreso aquí. Subí mis puntuaciones de 57 a 84 con cambios muy básicos. Mi LCP pasó de 12 a 2 segundos .

Dicho esto, es inconsistente. Desde que hice los cambios que describiré a continuación, mi puntaje varía de 69 a 84. Es evidente que hay una variación aleatoria en los puntajes de desempeño.

TLDR

Primero, como sugirieron @KyleAMathews y @Jimmydalecleveland , intenté configurar loading="eager" y fadeIn={false} en los componentes de mi imagen de gatsby que estaban en la parte superior.

A continuación, eliminé base64 de mis consultas.

Estos marcaron una gran diferencia.

El bueno

• ¡Agregar _noBase64 a mis fragmentos de imagen hizo que mi puntaje aumentara 20 puntos!

  • Parece que las imágenes en base64 están agregando mucho peso en el móvil. Estoy consultando imágenes de contentful usando localFile -> childImageSharp -> fluid -> GatsbyImageSharpFluid_withWebp_noBase64 .

• loading="eager" y fadeIn={false} redujeron mi tiempo de pintura más contenido en aproximadamente un 50%.

  • Mi puntuación de rendimiento real solo subió 6-7 puntos por alguna razón, pero LCP definitivamente está progresando ...

Mi consulta se ve así:

localFile {
  childImageSharp {
      fluid(maxWidth: 800, quality: 100) {
        ...GatsbyImageSharpFluid_withWebp_noBase64
      }
   }
}

Y mi gatsby-image ve así:

<Image 
  fluid={localFile.childImageSharp.fluid}
  fadeIn={false} 
  loading="eager"
/>

El menos bueno

Mi UX en mi sitio web ahora se ve mucho peor. El fade in base64 + proporcionó una gran experiencia de usuario. Ahora está un poco entrecortado. Supongo que es una compensación que tenemos que considerar ahora.

Antes y después eager & fadeIn={false}

Aquí hay algunas comparaciones lado a lado de las mismas páginas exactas. La única diferencia es que a la derecha, las imágenes tienen loading="eager" y fadeIn={false} .

1. Página de inicio

LCP bajó un 49%. Puntuación de rendimiento hasta 6 puntos.

2. Página del producto

LCP bajó un 46%. Puntuación de rendimiento hasta 7 puntos.

Lo que es extraño sobre este ejemplo anterior: las capturas de pantalla de la izquierda tienen el comportamiento de imagen gatsby predeterminado (se desvanecen y no tienen eager en). Y, sin embargo, aunque la puntuación de rendimiento es menor , las pequeñas capturas de pantalla en la parte inferior hacen que parezca que se carga más rápido que la imagen de la derecha.

Tal vez esté dentro del margen de error sobre cómo juzgan el rendimiento, o tal vez sea un error en su extremo relacionado con el efecto de desvanecimiento, como mencionó @KyleAMathews .

Después de configurar _noBase64 en fragmentos de imagen

Estas son las mismas pantallas que en el ejemplo anterior. Todos tienen loading="eager" , fadeIn={false} props en Gatsby Image. Además, los fragmentos de imagen en graqhql son GatsbyImageSharpFluid_withWebp_noBase64

Es un poco inexplicable, pero estoy haciendo una prueba de faro en la misma página una y otra vez, y obtuve 84, 75 y 69.

Un poco extraño, pero en cualquier caso, hizo subir mi puntuación.

Creo que el algoritmo Lighthouse se sentía inusualmente generoso aquí lol ^

Después de una mayor investigación, descubrí que Lighthouse se quejaba de un elemento específico que estaba afectando la puntuación de LCP.

Todo lo que hice fue simplemente mover este elemento que es solo un párrafo y mi puntaje saltó por encima de 80. Imagínate. No estoy seguro de por qué mover un párrafo aumentó mi puntaje de ~ 50 a ~ 80.

@nandorojo Gracias por la

Después de una mayor investigación, descubrí que Lighthouse se quejaba de un elemento específico que estaba afectando la puntuación de LCP.

Todo lo que hice fue simplemente mover este elemento que es solo un párrafo y mi puntaje saltó por encima de 80. Imagínate. No estoy seguro de por qué mover un párrafo aumentó mi puntaje de ~ 50 a ~ 80.

@ t2ca Esto es lo que obtuve (aunque la mía era una etiqueta de encabezado). Pero, ¿a dónde lo moviste?

@ t2ca Esto es lo que obtuve (aunque la mía era una etiqueta de encabezado). Pero, ¿a dónde lo moviste?

@michaeljwright Lo primero que hice fue borrar el párrafo y comprobar la puntuación del faro. Después de eliminar el párrafo, mi puntuación aumentó unos 20 puntos. Repetí la prueba muchas veces solo para asegurarme. También volví a poner el párrafo e hice más pruebas y mi dolor estaba más bajo una vez más.

Finalmente, decidí mover el párrafo, estoy usando movimiento de marco dentro de un div y simplemente moví el párrafo fuera del div. Esto me da el mismo resultado que cuando eliminé el párrafo.

@ t2ca Creo que LCP penaliza cualquier animación en nuestras páginas de héroe, lo cual es un fastidio.

Aquí están mis puntajes LCP donde la etiqueta de párrafo es el LCP

Con animación:

Sin animación:

@ t2ca Creo que LCP penaliza cualquier animación en nuestras páginas de héroe, lo cual es un fastidio.

Aquí están mis puntajes LCP donde la etiqueta de párrafo es el LCP

Con animación:

Sin animación:

@ daydream05 ¡ Gracias por confirmar!

@ daydream05

¿No iría esto en contra de cómo funciona la imagen de Gatsby? Además, la mayoría de los CMS manejan la transformación de imágenes en el servidor y se alojan en su propia CDN. (Lo cual es bueno, en mi opinión). Pero si lo alojamos en nuestro propio sitio, ¿no sería esto contraproducente también?

No, debido a que gatsby-image también funciona con imágenes locales, no es necesario alojarlo en un CDN diferente. Todo se reduce a optimizar su primer renderizado (lo que está en la ventana gráfica). Alojarlo en un dominio / CDN diferente significa que debe abrir una nueva conexión (dns resolve, tls handshake, ...) esto puede demorar hasta 300ms en un dispositivo lento y luego aún debe descargar su imagen.

Agregando a lo que dijo @Undistraction , Gatsby es rápido, pero si no es rápido según los ojos de Google, se vuelve problemático. Especialmente porque incluirán esto en la actualización del ranking de la

Optimizaremos Gatsby aún más para asegurarnos de que nuestros usuarios puedan obtener 100 gratis.

@ t2ca Creo que LCP penaliza cualquier animación en nuestras páginas de héroe, lo cual es un fastidio.

Eso se espera porque su pantalla nunca deja de pintar. Normalmente, LCP debería ignorar las animaciones CSS, pero depende de cómo haga las animaciones.

@ t2ca

Si puede mostrarnos el sitio, podemos ayudarlo a descubrir cómo mejorarlo, pero probablemente esté configurando la imagen como impaciente.

@nandorojo

¡Escritura impresionante! ¿Alguna posibilidad de que nos pueda dar enlaces a esos informes de faro?

Eso es lo esperado porque tu pantalla nunca deja de pintar ...

@wardpeet, ¿te importaría ampliar esto, por favor?

@DannyHinshaw recibí esta explicación del faro
"Lo que creo que está sucediendo es que a LCP le importa que las imágenes se carguen por completo y el momento en que se informa es cuando la imagen está completamente cargada y no cuando es visible por primera vez. Esta vez puede ser diferente debido a las imágenes progresivas y las pinturas iterativas. "

Y luego este enlace, quizás de ayuda
https://web.dev/lcp/#when -is-es-el-mayor-contenido-con-pintura-informado

Mientras tanto, lo que también puede intentar es cambiar su pintura de contenido más grande (LCP) de una imagen a texto (si tiene el lujo), precargar / precargar fuentes y cargar las imágenes de forma diferida. En mi caso, eso significó reducir el tamaño de la imagen de héroe en el móvil, lo que aumentó nuestra puntuación a los 90 superiores mientras se discutía el problema.

import semiBoldFont from 'static/fonts/SemiBold-Web.woff2';
...
<Helmet>
   <link rel="prefetch" href={semiBoldFont} as="font"></link>
</Helmet>

https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fwhatsmypayment.com%2F
https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content

Eso es lo esperado porque tu pantalla nunca deja de pintar ...

@wardpeet, ¿te importaría ampliar esto, por favor?

Claro que no sé qué sitio era este, intenté encontrar URL en este hilo pero fue difícil. LCP no tiene en cuenta las animaciones CSS (transición, accesorios de animación en css). Sin embargo, si tiene contenido que usa setTimeout / setInterval que cambia el componente de reacción, lo tendrá en cuenta. El último enfoque le dará puntuaciones CLS realmente malas.

Entonces, si desea animar el texto / imagen de su héroe. Utilice animaciones CSS.

Hola,

Traté de averiguar por qué mi proyecto tiene una puntuación tan baja en Google Page Speed ​​Insights, auditoría de Google Lighthouse y más.

Aparte de empezar desde cero, no estoy seguro de cuál es el problema. Usé este tema de inicio / tema para comenzar: https://github.com/alexislepresle/gatsby-shopify-theme

Principalmente estoy en el proceso de cambiar cosas CSS como pasar de bulma a chakra-ui.

Este es mi repositorio: https://github.com/Chizzah/genesis-style
Intenté eliminar todas las cosas de la cuenta y las cosas de gatsby-plugin-appollo-shopify, pero eso no cambia las cosas.

Aquí está el enlace en vivo: https://genesis-style.netlify.app

Nada de lo que parezco hacer cambia las cosas. Preferiría no tener que empezar de cero. Si alguien puede darme una pista o algo, lo agradeceré.

Supongo que me acostumbré demasiado a que Gatsby diera 90-100 gratis

Gracias por este hilo, ya que se necesita una discusión sobre cómo lograr buenos puntajes de faro. Las puntuaciones excelentes se han vuelto más difíciles con la versión 6, principalmente debido a la nueva métrica LCP. Mi sitio (https://www.jamify.org) bajó de ~ 100 a ~ 70 con Lighthouse v6.

Para devolverlo a 100 en el escritorio, tuve que

• eliminar una imagen de fondo que no era necesaria (ya que se eligió incorrectamente como LCP)
• optimizar el tamaño de las imágenes
• establecer gatsby-image en loading="eager" y fadeIn=false
  (eso es realmente un fastidio porque me gusta el efecto de desenfoque)

En el móvil, todavía estoy atascado en 80, nuevamente debido a un LCP de 5 segundos. Esto podría mejorarse dimensionando correctamente las imágenes específicamente para dispositivos móviles:

En general, estas optimizaciones son bastante factibles, sin embargo, estoy bastante descontento de tener que elegir entre imágenes de carga diferida con desenfoque o una buena puntuación de Lighhouse: roll_eyes:

¿Alguien ha hecho alguna prueba en Lighthouse v6.1? He notado una mejora en mi puntaje de desempeño.

Preguntó a Addy de Google sobre el problema de LCP borroso y es algo que están trabajando para solucionar https://twitter.com/addyosmani/status/1277293541878673411

La lección aquí es que no trate las nuevas puntuaciones de rendimiento como absolutas todavía, todavía están refinando casos extremos.

Creo que el problema empeora con Lighthouse 6.1. Hay algunas buenas sugerencias en torno a LCP, pero no estamos mirando tanto a TBT, que creo que es la razón más importante de las malas puntuaciones en dispositivos móviles y la más difícil de resolver.

Puede probar Lighthouse 6.1 en Chrome Canary. He comparado mi sitio entre 6.0 y 6.1, así como varios otros mencionados aquí y el TBT ha aumentado drásticamente. Por ejemplo, en mis pruebas 6.1:

• gatsbyjs.org TBT: 2550ms
• mi sitio TBT: 2200ms
• @styxlab sitio TBT: 1250 ms

Cualquier valor superior a 600 para TBT es rojo y el peso según la calculadora es del 25%, por lo que es un factor importante. TBT es causado por funciones que tardan más de 50ms en ejecutarse entre FCP y Time to Interactive.

La captura de pantalla anterior es un perfil de mi sitio. Si usa Lighthouse en Chrome, puede hacer clic en el botón Ver seguimiento para cargar los resultados en la pestaña de perfil y ver lo mismo. Cualquier tarea después de FCP con una bandera roja en la esquina cuenta para TBT. Todavía tengo que profundizar en cuáles son las tareas, por lo que tal vez alguien con más conocimiento de Gatsby pueda ayudar en esta área y tal vez @wardpeet pueda dar su idea de TBT si es posible. Hay algunas tareas grandes que toman entre 500ms - 1s en mis pruebas, así que creo que deberían analizarse.

@IanLunn eso es un rastro interesante, ¿

Es probable que exista una correlación entre la cantidad de JS que tiene cada sitio de Gatsby y lo caro que se vuelve en el hilo principal del navegador. Sin embargo, creo que el espacio abierto para la discusión podría ser, ¿hay alguna forma en que Gatsby pueda ayudar a "mitigar" el impacto mediante la forma en que carga las consultas y los scripts en conjunto?

Hay tres áreas que estoy tratando de comprender mejor en este momento:

• Gatsby agrega de forma predeterminada <link rel=preload/> por cada script necesario (según el patrón PRPL ) independientemente de cuántos haya. He notado algunas diferencias en el FCP medido (lo que me sorprendió bastante), pero principalmente en la brecha entre FCP / LCP al eliminarlos (lo que probablemente no sea una idea brillante sin otros cambios). Este número sobre el faro analiza este último.
• Las consultas terminan creando JSON (page-data.json y los hash para consultas estáticas) que se evalúan en el hilo principal. Consulte https://github.com/gatsbyjs/gatsby/issues/18787 pero no parece que hayamos encontrado (o si existe) una alternativa que no bloquee el hilo principal. Cuanto más grandes sean los datos, mayor será el impacto en el rendimiento (por lo que los presupuestos de rendimiento para el tamaño de las consultas sin duda serían muy bienvenidos), pero los datos no son realmente necesarios hasta el proceso de rehidratación, ¿o no?
• Los fragmentos reales se agregan como <script src=foo.js async /> al final de </body> . Esto significa que tan pronto como el navegador termine de analizar el HTML (que debería estar muy pronto en el seguimiento), comenzará a analizar y ejecutar esos scripts (ya que ya estaban precargados). Las tareas largas surgirán inevitablemente ya que se solicita al hilo principal que analice y ejecute todo ese javascript. ¿Existe una mejor manera de manejar esto (al menos _cuando_ esos scripts comienzan a ser analizados) para evitar bloquear el hilo principal? ¿Hay alguna forma de hacer esto (ya sea el análisis o la ejecución) en pequeñas tareas incrementales que no retrasan la retroalimentación de entrada (y por lo tanto dañan TTI), ni bloquean el hilo principal en trozos de tiempo (y por lo tanto dañan TBT)?

Si bien en este momento es cierto que los sitios de Gatsby están siendo un poco penalizados debido a que LCP aún no reconoce el patrón LQIP de gatsby-image , cuando se trata de cualquier cosa relacionada con TBT / TTI (y posiblemente una penalización importante en el costo de Javascript en comparación con Lighthouse v5) No creo que haya nada en la hoja de ruta del equipo de Lighthouse donde las cosas mejoren con respecto a los puntajes actuales.

@juanferreras La tarea más grande parece ser domready / ready.js (de terceros). Tengo la sensación de que tu declaración sobre la penalización de JavaScript por Lighthouse es correcta y, aunque pueden ser posibles pequeñas optimizaciones en Gatsby, no es algo que se pueda resolver.

Si así es como va a ser en Lighthouse, me siento tentado de al menos pedirles que reduzcan el peso del TBT o que den la opción de establecer el entorno de prueba deseado. Proporcionar una puntuación basada en un teléfono económico no siempre es apropiado para el sitio que se está probando. Deberíamos poder mostrarles a los jefes / clientes que sí, un teléfono económico obtiene una puntuación de 75, pero un teléfono de gama alta que tiene el 95% de nuestros usuarios obtiene una puntuación de 90, por ejemplo.

• Las consultas terminan creando JSON (page-data.json y los hash para consultas estáticas) que se evalúan en el hilo principal. Vea # 18787 pero no parece que hayamos encontrado (o si existe) una alternativa que no bloquee el hilo principal. Cuanto más grandes sean los datos, mayor será el impacto en el rendimiento (por lo que los presupuestos de rendimiento para el tamaño de las consultas sin duda serían muy bienvenidos), pero los datos no son realmente necesarios hasta el proceso de rehidratación, ¿o no?

@juanferreras , con respecto a este tema de analizar datos json en el hilo principal, lo que me viene a la mente es el trabajador web. Gatsby puede registrar un trabajador web si está disponible en el cliente, y almacenar este tipo de cosas en él, el proceso de rehidratación no es realmente necesario de inmediato, por lo que creo que es factible

El trabajador web es compatible con los principales navegadores, incluido ie10.

… No nos fijamos tanto en los TBT, que creo que es la razón principal de las malas puntuaciones en dispositivos móviles y la más difícil de resolver.

Quiero agregar algo que creo que es relevante para el tiempo de bloqueo total. Después de revisar mis paquetes con el analizador de paquetes Webpack, noté que los datos de las consultas estáticas se incluyen en los paquetes de JavaScript. Estoy seguro de que hay una buena razón para ello, pero funciona contra un TBT bajo.

TBT es un problema difícil de resolver, especialmente porque React no está diseñado para ello. Pasar a preact es un buen primer paso. Mejoraremos TBT cada vez más en los próximos meses, queremos que Gatsby tenga una huella realmente pequeña.

En la versión de gatsby> 2.24.0, enviamos un soporte mejorado de polyfill, por lo que solo cargamos polyfills en navegadores heredados como IE11. También eliminamos las consultas estáticas del paquete web, hace unos días (@MarkosKon).

@Teclone, lamentablemente, los webworkers no son buenos para el análisis JSON. Aún paga el precio por serializarlo y deserializarlo entre subprocesos. Con ShardArrayBuffer sería una historia diferente, lamentablemente están deshabilitados de forma predeterminada debido a Meltdown / spectre

Estaba obteniendo muy bien 100/100 en todo el Lighthouse (6.0) integrado en Chrome y luego usé la versión web.dev (6.1) y regresó con rendimiento en los 70 debido a LCP (aproximadamente 5-6 segundos en 6.1, aproximadamente 0.5 segundos en 6.0). Es una imagen de encabezado decorativa (usando gatsby-background-image) de la que se está quejando.

En mi propio sitio web, el tiempo de ejecución de Webpack tiene la mayor cantidad de tiempo de ejecución de JavaScript. Algo que la página ni siquiera necesita hasta que el usuario comienza a interactuar con la página.

Gatsby parece simplemente cargar todos estos recursos (fragmentos) a la vez. El archivo js en sí es muy pequeño, es un cargador, puede ver que solo toma 2 ms pasar el archivo. Pero el archivo en sí mismo carga fragmentos y archivos de plantilla.

De hecho, cuando inspecciono los archivos de fragmentos, descubro que todos son importaciones dinámicas, que esperamos que se carguen solo cuando se necesiten, pero no, todos se cargan de forma predeterminada. Este comportamiento no es el que esperaba.

Hicimos un poco de optimización de nuestra imagen de encabezado, como usar una imagen directamente en lugar de Gatsby-Image y reducir la resolución y la compresión, y la nuestra es un poco mejor. Solo que acabo de descubrir por las malas que Safari no es compatible con WebP (grr). Y sigue siendo el caso de que la versión web de Lighthouse es mucho menos indulgente que la integrada en Chrome, al menos para nuestro sitio de desarrollo "oculto". El tiempo dirá si los datos agregados del usuario ayudan una vez que estén en vivo; ¡no estoy convencido de que haya tantos que usan Moto G5 en el mundo real!

@derykmarl Debería recibir soporte pronto: https://www.macrumors.com/2020/06/22/webp-safari-14/
No entiendo por qué Apple se tomó tanto tiempo para admitir un formato de imagen generalizado ...

Leí que pagespeedinsight emula cómo se calcula la puntuación. Parece que no aceleran la red para que pueda obtener su informe más rápido. Yo personalmente uso https://lighthouse-metrics.com/ pero todavía no son compatibles con 6.1.

El problema con Lighthouse 6.x es que se basa en el tiempo de percepción, puede ejecutar la misma prueba 10 veces y no obtendrá los mismos resultados según las condiciones de la red.

volvió con rendimiento en los 70 gracias a LCP

Tenía un LCP que era la imagen de fondo de mi sitio web, pude reducir drásticamente mi LCP al dividir la imagen en 6 subimágenes. Hice un script de Python para hacer esto fácilmente, siempre que sepas la altura que quieres que tenga cada uno de tus segmentos.

from PIL import Image
import os
import ntpath

def crop(pathToFile, height, width=False):
    im = Image.open(pathToFile)
    imgwidth, imgheight = im.size
    [name, ext] = ntpath.basename(pathToFile).split('.')

    if(not width):
        width = imgwidth

    k=1
    for i in range(0,imgheight,height):
        for j in range(0,imgwidth,width):
            box = (j, i, j+width, i+height)
            a = im.crop(box)
            a.save(os.path.join("./" + name + "-" + str(k) + "." + ext), compress_level=9, optimize=True)
            k +=1

pathToFile = '/path/to/your/img.jpg'
crop(pathToFile, 933)

También encontré que este sitio web de compresión de imágenes funciona muy bien para reducir el tamaño de su imagen sin perder demasiada calidad. Por lo general, podría bajar a la marca de calidad del 20% -30% y reducir drásticamente el tamaño de mi archivo.

Hice algunas preguntas sobre esto en línea y algunas personas recomiendan que solo divida mi imagen en 2, para arriba y abajo del pliegue, pero encontré que dividir en 6 funciona mucho mejor.

@wardpeet en la nota TBT / TTI, es posible que podamos ver cómo otros sitios basados ​​en reacciones ahora están mitigando el impacto general en el hilo principal del navegador.

El propio reactjs.org (que también está construido con Gatsby hasta donde yo sé) parece tener un TTI considerablemente más pequeño (7-8 ~ vs 12 ~) que el nuevo gatsbyjs.com (¡felicitaciones por el lanzamiento por cierto!). NextJS también ha mantenido muy buenos números en TTI / TBT a pesar de estar basados ​​en React (también puede deberse al tamaño relativo de los scripts, donde gatsby.com tiene aproximadamente 628,3kb de script según PSI, reatjs.org 466,1kb y nextjs.org solo 216,8 kb)

(Obviamente, esta es una sola ejecución y no debe usarse como una comparación real, pero la tendencia es bastante consistente en varias ejecuciones).

¿La mayor parte de la diferencia de puntuación se debe al costo general de Javascript ™? Si el equipo de Gatsby optimiza el nuevo sitio web en algún momento, podría ser una gran oportunidad para compartir algunas ideas sobre el proceso, siempre que no quede mucha magia para agregar a cómo el marco de trabajo de Gatsby ya maneja javascript internamente.

@juanferreras @wardpeet , También hay algo que descubrí en mi propio proyecto. Si está utilizando componentes con estilo, por alguna razón, los estilos se vuelven a calcular / regenerar durante la hidratación y se reinyectan en el navegador. Esto toma gran parte del hilo principal.

Esto se debe a problemas de hidratación en gatsby. https://github.com/styled-components/styled-components/issues/2171

Gatsby también está trabajando en ejecutar ssr durante el desarrollo, https://github.com/gatsbyjs/gatsby/issues/25729 , esto ayudará a solucionar este tipo de problemas de rendimiento. también.

@teclone

https://github.com/styled-components/styled-components/issues/2171 no parece ofrecer una solución. ¿Cómo lo arreglaste en tu proyecto?

@dfguo , por ahora, no hay solución para eso, porque nadie sabe exactamente por qué los estilos se regeneran durante la rehidratación porque gatsby en producción no ofrece ayuda para el desarrollo con errores de rehidratación.

Es decir, no hay un registro de consola de React que señale diferencias durante la rehidratación porque está deshabilitado en la compilación de producción de gatsby.

El propósito de este trabajo en progreso # 25729 es ejecutar un verdadero SSR en desarrollo, por lo que podremos ver por qué. incluido el equipo de gatsby.

Por cierto, puede crear un sitio de Gatsby con gatsby build --no-uglify para crear su sitio con la versión de desarrollo de React para ver los registros. https://www.gatsbyjs.com/docs/gatsby-cli/#build

Dev SSR será muy útil en el futuro para cosas como esta.

Entonces, decidí migrar mi sitio de @emotion y theme-ui a linaria mientras implementaba el modo dark-light con variables css personalizadas

El objetivo era reducir el tiempo de bloqueo / hilo principal / cualquier cosa relacionada con js, ya que ahora css ya no se evalúan en tiempo de ejecución sino que se compilan en tiempo de compilación (en realidad linaria parece mucho más alineado con gatsby declaraciones que @emotion en este sentido)

El proceso no es totalmente sencillo, la mayoría de las cosas que hice con @emotion solo funcionan con linaria , pero algunas otras no lo hacen y tienes que reescribirlas y / o volver a implementarlas a través de CSS personalizado variables

La experiencia de DX con gatsby es __bad__, la recarga en caliente no funciona (debe detenerse y comenzar de nuevo en cualquier cambio ya que el navegador parece perder la conexión), pero en general el proceso ha sido bueno ya que lo obliga a ser más consciente de lo que ¿Realmente necesitas de las capacidades de ejecución de @emotion?

__ Dicho esto, las métricas del faro son muy similares__

Puedo comparar las dos implementaciones de netlify y, en realidad, el sitio @emotion tiene 70 altos y el sitio linaria tiene 70 bajos-medios

No hace falta decir que no estoy muy emocionado

Analizando el paquete:

• el documento del sitio ha aumentado de 14 Kb a 28 kb
• el script de marco se ha mantenido idéntico a 38,7 kb
• El script de la aplicación ha disminuido de 58,2 kb a 46,1 kb
• Y un cuarto script ( component--content.. . Entonces, 20bae078.. ahora) ha pasado de 44,2 kb a 46,8 kb

Entonces supongo que los estilos en js se han movido a estilos en css (y ~ 12 kb son IMO importantes), pero esto no ha tenido ningún impacto real en las métricas de Lighthouse (y esto es lo que importa, ¿no?)

Entonces, no estoy diciendo en absoluto que pasar a linaria no tenga sentido, no me sorprendería si alguien hace lo mismo y tiene mejores resultados (en teoría, este debería ser el caso (?)), pero en mis manos el proceso no ha valido la pena

Aún así, al explorar el script de la aplicación, abrí un nuevo problema tratando de averiguar cómo reducir el paquete js https://github.com/gatsbyjs/gatsby/issues/26655

La experiencia de DX con gatsby es mala , la recarga en caliente no funciona (debe detenerse y comenzar de nuevo en cualquier cambio ya que el navegador parece perder la conexión), pero en general el proceso ha sido bueno ya que lo obliga a ser más consciente de lo que ¿Realmente necesitas de las capacidades de ejecución de @emotion?

@kuworking Encontré un problema similar, pero noté que solo sucedía en las versiones gatsby más nuevas que 2.24.9 ; No estoy seguro de si la causa es la misma, pero pensé que podría ayudar a alguien saber que la gente está hablando de eso en el número 26192 .

@kuworking Encontré un problema similar, pero noté que solo sucedía en las versiones gatsby más nuevas que 2.24.9 ; No estoy seguro de si la causa es la misma, pero pensé que podría ayudar a alguien saber que la gente está hablando de eso en el número 26192 .

He estado con "gatsby": "2.24.14" durante varias semanas, diría, y hasta ahora solo he experimentado esto con linaria
Pero sabiendo esto, no actualizaré a Gatsby hasta que esto se resuelva, gracias 👍

@kuworking Lo que quise sugerir es que tal vez si bajara a 2.24.9 entonces el problema de detener el servidor de desarrollo no ocurriría incluso con linaria ; pero eso es solo una idea. Tendría curiosidad por saber si ese es el caso.

La experiencia de DX con gatsby es mala , la recarga en caliente no funciona (debe detenerse y comenzar de nuevo en cualquier cambio ya que el navegador parece perder la conexión), pero en general el proceso ha sido bueno ya que lo obliga a ser más consciente de lo que ¿Realmente necesitas de las capacidades de ejecución de @emotion?

¿Has probado la actualización rápida ?

Recientemente, migré un sitio de producción de Gatsby (~ 120 páginas) a preact con la esperanza de mejorar TBT & LCP. Nuestro sitio tiene mucho uso de svg utilizando componentes react svg generados con svgr y diseñados con estilos material-ui. Los resultados de rendimiento promedio estuvieron en el rango + -5 de la puntuación inicial (~ 45 rendimiento móvil por debajo de ~ 85 antes de la v6) y aunque la migración fue relativamente sencilla con el tema, requirió una migración a la actualización rápida que fue no.

Honestamente, un poco decepcionado de que no haya otras optimizaciones que pueda encontrar para probar o métricas más detalladas para disparar además de la advertencia genérica "Eliminar javascript no utilizado".

La velocidad es una de las principales razones por las que elegimos a gatsby y, aunque las páginas aún se cargan rápido, es difícil de justificar desde el punto de vista de SEO cuando sus puntajes de conocimiento tienen un impacto tan grande ...

susurra: Cambié a NextJS y estoy obteniendo mejores puntajes 🤭

susurra: Cambié a NextJS y estoy obteniendo mejores puntajes 🤭

¿Y Svelte?

Sería bueno saber si los desarrolladores de Gatsby le están dando a esto un sentido específico de importancia / prioridad en la hoja de ruta (que no sea la esperada), ya que asumo que no hay soluciones inmediatas, pero quizás algún tipo de direcciones e implementaciones futuras enfocadas esta o aquella

Dado que gatsby hace una compilación con gatsby-node *, me pregunto si están explorando formas de aumentar esa parte y desapalancar la parte del cliente.

* Para disminuir el pageContext que estaba usando (datos sobre todas las publicaciones publicadas), actualmente estoy almacenando (a través de gatsby-node ) la mayoría de esos datos en json archivos y buscarlos en el sitio si es necesario, lo que reduce el tamaño del paquete, pero también se siente más lógico

No se obsesione demasiado con las puntuaciones de los faros, especialmente cuando
como un punto de referencia frente a otros sitios, y no como un objetivo en el que deberíamos
esforzarse por lograr una puntuación perfecta.

No fue hasta hace poco que Gatsby estaba clavando 100 puros, seguro, hay
Hay algunos problemas que abordar, pero el juego de SEO en este momento es velocidad más contenido
más enlaces, y lo tenemos cubierto.

Mis dos centavos.

El viernes 28 de agosto de 2020 a las 16:57 kuworking, [email protected] escribió:

susurra: Cambié a NextJS y estoy obteniendo mejores puntajes 🤭

¿Y Svelte?

Sería bueno saber si los desarrolladores de Gatsby le están dando a esto algunos
sentido de importancia / prioridad en la hoja de ruta (que no sea el esperado
uno), ya que asumo que no hay soluciones inmediatas pero tal vez algunas
tipo de futuras direcciones e implementaciones centradas en esto o aquello

Como gatsby hace alguna compilación con gatsby-node *, me pregunto si
están explorando formas de aumentar esa parte y desapalancar la parte del cliente

* Para disminuir el pageContext que estaba usando (datos sobre todos
las publicaciones publicadas), actualmente estoy almacenando (a través de gatsby-node) la mayoría
de esos datos en archivos json y obtenerlos del sitio si es necesario,
que reduce el tamaño del paquete pero también se siente más lógico

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-682664232 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/ALSIKRHQUIKR5YO6OGA3DC3SC7AWPANCNFSM4NHP7XCA
.

Perdón por la respuesta tardía, hay muchas cosas relacionadas con el rendimiento y las métricas de carga son solo una pequeña pieza del rompecabezas. Estamos motivados en este trimestre y en el siguiente para hacer que Gatsby sea más pequeño y reducir el TBT. Los mayores problemas en este momento son el tamaño del paquete React, MDX, páginas grandes (contenido / estilo), seguimiento de scripts y fuentes / imágenes como contenido principal en la primera carga.

Actualmente estoy investigando scripts de gatsby-image & analytics para ver cómo podemos mejorar el tiempo de carga y posponer los análisis.

Lamentablemente, no puedo dar ninguna estimación. También estamos buscando en nuestro sitio .com y en nuestros clientes para ver cuáles son los problemas comunes para poder integrar estas optimizaciones en gatsby o en nuestros complementos.

Editar:

Me complace ver cualquiera de sus códigos fuente para obtener más información sobre lo que están haciendo y ver cómo podemos mejorar.

Hice una publicación en reddit donde traté de agregar todos los consejos de mejora que pude encontrar. Si se le ocurren más consejos, indíquelos

Eliminar solo la imagen de gatsby (

En algunas pruebas recientes que estaba haciendo, descubrí que el uso de tracedSVG realidad mejoró drásticamente la puntuación de rendimiento de Largest Contentful Paint. Imagino que esto se solucionará en Lighthouse, pero a partir de ahora esto sucede porque el SVG se considera que tiene las mismas dimensiones que la imagen de resolución completa, por lo que nunca cambia del SVG como el objetivo LCP a la imagen completa.

Cuando se usa base64, la pequeña resolución no lo convierte en un candidato para LCP, por lo que Lighthouse usa la imagen de resolución completa cada vez que se carga.

Entonces, si no le importa el aspecto de los SVG trazados (los prefiero personalmente), es posible que desee intentarlo.

¿Por qué v5 mejor resultado que v6? Estoy usando NextJS, el resultado siempre cambia de 60 a 85.

+1

He estado trabajando en un sucesor de imágenes de Gatsby. Todavía no está al 100%, todavía es necesario escribir una versión componible para que pueda crear su propio sabor de imagen gatsby, pero solucionará la mayoría de las malas puntuaciones de Lighthouse.

Ya puede usarlo, pero aún no ha sido probado en batalla.
https://github.com/wardpeet/gatsby-image-nextgen/tree/main/gatsby-image

Puede instalarlo por npm install --save @wardpeet/gatsby-image-nextgen . Hay una capa de compatibilidad para los usuarios actuales de gatsby-image .

Cosas que aún no son compatibles:

• El ajuste de objeto debe realizarse mediante CSS fuera del componente.
• dirección artística

Demostración actual de gatsby-image:
sitio: https://wardpeet-using-gatsby-image.netlify.app/
pagespeed-insights: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwardpeet-using-gatsby-image.netlify.app%2F
prueba de página web: https://webpagetest.org/result/200928_4M_0879160e38bb6c5489f85534de2dd197/

Nueva demostración de gatsby-image-nextgen:
sitio: https://gatsby-image-nextgen.netlify.app/
pagespeed-insights: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fgatsby-image-nextgen.netlify.app%2F
prueba de página web: https://webpagetest.org/result/200928_C0_63317160bdfc71ece1a2057df8b08133/

@wardpeet Su enlace de pagespeed-insights para la demostración actual va a nextgen para que muestren las mismas puntuaciones.
Impresionante trabajo, por cierto. Realmente emocionante ver el progreso.

¡Gracias arreglado!

Esta actualización me ha señalado algo que no me conecté antes, no estoy usando gatsby-image pero en realidad gatsby-background-image que aparentemente no usa gatsby-image debajo del capó ... Es posible que tenga que reescribir ese componente con este nuevo @wardpeet/gatsby-image-nextgen si eso es posible ...

Este artículo enumera algunos consejos adicionales https://www.freecodecamp.org/news/gatsby-perfect-lighthouse-score/ aunque creo que muchos de ellos ya se han mencionado en este hilo ...

@DannyHinshaw cuando el complemento esté completo. También echaré un vistazo a ese complemento. También tengo que mirar imágenes de comentarios

He publicado una nueva versión de @wardpeet/gatsby-image-nextgen - 0.0.2.

1. minimiza css y js en el html
2. solo cargamos los bits necesarios, cuando la carga de imágenes nativas está habilitada, solo cargamos alrededor de 2kb (sin gzip).
3. asegúrese de que el marcador de posición solo se llame en la primera carga, las imágenes en caché se cargan inmediatamente
4. Corregir la animación borrosa decodificando async

Me pregunto cuántos de ustedes necesitan un componente de imagen componible en el que puedan construir su propio contenedor y cuántos de ustedes están usando la dirección de arte y quieren eso dentro de la imagen de gatsby por defecto. Mi primera idea fue deshabilitar la funcionalidad pero habilitarla con la imagen componible de gatsby, por lo que tendrá que crear su propio componente de imagen para admitirla.

Última demostración: https://gatsby-image-nextgen.netlify.app/

@wardpeet ¡ Esto es genial! Confío mucho en la dirección de arte incorporada de gatsby-image. ¡Pero supongo que un ejemplo / ruta de actualización sin problemas también estaría bien!

Siempre recibí 99 en el móvil y ahora 76. Todo es genial, excepto mi LCP es 7.0s y dice que es mi imagen de héroe. No tiene sentido. Cuando abro mi sitio en cualquier teléfono móvil, es increíblemente rápido. La gente se maravilla, ¿sabes? También me dice que ponga mis imágenes en webp u otros, pero ya usé childImageSharp_withWebp, así que no lo entiendo. Estoy empezando a pensar que Gastby Image y background-image no funcionan con esta nueva versión en Lighthouse y Pagespeedinsight. Mi mente está aturdida. Fui y maté animaciones, cambié el tamaño de todas mis imágenes a la mitad y no se movió un solo punto. Estoy leyendo esto y no veo nada que me ayude ... Oh, acabo de mirar hacia arriba ... Yo creo que

@davidpaulsson ¿te importaría compartir un ejemplo sobre cómo haces esto? Debido a que la dirección de arte todavía es posible con la nueva imagen de gatsby, debes seguir algunos pasos manuales.

@davidpaulsson ¿te importaría compartir un ejemplo sobre cómo haces esto? Debido a que la dirección de arte todavía es posible con la nueva imagen de gatsby, debes seguir algunos pasos manuales.

¡Por supuesto! Lo uso así actualmente

const artDirection = [
  medium.childImageSharp.fluid,
  {
    ...large.childImageSharp.fluid,
    media: `(min-width: 1390px)`,
  },
];

return <Img fluid={artDirection} />

@wardpeet Hola Ward. ¿Podría blurha.sh ser útil para la imagen de gatsby nextgen?

@wardpeet Usé su complemento gatsby-image-nextgen y, de hecho, mejoró mi tiempo de LCP (lo redujo de ~ 5s a ~ 1.5s). ¡Gracias por esto!

Sin embargo, también estamos usando la dirección de arte, similar a cómo lo usa @davidpaulsson , y parece que no puedo hacer que funcione como lo hace con gatsby-image.

¿Podría detallar los pasos manuales necesarios para hacer esto posible con el complemento nextgen? ¡Gracias de nuevo!

@Jimmydalecleveland ¡ Gracias Jimmy! Reemplazar GatsbyImageSharpFluid_withWebp con GatsbyImageSharpFluid_withWebp_tracedSVG mejoró drásticamente la puntuación de rendimiento de mi nuevo Gatsby Webiste. No obtenía más del 54% y ahora con tracedSVG obtengo más del 80%. Esa es una gran mejora 💯

En algunas pruebas recientes que estaba haciendo, descubrí que el uso de tracedSVG realidad mejoró drásticamente la puntuación de rendimiento de Largest Contentful Paint. Imagino que esto se solucionará en Lighthouse, pero a partir de ahora esto sucede porque el SVG se considera que tiene las mismas dimensiones que la imagen de resolución completa, por lo que nunca cambia del SVG como el objetivo LCP a la imagen completa.

Cuando se usa base64, la pequeña resolución no lo convierte en un candidato para LCP, por lo que Lighthouse usa la imagen de resolución completa cada vez que se carga.

Entonces, si no le importa el aspecto de los SVG trazados (los prefiero personalmente), es posible que desee intentarlo.

@abdullahe Lo hemos comprobado antes y depende del lienzo y el lienzo del nodo no es muy confiable. O al menos no fue en el pasado. Te avisaré si lo volvemos a considerar :)

@guydumais asegúrese de poner loading="eager" también debería cambiar su puntaje.

@BenjaminSnoha & @davidpaulsson Compartiré un ejemplo en un momento. El mayor problema con la dirección de arte si cambia la relación de aspecto entre las imágenes, como de horizontal a vertical.

@wardpeet ¿cómo se usaría @wardpeet/gatsby-image-nextgen con gatsby-remark-images ? ¿Se trata simplemente de señalarlo como un complemento en gatsby-config.js , o no es posible hasta que se fusiona con el gatsby monorepo?

Si bien esto puede no tener nada que ver con Lighthouse, me pregunto por qué los archivos JSON de datos de página de gatsby no admiten el hash de contenido, al igual que los archivos js.

Sé que Webpack realiza el hash de contenido para los archivos js, pero gatsby también puede hacer lo mismo con los archivos JSON de datos de página. esto puede ahorrar muchas solicitudes de red cdn

Los archivos x a x.LONG_HASH ya que el hash no es predecible. Con JS / CSS, cargar un manifiesto es razonable ya que solo hay tantos archivos JS incluso en sitios muy grandes. Pero con los datos de la página, hay uno por página, por lo que el manifiesto puede crecer bastante. Solíamos hacer esto y encontramos en un sitio de 10k páginas, el manifiesto ya estaba comprimido en ~ 500k. https://github.com/gatsbyjs/gatsby/pull/13004

Si ve archivos page-data.json descargados una y otra vez, verifique que no haya deshabilitado el almacenamiento en caché en sus herramientas de desarrollo y verifique los encabezados de almacenamiento en caché con https://www.npmjs.com/package/check-gatsby-caching

@KyleAMathews , gracias por aclarar eso. Ese es un enfoque muy sensato

@wardpeet ¿ es cierto que image-nextgen no admite fadeIn="false" o fadeIn="{false}"

Sin embargo, funciona mucho mejor, pasó de ~ 80 a ~ 95

@MelleNi no, no creo que sea necesario, pero estamos felices de considerarlo.

puede echar un vistazo a https://github.com/gatsbyjs/gatsby/discussions/27950 para ver lo que estamos enviando.

@wardpeet ¿cómo se usaría @wardpeet/gatsby-image-nextgen con gatsby-remark-images ? ¿Se trata simplemente de señalarlo como un complemento en gatsby-config.js , o no es posible hasta que se fusiona con el gatsby monorepo?

Vamos a mover el comentario a este complemento también :)

@MelleNi no, no creo que sea necesario, pero estamos felices de considerarlo.

puede echar un vistazo a # 27950 para ver lo que estamos enviando.

@wardpeet ¿cómo se usaría @wardpeet/gatsby-image-nextgen con gatsby-remark-images ? ¿Se trata simplemente de señalarlo como un complemento en gatsby-config.js , o no es posible hasta que se fusiona con el gatsby monorepo?

Vamos a mover el comentario a este complemento también :)

Es genial escuchar el comentario, ya que vi una gran mejora en la velocidad.

Sin embargo, noté que no podía obtener 99-100 sin deshabilitar el javascript de Gatsby (y reintegrar una funcionalidad particular manualmente). Puedo hacer que la vieja imagen de Gatsby funcione sin javascript, usando fadeIn={false} , pero no image-nextgen. (¿Quizás me estoy perdiendo algo, y es absolutamente posible?) Ahora, sin javascript, nunca caigo por debajo de 99 sin nextgen.

Entiendo que deshabilitar javascript frustra la idea de Gatsby, pero bueno.

Curiosamente, vi una mejora en la puntuación de rendimiento móvil (~ 70 a ~ 90) cuando dejé de usar fuentes autohospedadas (fuente de fuentes) y cambié a fuentes de "sistema".

@wardpeet ¿ Alguna posibilidad de que pueda compartir un ejemplo de cómo construir un componente de imagen componible con dirección de arte? Estoy en el mismo barco que @BenjaminSnoha y @davidpaulsson , y no me importa crear el componente componible en mi propio proyecto.

El mayor problema que veo es lidiar con las consultas de medios y SSR. Las bibliotecas como Fresnel funcionan, pero sufren de rendimiento porque cargan todos los componentes y luego limpian el DOM después de que el componente window esté disponible.

En mi sitio web, parece que todas las páginas creadas con createPage tienen el código fuente (componentes de markdown y markdown react dentro de markdown) en el javascript pesado de velocidad de página (eliminar JavaScript no utilizado)

Acabo de lanzar Plaiceholder, que se puede usar para crear marcadores de posición borrosos CSS puros . ¿Quizás esto sea de interés? Más que feliz de charlar con cualquiera del equipo central sobre opciones de reenvío

Hice una versión Next.js de Jamify Blog Starter que puntúa muy bien con la última versión de Lighthouse 6.4.0:

Puede inspeccionar el sitio de demostración en next.jamify.org .

Estoy publicando esto aquí, NO para sugerirle que cambie a Next.js. Más bien, para aprender cómo se puede lograr lo mismo con Gatsby. Creo que los factores clave del éxito son:

• imágenes altamente optimizadas (Next logra esto con un optimizador lambda, pero esto también se puede hacer con gatsby-plugin-sharp).
• un simple svg de marcador de posición (efectos agradables como el desenfoque ralentizarán la página).
• uso del observador de intersección para mostrar solo imágenes cuando están a la vista (ver siguiente / imágenes).
• asegurar la carga diferida de imágenes.
• tamaño de paquete pequeño.

Si desea hablar más sobre esto, puede comunicarse conmigo en Twitter .

@styxlab Obtengo resultados ligeramente más bajos en web.dev/measure

pero mejor en los resultados de la publicación, definitivamente muy buenos valores en cualquier caso y marcadamente diferente de la versión de gatsby https://demo.jamify.org/

También publicaré que en un sitio cambié gatsby por 11ty , y el rendimiento ha mejorado pero no drásticamente

(gatsby)

(diseño diferente, esencialmente el mismo contenido, 11ty)

O en una página similar, esta vez con una imagen

(gatsby)

(diseño diferente, esencialmente el mismo contenido, 11ty)

Diré que la experiencia del desarrollador 11ty es muy agradable (también puede usar experimentalmente jsx y styled-components ), pero cualquier js en el lado del cliente se pierde (usted puedes insertarlo y luchar con webpack, ese momento es donde extrañas a gatsby)

Mientras usaba 11ty, también estaba pensando en lo bueno que sería que gatsby habilitara algún tipo de estrategia de renderizado 11ty para que uno pudiera implementar páginas estáticas mixtas de reacción y sin reacción en un marco ...

alguna actualización sobre esto? No tengo ninguna imagen y obtengo 76 de rendimiento debido al tiempo de bloqueo total