Il semble que Lighthouse 6 introduit de nouvelles métriques et en supprime d'autres de la v5, donc un changement de score est certainement probable. Cet article explique ce qui a changé:

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

Il y a aussi un lien à la fin vers un calculateur de score qui est vraiment utile pour décomposer le score et comprendre quels facteurs contribuent le plus.

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

J'ai l'impression que l'on se concentre davantage sur l'interactivité des threads principaux dans la v6, donc si votre site comprend de gros bundles JS, c'est probablement un facteur important.

Oui @shanekenney , j'en suis conscient, mais je ne sais pas vraiment comment le réduire en dehors de la suppression de parties du site pour voir quelles parties provoquent cela

Voyez-vous également l'impact sur les gaysbyjs et les sites à thème-ui? Je suis curieux / aimerais savoir à quelles optimisations sur leur site ils peuvent penser, ou s'ils ont repéré une cause spécifique

Ce problème est génial pour que nous puissions discuter des scores globaux des insights Lighthouse / PageSpeed ​​et des régressions possibles que nous voyons avec la v6.

@kuworking une chose à noter est que lighthouse-metrics.com semble utiliser _ "Emulated Nexus 5X" _ pour 5.6 et _ "Emulated Moto G4" _ pour 6.0, ce qui pourrait également ajouter du bruit à la comparaison.

Ce benchmark sur 922 sites revendique en v5 le score de performance médian pour un site Gatsby est de 75 . Je vais essayer de faire une vue rapide en utilisant des solutions hébergées pour éviter que mon réseau local ne soit encore un autre facteur de variabilité.

Actuellement (avec Lighthouse v5.6 / PageSpeed ​​Insights)

PSI fonctionne sur un Moto G4 sur "Fast 3G". La source

Certains sites «drapeau» créés à l'aide de Gatsby ne fonctionnent pas vraiment très bien sur PageSpeed ​​Insights (qui utilise toujours Lighthouse v5.6 je suppose - soumis à une variabilité standard à chaque exécution, pouvant fonctionner 3x ou 5x et la moyenne serait pondérée dans des métriques plus fiables ) .

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

Cependant, certains autres sites (et la plupart des démarreurs) fonctionnent très bien sur PageSpeed ​​Insights:

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

Le TTI moyen est perceptible - et bien que la v6 modifie le poids global du TTI de 33% à 15% et abandonne First CPU Idle, il ajoute du TBT avec un poids de 25%, ce qui pourrait éventuellement expliquer une régression des scores en général simplement due à analyse et exécution globales de JS.

Lighthouse v6 (avec WebPageTest.org )

• Cela a fonctionné WPT sur _Moto G (gen 4), Moto G4 - Chrome_ avec une connexion de _3G Fast (1.6mbps / 768kbps 150ms RTT) _. Cela semble être aussi proche qu'une correspondance périphérique / réseau que nous pouvons obtenir avant que PSI ne mette à jour sa version de phare sous-jacente.
• Assurez-vous de vérifier _Capture Lighthouse Report_ sous _Chromium_. J'ai désactivé la vue répétée pour conserver la portée lors d'un premier visiteur, premier chargement de la page.

Voici les résultats, vous pouvez voir le rapport Lighthouse en cliquant sur son numéro. J'extrais les valeurs de ce rapport.

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

Cependant, notez la régression sur les deux sites suivants:

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

Certaines des questions ouvertes que j'ai.

1. Le TTI global (et le TBT) s'explique-t-il par l'analyse JS + l'exécution, ou y a-t-il d'autres facteurs nuisant à l'interactivité?
2. Si tel est le cas, pourrions-nous être plus agressifs (soit sur Gatsby par défaut, comme les derniers changements tels que l' activation des blocs granulaires , soit sous un drapeau expérimental) lors de la construction des blocs pour _seulement_ envoyer ce dont la première charge a besoin (c'est-à-dire empêcher l'application- [hachage]) .js d'avoir un excès)? Il peut également s'agir simplement de documenter des façons de jouer avec l'extension de la configuration de Webpack avec plus de conseils.
3. Des modèles tels que Module / nomodule pourraient-ils aider à réduire les morceaux? Recommander / documenter l'utilisation de @ loadable / components? Réhydratation partielle ?
4. Cela peut être une deuxième étape pour pousser des scores élevés, mais puisque FMP n'est plus un facteur, LQIP sur gatsby-image aide-t-il ou nuit-il en ce qui concerne LCP? LCP de store.gatsby.org sur la course ci-dessus était de 4,7 s!

(J'utilise les liens ci-dessus à titre d'exemples - si quelqu'un souhaite qu'un certain lien soit supprimé, je peux modifier le message avec plaisir)

Mon site (https://matthewmiller.dev/) semble s'être amélioré (~ 92 à ~ 95), mais certains des nouveaux tests révèlent quelques choses qui pourraient probablement être améliorées.

Le test JavaScript inutile par exemple,
(La première colonne est la taille, la deuxième colonne est le montant qui n'est pas nécessaire)

Je suppose que cela est dû au fait que les éléments requis pour d'autres pages sont inclus ici, donc utiliser quelque chose comme des composants chargeables pourrait aider un peu.

Pour moi, j'ai de grandes difficultés à comprendre Largest Contentful Paint , dans le sens où j'obtiens de très grandes valeurs sans savoir pourquoi, et je vois un écart entre la valeur du rapport (par exemple 7,4 s, et le LCP étiquette qui apparaît dans l'onglet Performance - ViewTrace (~ 800 ms)

Je peux voir que quelque chose de similaire semble se produire dans le démarreur https://parmsang.github.io/gatsby-starter-ecommerce/

En tant que mise à jour - il semble que PageSpeed ​​Insights ait lancé la mise à jour pour exécuter Lighthouse v6 (il se peut que ce ne soit pas encore dans toutes les régions).

Lien pour tester https://gatsbyjs.org/ . Obtention actuelle de résultats variant entre les années 60 et 80, principalement en fonction des valeurs du TBT et du TTI.

@kuworking il peut y avoir un problème avec Lighthouse v6 reconnaissant gatsby-image.

Selon webdev

Pour les éléments d'image qui ont été redimensionnés à partir de leur taille intrinsèque, la taille qui est signalée est la taille visible ou la taille intrinsèque, selon la plus petite des deux.

Dans mon cas, je pense que Lighthouse ne respecte pas la taille de la vue.

Et voici l'image en question

Cela pourrait expliquer la taille intrinsèque qui est de 3000 pixels, d'où le LCP 13s pour moi.

@ daydream05 J'avais également des théories et des résultats similaires, alors j'ai testé mes pages sans images et j'avais toujours un long LCP fou (10-12sec). J'ai beaucoup de choses dans mon projet, donc cela pourrait aussi être d'autres variables, mais je suis curieux de savoir si vous avez testé une page avec un contenu textuel et pas encore d'images.

Chuté de 100 à 79 ~ https://dougsilkstone.com/ récemment. Saute jusqu'à 90 lorsque Google Tag Manager (et Google Analytics) sont supprimés.

Je rendrai compte de plus de résultats pendant que je teste les choses.

Edit: Hit 100 lors de la suppression de la police chargée de typekit de gatsby-plugin-web-font-loader (également en utilisant le cache de préchargement des polices).

GTM affecte globalement mon projet, mais ce n'est pas si radical qu'un changement lorsque je le supprime (5 à 10 points en tête sur les scores inférieurs à 50 après LH6). J'ai encore besoin de faire plus de tests, mais je voulais juste le lancer.

@Jimmydalecleveland intéressant! J'ai aussi un autre site où l'écran est juste un texte et blâme le texte du héros comme la cause principale de LCP. Et LCP ne tient compte que de ce qui est en vue, ce qui n'a aucun sens. Comment un texte peut-il être un si gros problème.

@dougwithseismic J'utilise aussi typekit et c'est sans aucun doute l'un des principaux coupables des scores de phare inférieurs. Je souhaite qu'il y ait un moyen de corriger typekit car ils ne prennent pas en charge l'affichage des polices

Je pense que Lighthouse v6 est vraiment difficile pour les frameworks JS car ils ont changé la pondération des scores. (Plus d'attention sur le temps de blocage) Et les sites Gatsby ont des scores historiquement bas d'évaluation de script / de thread principal en raison de la réhydratation et d'autres choses.

@dougwithseismic Comment avez-vous lié la police typekit sans utiliser la feuille de style?

J'ai une expérience similaire, avec le phare 5.7.1, mon score de performance était d'environ 91, mais le phare 6 a considérablement baissé mon score de performance à environ 60.

Chuté de 100 à 79 ~ https://dougsilkstone.com/ récemment. Saute jusqu'à 90 lorsque Google Tag Manager (et Google Analytics) sont supprimés.

Je rendrai compte de plus de résultats pendant que je teste les choses.

Edit: Hit 100 lors de la suppression de la police chargée de typekit de gatsby-plugin-web-font-loader (également en utilisant le cache de préchargement des polices).

Je n'ai même pas installé ces plugins, mais mon score mobile est passé de 90+ à 60 ~ 70+

Pareil ici. Chute massive de 90 à 60 sur plusieurs sites.

+1 goutte d'environ 30+ points

Est-ce que quelqu'un s'occupe de cela? Il semble qu'il ne sert à rien d'utiliser Gatsby plutôt que Next s'il ne fournit pas de meilleurs scores dès la sortie de la boîte.

Est-ce que quelqu'un s'occupe de cela? Il semble qu'il ne sert à rien d'utiliser Gatsby plutôt que Next s'il ne fournit pas de meilleurs scores dès la sortie de la boîte.

Avez-vous des numéros de Next?

Je me demande si ces scores sont la nouvelle norme pour les sites Web rapides (qui ne sont pas statiques, sans JS et probablement aussi sans image)

Avez-vous des numéros de Next?

https://nextjs.org/ a un score de 85, avec à la fois Largest Contentful Paint (3,8) et First Contentful Paint (2,8) étant les principaux contrevenants. Il a également un tas de "JS inutilisés". C'est en baisse de ~ 95 dans Lighthouse 5.7.1. C'est "seulement" une baisse d'environ 10 points, alors que les sites Gatsby semblent perdre deux fois plus de points.

Je suis assez nouveau dans ce monde, mais je suis ce problème après que mon site gatsby ait perdu environ 25 points lors des tests avec lighthouse 6.0.0 de npm. Fait intéressant, si j'utilise les informations sur la vitesse de page plutôt que le phare npm, mon site remonte à environ 99. Alors que gatsbyjs.org obtient ~ 70 insights sur la vitesse de la page, mais ~ 84 avec le phare npm. Quelque chose est probablement en train d'être modifié quelque part, je suppose? Tous reçoivent des avertissements `` JS inutilisés '' tho

Est-ce que quelqu'un s'occupe de cela? Il semble qu'il ne sert à rien d'utiliser Gatsby plutôt que Next s'il ne fournit pas de meilleurs scores dès la sortie de la boîte.

Avez-vous des numéros de Next?
Je me demande si ces scores sont la nouvelle norme pour les sites Web rapides (qui ne sont pas statiques, sans JS et probablement aussi sans image)

Un site Web Next.js -> https://masteringnextjs.com/ 77 score mobile. Beaucoup de "JS inutilisés".

Je vois de meilleurs scores avec les métriques de phare https://lighthouse-metrics.com/one-time-tests/5edfbbb1cf858500080125f7

Mais je ne vois pas non plus d'images là-bas, et d'après mon expérience, les images semblent avoir un impact élevé (et légitime) sur l'OMI

Pourtant, gatsbyjs.org n'a pas non plus d'images et son score est (relativement) mauvais https://lighthouse-metrics.com/one-time-tests/5edfbc58cf858500080125ff (par rapport à l'exemple @cbdp )

Voyons ce que les développeurs de Gatsby en pensent

Avec quelques ajustements, le site est de retour aux meilleurs scores.

Il me semble que Google déplace les poteaux d'objectifs pour qu'ils soient plus
strict sur les performances, notamment FCP.

Nos sites ne sont en aucun cas lents, ils sont simplement jugés avec des
Critères. Je vais aider sur celui-ci ✌️

Le mar 9 juin 2020, 18:48 kuworking, [email protected] a écrit:

Est-ce que quelqu'un s'occupe de cela? On dirait que ça ne sert à rien d'utiliser Gatsby
Ensuite, s'il ne fournit pas de meilleurs scores dès la sortie de la boîte.

Avez-vous des numéros de Next?
Je me demande si ces scores sont la nouvelle norme pour les webs rapides (qui
ne sont pas statiques, sans JS et probablement aussi sans image)

Un site Web Next.js -> https://masteringnextjs.com/ 77 score mobile. Beaucoup
de "JS inutilisé".

Je vois de meilleurs scores avec les métriques phares
https://lighthouse-metrics.com/one-time-tests/5edfbbb1cf858500080125f7

Mais je ne vois pas non plus d'images là-bas, et d'après mon expérience, les images semblent
avoir un impact élevé (et légitime sur l'OMI)

Pourtant, gatsbyjs.org n'a pas non plus d'images et son score est (relativement) mauvais
https://lighthouse-metrics.com/one-time-tests/5edfbc58cf858500080125ff
(par rapport à l'exemple @cbdp https://github.com/cbdp )

Voyons ce que les développeurs de Gatsby en pensent

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-641433463 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/ALSIKRH4G74CRN2FNCUO4NDRVZRVNANCNFSM4NHP7XCA
.

Je voulais juste supprimer cette calculatrice utile pour comparer les résultats de la v6 avec la v5: https://googlechrome.github.io/lighthouse/scorecalc/

Les scores de Lighthouse varient généralement beaucoup, même lorsque vous l'utilisez via PageSpeed ​​Insights. Par exemple, pour https://www.gatsbyjs.org/, j'ai tout reçu de 64 à 88 performances mobiles après 5 courses. Par conséquent, pour traquer ce problème, la calculatrice peut être utile pour voir les conséquences de différents poids sur la même exécution (note: comme les métriques sont un peu différentes, certaines valeurs comme FMP doivent être supposées en utilisant d'anciennes mesures).

PS: J'ai ici une comparaison de deux exécutions de PageSpeed ​​Insights pour gatsbyjs.org:
Exécuter 1 - v6: 67 - v5: 85
Exécuter 2 - v6: 78 - v5: 87
Le plus gros impact est causé par la nouvelle métrique "Temps de blocage total" qui est inférieur à 70 dans les deux courses et a également un poids de 25%.

Oui, pour ajouter à @Pyrax : LCP (Largest Contentful Paint) et TBT pèsent chacun

LCP

• Suppression des animations susceptibles de se déclencher lors du chargement (par exemple, cookie 💩 bannière).
• Passer au tracedSVG de gatsby-img a semblé aider un peu, car nous avons de grandes images de héros sur la plupart des pages. (Je ne sais pas pourquoi vraiment, sans autre enquête. UX s'améliore un peu aussi.)

TBT

• De loin, Unused JS du bundling de Gatsby semble être le plus gros élément (sauvegardé les documents de web.dev ), de loin. L'arborescence au niveau des pages pourrait certainement être améliorée ici?

Cette récente mise à jour de Lighthouse semble avoir vissé les scores de performance de tout le monde, y compris les leurs:

Le seul site de Gatsby qui n'a pas vraiment été effacé est un site qui est essentiellement une seule page et comme 99% html. Mais même celui-là a chuté d'environ 5 à 10 points.

Cependant, je vois l'inverse de la plupart des gens, c'est-à-dire que Lighthouse dans le navigateur Chrome affiche toujours de bons scores pour mon site, mais lorsqu'il est exécuté sur PageSpeed ​​Insights, le score de performance baisse de 20 à 30 points ... peut-être ma version Chrome Lighthouse est derrière? Chrome est le dernier, je ne sais pas comment vérifier la version intégrée de Lighthouse ...

Cette récente mise à jour de Lighthouse semble avoir vissé les scores de performance de tout le monde, y compris les leurs:

Le seul site de Gatsby qui n'a pas vraiment été effacé est un site qui est essentiellement une seule page et comme 99% html. Mais même celui-là a chuté d'environ 5 à 10 points.

Cependant, je vois l'inverse de la plupart des gens, c'est-à-dire que Lighthouse dans le navigateur Chrome affiche toujours de bons scores pour mon site, mais lorsqu'il est exécuté sur PageSpeed ​​Insights, le score de performance baisse de 20 à 30 points ... peut-être ma version Chrome Lighthouse est derrière? Chrome est le dernier, je ne sais pas comment vérifier la version intégrée de Lighthouse ...

La version phare est présentée au bas de l'audit.

@dylanblokhuis ah, oui c'est ça. Je suis sur 5.7.1, la v6 n'est-elle pas encore livrée dans Chrome?

@dylanblokhuis ah, oui c'est ça. Je suis sur 5.7.1, la v6 n'est-elle pas encore livrée dans Chrome?

Ce n'est pas. Pas encore en tout cas. Si vous voulez la dernière, vous pouvez l'installer à partir de npm, puis exécuter lighthouse https://yoursite.com --view et vous obtiendrez votre score dans le même format que celui auquel vous êtes habitué avec l'audit Chrome :)

Pour tous ceux qui ont pris un grand succès dans les scores, # 24866 pourrait également être pertinent. Il y a eu un changement apparemment assez important dans la façon dont Gatsby distribue le chunking. Bien que le changement semble vraiment avoir beaucoup de sens, pour nous du moins, ce changement a abouti à ce que le code distribué entre les blocs soit concentré en blocs commons et app . Ce qui signifie une charge / analyse js beaucoup plus grande.

La chose la plus préoccupante ici est que ces mesures vont commencer à avoir un impact sur le Page Rank relativement bientôt.

J'ai supprimé toutes les demandes tierces (Tag Manager / Typekit / Pixel / Analytics / ReCaptcha) et cela ne donne qu'une augmentation de score relativement faible, donc quelque chose d'autre est en jeu.

De plus, pour tous ceux qui cherchent à exécuter Lighthouse 6 localement, il est maintenant disponible dans Chrome Canary et devrait être livré à Chrome en juillet.

Premièrement: j'ai contacté un ingénieur Google qui travaille sur web.dev et je lui ai posé des questions à ce sujet. Je ne sais pas si cela mènera à une explication plus approfondie, mais ils semblent vouloir aider. Je ferai un suivi lorsque j'aurai réussi à discuter avec eux.

Mes scores de performance sont passés de 94-99 à 40-55. 😢

La plus grande peinture de contenu pour mon site Web s'applique principalement aux pages avec de grandes images. Pour une raison quelconque, cela signifie que le chargement des images prend environ 14 secondes.

Si vous ouvrez l'un des sites de démarrage minimal de

Voici les deux premières entrées que j'ai vues avec de nombreuses images:

ghost.gatsby.org :

gcn.netlify.app :

Cependant, le blog de démarrage Gatsby a 98 performances (d'accord, c'est une page super minimale avec juste du texte):

gatsbyjs.com :

Comparez les anciens scores aux nouveaux scores dans Chrome

Vous pouvez toujours comparer les scores de l'ancienne et de la nouvelle méthode Lighthouse sans utiliser la CLI. Je trouve utile de voir ce qui a changé.

Voir les tests des anciens phares

Pour afficher les anciens scores de Lighthouse, exécutez l'extension chrome Lighthouse à partir de vos outils de développement Chrome, au lieu de la barre d'outils du navigateur.

Voir les nouveaux tests Lighthouse

Cliquez sur l'icône de votre barre d'extensions Chrome.

Ma page change

Voici les deux partitions que j'ai exactement pour la même page:

Ancien phare (via les outils de développement Chrome)

Nouveau phare (via l'extension Chrome sur la barre d'adresse)

🤷‍♂️

@nandorojo mon impression avec les images est que l'émulation se fait avec une connexion très lente et là, les images prennent beaucoup de temps à être rendues

Puisque l'option de supprimer des images n'est pas toujours possible, peut-être que ces scores des années 70 sont les normaux pour ce type de pages

Et, l'option de retarder leur chargement pour que l'utilisateur puisse démarrer son interaction plus tôt, ne semble pas faire l'affaire (dans mon cas)

Hé, désolé pour la réponse tardive. J'ai travaillé sur Lighthouse, je vais essayer d'expliquer du mieux que je peux.

Les développeurs de Chrome ont publié "Web Vitals", des mesures essentielles pour un site sain. Il contient de nombreuses mesures, mais les principales sont la plus grande peinture de contenu (LCP) , le premier délai d'entrée (FID) et le décalage de mise en page cumulatif (CLS) . Pour des outils tels que Lighthouse, le FID est remplacé par le temps de blocage total (TBT) .

Lighthouse v6 prend également en compte ces métriques et a évolué. Cela ne veut pas dire que Gatsby est lent. Il se peut que certaines optimisations différentes soient nécessaires.

Voici comment les choses ont changé:

Si vous voulez en savoir plus sur LCP, vous devriez vérifier https://www.youtube.com/watch?v=diAc65p15ag.

Alors parlons de Gatsby. Gatsby lui-même est encore assez rapide et nous l'améliorons encore plus. Nous créons de nouvelles API pour que les constructeurs de pages comme MDX, le texte riche de Contentful, ... puissent également optimiser le bundle. Beaucoup peut être fait en optimisant votre LCP. Assurez-vous que lorsque vous utilisez des polices et des images, elles ne sont pas chargées paresseusement et sont chargées dès que possible. Ces ressources doivent être chargées depuis la même origine que votre site, elles ne doivent pas être chargées depuis un CDN.

Malheureusement, le TBT est un problème difficile à résoudre et pour lequel React n'optimise pas. Si vous souhaitez abandonner TBT, vous devez vérifier avant de procéder . Preact a la même API que React mais a une empreinte javascript plus petite. Ils font les choses différemment mais les composants React sont compatibles. Vous l'installez en exécutant gatsby recipes preact .

Quelque chose que j'ai remarqué lors du profilage de gatsbyjs.com & gatsbyjs.org est que nous devrions charger google analytics, etc. un peu plus tard que nous le faisons maintenant pour nous assurer qu'il ne fait pas partie de TBT.

Si nous regardons .com en reportant les analyses et GTM et en nous assurant que les polices se chargent plus rapidement, nous pouvons déjà voir une amélioration de +17. Si nous ajoutons du préact dans le mélange, nous voyons +6.

Nous pouvons faire de même pour .org, nous commençons avec un score de 63. Avec une certaine optimisation du LCP et du TBT, nous pouvons arriver à 75.

Je ne suis pas sûr de ce que nous devrions faire avec ce problème. Je pense que nous pouvons le fermer car il n'y a pas grand-chose que nous pouvons faire ici. Que pensez-vous tous?

@wardpeet Ty pour plus de perspicacité.

Nous avons beaucoup approfondi cette question sur un grand projet Gatsby que nous avons qui utilise Contentful et sera utilisé sur plusieurs sites pour nous (les thèmes Gatsby sont géniaux). Je vais partager quelques résultats au cas où ils seraient utiles à quiconque se pencherait sur cela.

1. Nous avons une situation qui n'est peut-être pas très courante, mais je l'ai assez vue pour croire qu'elle n'est pas si unique non plus, où nous avons dû utiliser useStaticQuery pour récupérer des images provenant de Contentful et .find un par l'identifiant. Nous avons toujours su que c'était faux, mais nous n'avons pas été sensiblement punis pour cela jusqu'à ce que l'échelle du site atteigne plus de 300 images et que LH6 soit apparu et nous ait frappé.

La raison en est que les images font partie des incorporations Rich Text, et nous ne pouvons pas graphql pour elles au niveau de la requête de page (c'est essentiellement un champ json que Contentful a des packages à analyser). Lors de l'utilisation de l'analyseur de bundle Webpack, nous avons remarqué un fichier JSON massif (environ 720 Ko) et l'avons suivi comme étant les données de cette requête, qui ont été regroupées dans un modèle que nous utilisons pour la plupart des pages par Webpack. Cela signifiait que chaque utilisateur visitant notre site le téléchargeait dans le cadre du bloc pour l'ensemble du modèle de page, quelle que soit la page utilisant des images ou non.

Big woopsie de notre part, mais si quelqu'un d'autre fait de grandes requêtes statiques (auxquelles vous ne pouvez bien sûr pas passer de paramètres afin de réduire la taille), assurez-vous de faire attention à ces situations et de garder un œil sur vos morceaux de bundle.

1. Nous avons eu un certain succès aujourd'hui en utilisant le prop loading pour l'image Gatsby sur les images qui sont au-dessus du pli (images Hero pour nous). Nous avons essayé de travailler sur la plus grande peinture de contenu et cela a donné de bons résultats dans certains tests initiaux. Il y a une partie importante que j'ai presque ratée à ceci: si vous définissez loading="eager" pour votre image la plus haute, vous voudrez peut-être définir fadeIn={false} également pour cette image car la transition entre la base64 et complètement chargée l'image prend du temps, ce qui retarde le LCP.

Voici la documentation des accessoires à laquelle je fais référence et la note sur fadeIn est en bas: https://www.gatsbyjs.org/packages/gatsby-image/#gatsby -image-props

J'aimerais partager des captures d'écran mais je ne sais pas si je suis autorisé à le faire, désolé. Si vous utilisez Chrome devtools et regardez le panneau des performances, vous recevez de jolies petites balises sous la ligne "timings" pour FP, FCP, FMP et LCP. Lorsque nous sommes passés au chargement critique de la première image, nous avons non seulement vu une augmentation du score de performance d'environ 8 à 10, mais vous pouvez voir le chargement de la balise LCP immédiatement après FMP au lieu d'une seconde environ plus tard dans mon cas.

J'espère que cela aidera quiconque à résoudre ce problème, et merci à tous ceux qui ont répondu jusqu'à présent.

Quelque chose que j'ai remarqué lors du profilage de gatsbyjs.com & gatsbyjs.org est que nous devrions charger google analytics, etc. un peu plus tard que nous ne le savons pour nous assurer qu'il ne fait pas partie de TBT.

@wardpeet Comment

@wardpeet merci pour votre réponse. C'est utile. Peut-être que le meilleur résultat de ce numéro serait une documentation décrivant comment optimiser pour chacune des mesures du nouveau phare. Je suis convaincu que notre site est rapide pour les utilisateurs et que Gatsby lui-même fait un excellent travail pour optimiser le site pour les vrais utilisateurs. Cependant, si les vitales Web de Google commencent à informer le classement des pages, obtenir un bon score phare deviendra une mission essentielle pour la plupart des sites.

@Jimmydalecleveland nous avons eu un problème similaire où nous devions charger tous les éléments d'une ressource afin que nous puissions utiliser les données de la démarque pour configurer un filtwr (c'est-à-dire que nous ne pouvions pas filtrer avec GraphQL) et optimisé en utilisant différents fragments (un beaucoup plus petit sous-ensemble de champs) lors du chargement d'une ressource complète par rapport au chargement de toutes les ressources pour le filtrage. Cela a considérablement réduit notre par JSON et donc notre taille de bundle.

@treyles, vous devez faire attention en retardant le chargement d'Analytics car cela peut signifier que vos statistiques sont incomplètes. Par exemple, cela peut signifier que votre taux de rebond signalé n'est pas précis. Il y a certains scripts que le marketing ne nous permettrait pas de retarder (pixel, analytics, hotjar et donc tag manager), mais d'autres, par exemple Intercom, fonctionnent bien et sont une optimisation intéressante. En ce qui concerne la façon de retarder ces scripts, les scripts fournis par des tiers se chargent généralement de manière asynchrone, mais cela seul ne suffit pas. Vous devrez probablement remplacer ces scripts par les vôtres. Écoutez window.load, puis lancez le téléchargement. Vous devez cependant faire attention car certains scripts s'appuient sur window.load pour s'initialiser, et si vous l'avez utilisé pour charger le script, il ne se déclenchera pas à nouveau, vous devez donc les initialiser manuellement. Par exemple avec Intercom, nous:

• supprimé le degault <script>...</script> fourni par Intercom.
• a ajouté un auditeur pour window.load
• a ajouté un bref délai dans cet auditeur
• a déclenché une version modifiée du script par défaut d'Intercom qui a chargé leur lib async.
• interrogé pour voir quand le script a été chargé (Intercom ne fournit pas d'événement fiable)
• initialisé manuellement leur script (ce qui a été fait sur page.load par leur script par défaut).

@wardpeet merci pour la perspicacité très utile!

Concernant cette solution:

Assurez-vous que lorsque vous utilisez des polices et des images, elles ne sont pas chargées paresseusement et sont chargées dès que possible. Ces ressources doivent être chargées depuis la même origine que votre site, elles ne doivent pas être chargées depuis un CDN.

Cela n'irait-il pas à l'encontre du fonctionnement de l'image de Gatsby? De plus, la plupart des CMS gèrent la transformation d'image sur le serveur et sont hébergés dans leur propre CDN. (Ce qui est une bonne chose, imo). Mais si nous l'hébergeons sur notre propre site, cela ne serait-il pas également contre-productif?

Ajoutant à ce que @Undistraction a dit, Gatsby est rapide, mais si ce n'est pas rapide selon les yeux de Google, cela devient problématique. Surtout qu'ils incluent cela dans la mise à

@Jimmydalecleveland j'ai trouvé un moyen de travailler avec l'image de Gatsby dans le texte riche de contentful sans ce hack de requête! Voici l' essentiel . Le code a été copié à partir de gatsby-source-contentful . Fondamentalement, vous pouvez générer le fluide contenu ou des accessoires fixes en dehors de GQL. Ce qui est parfait pour le texte riche de content.

J'ai également créé une pull request afin que nous puissions accéder aux API directement à partir de gatsby-source-contentful .

Quelque chose ne va pas pour moi. J'ai construit un site Web très simpliste avec environ une image par page, j'utilise SVG pour les images sans gatsby-image, j'ai également essayé de supprimer google analytics et cela ne faisait pas beaucoup de différence, mon score était d'environ 50 à 60 pour les performances.

Ce qui est vraiment déroutant pour moi, c'est que seule la page d'accueil (index.js) obtient le score très faible, tandis que d'autres pages comme la page des services ou la page de contact obtiennent un score d'environ 80. J'ai construit ce site de manière assez cohérente et il n'y a donc pas de différence énorme entre les pages et pourtant, pour une raison quelconque, la page d'accueil a un score de ~ 50 tandis que les pages de services ont un score de ~ 80.

Comme je l'ai mentionné plus tôt, avec Lighthouse v5, le score était de ~ 90, cela n'a aucun sens qu'un simple site comme celui-ci ait maintenant un faible score de ~ 50.

Btw, l'un d'entre vous a-t-il essayé de définir l'image ci-dessus comme eager ?
Cela désactive le chargement différé et peut augmenter le score. Le flou ou svg
les effets de chargement peuvent prêter à confusion pour Lighthouse (qui si tel est le cas est
une faille dans leur algorithme).

Le sam.13 juin 2020, 10:48 t2ca [email protected] a écrit:

Quelque chose ne va pas pour moi. J'ai construit un site Web très simpliste
avec environ une image par page, j'utilise SVG pour les images sans gatsby-image,
J'ai également essayé de supprimer Google Analytics et cela n'a pas fait grand-chose
différence, mon score était d'environ 50 à 60 pour la performance.

Ce qui est vraiment déroutant pour moi, c'est que seule la page d'accueil
(index.js) obtient le score très faible, tandis que d'autres pages comme le
la page des services ou la page de contact obtiennent un score de ~ 80. J'ai construit ça
site assez cohérent et il n'y a donc pas une énorme différence entre
pages et pourtant, pour une raison quelconque, la page d'accueil a un score d'environ 50 tandis que le
pages de services a un score d'environ 80.

Comme je l'ai mentionné plus tôt, avec Lighthouse v5, le score était de ~ 90, c'est juste
Cela n'a aucun sens qu'un site simple comme celui-ci ait maintenant un faible
score de ~ 50.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-643648423 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAARLB2Q2IVSNVKGGBZ3ZPDRWOUU5ANCNFSM4NHP7XCA
.

@KyleAMathews Nous l'avons fait, et cela a considérablement augmenté le score de performance et les premières peintures. C'est ce que j'ai décrit au point 2 dans mon long commentaire ci-dessus. Annuler le fadeIn est ce qui a finalement rendu LH heureux.

Edit : J'ai, probablement par ignorance, l'impression que l'accent mis sur le LCP n'est pas la bonne approche à adopter universellement en ce qui concerne les images. Évidemment anecdotique, mais je pense qu'un site Web se sent beaucoup plus rapide lorsque tout le contenu est chargé et que les images sont fanées dans les suites, à moins que l'image ne soit cruciale pour le contenu.

Un exemple courant serait un article Medium. Bien sûr, vous pourriez dire que c'est un défaut de conception, mais la plupart des articles Medium (et de nombreux autres blogs) commencent par une grande image en haut qui est juste pour la création d'humeur ou le décor et je m'en fiche si elle se charge .

Btw, l'un d'entre vous a-t-il essayé de définir l'image ci-dessus comme eager ? Cela désactive le chargement différé et peut augmenter le score. Les effets de flou ou de chargement de svg peuvent être déroutants pour Lighthouse (qui, si c'est le cas, est une faille dans leur algorithme).
…

Je vais essayer ça maintenant.

Je pense que j'ai fait de bons progrès ici. J'ai fait passer mes scores de 57 à 84 avec des changements très basiques. Mon LCP est passé de 12s à 2s .

Cela dit, c'est incohérent. Depuis que j'ai apporté les changements que je décrirai ci-dessous, mon score varie de 69 à 84. Il y a clairement une variation aléatoire dans les scores de performance.

TLDR

Tout d'abord, comme @KyleAMathews et @Jimmydalecleveland l'ont suggéré, j'ai essayé de définir loading="eager" et fadeIn={false} sur mes composants d'image gatsby qui étaient au-dessus du pli.

Ensuite, je me suis débarrassé de base64 de mes requêtes.

Celles-ci ont fait une énorme différence.

Le bon

• Ajouter _noBase64 à mes fragments d'image a fait monter mon score de 20 points!

  • Il semble que les images base64 ajoutent beaucoup de poids sur mobile. J'interroge des images de contentful en utilisant localFile -> childImageSharp -> fluid -> GatsbyImageSharpFluid_withWebp_noBase64 .

• loading="eager" et fadeIn={false} ont réduit d'environ 50% mon temps de peinture le plus important!

  • Mon score de performance réel n'a augmenté que de 6-7 points pour une raison quelconque, mais le LCP fait définitivement des progrès ...

Ma requête ressemble à ceci:

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

Et mon gatsby-image ressemble à ceci:

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

Le moins bon

Mon UX sur mon site Web semble maintenant bien pire. Le fondu en base64 + a fourni une excellente expérience utilisateur. Maintenant, c'est un peu saccadé. Je suppose que c'est un compromis que nous devons considérer maintenant?

Avant et après eager & fadeIn={false}

Voici quelques comparaisons côte à côte des mêmes pages. La seule différence est que sur la droite, les images ont loading="eager" et fadeIn={false} .

1. Page d'accueil

LCP en baisse de 49%. Score de performance jusqu'à 6 points.

2. Page produit

LCP en baisse de 46%. Score de performance en hausse de 7 points.

Ce qui est étrange dans cet exemple ci-dessus: les captures d'écran de gauche ont le comportement par défaut de l'image gatsby (elles disparaissent et n'ont pas de eager on.) Et pourtant, même si le score de performance est inférieur , les petites captures d'écran en bas donnent l'impression qu'il se charge plus rapidement que l'image de droite.

C'est peut-être dans la marge d'erreur de la façon dont ils jugent les performances, ou peut-être que c'est un bogue de leur côté lié au fondu en vigueur, comme l' a mentionné

Après avoir défini _noBase64 dans les fragments d'image

Voici les mêmes écrans que l'exemple ci-dessus. Ils ont tous des accessoires loading="eager" , fadeIn={false} sur Gatsby Image. De plus, les fragments d'image dans le graqhql sont GatsbyImageSharpFluid_withWebp_noBase64

C'est un peu inexplicable, mais j'exécute un test de phare sur la même page encore et encore, et j'ai 84, 75 et 69.

Un peu bizarre, mais en tout cas, ça a fait monter mon score.

Je pense que l'algorithme Lighthouse se sentait exceptionnellement généreux ici lol ^

Après une enquête plus approfondie, j'avais découvert que Lighthouse se plaignait d'un élément spécifique qui avait un impact sur le score LCP.

Tout ce que j'ai fait, c'est simplement déplacer cet élément qui n'est qu'un paragraphe et mon score a sauté au-dessus de 80. Allez comprendre. Je ne sais pas exactement pourquoi le déplacement d'un paragraphe a augmenté mon score de ~ 50 à ~ 80.

@nandorojo Merci pour la rédaction approfondie. Nous n'avons pas essayé de supprimer complètement base64, mais ce serait dommage si nous le devions. Nous ne mettons également un chargement impatient que sur la première image de la page, donc si vous ne le faites pas déjà, cela vaut la peine d'essayer si vous pouvez contrôler cela.

Après une enquête plus approfondie, j'avais découvert que Lighthouse se plaignait d'un élément spécifique qui avait un impact sur le score LCP.

Tout ce que j'ai fait, c'est simplement déplacer cet élément qui n'est qu'un paragraphe et mon score a sauté au-dessus de 80. Allez comprendre. Je ne sais pas exactement pourquoi le déplacement d'un paragraphe a augmenté mon score de ~ 50 à ~ 80.

@ t2ca C'est ce que j'ai obtenu (même si le mien était une balise d'en-tête). Mais où l'avez-vous déplacé?

@ t2ca C'est ce que j'ai obtenu (même si le mien était une balise d'en-tête). Mais où l'avez-vous déplacé?

@michaeljwright La première chose que j'ai faite a été de supprimer le paragraphe et de vérifier le score du phare. Après avoir supprimé le paragraphe, mon score a augmenté d'environ 20 points. J'ai répété le test plusieurs fois pour m'en assurer. J'ai également remis le paragraphe et j'ai fait d'autres tests et ma plaie était à nouveau plus faible.

Enfin, j'ai décidé de simplement déplacer le paragraphe, Im utilisant le framer-motion à l'intérieur d'un div et j'ai simplement déplacé le paragraphe en dehors du div. Cela me donne le même résultat que lorsque j'ai supprimé le paragraphe.

@ t2ca Je pense que LCP pénalise toute animation dans nos pages de héros, ce qui est décevant.

Voici mes scores LCP où la balise de paragraphe est le LCP

Avec animation:

Sans animation:

@ t2ca Je pense que LCP pénalise toute animation dans nos pages de héros, ce qui est décevant.

Voici mes scores LCP où la balise de paragraphe est le LCP

Avec animation:

Sans animation:

@ daydream05 Merci d'avoir confirmé!

@ daydream05

Cela n'irait-il pas à l'encontre du fonctionnement de l'image de Gatsby? De plus, la plupart des CMS gèrent la transformation d'image sur le serveur et sont hébergés dans leur propre CDN. (Ce qui est une bonne chose, imo). Mais si nous l'hébergeons sur notre propre site, cela ne serait-il pas également contre-productif?

Non, car gatsby-image fonctionne également avec des images locales, il n'est pas nécessaire de l'héberger sur un CDN différent. Tout se résume à optimiser votre premier rendu (ce qui est dans la fenêtre). L'héberger sur un domaine / CDN différent signifie que vous devez ouvrir une nouvelle connexion (résolution DNS, prise de contact tls, ...) cela peut prendre jusqu'à 300 ms sur un appareil lent, puis vous devez toujours télécharger votre image.

Ajoutant à ce que @Undistraction a dit, Gatsby est rapide, mais si ce n'est pas rapide selon les yeux de Google, cela devient problématique. Surtout qu'ils incluent cela dans la mise à

Nous optimiserons encore plus Gatsby pour nous assurer que nos utilisateurs peuvent obtenir des 100 gratuitement.

@ t2ca Je pense que LCP pénalise toute animation dans nos pages de héros, ce qui est décevant.

C'est attendu car votre écran n'arrête jamais de peindre. Normalement, LCP devrait ignorer les animations CSS, mais cela dépend de la façon dont vous faites les animations.

@ t2ca

Si vous pouvez nous montrer le site, nous pouvons vous aider à trouver comment l'améliorer, mais cela donne probablement à l'image un caractère impatient.

@nandorojo

Super écriture! Avez-vous une chance de nous donner des liens vers ces rapports sur les phares?

C'est attendu car votre écran n'arrête jamais de peindre ...

@wardpeet pourriez -vous développer ce sujet s'il vous plaît?

@DannyHinshaw J'ai reçu cette explication du phare
«Ce que je pense, c'est que LCP se soucie que les images soient complètement chargées et que le temps indiqué est celui où l'image est complètement chargée et non quand elle est visible pour la première fois. Cette fois peut être différente en raison des images progressives et des peintures itératives. "

Et puis ce lien, peut-être d'aide
https://web.dev/lcp/#when -is-plus grand-contenu-peinture-signalé

En attendant, vous pouvez également essayer de changer votre plus grande peinture de contenu (LCP) d'une image en texte (si vous en avez le luxe), de précharger / pré-lire les polices et de charger les images paresseux. Dans mon cas, cela signifiait réduire la taille de l'image du héros sur mobile, ce qui a fait remonter notre score dans les années 90 supérieures pendant que la question était discutée.

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

C'est attendu car votre écran n'arrête jamais de peindre ...

@wardpeet pourriez -vous développer ce sujet s'il vous plaît?

Bien sûr, je ne sais pas de quel site il s'agissait, j'ai essayé de trouver des URL dans ce fil, mais c'était difficile. LCP ne prend pas en compte les animations CSS (transition, accessoires d'animation en css). Cependant, si vous avez un contenu qui utilise setTimeout / setInterval qui change de composant de réaction, il le prendra en compte. Cette dernière approche vous donnera de très mauvais scores CLS.

Donc, si vous souhaitez animer votre texte / image de héros. Veuillez utiliser des animations css.

Salut,

J'ai essayé de comprendre pourquoi mon projet obtenait un score si bas sur Google Page Speed ​​Insights, l'audit Google Lighthouse et plus encore.

À moins de partir de zéro, je ne sais pas quel est le problème. J'ai utilisé ce démarreur / thème pour commencer: https://github.com/alexislepresle/gatsby-shopify-theme

Je suis principalement en train de changer des trucs css comme le passage de bulma à chakra-ui.

Ceci est mon repo: https://github.com/Chizzah/genesis-style
J'ai essayé de supprimer tous les éléments du compte et les éléments de gatsby-plugin-appollo-shopify mais cela ne change pas les choses.

Voici le lien en direct: https://genesis-style.netlify.app

Rien de ce que je semble faire ne change les choses. Je préférerais ne pas avoir à partir de zéro. Si quelqu'un peut me donner un indice ou quelque chose, je l'apprécierai.

Je suppose que je me suis trop habitué à Gatsby donnant gratuitement 90-100s

Merci pour ce fil car une discussion sur l'obtention de bons scores de phare est nécessaire. Les scores superbes sont devenus plus difficiles avec la v6, principalement en raison de la nouvelle métrique LCP. Mon site (https://www.jamify.org) est passé de ~ 100 à ~ 70 avec Lighthouse v6.

Pour le ramener à 100 sur le bureau, je devais

• supprimer une image d'arrière-plan qui n'était pas nécessaire (car elle a été mal choisie comme LCP)
• optimiser la taille des images
• définir gatsby-image à loading="eager" et fadeIn=false
  (c'est vraiment dommage car j'aime l'effet de flou)

Sur mobile, je suis toujours bloqué sur 80, encore une fois à cause d'un LCP de 5 secondes. Cela pourrait être amélioré en dimensionnant correctement les images spécifiquement pour les mobiles:

Dans l'ensemble, ces optimisations sont assez faisables, cependant, je suis assez mécontent de devoir maintenant choisir entre des images à chargement paresseux avec flou ou un bon score Lighhouse: roll_eyes:

Quelqu'un a-t-il déjà fait des tests sur Lighthouse v6.1? J'ai remarqué une amélioration de mon score de performance.

Interrogé Addy de Google sur le problème LCP flou et c'est quelque chose qu'ils travaillent à résoudre https://twitter.com/addyosmani/status/1277293541878673411

La leçon ici est de ne pas traiter les nouveaux scores de performance comme absolus pour l'instant - ils affinent encore les cas de pointe.

Je pense que le problème s'aggrave avec Lighthouse 6.1. Il y a quelques bonnes suggestions ici concernant LCP, mais nous ne cherchons pas tellement à TBT qui, je pense, est la principale raison des mauvais scores sur mobile et la plus difficile à résoudre.

Vous pouvez tester Lighthouse 6.1 dans Chrome Canary. J'ai comparé mon site entre 6.0 et 6.1, ainsi que plusieurs autres mentionnés ici et le TBT est considérablement augmenté. Par exemple dans mes tests 6.1:

• gatsbyjs.org TBT: 2550 ms
• mon site TBT: 2200ms
• @styxlab site TBT: 1250 ms

Tout ce qui dépasse 600 pour TBT est rouge et le poids selon le calculateur est de 25%, donc un facteur majeur. TBT est causé par des fonctions qui prennent plus de 50 ms pour s'exécuter entre FCP et Time to Interactive.

La capture d'écran ci-dessus est un profil de mon site. Si vous utilisez Lighthouse dans Chrome, vous pouvez cliquer sur le bouton Afficher la trace pour charger les résultats dans l'onglet de profil pour voir la même chose. Toute tâche après FCP avec un drapeau rouge dans le coin compte pour TBT. Je n'ai pas encore approfondi les tâches, alors peut-être que quelqu'un ayant plus de connaissances sur Gatsby pourra vous aider dans ce domaine et peut-être @wardpeet pourra-

@IanLunn c'est une trace intéressante, avez-vous pu avoir une idée de ce que ces tâches étaient en dessous?

Il y a probablement une corrélation entre la quantité de JS de chaque site Gatsby et son coût sur le fil principal du navigateur. Quoi qu'il en soit, je pense que la discussion pourrait être ouverte, y a-t-il un moyen pour Gatsby d'aider à «atténuer» l'impact en chargeant les requêtes et les scripts ensemble?

Il y a trois domaines que j'essaie de mieux comprendre pour le moment:

• Gatsby ajoute par défaut <link rel=preload/> pour chaque script nécessaire (selon le modèle PRPL ) quel que soit le nombre. J'ai remarqué quelques différences dans le FCP mesuré (dont j'ai été assez surpris) mais surtout dans l'écart entre FCP / LCP lors de la suppression de ces derniers (ce qui n'est probablement pas une bonne idée de se passer d'autres changements). Ce numéro sur le phare traite de ce dernier.
• Les requêtes finissent par créer des JSON (page-data.json et ceux hachés pour les requêtes statiques) qui sont évalués sur le thread principal. Voir https://github.com/gatsbyjs/gatsby/issues/18787 mais il ne semble pas que nous ayons trouvé (ou s'il y a) une alternative qui ne bloque pas le thread principal. Plus les données sont volumineuses, plus les performances sont affectées (donc les budgets de performance pour les tailles de requêtes seraient certainement les bienvenus) - mais les données ne sont pas vraiment nécessaires avant le processus de réhydratation, ou est-ce?
• Les blocs réels sont ajoutés en tant que <script src=foo.js async /> à la fin de </body> . Cela signifie que dès que le navigateur aura fini d'analyser le HTML (qui devrait être bientôt dans la trace), il commencera à analyser et à exécuter ces scripts (car ils étaient déjà préchargés). De longues tâches surviendront inévitablement car le thread principal est invité à analyser et à exécuter tout ce javascript. Existe-t-il un meilleur moyen de gérer cela (au moins _lorsque_ ces scripts commencent à être analysés) pour éviter de bloquer le thread principal? Existe-t-il un moyen de faire cela (soit l'analyse, soit l'exécution) dans de petites tâches incrémentielles qui ne retardent pas le retour d'entrée (et donc nuisent à TTI), ni ne bloquent le thread principal par tranches de temps (et donc nuisent à TBT)?

Alors qu'il est vrai pour le moment, les sites Gatsby sont un peu pénalisés parce que LCP ne reconnaît pas encore le modèle LQIP à partir de gatsby-image - en ce qui concerne tout ce qui concerne TBT / TTI (et peut-être une pénalisation majeure sur le coût de Javascript par rapport à Lighthouse v5) Je ne pense pas qu'il y ait quoi que ce soit dans la feuille de route de l'équipe Lighthouse où les choses s'amélioreront par rapport aux scores actuels.

@juanferreras La tâche la plus importante semble être domready / ready.js (tiers). J'ai le sentiment que votre déclaration à propos de la pénalisation de JavaScript par Lighthouse est correcte et bien que de petites optimisations soient possibles dans Gatsby, ce n'est pas quelque chose qui peut être résolu.

Si tel est le cas à Lighthouse, je suis tenté de leur demander au moins de réduire le poids du TBT ou de leur donner la possibilité de définir l'environnement de test souhaité. Fournir un score basé sur un téléphone à petit budget n'est pas toujours approprié pour le site testé. Nous devrions être en mesure de montrer aux patrons / clients que oui, un téléphone à petit budget obtient un score de 75, mais un téléphone haut de gamme que 95% de nos utilisateurs ont obtient un score de 90 par exemple.

• Les requêtes finissent par créer des JSON (page-data.json et ceux hachés pour les requêtes statiques) qui sont évalués sur le thread principal. Voir # 18787 mais il ne semble pas que nous ayons trouvé (ou s'il y en a) une alternative qui ne bloque pas le thread principal. Plus les données sont volumineuses, plus les performances sont affectées (donc les budgets de performance pour les tailles de requêtes seraient certainement les bienvenus) - mais les données ne sont pas vraiment nécessaires avant le processus de réhydratation, ou est-ce?

@juanferreras , concernant ce problème d'analyse des données json sur le thread principal, ce qui me vient à l'esprit, c'est le web worker. Gatsby peut enregistrer un web worker s'il est disponible sur le client, et tamponner ce genre de choses sur lui, le processus de réhydratation n'est pas vraiment nécessaire immédiatement, donc c'est faisable je crois

Web worker est pris en charge dans les principaux navigateurs, y compris ie10.

… Nous ne cherchons pas tellement à TBT qui, à mon avis, est la principale raison des mauvais scores sur mobile et la plus difficile à résoudre.

Je souhaite ajouter quelque chose qui, à mon avis, est pertinent pour le temps de blocage total. Après avoir examiné mes bundles avec l'analyseur de bundle Webpack, j'ai remarqué que les données des requêtes statiques sont incluses dans les bundles JavaScript. Je suis sûr qu'il y a une bonne raison à cela, mais cela fonctionne contre un TBT faible.

Le TBT est un problème difficile à résoudre, d'autant plus que React n'est pas conçu pour cela. Passer à la préaction est une bonne première étape. Nous améliorerons de plus en plus TBT dans les mois à venir, nous voulons que Gatsby ait une très petite empreinte.

Dans la version gatsby> 2.24.0, nous avons fourni un support polyfill amélioré, nous ne chargeons donc les polyfills que sur les navigateurs hérités comme IE11. Nous avons également supprimé les requêtes statiques de webpack il y a quelques jours (@MarkosKon).

@Teclone, malheureusement, les ShardArrayBuffer, ce serait une autre histoire, malheureusement, ils sont désactivés par défaut à cause de Meltdown / spectre

J'étais juste en train d'obtenir 100/100 sur tout sur le phare intégré (6.0) dans Chrome, puis j'ai utilisé la version web.dev (6.1) et il est revenu avec des performances dans les années 70 grâce à LCP (environ 5-6 secondes dans 6.1, environ 0,5 seconde en 6,0). C'est une image d'en-tête décorative (utilisant gatsby-background-image) dont il se plaint.

En regardant mon propre site Web, le runtime Webpack a la plus grande quantité de temps d'exécution javascript. Quelque chose dont la page n'a même pas besoin jusqu'à ce que l'utilisateur commence à interagir avec la page.

Gatsby semble charger toutes ces ressources (blocs) à la fois. Le fichier js lui-même est tout simplement très petit, c'est un chargeur, vous pouvez voir qu'il ne faut que 2 ms pour passer le fichier. Mais le fichier lui-même charge des morceaux et des fichiers modèles.

En fait, lorsque j'inspecte les fichiers chunk, je découvre que tous sont des importations dynamiques, qui, nous espérons qu'elles ne seront chargées que lorsqu'elles sont nécessaires, mais non, elles sont toutes chargées par défaut. Ce comportement n'est pas ce que j'attends.

Nous avons fait un peu d'optimisation de notre image d'en-tête, comme l'utilisation d'une image directement plutôt que Gatsby-Image et la réduction de la résolution et de la compression, et la nôtre est un peu meilleure. Seulement, je viens de découvrir à la dure que Safari ne prend pas en charge WebP (grr). Et il est toujours vrai que la version Web de Lighthouse est beaucoup moins indulgente que celle intégrée à Chrome, du moins pour notre site de développement "caché". Le temps nous dira si les données utilisateur agrégées aident une fois qu'elles sont en ligne - je ne suis pas convaincu qu'il y en ait autant qui utilisent des Moto G5 dans le monde réel!

@derykmarl Il devrait être bientôt pris en charge: https://www.macrumors.com/2020/06/22/webp-safari-14/
Je ne comprends pas pourquoi Apple a pris autant de temps pour prendre en charge un format d'image répandu ...

J'ai lu que pagespeedinsight émule la façon dont le score est calculé. Il semble qu'ils ne limitent pas le réseau afin que vous puissiez obtenir votre rapport plus rapidement. J'utilise personnellement https://lighthouse-metrics.com/ mais ils ne prennent pas encore en charge la version 6.1.

Le problème avec Lighthouse 6.x est qu'il repose sur le timing de perception, vous pouvez exécuter le même test 10 fois et vous n'aurez pas les mêmes résultats en fonction des conditions du réseau.

il est revenu avec des performances dans les années 70 grâce à LCP

J'avais un LCP qui était l'image de fond de mon site Web, j'ai pu réduire drastiquement mon LCP en divisant l'image en 6 sous-images. J'ai créé un script python pour faire cela facilement, tant que vous connaissez la hauteur que vous voulez que chacun de vos segments soit

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)

J'ai également trouvé que ce site Web de compression d'images fonctionnait vraiment bien pour réduire la taille de votre image sans perdre trop de qualité. Je pourrais généralement descendre à la marque de qualité 20% -30% et réduire considérablement la taille de mon fichier.

J'ai posé des questions à ce sujet en ligne et certaines personnes recommandent de ne diviser mon image qu'en 2, au-dessus du pli et en dessous du pli, mais j'ai trouvé que le fractionnement en 6 fonctionnait beaucoup mieux.

@wardpeet sur la note TBT / TTI, nous pourrons peut-être voir comment d'autres sites basés sur les

reactjs.org lui-même (qui est également construit avec Gatsby pour autant que je sache) semble avoir un TTI considérablement plus petit (7-8 ~ vs 12 ~) que le nouveau gatsbyjs.com (félicitations pour le lancement d'ailleurs!). NextJS a également maintenu de très bons chiffres sur TTI / TBT bien qu'ils soient eux-mêmes basés sur React (cela peut aussi être dû à la taille relative des scripts - où gatsby.com a environ 628,3kb de script selon PSI, reatjs.org 466.1kb , et nextjs.org seulement 216.8kb)

(il s'agit évidemment d'une seule exécution et ne doit pas être utilisée comme une comparaison réelle, mais la tendance est assez cohérente sur plusieurs exécutions).

La majorité de la différence de score est-elle due au coût global de Javascript ™? Si l'équipe Gatsby optimise le nouveau site Web à un moment donné, cela pourrait être une excellente occasion de partager des informations sur le processus, à condition qu'il ne reste plus beaucoup de magie à ajouter à la façon dont le framework gatsby gère déjà le javascript en interne.

@juanferreras @wardpeet , Il y a aussi quelque chose que j'ai découvert sur mon propre projet. Si vous utilisez des composants stylisés, pour certaines raisons, les styles sont recalculés / régénérés pendant l'hydratation et réinjectés dans le navigateur. Cela prend une grande partie du fil principal.

Cela est dû à des problèmes d'hydratation chez Gatsby. https://github.com/styled-components/styled-components/issues/2171

Gatsby travaille également sur l'exécution de ssr pendant le développement, https://github.com/gatsbyjs/gatsby/issues/25729 , cela aidera à résoudre ce genre de problèmes de performances. aussi.

@teclone

https://github.com/styled-components/styled-components/issues/2171 ne semble pas offrir de solution. Comment l'avez-vous résolu dans votre projet?

@dfguo , pour l'instant, il n'y a pas de solution à cela, car personne ne sait exactement pourquoi les styles sont régénérés lors de la réhydratation, car gatsby en production n'offre pas d'aide au développement pour les erreurs de réhydratation.

Autrement dit, il n'y a pas de journal de console de React indiquant les différences pendant la réhydratation, car il est désactivé dans la version de production de gatsby.

Le but de ce travail en cours # 25729 est d'exécuter un véritable SSR en développement, nous pourrons donc voir pourquoi. y compris l'équipe de Gatsby.

BTW, vous pouvez créer un site Gatsby avec gatsby build --no-uglify pour créer votre site avec la version de développement de React pour voir les journaux. https://www.gatsbyjs.com/docs/gatsby-cli/#build

Dev SSR sera très utile à l'avenir pour des trucs comme ça!

J'ai donc décidé de migrer mon site de @emotion et theme-ui à linaria tout en implémentant le mode dark-light avec des variables css personnalisées

L'objectif était de réduire le temps de blocage / le thread principal / tout ce qui concerne js, puisque maintenant css ne sont plus évalués à l'exécution mais compilés au moment de la construction (en fait linaria semble beaucoup plus aligné sur gatsby déclarations que @emotion à cet égard)

Le processus n'est pas totalement fluide, la plupart des choses que j'ai faites avec @emotion fonctionnent simplement avec linaria , mais d'autres ne le font pas et vous devez les réécrire et / ou les réimplémenter via un css personnalisé variables

L'expérience DX avec gatsby est __bad__, le rechargement à chaud ne fonctionne pas (vous devez vous arrêter et recommencer à tout changement car le navigateur semble perdre la connexion), mais dans l'ensemble, le processus a été agréable car il vous oblige à être plus consciencieux sur ce avez-vous vraiment besoin des capacités d'exécution @emotion

__ Cela dit, les métriques des phares sont très similaires__

Je peux comparer les deux déploiements netlify et en fait le site @emotion a des années 70 élevées et le site linaria a des années 70 faibles à moyennes

Inutile de dire que je ne suis pas très excité

Analyse du bundle:

• le document du site est passé de 14 Ko à 28 Ko
• le script du framework est resté identique à 38,7 ko
• Le script de l'application est passé de 58,2 Ko à 46,1 Ko
• Et un quatrième script ( component--content.. . Puis, 20bae078.. maintenant) est passé de 44,2 ko à 46,8 ko

Je suppose donc que les styles de js sont passés aux styles en css (et ~ 12 ko sont importants pour l'OMI), mais cela n'a pas eu d'impact réel sur les métriques de phare (et c'est ce qui compte, n'est-ce pas?)

Donc, je ne dis pas du tout que passer à linaria n'a aucun sens, je ne serais pas surpris que quelqu'un fasse de même et ait de meilleurs résultats (en théorie, cela devrait être le cas (?)), mais entre mes mains le processus n'a pas valu

Pourtant, en explorant le script de l'application, j'ai ouvert un nouveau problème en essayant de comprendre comment réduire le bundle js https://github.com/gatsbyjs/gatsby/issues/26655

L'expérience DX avec gatsby est mauvaise , le rechargement à chaud ne fonctionne pas (vous devez vous arrêter et recommencer à tout changement car le navigateur semble perdre la connexion), mais dans l'ensemble, le processus a été agréable car il vous oblige à être plus consciencieux sur ce avez-vous vraiment besoin des capacités d'exécution @emotion

@kuworking J'ai rencontré un problème similaire, mais j'ai remarqué qu'il ne s'est produit que sur les versions gatsby plus récentes que 2.24.9 ; Je ne sais pas si la cause est la même, mais j'ai pensé que cela pourrait aider quelqu'un à savoir que les gens en parlent dans le numéro 26192 .

@kuworking J'ai rencontré un problème similaire, mais j'ai remarqué qu'il ne s'est produit que sur les versions gatsby plus récentes que 2.24.9 ; Je ne sais pas si la cause est la même, mais j'ai pensé que cela pourrait aider quelqu'un à savoir que les gens en parlent dans le numéro 26192 .

Je suis avec "gatsby": "2.24.14" depuis plusieurs semaines, je dirais, et jusqu'à présent, je n'ai vécu cela qu'avec linaria
Mais sachant cela, je ne mettrai pas à jour gatsby tant que cela ne sera pas compris, merci 👍

@kuworking Ce que je voulais suggérer, c'est que peut-être que si vous rétrogradiez à 2.24.9 alors le problème d'arrêt du serveur de développement ne se produirait pas même avec linaria ; mais ce n'est qu'une idée. Je serais curieux de savoir si c'est le cas.

L'expérience DX avec gatsby est mauvaise , le rechargement à chaud ne fonctionne pas (vous devez vous arrêter et recommencer à tout changement car le navigateur semble perdre la connexion), mais dans l'ensemble, le processus a été agréable car il vous oblige à être plus consciencieux sur ce avez-vous vraiment besoin des capacités d'exécution @emotion

Avez-vous essayé l' actualisation rapide ?

J'ai récemment migré un site de production Gatsby (~ 120 pages) pour préagir dans l'espoir d'améliorer TBT & LCP. Notre site est lourd en svg et utilise des composants react svg générés avec svgr et stylisés à l'aide des styles material-ui. Les résultats de performance moyens se situaient dans la plage + -5 du score initial (~ 45 performances mobiles contre ~ 85 avant la v6) et bien que la migration ait été relativement simple en utilisant le thème, elle nécessitait une migration vers une actualisation rapide qui était ne pas.

Honnêtement, je suis un peu déçu qu'il n'y ait pas d'autres optimisations que je puisse trouver à essayer ou des métriques plus détaillées à partir de l'avertissement générique de phare "Supprimer le javascript inutilisé".

La vitesse est l'une des principales raisons pour lesquelles nous avons choisi gatsby et même si les pages sont encore rapides à charger, il est difficile de justifier d'un point de vue SEO lorsque vos scores de perspicacité prennent un si grand succès ...

chuchote: je suis passé à NextJS et j'obtiens de meilleurs scores 🤭

chuchote: je suis passé à NextJS et j'obtiens de meilleurs scores 🤭

Et Svelte?

Il serait bon de savoir si les développeurs de Gatsby donnent à cela un sens spécifique d'importance / priorité dans la feuille de route (autre que celle attendue), car je suppose qu'il n'y a pas de solutions immédiates mais peut-être une sorte d'orientations et d'implémentations futures axées sur Ceci ou cela

Puisque gatsby fait une compilation avec gatsby-node *, je me demande s'ils explorent des moyens d'augmenter cette partie et de désendetter la partie cliente

* Afin de réduire les pageContext que j'utilisais (données sur tous les articles publiés), je stocke actuellement (via gatsby-node ) la plupart de ces données dans des fichiers json et les récupérer si nécessaire sur le site, ce qui réduit la taille du bundle mais semble également plus logique

Ne soyez pas trop accro aux scores des phares - surtout lorsqu'ils
conçu comme une référence par rapport à d'autres sites, et non comme un objectif où nous devrions
efforcez-vous d'obtenir un score parfait.

Ce n'est que récemment que Gatsby clouait des 100 pures - bien sûr, là
il y a quelques problèmes à résoudre, mais le jeu SEO en ce moment est la vitesse plus le contenu
plus des liens, et nous l'avons couvert.

Mes deux centimes.

Le vendredi 28 août 2020, 16:57 kuworking, [email protected] a écrit:

chuchote: je suis passé à NextJS et j'obtiens de meilleurs scores 🤭

Et Svelte?

Il serait bon de savoir si les développeurs de Gatsby donnent à cela des
sens de l'importance / priorité dans la feuille de route (autre que le
one), car je suppose qu'il n'y a pas de solutions immédiates mais peut-être
genre d'orientations et d'implémentations futures axées sur tel ou tel

Depuis que gatsby fait une compilation avec gatsby-node *, je me demande s'ils
explorent des moyens d'augmenter cette part et de désendetter la part du client

* Afin de diminuer le pageContext que j'utilisais (données sur tous
les articles publiés), je stocke actuellement (via gatsby-node) la plupart
de ces données dans des fichiers json et les récupérer si nécessaire sur le site,
ce qui réduit la taille du paquet mais semble également plus logique

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-682664232 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/ALSIKRHQUIKR5YO6OGA3DC3SC7AWPANCNFSM4NHP7XCA
.

Désolé pour la réponse tardive, il y a beaucoup de choses qui entrent dans la performance et les métriques de charge ne sont qu'une petite pièce du puzzle. Nous sommes motivés ce trimestre et le prochain pour réduire la taille de Gatsby et réduire le TBT. Les plus gros problèmes actuellement sont la taille du bundle React, MDX, les grandes pages (contenu / style), le suivi des scripts et des polices / images comme contenu principal lors du premier chargement.

Je suis actuellement à la recherche de scripts gatsby-image & analytics pour voir comment nous pouvons améliorer le temps de chargement et reporter les analyses.

Malheureusement, je ne peux donner aucune estimation. Nous examinons également notre site .com et nos clients pour voir quels sont les problèmes courants afin que nous puissions intégrer ces optimisations dans gatsby ou dans nos plugins.

Éditer:

Je suis heureux de consulter l'un de vos codes sources pour obtenir plus d'informations sur ce que vous faites tous et voir comment nous pouvons nous améliorer.

J'ai publié un article sur

En supprimant uniquement gatsby-image (

Lors de certains tests récents que je faisais, j'ai trouvé que l'utilisation de tracedSVG améliorait considérablement le score de performance de Largest Contentful Paint. J'imagine que cela sera corrigé dans Lighthouse, mais à partir de maintenant, cela se produit parce que le SVG est considéré comme étant les mêmes dimensions que l'image pleine résolution, donc il ne passe jamais du SVG en tant que cible LCP à l'image complète.

Lors de l'utilisation de base64, la petite résolution en fait pas un candidat pour LCP, donc Lighthouse utilise l'image en pleine résolution chaque fois que cela se charge.

Donc, si l'apparence des SVG tracés ne vous dérange pas (je les préfère personnellement), vous voudrez peut-être essayer.

Pourquoi la v5 est-elle plus meilleure que la v6? J'utilise NextJS le résultat est toujours passé de 60 à 85.

+1

J'ai travaillé sur un successeur d'image de Gatsby. Ce n'est pas encore 100% là, il faut encore écrire une version composable pour que vous puissiez créer votre propre saveur gatsby-image, mais cela corrigera la plupart des mauvais scores de phare.

Vous pouvez déjà l'utiliser mais ce n'est pas encore testé au combat.
https://github.com/wardpeet/gatsby-image-nextgen/tree/main/gatsby-image

Vous pouvez l'installer par npm install --save @wardpeet/gatsby-image-nextgen . Il existe une couche de compatibilité pour les utilisateurs actuels de gatsby-image .

Choses qui ne sont pas encore prises en charge:

• l'ajustement d'objet doit être effectué par css en dehors du composant
• Direction artistique

Démo actuelle de Gatsby-Image:
site: 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
Webpagetest: https://webpagetest.org/result/200928_4M_0879160e38bb6c5489f85534de2dd197/

Nouvelle démo de gatsby-image-nextgen:
site: 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
Webpagetest: https://webpagetest.org/result/200928_C0_63317160bdfc71ece1a2057df8b08133/

@wardpeet Votre lien pagespeed-insights pour la démo actuelle va à nextgen afin qu'ils affichent les mêmes scores.
Super travail, au fait. Vraiment excitant de voir les progrès.

Merci réparé!

Cette mise à jour m'a fait remarquer quelque chose que je ne m'étais pas connecté auparavant, je n'utilise pas gatsby-image mais en fait gatsby-background-image qui n'utilise apparemment pas gatsby-image sous le capot ... Je devrai peut-être réécrire ce composant avec ce nouveau @wardpeet/gatsby-image-nextgen si c'est possible ....

Cet article répertorie quelques conseils supplémentaires https://www.freecodecamp.org/news/gatsby-perfect-lighthouse-score/ bien que je pense que beaucoup d'entre eux ont déjà été mentionnés dans ce fil ...

@DannyHinshaw lorsque la fonctionnalité du plugin est terminée. Je vais également jeter un œil à ce plugin. Je dois aussi regarder les images de remarques

J'ai publié une nouvelle version de @wardpeet/gatsby-image-nextgen - 0.0.2.

1. minifie css & js dans le html
2. ne chargez que les bits nécessaires, lorsque le chargement d'image native est activé, nous ne chargeons qu'environ 2 ko (non gzippé).
3. assurez-vous que l'espace réservé n'est appelé qu'au premier chargement, les images mises en cache se chargent immédiatement
4. Correction de l'animation floue en décodant asynchrone

Je me demande combien d'entre vous ont besoin d'un composant Image composable où vous pouvez créer votre propre wrapper et combien d'entre vous utilisent réellement la direction artistique et le souhaitent dans gatsby-image par défaut? Ma première idée a été de désactiver la fonctionnalité mais de l'activer avec l'image gatsby composable afin que vous deviez créer votre propre composant image pour le prendre en charge.

Dernière démo: https://gatsby-image-nextgen.netlify.app/

@wardpeet C'est génial! Je compte beaucoup sur la direction artistique intégrée de gatsby-image. Mais je suppose qu'un exemple / un chemin de mise à niveau fluide serait également acceptable!

J'ai toujours reçu 99 sur mobile maintenant un 76. Tout est super sauf mon LCP c'est 7.0s et il dit que c'est mon image de héros. Ça n'a aucun sens. Lorsque je consulte mon site sur n'importe quel téléphone mobile, c'est extrêmement rapide. Les gens s'émerveillent, tu sais? Il me dit aussi de mettre mes images dans webp ou autres, mais je utilise déjà childImageSharp_withWebp donc je ne comprends pas. Je commence à penser que Gastby Image et background-image ne fonctionnent pas avec cette nouvelle version de Lighthouse et Pagespeedinsight. Mon esprit est ahuri. Je suis allé tuer des animations, redimensionné toutes mes images de moitié et cela n'a pas bougé d'un seul point. Je lis ceci et je ne vois rien qui puisse m'aider ... Oh j'ai juste levé les yeux ... Je pense que

@davidpaulsson pense-t-il à partager un exemple sur la façon dont vous faites cela? Parce que la direction artistique est toujours possible avec la nouvelle image gatsby, vous devez faire quelques étapes manuelles.

@davidpaulsson pense-t-il à partager un exemple sur la façon dont vous faites cela? Parce que la direction artistique est toujours possible avec la nouvelle image gatsby, vous devez faire quelques étapes manuelles.

Sûr! Je l'utilise comme ça actuellement

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

return <Img fluid={artDirection} />

@wardpeet Salut Ward. Blurha.sh pourrait-

@wardpeet J'ai utilisé votre plugin gatsby-image-nextgen et il a en fait amélioré mon temps LCP (il l'a réduit de ~ 5s à ~ 1,5s). Merci pour ça!

Cependant, nous utilisons également la direction artistique, similaire à la façon dont @davidpaulsson l' utilise, et je n'arrive pas à la faire fonctionner comme elle le fait avec gatsby-image.

Pourriez-vous élaborer sur les étapes manuelles nécessaires pour rendre cela possible avec le plugin nextgen? Merci encore!

@Jimmydalecleveland Merci Jimmy! Le remplacement de GatsbyImageSharpFluid_withWebp par GatsbyImageSharpFluid_withWebp_tracedSVG considérablement amélioré le score de performance de mon nouveau Gatsby Webiste. Je n'obtenais pas plus de 54% et maintenant avec tracedSVG j'obtiens plus de 80%. C'est une énorme amélioration 💯

Lors de certains tests récents que je faisais, j'ai trouvé que l'utilisation de tracedSVG améliorait considérablement le score de performance de Largest Contentful Paint. J'imagine que cela sera corrigé dans Lighthouse, mais à partir de maintenant, cela se produit parce que le SVG est considéré comme étant les mêmes dimensions que l'image pleine résolution, donc il ne passe jamais du SVG en tant que cible LCP à l'image complète.

Lors de l'utilisation de base64, la petite résolution en fait pas un candidat pour LCP, donc Lighthouse utilise l'image en pleine résolution chaque fois que cela se charge.

Donc, si l'apparence des SVG tracés ne vous dérange pas (je les préfère personnellement), vous voudrez peut-être essayer.

@abdullahe Nous l'avons déjà vérifié et il a une dépendance sur canvas et node-canvas n'est pas super fiable. Ou du moins ce n'était pas dans le passé. Je vous ferai savoir si nous y réfléchissons à nouveau :)

@guydumais assurez-vous de mettre loading="eager" cela devrait également changer votre score.

@BenjaminSnoha & @davidpaulsson Je vais partager un exemple dans un

@wardpeet comment utiliserait-on @wardpeet/gatsby-image-nextgen avec gatsby-remark-images ? S'agit-il simplement de le désigner comme un plugin dans gatsby-config.js , ou n'est-ce pas possible tant qu'il n'est pas fusionné dans le gatsby monorepo?

bien que cela n'ait rien à voir avec lighthouse, je me demande pourquoi les fichiers JSON de données de page gatsby ne prennent pas en charge le hachage de contenu, tout comme les fichiers js.

Je sais que le hachage de contenu pour les fichiers js est effectué par Webpack, mais gatsby peut également faire de même pour les fichiers JSON de données de page. cela peut économiser beaucoup de requêtes réseau cdn

Les fichiers @teclone page-data.json ne doivent pas être téléchargés encore et encore si votre mise en cache est correctement configurée. Ils se chargeront une fois, puis le navigateur les revalidera. Le problème avec le hachage de contenu pour les données de page (par rapport aux fichiers JS / CSS) est simplement qu'il y en a tellement. Avec le hachage de contenu, avant de pouvoir charger un fichier, vous devez charger un manifeste qui se traduit de x en x.LONG_HASH car le hachage n'est pas prévisible. Avec JS / CSS, le chargement d'un manifeste est raisonnable car il n'y a qu'un nombre limité de fichiers JS, même sur de très grands sites. Mais avec les données de page, il y en a une par page, donc le manifeste peut devenir assez volumineux. Nous avions l'habitude de faire cela et nous avons trouvé sur un site de 10 000 pages que le manifeste était déjà compressé à ~ 500 000. https://github.com/gatsbyjs/gatsby/pull/13004

Si vous voyez des fichiers page-data.json téléchargés encore et encore - vérifiez que vous n'avez pas désactivé la mise en cache dans vos outils de développement et vérifiez vos en-têtes de cache avec https://www.npmjs.com/package/check-gatsby-caching

@KyleAMathews , merci d'avoir clarifié cela. C'est une approche très sensée

@wardpeet est-il vrai que image-nextgen ne prend pas en charge fadeIn="false" ou fadeIn="{false}"

Cela fonctionne beaucoup mieux cependant, est passé de ~ 80 à ~ 95

@MelleNi ce n'est pas le cas, je ne pense pas que ce soit nécessaire mais nous sommes heureux de le considérer.

vous pouvez consulter https://github.com/gatsbyjs/gatsby/discussions/27950 pour voir ce que nous expédions.

@wardpeet comment utiliserait-on @wardpeet/gatsby-image-nextgen avec gatsby-remark-images ? S'agit-il simplement de le désigner comme un plugin dans gatsby-config.js , ou n'est-ce pas possible tant qu'il n'est pas fusionné dans le gatsby monorepo?

Nous allons également déplacer la remarque sur ce plugin :)

@MelleNi ce n'est pas le cas, je ne pense pas que ce soit nécessaire mais nous sommes heureux de le considérer.

vous pouvez jeter un œil à # 27950 pour voir ce que nous expédions.

@wardpeet comment utiliserait-on @wardpeet/gatsby-image-nextgen avec gatsby-remark-images ? S'agit-il simplement de le désigner comme un plugin dans gatsby-config.js , ou n'est-ce pas possible tant qu'il n'est pas fusionné dans le gatsby monorepo?

Nous allons également déplacer la remarque sur ce plugin :)

C'est formidable d'entendre parler de remarque, car j'ai vu beaucoup d'amélioration de la vitesse.

Cependant, j'ai remarqué que je ne pouvais pas obtenir 99-100 sans désactiver le javascript de Gatsby (et réintégrer manuellement des fonctionnalités particulières). Je peux faire fonctionner l'ancienne image Gatsby sans javascript, en utilisant fadeIn={false} , mais pas image-nextgen. (Peut-être que je manque quelque chose, et c'est absolument possible?) Maintenant, sans JavaScript, je ne descends jamais en dessous de 99 sans nextgen.

Je comprends que la désactivation de javascript va à l'encontre de l'idée de Gatsby, mais bon.

Fait intéressant, j'ai vu une amélioration du score de performance mobile (~ 70 à ~ 90) lorsque j'ai arrêté d'utiliser des polices auto-hébergées (fontsource) et que j'ai basculé vers des polices «système».

@wardpeet Avez -vous une chance de partager un exemple de création d'un composant d'image composable avec la direction artistique? Je suis dans le même bateau que @BenjaminSnoha & @davidpaulsson , et cela ne me dérange pas de créer le composant composable dans mon propre projet.

Le plus gros problème que je vois concerne les requêtes des médias et la SSR. Les bibliothèques telles que fresnel fonctionnent, mais souffrent de performances car elles chargent tous les composants, puis nettoient le DOM une fois que le composant window devient disponible.

Sur mon site Web, il semble que toutes les pages créées avec createPage ont le code source (composants markdown et markdown réagissent à l'intérieur du markdown) dans le javascript lourd de vitesse de page (Supprimer le JavaScript inutilisé)

Je viens de lancer Plaiceholder qui peut être utilisé pour créer de purs espaces réservés flous

J'ai créé une version Next.js du Jamify Blog Starter qui obtient de bons résultats avec le dernier Lighthouse 6.4.0:

Vous pouvez inspecter le site de démonstration sur next.jamify.org .

Je publie ceci ici, PAS pour vous suggérer de passer à Next.js. Plutôt, pour apprendre comment la même chose peut être obtenue avec Gatsby. Je pense que les principaux facteurs de succès sont:

• images hautement optimisées (Next réalise cela avec un optimiseur lambda, mais cela peut également être fait avec gatsby-plugin-sharp).
• un simple svg d'espace réservé (de jolis effets comme le flou ralentiront la page).
• utilisation de l'observateur d'intersection pour n'afficher les images qu'en vue (voir suivant / images).
• assurer un chargement paresseux des images.
• petite taille de paquet.

Si vous souhaitez en discuter davantage, vous pouvez me joindre sur Twitter .

@styxlab J'obtiens des résultats légèrement inférieurs dans web.dev/measure

mais mieux dans les résultats de publication, définitivement de très bonnes valeurs dans tous les cas et nettement différentes de la version gatsby https://demo.jamify.org/

Je publierai également que sur un site, j'ai changé gatsby pour 11ty , et les performances se sont améliorées mais pas de façon spectaculaire

(Gatsby)

(conception différente, essentiellement le même contenu, 11ty)

Ou dans une page similaire, cette fois avec une image

(Gatsby)

(conception différente, essentiellement le même contenu, 11ty)

Je dirai que l'expérience du développeur 11ty est très agréable (vous pouvez aussi - expérimentalement utiliser jsx et styled-components ), mais tout js côté client est perdu (vous pouvez l'insérer et vous battre avec webpack, c'est à ce moment que vous manquez Gatsby)

Pendant que j'utilisais 11ty, je pensais aussi à quel point ce serait bien que gatsby ait activé une sorte de stratégie de rendu 11ty afin que l'on puisse déployer des pages statiques mixtes réactives et sans réaction dans un seul cadre ...

des mises à jour à ce sujet? Je n'ai pas d'images et j'obtiens 76 sur les performances en raison du temps total de blocage