Es sieht so aus, als würde Lighthouse 6 einige neue Metriken einführen und einige andere aus Version 5 entfernen, sodass eine Änderung der Punktzahl sicherlich wahrscheinlich ist. Dieser Artikel erklärt, was sich geändert hat:

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

Am Ende befindet sich auch ein Link zu einem Punktezähler, der sehr nützlich ist, um die Punktzahl aufzuschlüsseln und zu verstehen, welche Faktoren am meisten dazu beitragen.

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

Ich habe den Eindruck, dass in Version 6 mehr Wert auf die Interaktivität des Hauptthreads gelegt wird. Wenn Ihre Site also große JS-Bundles enthält, ist dies wahrscheinlich ein wichtiger Faktor.

Ja, @shanekenney , ich bin mir bewusst, aber ich weiß nicht wirklich, wie ich es reduzieren soll, abgesehen davon, dass Teile der Website entfernt werden, um zu sehen, welche Teile dies provozieren

Sehen Sie auch die Auswirkungen auf Gaysbyjs und Theme-UI-Sites? Ich bin neugierig / würde gerne wissen, über welche Optimierungen auf ihrer Website sie nachdenken oder ob sie eine bestimmte Ursache entdeckt haben

Diese Ausgabe ist großartig, damit wir die allgemeinen Lighthouse / PageSpeed ​​Insights-Ergebnisse und die möglichen Regressionen, die wir mit Version 6 sehen, diskutieren können.

@kuworking Eine bemerkenswerte Sache ist, dass lighthouse-metrics.com _ "Emulated Nexus 5X" _ für 5.6 und _ "Emulated Moto G4" _ für 6.0 zu verwenden scheint, was dem Vergleich ebenfalls etwas Rauschen hinzufügen könnte.

Dieser Benchmark über 922 Websites gibt in Version 5 an, dass der mittlere Leistungswert für eine Gatsby-Website 75 beträgt . Ich werde versuchen, mithilfe gehosteter Lösungen eine schnelle Ansicht zu erstellen, um zu verhindern, dass mein lokales Netzwerk ein weiterer Variabilitätsfaktor ist.

Derzeit (mit Lighthouse v5.6 / PageSpeed ​​Insights)

PSI läuft auf einem Moto G4 auf "Fast 3G". Quelle

Bestimmte "Flag" -Sites, die mit Gatsby erstellt wurden, weisen bei PageSpeed ​​Insights (das immer noch Lighthouse v5.6 verwendet, nehme ich an - vorbehaltlich der Standardvariabilität bei jedem Lauf, möglicherweise 3x oder 5x, und die Mittelwertbildung würde zuverlässigere Metriken gewichten ) keine wirklich gute Leistung auf. .

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

Einige andere Websites (und die meisten Starter) schneiden jedoch bei PageSpeed ​​Insights sehr gut ab:

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

Der durchschnittliche TTI ist spürbar - und während v6 das Gesamtgewicht des TTI von 33% auf 15% ändert und den ersten CPU-Leerlauf senkt, fügt es TBT mit einem Gewicht von 25% hinzu, was möglicherweise eine Regression der Punktzahlen erklären könnte, die im Allgemeinen nur aufgrund von Gesamtanalyse und Ausführung von JS.

Lighthouse v6 (mit WebPageTest.org )

• Dies lief WPT auf _Moto G (Gen 4), Moto G4 - Chrome_ mit einer Verbindung von _3G Fast (1,6 MBit / s / 768 KBit / s 150 ms RTT) _. Dies scheint so nah wie möglich an der Übereinstimmung von Gerät / Netzwerk zu sein, bevor PSI die zugrunde liegende Leuchtturmversion aktualisiert.
• Stellen Sie sicher, dass Sie _Capture Lighthouse Report_ unter _Chromium_ überprüfen. Ich habe die Wiederholungsansicht deaktiviert, um den Bereich beim ersten Laden der Seite beim ersten Besuch der Seite beizubehalten.

Hier sind die Ergebnisse. Sie können den Leuchtturmbericht anzeigen, indem Sie auf seine Nummer klicken. Ich extrahiere die Werte aus diesem Bericht.

• gatsbyjs.org (72 -> 67/100, TTI 7,5 s, TBT 2150 ms) Quelle
• reactjs.org (62 -> 66/100, TTI 7.8s, TBT 3520ms) Quelle
• gatsbyjs.com (77 -> 66/100, TTI 8,4 s, TBT 2440 ms) Quelle

Beachten Sie jedoch die Regression an den folgenden beiden Standorten:

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

Einige der offenen Fragen, die ich habe.

1. Wird der Gesamt-TTI (und TBT) durch JS-Parsing + Executing erklärt, oder gibt es andere Faktoren, die die Interaktivität beeinträchtigen?
2. Wenn ja, könnten wir aggressiver sein (entweder standardmäßig bei Gatsby, z. B. bei den letzten Änderungen wie dem Aktivieren granularer Chunks oder unter einem experimentellen Flag), wenn wir die Chunks so erstellen, dass sie nur das senden, was das erste Laden benötigt (dh den App-Hash verhindern) .js von Überschuss)? Es könnte auch einfach sein, Wege zu dokumentieren, um mit der Erweiterung der Webpack-Konfiguration mit mehr Anleitung zu spielen.
3. Könnten Muster wie Module / Nomodule helfen, Chunks zu verringern? Verwendung von @ loadable / components empfehlen / dokumentieren? Teilweise Rehydratation ?
4. Dies mag ein zweiter Schritt sein, um Highscores zu erzielen, aber da FMP kein Faktor mehr ist, hilft oder schadet LQIP auf gatsby-image wenn es um LCP geht? LCP von store.gatsby.org auf dem Lauf oben war 4.7s!

(Ich verwende die obigen Links nur als Beispiele - wenn jemand möchte, dass ein bestimmter Link entfernt wird, kann ich die Nachricht gerne bearbeiten.)

Meine Website (https://matthewmiller.dev/) scheint besser geworden zu sein (~ 92 bis ~ 95), aber einige der neuen Tests zeigen einige Dinge auf, die wahrscheinlich verbessert werden könnten.

Der unnötige JavaScript-Test zum Beispiel,
(Die erste Spalte ist die Größe, die zweite Spalte ist die Menge, die nicht benötigt wird.)

Ich gehe davon aus, dass dies auf Elemente zurückzuführen ist, die für andere Seiten erforderlich sind, die hier enthalten sind. Daher könnte die Verwendung von ladbaren Komponenten etwas hilfreich sein.

Für mich habe ich große Schwierigkeiten, Largest Contentful Paint verstehen, in dem Sinne, dass ich sehr große Werte erhalte, ohne zu wissen warum, und eine Diskrepanz zwischen dem Wert im Bericht (z. B. 7,4 s und dem LCP -Label, das auf der Registerkarte Performance - ViewTrace angezeigt wird (~ 800 ms)

Ich kann sehen, dass im Starter https://parmsang.github.io/gatsby-starter-ecommerce/ etwas Ähnliches zu passieren scheint.

Als Update - scheint PageSpeed ​​Insights das Update für die Ausführung von Lighthouse v6 sanft gestartet zu haben (möglicherweise noch nicht in allen Regionen).

Link zum Testen von https://gatsbyjs.org/ . Derzeit werden Ergebnisse zwischen niedrigen 60ern und mittleren 80ern erzielt, die hauptsächlich von den Werten für TBT und TTI abhängen.

@kuworking Möglicherweise liegt ein Problem mit der Erkennung von Gatsby-Bildern durch Lighthouse v6 vor.

Laut webdev

Bei Bildelementen, deren Größe von ihrer Eigengröße geändert wurde, ist die gemeldete Größe entweder die sichtbare Größe oder die Eigengröße, je nachdem, welcher Wert kleiner ist.

In meinem Fall denke ich, dass Lighthouse die Ansichtsgröße nicht berücksichtigt.

Und hier ist das fragliche Bild

Es könnte für die intrinsische Größe verantwortlich sein, die 3000 Pixel beträgt, daher der 13s LCP für mich.

@ daydream05 Ich hatte ähnliche Theorien und Erkenntnisse, also habe ich meine Seiten ohne Bilder getestet und hatte immer noch einen verrückten langen LCP (10-12 Sekunden). In meinem Projekt ist viel los, daher können es auch andere Variablen sein, aber ich bin gespannt, ob Sie eine Seite mit Textinhalt und noch keinen Bildern getestet haben.

Vor kurzem von 100 auf 79 gefallen ~

Ich werde über weitere Ergebnisse berichten, wenn ich Dinge teste.

Bearbeiten: Drücken Sie 100, wenn Sie typekit-geladene Schriftarten aus dem gatsby-plugin-web-font-loader entfernen (auch unter Verwendung des Preload-Fonts-Cache).

GTM wirkt sich insgesamt ein wenig auf mein Projekt aus, aber es ist keine so drastische Änderung, wenn ich es entferne (5-10 Punkte liegen bei den Ergebnissen unter 50 nach LH6). Ich muss noch mehr testen, wollte das aber nur rauswerfen.

@ Jimmyydalecleveland interessant! Ich habe auch eine andere Seite, auf der der Bildschirm nur Text ist und der den Heldentext als Hauptursache für LCP beschuldigt. Und LCP berücksichtigt nur das, was in Sicht ist, was keinen Sinn ergibt. Wie kann ein Text ein so großes Problem sein?

@dougwithseismic Ich

Ich denke, Lighthouse v6 ist für JS-Frameworks sehr schwierig, da sie die Gewichtung der Ergebnisse verändert haben. (Mehr Fokus auf Blockierungszeit) Und Gatsby-Sites weisen aufgrund von Rehydration und anderen Faktoren historisch niedrige Skriptbewertungs- / Haupt-Thread-Werte auf.

@dougwithseismic Wie haben Sie Typekit-Schriftarten ohne Verwendung des Stylesheets verknüpft?

Ich habe eine ähnliche Erfahrung mit Leuchtturm 5.7.1. Mein Leistungswert betrug ungefähr 91, jedoch hat Leuchtturm 6 meinen Leistungswert dramatisch auf ungefähr 60 gesenkt.

Vor kurzem von 100 auf 79 gefallen ~

Ich werde über weitere Ergebnisse berichten, wenn ich Dinge teste.

Bearbeiten: Drücken Sie 100, wenn Sie typekit-geladene Schriftarten aus dem gatsby-plugin-web-font-loader entfernen (auch unter Verwendung des Preload-Fonts-Cache).

Ich habe nicht einmal diese Plugins installiert, aber meine mobile Punktzahl ist von 90+ auf 60 ~ 70+ gesunken

Hier gilt das gleiche. Massiver Rückgang von 90 auf 60 an mehreren Standorten.

+1 Tropfen von mehr als 30 Punkten

Spricht jemand das an? Es scheint, als hätte es keinen Sinn, Gatsby über Next zu verwenden, wenn es nicht sofort bessere Ergebnisse liefert.

Spricht jemand das an? Es scheint, als hätte es keinen Sinn, Gatsby über Next zu verwenden, wenn es nicht sofort bessere Ergebnisse liefert.

Hast du irgendwelche Nummern von Next?

Ich frage mich, ob diese Ergebnisse die neue Normalität für schnelle Websites sind (die nicht statisch, JS-frei und wahrscheinlich auch bildfrei sind).

Hast du irgendwelche Nummern von Next?

https://nextjs.org/ hat eine Punktzahl von 85, wobei sowohl Largest Contentful Paint (3,8) als auch First Contentful Paint (2,8) die Haupttäter sind. Es hat auch eine Reihe von "Unused JS". Das ist weniger als ~ 95 in Lighthouse 5.7.1. Es ist "nur" ein Rückgang von rund 10 Punkten, während Gatsby-Sites doppelt so viele Punkte zu verlieren scheinen.

Ich bin ziemlich neu auf dieser Welt, aber ich verfolge dieses Problem, nachdem meine Gatsby-Site beim Testen mit Lighthouse 6.0.0 ab npm etwa 25 Punkte verloren hat. Interessanterweise geht meine Website auf etwa 99 zurück, wenn ich die Pagespeed-Einblicke anstelle des npm-Leuchtturms verwende. Während gatsbyjs.org ~ 70 auf Seitengeschwindigkeit Einblicke erhält, aber ~ 84 mit npm Leuchtturm. Irgendwo wird wahrscheinlich etwas optimiert, denke ich? Alle von ihnen erhalten 'Unused JS'-Warnungen

Spricht jemand das an? Es scheint, als hätte es keinen Sinn, Gatsby über Next zu verwenden, wenn es nicht sofort bessere Ergebnisse liefert.

Hast du irgendwelche Nummern von Next?
Ich frage mich, ob diese Ergebnisse die neue Normalität für schnelle Websites sind (die nicht statisch, JS-frei und wahrscheinlich auch bildfrei sind).

Eine Next.js-Website -> https://masteringnextjs.com/ 77 mobile Punktzahl. Viel "Unused JS".

Ich sehe bessere Ergebnisse mit Leuchtturm-Metriken https://lighthouse-metrics.com/one-time-tests/5edfbbb1cf858500080125f7

Aber ich sehe dort auch keine Bilder, und meiner Erfahrung nach scheinen Bilder eine hohe (und legitime IMO) Wirkung zu haben

Gatsbyjs.org hat jedoch keine Bilder und die Punktzahl ist (relativ) schlecht. Https://lighthouse-metrics.com/one-time-tests/5edfbc58cf858500080125ff (im Vergleich zum Beispiel

Mal sehen, was Gatsby-Entwickler darüber denken

Mit ein paar Verbesserungen ist die Website wieder auf dem neuesten Stand.

Es scheint mir ein Fall zu sein, in dem Google die Zielpfosten auf mehr verschiebt
streng in Bezug auf Leistung - insbesondere FCP.

Unsere Websites sind keineswegs langsam, außerdem werden sie nur mit anderen beurteilt
Kriterien. Ich werde in diesem Fall helfen ✌️

Am Di, 9. Juni 2020, 18:48 Uhr kuworking, schrieb [email protected] :

Spricht jemand das an? Es scheint, als hätte es keinen Sinn, Gatsby zu benutzen
Weiter, wenn es nicht sofort bessere Ergebnisse liefert.

Hast du irgendwelche Nummern von Next?
Ich frage mich, ob diese Werte die neue Normalität für schnelle Websites sind (das
sind nicht statisch, JS-frei und wahrscheinlich auch bildfrei)

Eine Next.js-Website -> https://masteringnextjs.com/ 77 mobile Punktzahl. Viel
von "Unused JS".

Ich sehe bessere Ergebnisse mit Leuchtturm-Metriken
https://lighthouse-metrics.com/one-time-tests/5edfbbb1cf858500080125f7

Aber ich sehe dort auch keine Bilder und meiner Erfahrung nach scheinen Bilder
haben eine hohe (und legitime IMO) Wirkung

Gatsbyjs.org hat jedoch keine Bilder und die Punktzahl ist (relativ) schlecht
https://lighthouse-metrics.com/one-time-tests/5edfbc58cf858500080125ff
(im Vergleich zum Beispiel https://github.com/cbdp )

Mal sehen, was Gatsby-Entwickler darüber denken

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-641433463 ,
oder abbestellen
https://github.com/notifications/unsubscribe-auth/ALSIKRH4G74CRN2FNCUO4NDRVZRVNANCNFSM4NHP7XCA
.

Ich wollte nur diesen nützlichen Rechner fallen lassen, um die Ergebnisse von Version 6 mit Version 5 zu vergleichen: https://googlechrome.github.io/lighthouse/scorecalc/

Die Ergebnisse von Leuchttürmen variieren im Allgemeinen stark, selbst wenn sie über PageSpeed ​​Insights verwendet werden. Zum Beispiel habe ich für https://www.gatsbyjs.org/ nach 5 Läufen alles von 64 bis 88 Mobilgeräten erhalten. Um dieses Problem aufzuspüren, kann der Taschenrechner hilfreich sein, um die Konsequenzen unterschiedlicher Gewichte im selben Lauf zu ermitteln (Hinweis: Da die Metriken etwas unterschiedlich sind, müssen einige Werte wie FMP unter Verwendung früherer Messungen angenommen werden).

PS: Hier habe ich einen Vergleich von zwei Läufen von PageSpeed ​​Insights für gatsbyjs.org:
Führen Sie 1 - v6: 67 - v5: 85 aus
Führen Sie 2 - v6: 78 - v5: 87 aus
Die größte Auswirkung wird durch die neue Metrik "Total Blocking Time" verursacht, die in beiden Läufen unter einem Wert von 70 liegt und außerdem ein Gewicht von 25% aufweist.

Ja, um @Pyrax hinzuzufügen: LCP (Largest Contentful Paint) und TBT wiegen in Lighthouse v6 jeweils

LCP

• Entfernen von Animationen, die beim Laden ausgelöst werden könnten (z. B. Cookie 💩 Banner).
• Der Wechsel zu tracedSVG von gatsby-img schien ein wenig zu helfen, da wir auf den meisten Seiten große Heldenbilder haben. (Ich weiß nicht warum, ohne weitere Untersuchung. UX verbessert sich auch ein wenig.)

TBT

• Bei weitem scheint Unused JS aus Gatsbys Bündelung bei weitem der größte Cuplrit (gesichert die Dokumente von

Dieses kürzlich veröffentlichte Lighthouse-Update scheint die Perfektionswerte aller Beteiligten, einschließlich ihrer eigenen, durcheinander gebracht zu haben:

Die einzige Gatsby-Site von mir, die nicht wirklich ausgelöscht wurde, ist eine Site, die im Grunde eine einzelne Seite ist und 99% HTML enthält. Aber selbst dieser fiel um 5-10 Punkte.

Ich sehe das Gegenteil der meisten Leute, das heißt, Lighthouse im Chrome-Browser zeigt immer noch gute Ergebnisse für meine Website an, aber wenn es auf PageSpeed ​​Insights ausgeführt wird, sinkt der Perf-Score um 20 bis 30 Punkte ... vielleicht meine Chrome Lighthouse-Version ist hinter? Chrome ist auf dem neuesten Stand und weiß nicht, wie Sie die integrierte Lighthouse-Version überprüfen sollen ...

Dieses kürzlich veröffentlichte Lighthouse-Update scheint die Perfektionswerte aller Beteiligten, einschließlich ihrer eigenen, durcheinander gebracht zu haben:

Die einzige Gatsby-Site von mir, die nicht wirklich ausgelöscht wurde, ist eine Site, die im Grunde eine einzelne Seite ist und 99% HTML enthält. Aber selbst dieser fiel um 5-10 Punkte.

Ich sehe das Gegenteil der meisten Leute, das heißt, Lighthouse im Chrome-Browser zeigt immer noch gute Ergebnisse für meine Website an, aber wenn es auf PageSpeed ​​Insights ausgeführt wird, sinkt der Perf-Score um 20 bis 30 Punkte ... vielleicht meine Chrome Lighthouse-Version ist hinter? Chrome ist auf dem neuesten Stand und weiß nicht, wie Sie die integrierte Lighthouse-Version überprüfen sollen ...

Die Leuchtturmversion wird am Ende des Audits angezeigt.

@ Dylanblokhuis ah, yep da ist es. Ich bin auf 5.7.1, ist v6 noch nicht in Chrome ausgeliefert?

@ Dylanblokhuis ah, yep da ist es. Ich bin auf 5.7.1, ist v6 noch nicht in Chrome ausgeliefert?

Es ist nicht. Jedenfalls noch nicht. Wenn Sie das Neueste möchten, können Sie es von npm aus installieren und dann lighthouse https://yoursite.com --view ausführen, und Sie erhalten Ihre Punktzahl im gleichen Format, wie Sie es von Chrome Audit gewohnt sind :)

Für alle anderen, die einen großen Punktestand erzielt haben, ist # 24866 möglicherweise ebenfalls relevant. Es hat eine scheinbar ziemlich bedeutende Änderung in der Art und Weise gegeben, wie Gatsby Chunking übergibt. Obwohl die Änderung definitiv sehr sinnvoll erscheint, hat diese Änderung zumindest für uns dazu geführt, dass Code, der über Chunks verteilt wurde, in Chunks commons und app . Dies bedeutet eine deutlich größere Last / Analyse von js.

Das Besorgniserregendste dabei ist, dass sich diese Metriken relativ bald auf den Page Rank auswirken werden.

Ich habe alle Anfragen von Drittanbietern (Tag Manager / Typekit / Pixel / Analytics / ReCaptcha) entfernt, und das gibt nur einen relativ kleinen Punkteschub, sodass etwas anderes im Spiel ist.

Für alle, die Lighthouse 6 lokal ausführen möchten, ist es ab sofort in Chrome Canary erhältlich und wird voraussichtlich im Juli an Chrome ausgeliefert.

Erstens: Ich habe mich mit einem Google-Ingenieur in Verbindung gesetzt, der an web.dev arbeitet, und danach gefragt. Ich bin mir nicht sicher, ob dies zu einer besseren Erklärung führen wird, aber sie scheinen darauf bedacht zu sein, zu helfen. Ich werde nachverfolgen, wenn ich es geschafft habe, mit ihnen zu chatten.

Meine Leistungswerte gingen von 94-99 auf 40-55. 😢

Die größte inhaltliche Farbe für meine Website gilt hauptsächlich für Seiten mit großen Bildern. Aus irgendeinem Grund dauert das Laden der Bilder etwa 14 Sekunden.

Wenn Sie eine der minimalen Gatsby-Starterseiten öffnen, scheinen alle Seiten mit Bildern in den 70er Jahren zu sein.

Hier sind die ersten beiden Vorspeisen, die ich mit vielen Bildern gesehen habe:

ghost.gatsby.org :

gcn.netlify.app :

Der Gatsby-Starter-Blog hat jedoch eine Leistung von 98 (zugegeben, es ist eine super minimale Seite mit nur etwas Text):

gatsbyjs.com :

Vergleichen Sie alte Ergebnisse mit neuen Ergebnissen in Chrome

Sie können die Ergebnisse der alten und der neuen Lighthouse-Methode weiterhin ohne Verwendung der CLI vergleichen. Ich finde es nützlich zu sehen, was sich geändert hat.

Alte Leuchtturmtests anzeigen

Führen Sie zum Anzeigen alter Lighthouse-Ergebnisse die Lighthouse-Chrome-Erweiterung in Ihren Chrome-Entwicklertools anstelle der Browser-Symbolleiste aus.

Neue Leuchtturmtests anzeigen

Klicken Sie in Ihrer Chrome-Erweiterungsleiste auf das Symbol.

Meine Seite ändert sich

Dies sind die beiden Ergebnisse, die ich für genau dieselbe Seite habe:

Alter Leuchtturm (über Chrome Dev Tools)

Neuer Leuchtturm (über Chrome-Erweiterung in der Adressleiste)

🤷‍♂️

@nandorojo Mein Eindruck bei Bildern ist, dass die Emulation mit einer sehr langsamen Verbindung erfolgt und das Rendern von Bildern sehr lange dauert

Da das Entfernen von Bildern nicht immer möglich ist, sind diese 70er-Jahre-Scores möglicherweise die normalen für diesen Seitentyp

Und die Möglichkeit, das Laden zu verzögern, damit der Benutzer seine Interaktion früher starten kann, scheint (in meinem Fall) nicht den Trick zu tun.

Hey, entschuldige die späte Antwort. Ich habe an Lighthouse gearbeitet, ich werde versuchen, es so gut wie möglich zu erklären.

Chrome-Entwickler haben "Web Vitals" veröffentlicht, wesentliche Messdaten für eine gesunde Website. Es enthält viele Metriken, aber die wichtigsten sind LCP (Largest Contentful Paint) , FID (First Input Delay) und CLS (Cumulative Layout Shift) . Bei Tools wie Lighthouse wird FID gegen Total Blocking Time (TBT) ausgetauscht.

Lighthouse v6 berücksichtigt diese Metriken ebenfalls und hat sich verschoben. Das bedeutet nicht, dass Gatsby langsam ist. Möglicherweise sind verschiedene Optimierungen erforderlich.

So haben sich die Dinge verändert:

Wenn Sie mehr über LCP erfahren möchten, besuchen Sie https://www.youtube.com/watch?v=diAc65p15ag.

Reden wir also über Gatsby. Gatsby selbst ist immer noch ziemlich schnell und wir verbessern es noch weiter. Wir erstellen neue APIs, damit Seitenersteller wie MDX, der Rich Text von Contentful, ... das Bundle ebenfalls optimieren können. Durch die Optimierung Ihres LCP kann viel erreicht werden. Stellen Sie sicher, dass Schriftarten und Bilder nicht träge und so schnell wie möglich geladen werden. Diese Assets sollten vom selben Ursprung wie Ihre Site geladen werden. Sie sollten nicht von einem CDN geladen werden.

Leider ist TBT ein schwer zu lösendes Problem, für das React nicht optimiert ist. Wenn Sie TBT löschen möchten, sollten Sie gatsby recipes preact .

Bei der Profilerstellung von gatsbyjs.com & gatsbyjs.org ist mir aufgefallen, dass wir Google Analytics usw. etwas später als jetzt laden sollten, um sicherzustellen, dass es nicht Teil von TBT wird.

Wenn wir uns .com ansehen, indem wir Analytics und GTM verschieben und sicherstellen, dass Schriftarten schneller geladen werden, können wir bereits eine Verbesserung von +17 feststellen. Wenn wir der Mischung Preact hinzufügen, sehen wir +6.

Wir können dasselbe für .org tun, wir beginnen bei einer Punktzahl von 63. Mit einigen Optimierungen von LCP und TBT können wir 75 erreichen.

Ich bin mir nicht sicher, was wir mit diesem Problem anfangen sollen. Ich denke, wir können es schließen, da wir hier nicht viel anderes tun können. Was denkst du alle?

@wardpeet Ty für den zusätzlichen Einblick.

Wir haben uns in einem großen Gatsby-Projekt, das Contentful verwendet und auf mehreren Websites für uns verwendet wird, intensiv mit dieser Angelegenheit befasst (Gatsby-Themen sind fantastisch). Ich werde ein paar Ergebnisse mitteilen, falls sie für andere hilfreich sind, die sich das ansehen.

1. Wir haben eine Situation, die vielleicht nicht sehr häufig ist, aber ich habe sie genug gesehen, um zu glauben, dass sie auch nicht so einzigartig ist. Wir mussten useStaticQuery , um Bilder von Contentful und .find eins durch die Kennung. Wir wussten immer, dass dies falsch war, wurden aber nicht merklich dafür bestraft, bis die Größe der Website auf über 300 Bilder angewachsen war und LH6 zustande kam und uns schlug.

Der Grund dafür ist, dass die Bilder Teil von Rich-Text-Einbettungen sind und wir sie auf Seitenabfrageebene nicht grafisch darstellen können (es handelt sich im Wesentlichen um ein JSON-Feld, das von Contentful analysiert werden muss). Bei der Verwendung von Webpack Bundle Analyzer haben wir eine massive JSON-Datei (ca. 720 KB) festgestellt und sie als Daten aus dieser Abfrage aufgespürt, die in einer Vorlage gruppiert wurde, die wir für die meisten Seiten von Webpack verwenden. Dies bedeutete, dass jeder Benutzer, der unsere Website besuchte, sie als Teil des Blocks für die gesamte Seitenvorlage

Big Woopsie unsererseits, aber wenn jemand andere große statische Abfragen ausführt (an die Sie natürlich keine Parameter übergeben können, um die Größe zu verringern), achten Sie auf diese Situationen und behalten Sie Ihre Bündelstücke im Auge.

1. Wir hatten gerade heute einige Erfolge, als wir die loading Requisite für das Gatsby-Bild für Bilder verwendeten, die über der Falte liegen (Heldenbilder für uns). Wir haben versucht, an Largest Contentful Paint zu arbeiten, und dies hat in einigen ersten Tests zu guten Ergebnissen geführt. Es gibt einen wichtigen Teil, den ich fast übersehen habe: Wenn Sie loading="eager" für Ihr oberstes Bild festlegen, möchten Sie möglicherweise auch fadeIn={false} für dieses Bild festlegen, da der Übergang zwischen base64 und vollständig geladen ist Bild braucht Zeit, was LCP verzögert.

Hier ist die Requisitendokumentation, auf die ich mich beziehe, und der Hinweis zu fadeIn befindet sich unten: https://www.gatsbyjs.org/packages/gatsby-image/#gatsby -image-Requisiten

Ich würde gerne Screenshots teilen, aber ich weiß nicht, ob ich darf, sorry. Wenn Sie Chrome-Devtools verwenden und sich das Leistungsfenster ansehen, erhalten Sie in der Zeile "Timings" nette kleine Tags für FP, FCP, FMP und LCP. Als wir zum kritischen Laden des ersten Bildes übergingen, konnten wir nicht nur eine Leistungssteigerung von ~ 8-10 feststellen, sondern Sie können sehen, dass das LCP-Tag in meinem Fall unmittelbar nach FMP geladen wird, stattdessen etwa eine Sekunde später.

Ich hoffe, das hilft jedem bei der Fehlerbehebung und danke an alle, die bisher geantwortet haben.

Bei der Profilerstellung von gatsbyjs.com & gatsbyjs.org ist mir aufgefallen, dass wir Google Analytics usw. etwas später laden sollten, als wir wissen, um sicherzustellen, dass es nicht Teil von TBT wird.

@wardpeet Wie verschieben Sie Analytics und GTM?

@wardpeet danke für deine Antwort. Es ist nützlich. Die vielleicht beste Ausgabe dieses Problems wäre eine Dokumentation, in der erläutert wird, wie die einzelnen Metriken im neuen Leuchtturm optimiert werden können. Ich bin zuversichtlich, dass sich unsere Website für Benutzer schnell anfühlt und dass Gatsby selbst die Website für echte Benutzer hervorragend optimiert. Wenn jedoch die Web-Vitale von Google den Seitenrang informieren, wird es für die meisten Websites von entscheidender Bedeutung sein, eine gute Leuchtturm-Punktzahl zu erzielen.

@Jimmydalecleveland Wir hatten ein ähnliches Problem, bei dem wir alle Elemente einer Ressource laden mussten, damit wir Daten aus Markdown verwenden konnten, um einen Filtwr zu konfigurieren (dh wir konnten nicht mit GraphQL filtern) und mithilfe verschiedener Fragmente optimiert wurden (a viel kleinere Teilmenge von Feldern) beim Laden einer vollständigen Ressource im Vergleich zum Laden aller Ressourcen zum Filtern. Dies hat unsere JSON und damit unsere Bundle-Größe stark reduziert.

@treyles Sie müssen vorsichtig sein, um das Laden von Analytics zu verzögern, da dies bedeuten kann, dass Ihre Statistiken unvollständig sind. Dies kann beispielsweise bedeuten, dass Ihre gemeldete Absprungrate nicht korrekt ist. Es gibt einige Skripte, die wir durch Marketing nicht verzögern könnten (Pixel, Analytics, Hotjar und damit Tag-Manager), aber andere, z. B. Intercom, sind in Ordnung und eine lohnende Optimierung. In Bezug auf die Verzögerung dieser Skripte werden die von Drittanbietern bereitgestellten Skripte normalerweise asynchron geladen, dies allein reicht jedoch nicht aus. Was Sie wahrscheinlich tun müssen, ist, diese Skripte durch Ihre eigenen zu ersetzen. Warten Sie auf window.load und lösen Sie dann den Download aus. Sie müssen jedoch vorsichtig sein, da einige Skripte zum Initialisieren auf window.load angewiesen sind. Wenn Sie das Skript zum Laden verwendet haben, wird es nicht erneut ausgelöst. Sie müssen sie daher manuell initialisieren. Zum Beispiel mit Intercom wir:

• Der von Intercom bereitgestellte Degault <script>...</script> wurde entfernt.
• fügte einen Listener für window.load
• fügte eine kurze Verzögerung innerhalb dieses Listeners hinzu
• löste eine geänderte Version des Standard-Skripts von Intercom aus, das ihre lib asynchrone Version lud.
• abgefragt, um zu sehen, wann das Skript geladen wurde (Intercom liefert kein zuverlässiges Ereignis)
• Das Skript wurde manuell initialisiert (dies wurde auf page.load mit dem Standard-Skript durchgeführt).

@wardpeet danke für den sehr nützlichen Einblick!

Zu dieser Lösung:

Stellen Sie sicher, dass Schriftarten und Bilder nicht träge und so schnell wie möglich geladen werden. Diese Assets sollten vom selben Ursprung wie Ihre Site geladen werden. Sie sollten nicht von einem CDN geladen werden.

Würde dies nicht gegen die Funktionsweise von Gatsby Image verstoßen? Außerdem übernehmen die meisten CMS die Image-Transformation auf dem Server und werden in ihrem eigenen CDN gehostet. (Was gut ist, imo). Aber wenn wir es auf unserer eigenen Website hosten, wäre das nicht auch kontraproduktiv?

Zusätzlich zu dem, was Seitenranking-Update aufnehmen .

@Jimmydalecleveland Ich habe einen Weg gefunden, mit Gatsby-Bildern im Rich-Text von contentful ohne diesen Abfrage-Hack zu arbeiten! Hier ist das Wesentliche . Der Code wurde von gatsby-source-contentful kopiert. Grundsätzlich können Sie die inhaltliche Flüssigkeit oder feste Requisiten außerhalb von GQL generieren. Welches ist perfekt für den Rich Text von Contentful.

Ich habe auch eine Pull-Anfrage erstellt, damit wir direkt von gatsby-source-contentful auf die APIs zugreifen können.

Etwas passt einfach nicht zu mir. Ich habe eine sehr vereinfachte Website mit ungefähr einem Bild pro Seite erstellt. Ich verwende SVG für Bilder ohne Gatsby-Bild. Ich habe auch versucht, Google Analytics zu entfernen, und das machte keinen großen Unterschied. Meine Punktzahl für die Leistung lag bei 50 bis 60.

Was für mich wirklich rätselhaft ist, ist, dass nur die Homepage (index.js) die sehr niedrige Punktzahl erhält, während andere Seiten wie die Serviceseite oder die Kontaktseite eine Punktzahl von ~ 80 erhalten. Ich habe diese Seite ziemlich konsistent erstellt und daher gibt es keinen großen Unterschied zwischen den Seiten. Aus irgendeinem Grund hat die Startseite eine Punktzahl von ~ 50, während die Serviceseiten eine Punktzahl von ~ 80 haben.

Wie ich bereits erwähnt habe, lag die Punktzahl bei Lighthouse v5 bei ~ 90. Es macht überhaupt keinen Sinn, dass eine einfache Site wie diese jetzt eine niedrige Punktzahl von ~ 50 hat.

Übrigens, hat jemand von euch versucht, das Bild über der Falte auf eager ?
Dies deaktiviert das verzögerte Laden und kann die Punktzahl erhöhen. Die Unschärfe oder SVG
Ladeeffekte können Lighthouse verwirren (was der Fall ist, wenn dies der Fall ist
ein Fehler in ihrem Algorithmus).

Am Samstag, den 13. Juni 2020 um 10:48 Uhr schrieb t2ca [email protected] :

Etwas passt einfach nicht zu mir. Ich habe eine sehr vereinfachte Website erstellt
Mit ungefähr einem Bild pro Seite verwende ich SVG für Bilder ohne Gatsby-Bild.
Ich habe auch versucht, Google Analytics zu entfernen, und das hat nicht viel gebracht
Unterschied, meine Punktzahl war etwa 50 - 60 für die Leistung.

Was mich wirklich verwirrt ist, dass nur die Homepage
(index.js) erhält die sehr niedrige Punktzahl, während andere Seiten wie die
Die Serviceseite oder die Kontaktseite erhalten eine Punktzahl von ~ 80. Ich habe das gebaut
Website ziemlich konsistent und so gibt es keinen großen Unterschied zwischen
Seiten und doch hat die Homepage aus irgendeinem Grund eine Punktzahl von ~ 50, während die
Serviceseiten haben eine Punktzahl von ~ 80.

Wie ich bereits erwähnt habe, lag die Punktzahl bei Lighthouse v5 bei ~ 90
macht überhaupt keinen Sinn, dass eine einfache Site wie diese jetzt einen Tiefpunkt haben würde
Punktzahl von ~ 50.

- -
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-643648423 ,
oder abbestellen
https://github.com/notifications/unsubscribe-auth/AAARLB2Q2IVSNVKGGBZ3ZPDRWOUU5ANCNFSM4NHP7XCA
.

@KyleAMathews Wir haben, und es hat eine signifikante Steigerung der Leistungsbewertung und der ersten Farben gemacht. Dies habe ich in meinem ausführlichen Kommentar oben als Punkt 2 umrissen. Das Abbrechen von fadeIn hat LH schließlich glücklich gemacht.

Bearbeiten : Ich bin wahrscheinlich unwissend der Meinung, dass der Fokus auf LCP nicht der richtige Ansatz ist, um Bilder allgemein zu betrachten. Natürlich anekdotisch, aber ich habe das Gefühl, dass sich eine Website viel schneller anfühlt, wenn der gesamte Inhalt geladen und die Bilder in Nachwörtern eingeblendet werden, es sei denn, das Bild ist für den Inhalt entscheidend.

Ein häufiges Beispiel wäre ein mittlerer Artikel. Sicher, man könnte sagen, dass dies ein Designfehler ist, aber die meisten Artikel von Medium (und viele andere Blogs) beginnen mit einem großen alten Bild oben, das nur zur Schaffung von Stimmung oder Szenerie dient, und es ist mir egal, ob es faul geladen wird .

Übrigens, hat jemand von euch versucht, das Bild über der Falte auf eager ? Dies deaktiviert das verzögerte Laden und kann die Punktzahl erhöhen. Die Unschärfe- oder SVG-Ladeeffekte können Lighthouse verwirren (was in diesem Fall ein Fehler in ihrem Algorithmus ist).
…

Ich werde es jetzt versuchen.

Ich denke, ich habe hier einige gute Fortschritte gemacht. Ich habe meine Punktzahl von 57 auf 84 mit sehr grundlegenden Änderungen erhöht. Mein LCP ging von 12 auf 2 Sekunden .

Das heißt, es ist inkonsistent. Seit ich die Änderungen vornehme, die ich unten beschreibe, variiert meine Punktzahl zwischen 69 und 84. Die Leistungswerte variieren eindeutig zufällig.

TLDR

Zuerst habe ich versucht, wie @KyleAMathews und @Jimmydalecleveland vorgeschlagen haben, loading="eager" und fadeIn={false} für meine Gatsby-Bildkomponenten festzulegen, die sich über der Falte befanden.

Als nächstes habe ich base64 aus meinen Abfragen entfernt.

Diese machten einen großen Unterschied.

Die gute

• Durch Hinzufügen von _noBase64 zu meinen Bildfragmenten stieg meine Punktzahl um 20 Punkte!

  • Es scheint, als würden base64-Bilder auf Mobilgeräten viel Gewicht hinzufügen. Ich frage Bilder von Inhalten mit localFile -> childImageSharp -> fluid -> GatsbyImageSharpFluid_withWebp_noBase64 .

• loading="eager" und fadeIn={false} meine größte Zeit für zufriedenes Malen um etwa 50% verkürzt!

  • Mein tatsächlicher Leistungswert stieg aus irgendeinem Grund nur um 6-7 Punkte, aber LCP macht definitiv Fortschritte ...

Meine Anfrage sieht folgendermaßen aus:

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

Und mein gatsby-image sieht so aus:

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

Je weniger gut

Meine UX auf meiner Website sieht jetzt viel schlechter aus. Das Einblenden der base64 + bot eine großartige UX. Jetzt ist es ein bisschen abgehackt. Ich denke, das ist ein Kompromiss, den wir jetzt berücksichtigen müssen.

Vor und nach eager & fadeIn={false}

Hier finden Sie einige Nebeneinander-Vergleiche genau derselben Seiten. Der einzige Unterschied ist, dass die Bilder rechts loading="eager" und fadeIn={false} .

1. Homepage

LCP um 49% gesunken. Leistungspunktzahl um 6 Punkte.

2. Produktseite

LCP um 46% gesunken. Leistungspunktzahl um 7 Punkte.

Was an diesem Beispiel oben seltsam ist: Die Screenshots auf der linken Seite haben das Standardverhalten von Gatsby-Bildern (sie werden eingeblendet und sie haben nicht eager aktiviert.) Und dennoch, obwohl der Leistungswert niedriger ist Die kleinen Screenshots unten lassen es so aussehen, als würde es schneller geladen als das Bild rechts.

Vielleicht liegt es innerhalb der Fehlergrenze, wie sie die Leistung beurteilen, oder es ist ein Fehler an ihrem Ende, der mit dem Einblenden zusammenhängt, wie @KyleAMathews erwähnte.

Nach dem Setzen von _noBase64 in Bildfragmenten

Hier sind die gleichen Bildschirme wie im obigen Beispiel. Sie haben alle loading="eager" , fadeIn={false} Requisiten auf Gatsby Image. Außerdem sind die Bildfragmente im graqhql GatsbyImageSharpFluid_withWebp_noBase64

Es ist ein bisschen unerklärlich, aber ich führe immer wieder einen Leuchtturmtest auf genau derselben Seite durch und habe 84, 75 und 69.

Ein bisschen komisch, aber auf jeden Fall hat es meine Punktzahl erhöht.

Ich denke, der Lighthouse-Algorithmus fühlte sich hier ungewöhnlich großzügig an

Nach weiteren Untersuchungen hatte ich festgestellt, dass sich der Leuchtturm über ein bestimmtes Element beschwerte, das sich auf den LCP-Score auswirkte.

Ich habe nur dieses Element verschoben, das nur ein Absatz ist, und meine Punktzahl ist über 80 gestiegen. Ich bin mir nicht ganz sicher, warum das Verschieben eines Absatzes meine Punktzahl von ~ 50 auf ~ 80 erhöht hat.

@nandorojo Danke für das gründliche Schreiben. Wir haben nicht versucht, base64 vollständig zu entfernen, wären aber ein Mist, wenn wir müssten. Wir laden auch nur das erste Bild der Seite eifrig. Wenn Sie dies also noch nicht tun, ist es einen Versuch wert, wenn Sie dies kontrollieren können.

Nach weiteren Untersuchungen hatte ich festgestellt, dass sich der Leuchtturm über ein bestimmtes Element beschwerte, das sich auf den LCP-Score auswirkte.

Ich habe nur dieses Element verschoben, das nur ein Absatz ist, und meine Punktzahl ist über 80 gestiegen. Ich bin mir nicht ganz sicher, warum das Verschieben eines Absatzes meine Punktzahl von ~ 50 auf ~ 80 erhöht hat.

@ t2ca Das habe ich bekommen (obwohl meins ein Header-Tag war). Aber wohin hast du es gebracht?

@ t2ca Das habe ich bekommen (obwohl meins ein Header-Tag war). Aber wohin hast du es gebracht?

@michaeljwright Das erste, was ich tat, war, den Absatz zu löschen und die Leuchtturm-Punktzahl zu überprüfen. Nachdem ich den Absatz entfernt hatte, erhöhte sich meine Punktzahl um etwa 20 Punkte. Ich habe den Test viele Male wiederholt, nur um sicherzugehen. Ich habe auch den Absatz zurückgesetzt und weitere Tests durchgeführt, und meine Wunde war wieder geringer.

Schließlich habe ich beschlossen, nur den Absatz zu verschieben. Ich verwende Framer-Bewegung innerhalb eines Div und ich habe den Absatz nur außerhalb des Div verschoben. Dies gibt mir das gleiche Ergebnis wie beim Löschen des Absatzes.

@ t2ca Ich denke, LCP bestraft alle Animationen auf unseren Heldenseiten, was ein Mist ist.

Hier sind meine LCP-Ergebnisse, bei denen das Absatz-Tag das LCP ist

Mit Animation:

Ohne Animation:

@ t2ca Ich denke, LCP bestraft alle Animationen auf unseren Heldenseiten, was ein Mist ist.

Hier sind meine LCP-Ergebnisse, bei denen das Absatz-Tag das LCP ist

Mit Animation:

Ohne Animation:

@ daydream05 Danke für die Bestätigung!

@ daydream05

Würde dies nicht gegen die Funktionsweise von Gatsby Image verstoßen? Außerdem übernehmen die meisten CMS die Image-Transformation auf dem Server und werden in ihrem eigenen CDN gehostet. (Was gut ist, imo). Aber wenn wir es auf unserer eigenen Website hosten, wäre das nicht auch kontraproduktiv?

Nein, da gatsby-image auch mit lokalen Images funktioniert, muss es nicht auf einem anderen CDN gehostet werden. Es kommt darauf an, Ihr erstes Rendering zu optimieren (was sich im Ansichtsfenster befindet). Wenn Sie es auf einer anderen Domain / einem anderen CDN hosten, müssen Sie eine neue Verbindung herstellen (DNS-Auflösung, TL-Handshake, ...). Dies kann auf einem langsamen Gerät bis zu 300 ms dauern, und dann müssen Sie Ihr Image noch herunterladen.

Zusätzlich zu dem, was Seitenranking-Update aufnehmen .

Wir werden Gatsby noch weiter optimieren, um sicherzustellen, dass unsere Benutzer 100 kostenlos erhalten können.

@ t2ca Ich denke, LCP bestraft alle Animationen auf unseren Heldenseiten, was ein Mist ist.

Das wird erwartet, weil Ihr Bildschirm nie aufhört zu malen. Normalerweise sollte LCP CSS-Animationen ignorieren, dies hängt jedoch davon ab, wie Sie die Animationen erstellen.

@ t2ca

Wenn Sie uns die Website zeigen können, können wir Ihnen helfen, herauszufinden, wie Sie sie verbessern können, aber das Bild wird wahrscheinlich eifrig.

@nandorojo

Super Bericht! Gibt es eine Chance, dass Sie uns Links zu diesen Leuchtturmberichten geben können?

Das wird erwartet, weil Ihr Bildschirm nie aufhört zu malen ...

@wardpeet Würde es Ihnen etwas

@DannyHinshaw Ich habe diese Erklärung vom Leuchtturm erhalten
"Ich denke, LCP kümmert sich darum, dass Bilder vollständig geladen werden. Die gemeldete Zeit ist, wenn das Bild vollständig geladen ist und nicht, wenn es zum ersten Mal sichtbar ist. Diese Zeit kann aufgrund progressiver Bilder und iterativer Farben unterschiedlich sein. ""

Und dann dieser Link, vielleicht hilfreich
https://web.dev/lcp/#when -ist-größte-inhaltliche-Farbe-gemeldet

In der Zwischenzeit können Sie auch versuchen, Ihre LCP (Largest Contentful Paint) von einem Bild in Text zu ändern (wenn Sie den Luxus haben), Schriftarten vorzuladen / vorab abzurufen und die Bilder verzögert zu laden. In meinem Fall bedeutete dies, die Größe des Heldenbildes auf dem Handy zu reduzieren, was unsere Punktzahl bis in die oberen 90er Jahre erhöhte, während das Problem diskutiert wird.

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

Das wird erwartet, weil Ihr Bildschirm nie aufhört zu malen ...

@wardpeet Würde es Ihnen etwas

Sicher, ich weiß nicht, um welche Site es sich handelt. Ich habe versucht, URLs in diesem Thread zu finden, aber das war schwierig. LCP berücksichtigt keine CSS-Animationen (Übergang, Animations-Requisiten in CSS). Wenn Sie jedoch Inhalte haben, die setTimeout / setInterval verwenden, um die Reaktionskomponente zu wechseln, wird dies berücksichtigt. Der letztere Ansatz führt zu wirklich schlechten CLS-Werten.

Also, wenn Sie Ihren Heldentext / Bild animieren möchten. Bitte verwenden Sie CSS-Animationen.

Hallo,

Ich habe versucht herauszufinden, warum mein Projekt bei Google Page Speed ​​Insights, Google Lighthouse Audit und mehr so ​​schlecht abschneidet.

Ich bin mir nicht sicher, wo das Problem liegt. Ich habe diesen Starter / dieses Thema verwendet, um loszulegen: https://github.com/alexislepresle/gatsby-shopify-theme

Ich bin meistens dabei, CSS-Dinge wie den Wechsel von Bulma zu Chakra-UI zu ändern.

Dies ist mein Repo: https://github.com/Chizzah/genesis-style
Ich habe versucht, alle Account-Sachen und die Gatsby-Plugin-Appollo-Shopify-Sachen zu entfernen, aber das ändert nichts.

Hier ist der Live-Link: https://genesis-style.netlify.app

Nichts, was ich zu tun scheine, ändert etwas. Ich würde es vorziehen, nicht von vorne anfangen zu müssen. Wenn mir jemand einen Hinweis oder etwas geben kann, werde ich es zu schätzen wissen.

Ich schätze, ich habe mich zu sehr daran gewöhnt, dass Gatsby 90-100 gratis gibt

Vielen Dank für diesen Thread, da eine Diskussion über das Erreichen guter Leuchtturmwerte erforderlich ist. Hervorragende Ergebnisse sind mit Version 6 schwieriger geworden, hauptsächlich aufgrund der neuen LCP-Metrik. Meine Website (https://www.jamify.org) ist mit Lighthouse v6 von ~ 100 auf ~ 70 gesunken.

Um es auf dem Desktop wieder auf 100 zu bringen, musste ich

• Entfernen Sie ein nicht benötigtes Hintergrundbild (da es fälschlicherweise als LCP ausgewählt wurde).
• Optimieren Sie die Größe der Bilder
• Setzen Sie gatsby-image auf loading="eager" und fadeIn=false
  (Das ist wirklich ein Mist, da ich den Unschärfeeffekt mag)

Auf dem Handy stecke ich immer noch auf 80 fest, wieder wegen eines LCP von 5 Sekunden. Dies könnte verbessert werden, indem Bilder speziell für Mobilgeräte richtig dimensioniert werden:

Insgesamt sind diese Optimierungen ziemlich machbar, aber ich bin ziemlich unglücklich, dass ich mich jetzt zwischen Bildern mit verzögertem Laden mit Unschärfe oder einer guten Lighhouse-Punktzahl entscheiden muss: roll_eyes:

Hat jemand schon Tests mit Lighthouse v6.1 durchgeführt? Ich habe eine Verbesserung meiner Leistungsbewertung festgestellt.

Hat Addy von Google nach dem verschwommenen LCP-Problem gefragt und es wird daran gearbeitet, https://twitter.com/addyosmani/status/1277293541878673411 zu beheben

Die Lektion hier ist, die neuen Perf-Scores noch nicht als absolut zu behandeln - sie verfeinern immer noch Randfälle.

Ich glaube, das Problem wird mit Lighthouse 6.1 noch schlimmer. Es gibt hier einige gute Vorschläge rund um LCP, aber wir beschäftigen uns nicht so sehr mit TBT, was meiner Meinung nach der Hauptgrund für schlechte Ergebnisse auf Mobilgeräten und der am schwierigsten zu lösende ist.

Sie können Lighthouse 6.1 in Chrome Canary testen. Ich habe meine Website zwischen 6.0 und 6.1 sowie einige andere hier erwähnte verglichen und die TBT ist drastisch erhöht. Zum Beispiel in meinen 6.1-Tests:

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

Alles über 600 für TBT ist rot und das Gewicht laut Rechner beträgt 25%, also ein wichtiger Faktor. TBT wird durch Funktionen verursacht, deren Ausführung zwischen FCP und Time to Interactive länger als 50 ms dauert.

Der obige Screenshot ist ein Profil von meiner Seite. Wenn Sie Lighthouse in Chrome verwenden, können Sie auf die Schaltfläche Trace anzeigen klicken, um die Ergebnisse auf die Registerkarte Profil zu laden und anzuzeigen. Jede Aufgabe nach dem FCP mit einer roten Flagge in der Ecke zählt für TBT. Ich muss mich noch mit den Aufgaben befassen, also kann vielleicht jemand mit mehr Wissen über Gatsby in diesem Bereich helfen und vielleicht kann @wardpeet seinen Einblick in TBT geben, wenn möglich. Es gibt einige große Aufgaben, die in meinen Tests zwischen 500 ms und 1 s dauern, daher denke ich, dass sie analysiert werden sollten.

@ IanLunn , das ist eine interessante Spur.

Es besteht wahrscheinlich eine Korrelation zwischen dem JS-Wert jeder Gatsby-Site und dem Preis, den sie im Hauptthread des Browsers verursacht. Wie auch immer ich denke, der offene Raum für Diskussionen könnte sein, gibt es eine Möglichkeit, wie Gatsby dazu beitragen kann, die Auswirkungen durch das Laden von Abfragen und Skripten insgesamt zu "mildern"?

Es gibt drei Bereiche, die ich im Moment besser zu verstehen versuche:

• Gatsby fügt standardmäßig <link rel=preload/> für jedes benötigte Skript hinzu (gemäß PRPL-Muster ), unabhängig davon, wie viele vorhanden sind. Ich habe einige Unterschiede im gemessenen FCP festgestellt (was mich ziemlich überrascht hat), aber hauptsächlich in der Lücke zwischen FCP / LCP beim Entfernen dieser (was wahrscheinlich keine gute Idee ist, auf andere Änderungen zu verzichten). In dieser Ausgabe zum Thema Leuchtturm wird Letzteres erörtert.
• Die Abfragen erstellen schließlich JSONs (page-data.json und die gehashten für statische Abfragen), die im Hauptthread ausgewertet werden. Siehe https://github.com/gatsbyjs/gatsby/issues/18787, aber es scheint nicht, dass wir eine Alternative gefunden haben (oder ob es eine gibt), die den Hauptthread nicht blockiert. Je größer die Daten sind, desto größer ist der Leistungseinbruch (daher wären Leistungsbudgets für Abfragegrößen sicherlich sehr willkommen) - aber die Daten werden erst nach dem Rehydratisierungsprozess wirklich benötigt, oder?
• Die tatsächlichen Chunks werden am Ende von </body> als <script src=foo.js async /> hinzugefügt. Dies bedeutet, dass sobald der Browser das Parsen des HTML-Codes beendet hat (was ziemlich bald in der Ablaufverfolgung sein sollte), diese Skripte analysiert und ausgeführt werden (da sie bereits vorinstalliert waren). Lange Aufgaben werden unweigerlich entstehen, wenn der Hauptthread aufgefordert wird, das gesamte Javascript zu analysieren und auszuführen. Gibt es eine bessere Möglichkeit, damit umzugehen (zumindest wenn diese Skripte analysiert werden), um zu vermeiden, dass der Hauptthread blockiert wird? Gibt es eine Möglichkeit, dies (entweder das Parsen oder die Ausführung) in inkrementellen kleinen Aufgaben zu tun, die weder die Eingangsrückmeldung verzögern (und somit TTI schädigen), noch den Haupt-Thread in Zeitabschnitten blockieren (und somit TBT schädigen)?

Während es im Moment wahr ist, dass Gatsby-Sites ein wenig bestraft werden, weil LCP das LQIP-Muster von gatsby-image noch nicht erkannt hat - wenn es um irgendetwas im Zusammenhang mit TBT / TTI geht (und möglicherweise eine erhebliche Bestrafung der Kosten von Javascript im Vergleich zu Lighthouse v5) Ich glaube nicht, dass die Roadmap des Lighthouse-Teams irgendetwas enthält, bei dem sich die Situation gegenüber den aktuellen Ergebnissen verbessern wird.

@juanferreras Die größte Aufgabe scheint domready / ready.js (Drittanbieter) zu sein. Ich habe das Gefühl, dass Ihre Aussage über die Bestrafung von JavaScript durch Lighthouse richtig ist, und obwohl in Gatsby möglicherweise kleine Optimierungen möglich sind, ist dies nicht lösbar.

Wenn es so in Lighthouse sein wird, bin ich versucht, sie zumindest zu bitten, das Gewicht von TBT zu verringern oder die Option zu geben, die gewünschte Testumgebung einzustellen. Das Bereitstellen einer Punktzahl basierend auf einem Budget-Telefon ist für die getestete Site nicht immer geeignet. Wir sollten in der Lage sein, Chefs / Kunden zu zeigen, dass ein Budget-Telefon eine Punktzahl von 75 erhält, ein High-End-Telefon, das 95% unserer Benutzer haben, beispielsweise eine Punktzahl von 90.

• Die Abfragen erstellen schließlich JSONs (page-data.json und die gehashten für statische Abfragen), die im Hauptthread ausgewertet werden. Siehe # 18787, aber es scheint nicht, dass wir eine Alternative gefunden haben (oder ob es eine gibt), die den Hauptthread nicht blockiert. Je größer die Daten sind, desto größer ist der Leistungseinbruch (daher wären Leistungsbudgets für Abfragegrößen sicherlich sehr willkommen) - aber die Daten werden erst nach dem Rehydratisierungsprozess wirklich benötigt, oder?

@juanferreras , in Bezug auf dieses Problem des Parsens von JSON-Daten im Haupt-Thread fällt mir der Web-Worker ein. Gatsby kann einen Web-Worker registrieren, falls dieser auf dem Client verfügbar ist, und diese Art von Dingen puffern. Der Rehydratisierungsprozess wird nicht sofort benötigt, daher ist dies meiner Meinung nach machbar

Web Worker wird in gängigen Browsern einschließlich ie10 unterstützt.

… Wir schauen uns TBT nicht so sehr an, was meiner Meinung nach der Hauptgrund für schlechte Ergebnisse auf Mobilgeräten und der am schwierigsten zu lösende ist.

Ich möchte etwas hinzufügen, das meiner Meinung nach für die Gesamtblockierungszeit relevant ist. Nachdem ich meine Bundles mit dem Webpack Bundle Analyzer überprüft hatte, stellte ich fest, dass Daten aus statischen Abfragen in den JavaScript-Bundles enthalten sind. Ich bin mir sicher, dass es dafür einen guten Grund gibt, aber es funktioniert gegen eine niedrige TBT.

TBT ist ein schwer zu lösendes Problem, insbesondere weil React nicht dafür entwickelt wurde. Der Übergang zum Predigen ist ein guter erster Schritt. Wir werden TBT in den kommenden Monaten immer weiter verbessern. Wir möchten, dass Gatsby einen wirklich kleinen Fußabdruck hat.

In der Gatsby-Version> 2.24.0 haben wir eine verbesserte Polyfill-Unterstützung ausgeliefert, sodass wir Polyfills nur in älteren Browsern wie IE11 laden. Wir haben vor einigen Tagen auch statische Abfragen aus dem Webpack entfernt (@MarkosKon).

@Teclone Leider sind Webworker nicht besonders gut für das JSON-Parsing geeignet. Sie zahlen immer noch den Preis für die Serialisierung und Deserialisierung zwischen Threads. Mit ShardArrayBuffer wäre es eine andere Geschichte, leider sind sie aufgrund von Meltdown / Spectre standardmäßig deaktiviert

Ich habe gerade 100/100 auf alles auf dem eingebauten Lighthouse (6.0) in Chrome bekommen und dann die web.dev-Version (6.1) verwendet und es kam in den 70ern aufgrund von LCP mit Leistung zurück (ungefähr 5-6 Sekunden in 6,1, ungefähr 0,5 Sekunden in 6,0). Es ist ein dekoratives Header-Bild (mit Gatsby-Hintergrundbild), über das es sich beschwert.

Auf meiner eigenen Website hat die Webpack-Laufzeit die höchste Ausführungszeit für Javascript. Etwas, das die Seite erst benötigt, wenn der Benutzer mit der Seite interagiert.

Gatsby scheint nur alle diese Ressourcen (Chunks) auf einmal zu laden. Die js-Datei selbst ist nur sehr klein, es ist ein Loader, Sie können sehen, dass es nur 2 ms dauert, um die Datei zu übergeben. Die Datei selbst lädt jedoch Chunks und Vorlagendateien.

Wenn ich die Chunk-Dateien inspiziere, stelle ich fest, dass es sich bei allen um dynamische Importe handelt. Wir hoffen, dass sie nur geladen werden, wenn sie benötigt werden, aber nein, sie werden standardmäßig alle geladen. Dieses Verhalten ist nicht das, was ich erwarte.

Wir haben unser Header-Bild ein wenig optimiert, z. B. ein Bild direkt anstelle von Gatsby-Image verwendet und die Auflösung und Komprimierung reduziert. Unser Bild ist ein gutes Stück besser. Nur habe ich gerade herausgefunden, wie schwierig es ist, dass Safari WebP (grr) nicht unterstützt. Und es ist weiterhin so, dass die Webversion von Lighthouse viel weniger verzeiht als die in Chrome integrierte, zumindest für unsere "versteckte" Entwicklungsseite. Die Zeit wird zeigen, ob aggregierte Benutzerdaten helfen, sobald sie live sind - ich bin nicht davon überzeugt, dass es in der realen Welt so viele gibt, die Moto G5 verwenden!

@derykmarl Es sollte bald unterstützt werden: https://www.macrumors.com/2020/06/22/webp-safari-14/
Ich verstehe nicht, warum Apple so viel Zeit gebraucht hat, um ein weit verbreitetes Bildformat zu unterstützen ...

Ich habe gelesen, dass pagespeedinsight nachahmt, wie die Punktzahl berechnet wird. Es scheint, dass sie das Netzwerk nicht drosseln, sodass Sie Ihren Bericht schneller erhalten können. Ich persönlich benutze https://lighthouse-metrics.com/, aber sie unterstützen 6.1 noch nicht.

Das Problem mit Lighthouse 6.x ist, dass es auf dem Timing der Wahrnehmung beruht. Sie können denselben Test zehnmal ausführen und haben abhängig von den Netzwerkbedingungen nicht dieselben Ergebnisse.

es kam mit Leistung in den 70er Jahren aufgrund von LCP zurück

Ich hatte ein LCP, das das Hintergrundbild für meine Website war. Ich konnte mein LCP drastisch reduzieren, indem ich das Bild in 6 Teilbilder aufteilte. Ich habe ein Python-Skript erstellt, um dies einfach zu machen, solange Sie die Höhe kennen, die jedes Ihrer Segmente haben soll

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)

Ich fand auch, dass diese Website zur

Ich habe online einige Fragen dazu gestellt und einige Leute empfehlen, mein Bild nur in 2 zu teilen, für oberhalb und unterhalb der Falte, aber ich fand, dass die Aufteilung in 6 viel besser funktioniert.

@wardpeet in der TBT / TTI-Notiz können wir möglicherweise sehen, wie andere

reactjs.org selbst (das meines Wissens auch mit Gatsby erstellt wurde) scheint einen erheblich kleineren TTI (7-8 ~ vs 12 ~) zu haben als das neue gatsbyjs.com (Glückwunsch zum Start übrigens!). NextJS hat auch sehr gute TTI / TBT-Zahlen beibehalten, obwohl es selbst reaktionsbasiert ist (dies kann auch an der relativen Größe der Skripte liegen - wo gatsby.com laut PSI etwa 628,3 KB Skript hat, reatjs.org 466.1kb und nextjs.org nur 216,8 kb)

(Dies ist offensichtlich ein einzelner Lauf und sollte nicht als tatsächlicher Vergleich verwendet werden, aber der Trend ist über mehrere Läufe hinweg ziemlich konsistent).

Ist der größte Teil des Bewertungsunterschieds auf die Gesamtkosten von Javascript ™ zurückzuführen? Wenn das Gatsby-Team die neue Website irgendwann optimiert, ist dies möglicherweise eine großartige Gelegenheit, um einige Einblicke in den Prozess zu erhalten, vorausgesetzt, es bleibt nicht viel Magie übrig, um hinzuzufügen, wie das Gatsby-Framework bereits intern mit Javascript umgeht.

@juanferreras @wardpeet , Es gibt auch etwas, das ich in meinem eigenen Projekt herausgefunden habe. Wenn Sie gestylte Komponenten verwenden, werden Stile aus bestimmten Gründen während der Flüssigkeitszufuhr neu berechnet / regeneriert und erneut in den Browser eingefügt. Dies nimmt einen großen Teil des Hauptthreads in Anspruch.

Dies ist auf Hydratationsprobleme in Gatsby zurückzuführen. https://github.com/styled-components/styled-components/issues/2171

Gatsby arbeitet auch daran, ssr während der Entwicklung auszuführen ( https://github.com/gatsbyjs/gatsby/issues/25729) . Dies hilft dabei, diese Art von Leistungsproblemen zu beseitigen. auch.

@teclone

https://github.com/styled-components/styled-components/issues/2171 scheint keine Lösung zu bieten. Wie haben Sie es in Ihrem Projekt behoben?

@dfguo , im

Das heißt, es gibt kein Konsolenprotokoll von React, das auf Unterschiede während der Rehydratation hinweist, da es in der Produktionsversion von Gatsby deaktiviert ist.

Der Zweck dieser laufenden Arbeit # 25729 besteht darin, eine echte SSR in der Entwicklung auszuführen, sodass wir sehen können, warum. einschließlich des Gatsby-Teams.

Übrigens können Sie eine Gatsby-Site mit gatsby build --no-uglify erstellen, um Ihre Site mit der Entwicklungsversion von React zu erstellen und Protokolle anzuzeigen. https://www.gatsbyjs.com/docs/gatsby-cli/#build

Dev SSR wird in Zukunft für solche Dinge super hilfreich sein!

Daher habe ich beschlossen, meine Website von @emotion und theme-ui auf linaria zu migrieren, während ich den Modus dark-light mit benutzerdefinierten CSS-Variablen implementiere

Das Ziel war es, die Blockierungszeit / den Haupt-Thread / alles, was mit js zu tun hat, zu reduzieren, da jetzt css nicht mehr zur Laufzeit ausgewertet, sondern zur Erstellungszeit kompiliert werden (tatsächlich scheinen linaria viel mehr auf gatsby ausgerichtet zu sein @emotion in dieser Hinsicht)

Der Prozess ist nicht ganz reibungslos, die meisten Dinge, die ich mit @emotion funktionieren nur mit linaria , aber einige andere tun dies nicht und Sie müssen sie neu schreiben und / oder durch benutzerdefiniertes CSS neu implementieren Variablen

Die DX-Erfahrung mit Gatsby ist __bad__, das Hot-Reloading funktioniert nicht (Sie müssen bei jeder Änderung anhalten und erneut starten, da der Browser die Verbindung zu verlieren scheint), aber insgesamt war der Prozess nett, da Sie gezwungen sind, gewissenhafter vorzugehen Benötigen Sie wirklich von

__Das heißt, Leuchtturm Metriken sind sehr ähnlich__

Ich kann die beiden Netlify-Bereitstellungen vergleichen und tatsächlich hat die @emotion Site hohe 70er Jahre und die linaria Site hat niedrige bis mittlere 70er Jahre

Unnötig zu sagen, ich bin nicht sehr aufgeregt

Analyse des Bundles:

• Das Site-Dokument wurde von 14 KB auf 28 KB erhöht
• Das Framework-Skript ist mit 38,7 KB identisch geblieben
• Das App-Skript wurde von 58,2 kb auf 46,1 kb verringert
• Und ein viertes Skript ( component--content.. . Damals 20bae078.. jetzt) ​​ist von 44,2 kb auf 46,8 kb gestiegen

Ich gehe also davon aus, dass die Stile in js zu Stilen in CSS verschoben wurden (und ~ 12 kb sind IMO von Bedeutung), aber dies hatte keine wirklichen Auswirkungen auf die Leuchtturmmetriken (und das ist wichtig, nicht wahr?)

Ich sage also überhaupt nicht, dass ein Wechsel zu linaria keinen Sinn hat. Ich wäre nicht überrascht, wenn jemand dasselbe tut und bessere Ergebnisse erzielt (theoretisch sollte dies der Fall sein (?)). aber in meinen Händen hat sich der Prozess nicht gelohnt

Beim Erkunden des App-Skripts habe ich dennoch eine neue Ausgabe geöffnet, in der versucht wird, herauszufinden, wie das js -Paket https://github.com/gatsbyjs/gatsby/issues/26655 reduziert werden kann

Die DX-Erfahrung mit Gatsby ist schlecht , das Hot-Reloading funktioniert nicht (Sie müssen bei jeder Änderung anhalten und erneut starten, da der Browser die Verbindung zu verlieren scheint), aber insgesamt war der Prozess gut, da Sie gezwungen sind, gewissenhafter vorzugehen Benötigen Sie wirklich von

@kuworking Ich bin auf ein ähnliches Problem gestoßen, habe jedoch festgestellt, dass es nur gatsby Versionen mit 2.24.9 . Ich bin mir nicht sicher, ob die Ursache dieselbe ist, aber ich dachte, es könnte jemandem helfen zu wissen, dass in Ausgabe Nr. 26192 darüber gesprochen wird .

@kuworking Ich bin auf ein ähnliches Problem gestoßen, habe jedoch festgestellt, dass es nur gatsby Versionen mit 2.24.9 . Ich bin mir nicht sicher, ob die Ursache dieselbe ist, aber ich dachte, es könnte jemandem helfen zu wissen, dass in Ausgabe Nr. 26192 darüber gesprochen wird .

Ich bin seit einigen Wochen mit "gatsby": "2.24.14" würde ich sagen, und bisher habe ich dies nur mit linaria erlebt
Aber da ich das weiß, werde ich gatsby nicht aktualisieren, bis dies herausgefunden ist, danke 👍

@kuworking Was ich vorschlagen wollte, ist, dass bei einem Downgrade auf 2.24.9 das Problem mit dem Stoppen des Entwicklungsservers selbst mit linaria . aber das ist nur eine idee. Ich wäre gespannt, ob das der Fall ist.

Die DX-Erfahrung mit Gatsby ist schlecht , das Hot-Reloading funktioniert nicht (Sie müssen bei jeder Änderung anhalten und erneut starten, da der Browser die Verbindung zu verlieren scheint), aber insgesamt war der Prozess gut, da Sie gezwungen sind, gewissenhafter vorzugehen Benötigen Sie wirklich von

Haben Sie versucht, schnell zu aktualisieren ?

Ich habe kürzlich eine Produktions-Gatsby-Site (~ 120 Seiten) migriert, um in der Hoffnung, TBT & LCP zu verbessern, zu predigen. Unsere Website ist svg-schwer mit reaktionsfähigen svg-Komponenten, die mit svgr erstellt und mit Material-UI-Stilen gestaltet wurden. Die durchschnittlichen Leistungsergebnisse lagen im Bereich von + -5 der anfänglichen Punktzahl (~ 45 mobile Leistung von ~ 85 vor Version 6), und obwohl die Migration unter Verwendung des Themas relativ schmerzlos war, war eine Migration zur schnellen Aktualisierung erforderlich nicht.

Ehrlich gesagt ein wenig enttäuscht darüber, dass es neben der generischen Leuchtturmwarnung "Nicht verwendetes Javascript entfernen" keine weiteren Optimierungen gibt, die ich ausprobieren oder detailliertere Messdaten finden kann.

Geschwindigkeit ist einer der Hauptgründe, warum wir uns für Gatsby entschieden haben, und obwohl die Seiten immer noch schnell geladen werden können, ist es aus SEO-Sicht schwer zu rechtfertigen, wenn Ihre Insight-Scores einen so großen Erfolg haben ...

Flüstern: Ich bin zu NextJS gewechselt und bekomme bessere Ergebnisse 🤭

Flüstern: Ich bin zu NextJS gewechselt und bekomme bessere Ergebnisse 🤭

Was ist mit Svelte?

Es wäre gut zu wissen, ob Gatsby-Entwickler diesem in der Roadmap ein bestimmtes Gefühl von Wichtigkeit / Priorität geben (außer dem erwarteten), da ich davon ausgehe, dass es keine unmittelbaren Lösungen gibt, sondern vielleicht eine Art von zukünftigen Richtungen und Implementierungen, auf die man sich konzentriert Dies oder das

Da Gatsby einige Kompilierungen mit gatsby-node * durchführt, frage ich mich, ob sie nach Möglichkeiten suchen, diesen Teil zu vergrößern und den Client-Teil zu entlasten

* Um die pageContext mir verwendeten gatsby-node ) die meisten dieser Daten in json -Dateien und sie bei Bedarf von der Site abzurufen, was die Bundle-Größe verringert, sich aber auch logischer anfühlt

Lassen Sie sich nicht zu sehr auf die Leuchtturm-Partituren ein - besonders wenn sie es sind
gemeint als Benchmark im Vergleich zu anderen Websites und nicht als Ziel, wo wir sollten
bemühen sich um eine perfekte Punktzahl.

Es war nicht bis vor kurzem, dass Gatsby reine 100er nagelte - klar, da
Es gibt einige Probleme zu lösen, aber das SEO-Spiel im Moment ist Geschwindigkeit plus Inhalt
plus Links, und wir haben es abgedeckt.

Meine zwei Cent.

Am Fr, 28. August 2020, 16:57 Uhr kuworking, schrieb [email protected] :

Flüstern: Ich bin zu NextJS gewechselt und bekomme bessere Ergebnisse 🤭

Was ist mit Svelte?

Es wäre gut zu wissen, ob Gatsby-Entwickler dies spezifisch geben
Sinn für Wichtigkeit / Priorität in der Roadmap (anders als erwartet
eins), da ich davon ausgehe, dass es keine unmittelbaren Lösungen gibt, aber vielleicht einige
Art der zukünftigen Richtungen und Implementierungen, die sich auf dieses oder jenes konzentrieren

Da gatsby einige Kompilierungen mit gatsby-node * durchführt, frage ich mich, ob dies der Fall ist
suchen nach Möglichkeiten, diesen Teil zu vergrößern und den Client-Teil zu entlasten

* Um den von mir verwendeten pageContext zu verringern (Daten über alle
Die veröffentlichten Beiträge) speichere ich derzeit (über Gatsby-Node) am meisten
dieser Daten in JSON-Dateien und bei Bedarf von der Site abrufen,
Dies reduziert die Bündelgröße, fühlt sich aber auch logischer an

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-682664232 ,
oder abbestellen
https://github.com/notifications/unsubscribe-auth/ALSIKRHQUIKR5YO6OGA3DC3SC7AWPANCNFSM4NHP7XCA
.

Entschuldigen Sie die verspätete Antwort, es gibt eine Menge, die in die Leistung einfließen, und Lastmetriken sind nur ein kleiner Teil des Puzzles. Wir sind in diesem und im nächsten Quartal motiviert, Gatsby kleiner zu machen und TBT zu reduzieren. Die derzeit größten Probleme sind React Bundle-Größe, MDX, große Seiten (Inhalt / Stil), Tracking-Skripte und Schriftarten / Bilder als Hauptinhalt beim ersten Laden.

Ich beschäftige mich derzeit mit Gatsby-Image- und Analytics-Skripten, um herauszufinden, wie wir die Ladezeit verbessern und die Analyse verschieben können.

Leider kann ich keine Schätzungen abgeben. Wir schauen uns auch unsere .com-Website und unsere Kunden an, um herauszufinden, welche Probleme häufig auftreten, damit wir diese Optimierungen in Gatsby oder in unseren Plugins backen können.

Bearbeiten:

Gerne schaue ich mir einen Ihrer Quellcodes an, um mehr darüber zu erfahren, was Sie alle tun, um zu sehen, wie wir uns verbessern können.

Ich habe einen reddit-Beitrag erstellt, in dem ich versucht habe, alle Verbesserungstipps zusammenzufassen, die ich finden konnte. Wenn Sie weitere Tipps finden können, listen Sie diese bitte auf

Das Entfernen nur des Gatsby-Bildes (Bild des

Bei einigen kürzlich durchgeführten Tests habe ich festgestellt, dass die Verwendung von tracedSVG die Leistungsbewertung von Largest Contentful Paint tatsächlich dramatisch verbessert hat. Ich kann mir vorstellen, dass dies in Lighthouse behoben wird, aber ab sofort geschieht dies, weil das SVG die gleichen Abmessungen wie das Bild mit voller Auflösung hat und daher niemals vom SVG als LCP-Ziel zum Vollbild wechselt.

Bei Verwendung von base64 ist es aufgrund der geringen Auflösung kein Kandidat für LCP. Daher verwendet Lighthouse das Bild mit voller Auflösung, wenn es geladen wird.

Wenn Ihnen das Aussehen der verfolgten SVGs nichts ausmacht (ich persönlich bevorzuge sie), sollten Sie es versuchen.

Warum ist v5 besser als v6? Ich benutze NextJS, das Ergebnis hat sich immer von 60 auf 85 geändert.

+1

Ich habe an einem Gatsby-Image-Nachfolger gearbeitet. Es ist noch nicht zu 100% da, es muss noch eine komponierbare Version geschrieben werden, damit Sie Ihr eigenes Gatsby-Image-Flair erstellen können, aber es wird die meisten schlechten Leuchtturm-Scores beheben.

Sie können es bereits verwenden, aber es ist noch nicht kampferprobt.
https://github.com/wardpeet/gatsby-image-nextgen/tree/main/gatsby-image

Sie können es mit npm install --save @wardpeet/gatsby-image-nextgen installieren. Es gibt eine kompatible Ebene für aktuelle Benutzer von Gatsby-Image .

Dinge, die noch nicht unterstützt werden:

• Die Objektanpassung muss per CSS außerhalb der Komponente erfolgen
• Kunstrichtung

Aktuelle Gatsby-Image-Demo:
Website: https://wardpeet-using-gatsby-image.netlify.app/
Pagespeed-Einblicke: 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/

Neue Gatsby-Image-Nextgen-Demo:
Website: 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 Ihr Pagespeed-Insights-Link für die aktuelle Demo geht an nextgen, sodass die gleichen Ergebnisse angezeigt werden.
Tolle Arbeit, übrigens. Wirklich aufregend, Fortschritte zu sehen.

Danke behoben!

Dieses Update hat mich auf etwas hingewiesen, das ich vorher nicht verbunden habe. Ich verwende nicht gatsby-image sondern tatsächlich gatsby-background-image das anscheinend nicht gatsby-image unter der Haube verwendet ... Ich muss diese Komponente möglicherweise mit diesem neuen @wardpeet/gatsby-image-nextgen umschreiben, wenn das möglich ist ....

Dieser Artikel listet einige zusätzliche Tipps auf: https://www.freecodecamp.org/news/gatsby-perfect-lighthouse-score/, obwohl ich denke, dass viele davon bereits in diesem Thread erwähnt wurden ...

@DannyHinshaw, wenn das Plugin vollständig ist. Ich werde mir auch dieses Plugin ansehen. Ich muss mir auch Bemerkungsbilder ansehen

Ich habe eine neue Version von @wardpeet/gatsby-image-nextgen - 0.0.2 veröffentlicht.

1. minimiert CSS & JS im HTML
2. Laden Sie nur die erforderlichen Bits. Wenn das Laden nativer Bilder aktiviert ist, laden wir nur etwa 2 KB (nicht komprimiert).
3. Stellen Sie sicher, dass der Platzhalter nur beim ersten Laden aufgerufen wird und die zwischengespeicherten Bilder sofort geladen werden
4. Korrektur von Unschärfe-Animationen durch Dekodieren von Async

Ich frage mich, wie viele von Ihnen eine zusammensetzbare Image-Komponente benötigen, mit der Sie Ihren eigenen Wrapper erstellen können, und wie viele von Ihnen tatsächlich Art-Direction verwenden und diese standardmäßig in Gatsby-Image verwenden möchten. Meine erste Idee war, die Funktionalität zu deaktivieren, aber mit dem zusammensetzbaren Gatsby-Image zu aktivieren, sodass Sie Ihre eigene Image-Komponente erstellen müssen, um sie zu unterstützen.

Neueste Demo: https://gatsby-image-nextgen.netlify.app/

@wardpeet Das ist großartig! Ich verlasse mich stark auf die eingebaute Art Direktion von Gatsby-Image. Aber ich denke, ein Beispiel / reibungsloser Upgrade-Pfad wäre auch in Ordnung!

Ich habe immer 99 auf dem Handy jetzt eine 76 erhalten. Alles ist großartig, außer meinem LCP ist es 7.0s und es sagt, es ist mein Heldenbild. Macht keinen Sinn. Wenn ich meine Website auf einem Mobiltelefon aufrufe, ist sie blitzschnell. Die Leute wundern sich, weißt du? Es sagt mir auch, dass ich meine Bilder in Webp oder andere einfügen soll, aber ich habe bereits childImageSharp_withWebp, damit ich es nicht verstehe. Ich fange an, dass Gastby Image und Hintergrundbild bei Leuchtturm und Pagespeedinsight nicht mit dieser neuen Version funktionieren. Mein Verstand ist verwirrt. Ich habe Animationen getötet, alle meine Bilder um die Hälfte verkleinert und keinen einzigen Punkt erreicht. Ich lese das durch und sehe nichts, was mir helfen könnte ... Oh, ich habe nur aufgeschaut ... Ich denke, @wardpeet mein

@davidpaulsson Lust , ein Beispiel zu teilen, wie Sie dies tun? Da mit dem neuen Gatsby-Image weiterhin Art-Direction möglich ist, müssen Sie einige manuelle Schritte ausführen.

@davidpaulsson Lust , ein Beispiel zu teilen, wie Sie dies tun? Da mit dem neuen Gatsby-Image weiterhin Art-Direction möglich ist, müssen Sie einige manuelle Schritte ausführen.

Sicher! Ich benutze es derzeit so

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

return <Img fluid={artDirection} />

@wardpeet Hallo Ward. Könnte blurha.sh für gatsby image nextgen nützlich sein?

@wardpeet Ich habe Ihr Gatsby-Image-Nextgen-Plugin verwendet und es hat meine LCP-Zeit tatsächlich verbessert (von ~ 5s auf ~ 1,5s verringert). Danke dafür!

Wir verwenden jedoch auch Art-Direction, ähnlich wie @davidpaulsson es verwendet, und ich kann nicht scheinen, dass es so funktioniert wie bei Gatsby-Image.

Könnten Sie die manuellen Schritte erläutern, die erforderlich sind, um dies mit dem nextgen-Plugin zu ermöglichen? Danke noch einmal!

@ Jimmyydalecleveland Danke Jimmy! Das Ersetzen von GatsbyImageSharpFluid_withWebp durch GatsbyImageSharpFluid_withWebp_tracedSVG die Leistungsbewertung meiner neuen Gatsby Webiste dramatisch verbessert. Ich habe nicht mehr als 54% bekommen und jetzt mit tracedSVG bekomme ich über 80%. Das ist eine enorme Verbesserung 💯

Bei einigen kürzlich durchgeführten Tests habe ich festgestellt, dass die Verwendung von tracedSVG die Leistungsbewertung von Largest Contentful Paint tatsächlich dramatisch verbessert hat. Ich kann mir vorstellen, dass dies in Lighthouse behoben wird, aber ab sofort geschieht dies, weil das SVG die gleichen Abmessungen wie das Bild mit voller Auflösung hat und daher niemals vom SVG als LCP-Ziel zum Vollbild wechselt.

Bei Verwendung von base64 ist es aufgrund der geringen Auflösung kein Kandidat für LCP. Daher verwendet Lighthouse das Bild mit voller Auflösung, wenn es geladen wird.

Wenn Ihnen das Aussehen der verfolgten SVGs nichts ausmacht (ich persönlich bevorzuge sie), sollten Sie es versuchen.

@abdullahe Wir haben es schon einmal überprüft und es hat eine Abhängigkeit von Canvas und Node-Canvas ist nicht besonders zuverlässig. Zumindest war es nicht in der Vergangenheit. Ich werde dich wissen lassen, wenn wir es uns noch einmal überlegen :)

@guydumais stellen Sie sicher, dass Sie loading="eager" eingeben , damit sich auch Ihre Punktzahl ändert.

@BenjaminSnoha & @davidpaulsson Ich werde gleich ein Beispiel nennen. Das größte Problem bei der Art-Direction, wenn sich das Seitenverhältnis zwischen Bildern ändert, z. B. horizontal zu vertikal.

@wardpeet wie würde man @wardpeet/gatsby-image-nextgen mit gatsby-remark-images ? Geht es darum, einfach als Plugin in gatsby-config.js darauf zu verweisen, oder ist es nicht möglich, bis es mit dem Gatsby Monorepo zusammengeführt wird?

Obwohl dies möglicherweise nichts mit Leuchtturm zu tun hat, frage ich mich, warum JSON-Dateien mit Gatsby-Seitendaten kein Content-Hashing unterstützen, genau wie JS-Dateien.

Ich weiß, dass das Content-Hashing für js-Dateien von Webpack durchgeführt wird, aber gatsby kann dasselbe auch für JSON-Dateien mit Seitendaten tun. Dies kann eine Menge CDN-Netzwerkanforderungen sparen

@teclone page-data.json-Dateien sollten nicht immer wieder heruntergeladen werden, wenn das Caching korrekt eingerichtet ist. Sie werden einmal geladen und dann vom Browser erneut validiert. Das Problem beim Content-Hashing für Seitendaten (im Vergleich zu JS / CSS-Dateien) ist nur, dass es so viele davon gibt. Beim Content-Hashing müssen Sie vor dem Laden einer Datei ein Manifest laden, das von x in x.LONG_HASH da der Hash nicht vorhersehbar ist. Mit JS / CSS ist das Laden eines Manifests sinnvoll, da selbst auf sehr großen Websites nur so viele JS-Dateien vorhanden sind. Bei Seitendaten gibt es jedoch eine pro Seite, sodass das Manifest sehr groß werden kann. Früher haben wir dies getan und auf einer Site mit 10.000 Seiten festgestellt, dass das Manifest bereits ~ 500.000 komprimiert war. https://github.com/gatsbyjs/gatsby/pull/13004

Wenn Sie sehen, dass page-data.json-Dateien immer wieder heruntergeladen werden, überprüfen Sie, ob Sie das Caching in Ihren devtools nicht deaktiviert haben, und überprüfen Sie Ihre Caching-Header unter https://www.npmjs.com/package/check-gatsby-caching

@ KyleAMathews , danke für die Klarstellung. Das ist ein sehr vernünftiger Ansatz

@wardpeet ist es wahr, dass image-nextgen fadeIn="false" oder fadeIn="{false}"

Es funktioniert viel besser, ging von ~ 80 auf ~ 95

@MelleNi nicht, ich denke nicht, dass es notwendig ist, aber wir freuen uns, darüber nachzudenken.

Sie können unter https://github.com/gatsbyjs/gatsby/discussions/27950 nachsehen, was wir versenden.

@wardpeet wie würde man @wardpeet/gatsby-image-nextgen mit gatsby-remark-images ? Geht es darum, einfach als Plugin in gatsby-config.js darauf zu verweisen, oder ist es nicht möglich, bis es mit dem Gatsby Monorepo zusammengeführt wird?

Wir werden auch die Bemerkung zu diesem Plugin verschieben :)

@MelleNi nicht, ich denke nicht, dass es notwendig ist, aber wir freuen uns, darüber nachzudenken.

Sie können einen Blick auf # 27950 werfen, um zu sehen, was wir versenden.

@wardpeet wie würde man @wardpeet/gatsby-image-nextgen mit gatsby-remark-images ? Geht es darum, einfach als Plugin in gatsby-config.js darauf zu verweisen, oder ist es nicht möglich, bis es mit dem Gatsby Monorepo zusammengeführt wird?

Wir werden auch die Bemerkung zu diesem Plugin verschieben :)

Es ist großartig, von einer Bemerkung zu hören, da ich eine große Verbesserung der Geschwindigkeit gesehen habe.

Ich bemerkte jedoch, dass ich 99-100 nicht erhalten konnte, ohne Gatsbys Javascript zu deaktivieren (und bestimmte Funktionen manuell wieder zu integrieren). Ich kann das alte Gatsby-Bild ohne Javascript zum Laufen bringen, indem ich fadeIn={false} , aber nicht image-nextgen. (Vielleicht fehlt mir etwas und es ist absolut möglich?) Jetzt ohne Javascript falle ich ohne nextgen nie unter 99.

Ich verstehe, dass das Deaktivieren von Javascript die Idee von Gatsby zunichte macht, aber na ja.

Interessanterweise stellte ich eine Verbesserung der mobilen Leistungsbewertung fest (~ 70 bis ~ 90), als ich aufhörte, selbst gehostete Schriftarten (Fontsource) zu verwenden, und auf "System" -Schriftarten umstellte.

@wardpeet Gibt es eine Chance, ein Beispiel dafür zu geben, wie eine zusammensetzbare Bildkomponente mit Art Direction erstellt wird? Ich bin im selben Boot wie @BenjaminSnoha & @davidpaulsson und es macht mir nichts aus, die zusammensetzbare Komponente in meinem eigenen Projekt zu erstellen.

Das größte Problem, das ich sehe, ist der Umgang mit Medienabfragen und SSR. Bibliotheken wie Fresnel arbeiten, leiden jedoch unter der Leistung, da sie alle Komponenten laden. Bereinigen Sie dann das DOM, nachdem die Komponente window verfügbar ist.

Auf meiner Website scheinen alle mit createPage erstellten Seiten den Quellcode (Markdown und Markdown reagieren auf Komponenten innerhalb von Markdown) im Javascript mit Seitengeschwindigkeit (nicht verwendetes JavaScript entfernen) zu haben.

Ich habe gerade Plaiceholder gestartet, reine CSS- unscharfe Platzhalter erstellt werden können. Vielleicht wäre das von Interesse? Ich freue mich sehr, mit einem der Kernteams über Optionen für die Weiterleitung zu sprechen

Ich habe eine Next.js-Version des Jamify Blog Starters erstellt , die mit dem neuesten Lighthouse 6.4.0 gut

Sie können die Demo-Site unter next.jamify.org überprüfen .

Ich poste dies hier, NICHT um vorzuschlagen, dass Sie zu Next.js wechseln. Vielmehr um zu lernen, wie das gleiche mit Gatsby erreicht werden kann. Ich denke, die wichtigsten Erfolgsfaktoren sind:

• Hochoptimierte Bilder (Next erreicht dies mit einem Lambda-Optimierer, dies kann jedoch auch mit Gatsby-Plugin-Sharp erfolgen).
• ein einfaches Platzhalter-SVG (nette Effekte wie Unschärfe verlangsamen die Seite).
• Verwendung des Kreuzungsbeobachters, um Bilder nur in der Ansicht anzuzeigen (siehe weiter / Bilder).
• Achten Sie auf ein verzögertes Laden der Bilder.
• kleine Bündelgröße.

Wenn Sie dies weiter diskutieren möchten, können Sie mich auf Twitter erreichen .

@styxlab Ich erhalte etwas niedrigere Ergebnisse in web.dev/measure

aber besser in den Post-Ergebnissen, definitiv sehr gute Werte auf jeden Fall und deutlich anders als die Gatsby-Version https://demo.jamify.org/

Ich werde auch veröffentlichen, dass ich auf einer Website gatsby für 11ty geändert habe und die Leistung sich verbessert hat, aber nicht dramatisch

(Gatsby)

(unterschiedliches Design, im Wesentlichen der gleiche Inhalt, 11ty)

Oder auf einer ähnlichen Seite, diesmal mit einem Bild

(Gatsby)

(unterschiedliches Design, im Wesentlichen der gleiche Inhalt, 11ty)

Ich werde sagen, dass die 11ty Entwicklererfahrung sehr schön ist (Sie können auch - experimentell jsx und styled-components ), aber alle js auf der Client-Seite gehen verloren (Sie kann es einfügen und mit Webpack kämpfen, in diesem Moment vermisst du Gatsby)

Während ich 11ty verwendete, dachte ich auch darüber nach, wie schön es wäre, wenn Gatsby eine Art 11ty-Renderstrategie aktivieren würde, damit man gemischte reaktive und reaktionslose statische Seiten in einem Framework bereitstellen kann ...

irgendwelche Updates dazu? Ich habe keine Bilder und bekomme wegen der Gesamtblockierungszeit 76 auf Leistung