Lighthouse 6はいくつかの新しいメトリックを導入し、v5から他のいくつかを削除しているように見えるので、スコアの変更は確かにありそうです。 この記事では、何が変更されたかについて説明します。

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

スコア計算機へのリンクも最後にあります。これは、スコアを分類し、どの要因が最も貢献しているかを理解するのに非常に役立ちます。

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

v6ではメインスレッドの対話性に重点が置かれているように思われるので、サイトに大きなJSバンドルが含まれている場合、それはおそらく重要な要素です。

はい@shanekenney 、私は知っていますが、サイトの一部を削除してこれを引き起こしている部分を確認する以外に、それを減らす方法を本当に知りません

gaysbyjsやtheme-uiサイトへの影響もわかりますか？ 私は興味があります/彼らが考えているかもしれない彼らのサイトのどの最適化、または彼らがいくつかの特定の原因を見つけたかどうか知りたいです

この問題は素晴らしいので、全体的なLighthouse / PageSpeedインサイトスコアと、v6で見られる可能性のあるリグレッションについて説明できます。

@kuworking注目に値する1つのことは、lighthouse-metrics.comが5.6では_ "Emulated Nexus 5X" _を使用し、6.0では_ "Emulated Moto G4" _を使用しているように見えることです。これも、比較にノイズを追加する可能性があります。

922サイトを超えるこのベンチマークは、v5ではギャツビーサイトのパフォーマンススコアの中央値が75であると主張しています。 ホストされたソリューションを使用してクイックビューを実行し、ローカルネットワークがさらに別の変動要因にならないようにします。

現在（Lighthouse v5.6 / PageSpeed Insightsを使用）

PSIは、「Fast3G」のMotoG4で動作します。 ソース

Gatsbyを使用して構築された特定の「フラグ」サイトは、PageSpeed Insightsで実際に優れたパフォーマンスを発揮していません（これは、Lighthouse v5.6をまだ使用していると思います。実行ごとに標準の変動があり、 3倍または5倍実行され、平均化すると、より信頼性の高いメトリックが重み付けされます） 。

• gatsbyjs.org（Mobile 72/100、TTI 9s）ソース
• reactjs.org（Mobile 62/100、TTI 9.5s）ソース
• gatsbyjs.com（Mobile 77/100、TTI 6.6s）出典

ただし、他のいくつかのサイト（およびほとんどのスターター）は、PageSpeedInsightsで非常に良好に機能しています。

• store.gatsbyjs.org（Mobile 99/100、TTI 2.5s）ソース
• thirdandgrove.com（Mobile 91/100、TTI 4.0s）ソース

平均TTIは顕著です。v6はTTIの全体的な重みを33％から15％に変更し、First CPU Idleを落としましたが、25％の重みでTBTを追加します。これは、一般的に言って、スコアの回帰を説明できる可能性があります。全体的なJSの解析と実行。

Lighthouse v6（ WebPageTest.orgを使用）

• これは、_Moto G（gen 4）、Moto G4-Chrome_で_3GFast（1.6mbps / 768kbps 150ms RTT）_の接続でWPTを実行しました。 これは、PSIが基になる灯台のバージョンを更新する前に取得できるデバイス/ネットワークの一致に
• _Chromium_の下の_CaptureLighthouseReport_を必ず確認してください。 初めての訪問者、ページの最初のロードでスコープを維持するために、リピートビューを無効にしました。

結果は次のとおりです。灯台の番号をクリックすると、灯台のレポートを確認できます。 そのレポートから値を抽出しています。

• gatsbyjs.org（72-> 67/100、TTI 7.5s、TBT 2150ms）ソース
• reactjs.org（62-> 66/100、TTI 7.8s、TBT 3520ms）ソース
• gatsbyjs.com（77-> 66/100、TTI 8.4s、TBT 2440ms）ソース

ただし、次の2つのサイトでのリグレッションに注意してください。

• store.gatsbyjs.org（ 99-> 54/100 、TTI 6.8s、TBT 1300ms）ソース
• thirdandgrove.com（91- > 63/ ソース

私が持っている未解決の質問のいくつか。

1. 全体的なTTI（およびTBT）は、JSの解析と実行によって説明されていますか？それとも双方向性を損なう他の要因がありますか？
2. もしそうなら、私たちはより積極的な可能性があります（デフォルトでギャツビーのいずれかのようなのような最新の変更粒状塊を有効にするか、いくつかの実験的な旗の下で）最初のロードのニーズは（つまりは、APP-、[ハッシュ]を防ぐことを何_のみ_送信するためにチャンクを構築するとき.jsが過剰になることから）？ また、より多くのガイダンスを使用してwebpack構成を拡張する方法を文書化することもできます。
3. Module / nomoduleのようなパターンはチャンクの減少に役立ちますか？ @ loadable / componentsの使用を推奨/文書化しますか？ 部分的な水分補給？
4. これはハイスコアを押し上げるための第2のステップかもしれませんが、FMPはもはや要因ではないので、 gatsby-image LQIPはLCPに関して助けになるのでしょうか、それとも害を及ぼすのでしょうか。 上記の実行でのstore.gatsby.orgのLCPは4.7秒でした！

（上記のリンクを例として使用しています。特定のリンクを削除したい場合は、メッセージを喜んで編集できます）

私のサイト（https://matthewmiller.dev/）は改善されたようです（〜92から〜95）が、新しいテストのいくつかはおそらく改善される可能性のあるいくつかのことを明らかにしています。

たとえば、不要なJavaScriptテスト。
（最初の列はサイズ、2番目の列は不要な量です）

これは、他のページに必要なアイテムがここに含まれているためだと思います。したがって、loadable-componentsのようなものを使用すると少し役立つ場合があります。

私にとって、 Largest Contentful Paintを理解するのLCP Performance - ViewTraceタブに表示されるLCPラベル（〜800ミリ秒）

スターターhttps://parmsang.github.io/gatsby-starter-ecommerce/でも同様のことが起こっているようです

アップデートとして– PageSpeed Insightsは、Lighthouse v6を実行するためのアップデートをソフトローンチしたようです（まだすべての地域にあるとは限りません）。

テストへのリンクhttps://gatsbyjs.org/ 。 現在、主にTBTとTTIの値に応じて、60年代後半から80年代半ばまでさまざまな結果が得られています。

@kuworking Lighthousev6がgatsby-imageを認識する際に問題が発生する可能性があります。

webdevによると

本来のサイズからサイズ変更された画像要素の場合、報告されるサイズは、表示サイズまたは本来のサイズのいずれか小さい方です。

私の場合、Lighthouseはビューサイズを尊重していないと思います。

そして、これが問題の画像です

それは3000ピクセルである固有のサイズを説明している可能性があります。したがって、私にとっては13秒LCPです。

@ daydream05同様の理論と発見があったので、画像なしでページをテストしましたが、それでも非常に長いLCP（10〜12秒）がありました。 私は自分のプロジェクトで多くのことを行っているので、他の変数でもかまいませんが、テキストコンテンツがあり、画像がまだないページをテストしたかどうか知りたいです。

最近、100から79〜https ：//dougsilkstone.com/に削除されました。 Googleタグマネージャー（およびGoogleアナリティクス）を削除すると、最大90にジャンプします。

私が物事をテストするとき、より多くの発見について報告します。

編集：gatsby-plugin-web-font-loaderからtypekitがロードされたフォントを削除するときに100を押します（これもpreload-fontsキャッシュを使用します）。

GTMは全体的に私のプロジェクトに大きな影響を与えていますが、それを削除してもそれほど大きな変化ではありません（LH6以降の50秒未満のスコアで5〜10ポイントがトップになります）。 私はまだもっとテストをする必要がありますが、それをそこに捨てたかっただけです。

@Jimmydaleclevelandおもしろい！ 私はまた、画面がテキストであるという別のサイトを持っており、それはLCPの主な原因としてヒーローのテキストを非難しています。 そして、LCPは、表示されているものだけを考慮しますが、これは意味がありません。 どうしてテキストがそんなに大きな問題になるのでしょうか。

@dougwithseismic私も

Lighthouse v6は、スコアの重み付けをどのように変更したかという点で、JSフレームワークでは非常に難しいと思います。 （ブロッキング時間により重点を置いています）そして、ギャツビーのサイトは、水分補給などのために、歴史的に低いスクリプト評価/メインスレッドスコアを持っています。

@dougwithseismicスタイルシートを使用せずにtypekitフォントをどのようにリンクしましたか？

私は同様の経験をしており、灯台5.7.1のパフォーマンススコアは約91でしたが、灯台6ではパフォーマンススコアが約60に劇的に低下しました。

最近、100から79〜https ：//dougsilkstone.com/に削除されました。 Googleタグマネージャー（およびGoogleアナリティクス）を削除すると、最大90にジャンプします。

私が物事をテストするとき、より多くの発見について報告します。

編集：gatsby-plugin-web-font-loaderからtypekitがロードされたフォントを削除するときに100を押します（これもpreload-fontsキャッシュを使用します）。

これらのプラグインもインストールしていませんが、モバイルスコアが90以上から60〜70以上に低下しました

こっちも一緒。 複数のサイトで90ishから60ishに大幅に減少。

約30ポイント以上の+1ドロップ

誰かがこれに取り組んでいますか？ Gatsby over Nextを使用しても、すぐに良いスコアが得られない場合は意味がないようです。

誰かがこれに取り組んでいますか？ Gatsby over Nextを使用しても、すぐに良いスコアが得られない場合は意味がないようです。

Nextの番号はありますか？

これらのスコアが高速Webの新しい標準であるかどうか疑問に思っています（静的ではなく、JSがなく、画像も含まれていない可能性があります）

Nextの番号はありますか？

https://nextjs.org/のスコアは85で、最大のコンテンツフルペイント（3.8）と最初のコンテンツフルペイント（2.8）の両方が主な違反者です。 また、「未使用のJS」もたくさんあります。 これは、Lighthouse5.7.1の約95から減少しています。 ギャツビーサイトは2倍のポイントを失うようですが、それは約10ポイントの「わずか」な低下です。

私はこの世界にまったく慣れていませんが、npmの灯台6.0.0でテストしたときにgatsbyサイトが約25ポイントを失った後、この問題を追跡しています。 興味深いことに、npm灯台ではなくpagespeedインサイトを使用している場合、私のサイトは約99に戻ります。 gatsbyjs.orgはページスピードの洞察で最大70を取得しますが、npm灯台では最大84を取得します。 おそらくどこかで何かが調整されていると思いますか？ それらのすべてが「未使用のJS」警告を受け取っています

誰かがこれに取り組んでいますか？ Gatsby over Nextを使用しても、すぐに良いスコアが得られない場合は意味がないようです。

Nextの番号はありますか？
これらのスコアが高速Webの新しい標準であるかどうか疑問に思っています（静的ではなく、JSがなく、画像も含まれていない可能性があります）

Next.jsWebサイト-> https://masteringnextjs.com/77モバイルスコア。 「未使用のJS」がたくさん。

lighthouse-metricshttps ：//lighthouse-metrics.com/one-time-tests/5edfbbb1cf858500080125f7でより良いスコアが表示され

しかし、そこには画像も表示されません。私の経験では、画像は高い（そして正当なIMO）影響を与えるようです

まだ、gatsbyjs.orgも画像を有し、そのスコアは（比較的）悪いhttps://lighthouse-metrics.com/one-time-tests/5edfbc58cf858500080125ff （@cbdp例と比較して）

ギャツビーの開発者がこれについてどう思うか見てみましょう

いくつかの調整を加えることで、サイトはトップスコアに戻ります。

グーグルがゴールポストをもっと大きくする場合のように私には思えます
パフォーマンス、特にFCPについて厳密です。

私たちのサイトは決して遅くはありません、それ以上に異なると判断されているだけです
基準。 これを手伝います✌️

2020年6月9日火曜日、18：48 kuworking、 notifications @ github.comは次のように書いています。

誰かがこれに取り組んでいますか？ ギャツビーを使っても意味がないようです
次に、すぐに良いスコアが得られない場合。

Nextの番号はありますか？
これらのスコアが高速Webの新しい標準であるかどうか疑問に思っています（
静的ではなく、JSフリーであり、おそらく画像フリーでもあります）

Next.jsWebサイト-> https://masteringnextjs.com/77モバイルスコア。 たくさん
「未使用JS」の。

灯台メトリクスでより良いスコアが表示されます
https://lighthouse-metrics.com/one-time-tests/5edfbbb1cf858500080125f7

しかし、私もそこに画像を見ていません、そして私の経験では画像は
高い（そして正当なIMO）影響がある

それでも、gatsbyjs.orgには画像がなく、そのスコアは（比較的）悪いです
https://lighthouse-metrics.com/one-time-tests/5edfbc58cf858500080125ff
（ @cbdp https://github.com/cbdpの例と比較して）

ギャツビーの開発者がこれについてどう思うか見てみましょう

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-641433463 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/ALSIKRH4G74CRN2FNCUO4NDRVZRVNANCNFSM4NHP7XCA
。

v6とv5の結果を比較するためのこの便利な計算機を削除したかっただけです： https ：

灯台のスコアは、PageSpeed Insightsで使用する場合でも、一般的に大きく異なります。 たとえば、 https：//www.gatsbyjs.org/の場合、5回の実行後に64から88のモバイルパフォーマンスをすべて受け取りました。 したがって、この問題を追跡するために、計算機は、同じ実行での異なる重みの結果を確認するのに役立つ場合があります（注：メトリックは少し異なるため、FMPなどの一部の値は以前の測定値を使用して想定する必要があります）。

PS：ここにgatsbyjs.orgのPageSpeedInsightsからの2つの実行の比較があります：
実行1-v6：67-v5：85
実行2-v6：78-v5：87
最大の影響は、両方の実行でスコア70を下回り、重みも25％である新しいメトリック「合計ブロッキング時間」によって引き起こされます。

はい、 ます：LCP（Largest Contentful Paint）とTBTの重量はLighthouse v6でそれぞれ

LCP

• ロード時にトリガーされる可能性のあるアニメーション（Cookie💩バナーなど）を削除します。
• ほとんどのページに大きなヒーロー画像があるので、gatsby-imgのtracedSVG切り替えると少し役に立ったようです。 （理由はわかりませんが、さらに調査する必要はありません。UXも少し向上します。）

TBT

• ロングショットでは、ギャツビーのバンドルからのUnused JSは、ロングショットでweb.devのドキュメントをバックアップ）のようです。 ページレベルのツリーシェイクは、ここで確実に改善できますか？

この最近の灯台の更新は、自分自身を含むすべての人のパフォーマンススコアを台無しにしたようです：

私の唯一のgatsbyサイトは、実際には消去されていませんが、基本的に1ページで、99％htmlのようなサイトです。 しかし、それでも約5-10ポイント低下しました。

ほとんどの人の逆が見られます。つまり、ChromeブラウザのLighthouseはまだ私のサイトで良いスコアを示していますが、PageSpeed Insightsで実行すると、パフォーマンススコアが20〜30ポイント低下します...おそらく私のChromeLighthouseバージョン遅れていますか？ Chromeは最新ですが、組み込みのLighthouseバージョンを確認する方法がわかりません...

この最近の灯台の更新は、自分自身を含むすべての人のパフォーマンススコアを台無しにしたようです：

私の唯一のgatsbyサイトは、実際には消去されていませんが、基本的に1ページで、99％htmlのようなサイトです。 しかし、それでも約5-10ポイント低下しました。

ほとんどの人の逆が見られます。つまり、ChromeブラウザのLighthouseはまだ私のサイトで良いスコアを示していますが、PageSpeed Insightsで実行すると、パフォーマンススコアが20〜30ポイント低下します...おそらく私のChromeLighthouseバージョン遅れていますか？ Chromeは最新ですが、組み込みのLighthouseバージョンを確認する方法がわかりません...

灯台のバージョンは、監査の下部に表示されます。

@dylanblokhuisああ、そうだね。 5.7.1を使用していますが、v6はまだChromeに同梱されていませんか？

@dylanblokhuisああ、そうだね。 5.7.1を使用していますが、v6はまだChromeに同梱されていませんか？

そうではない。 とにかくまだ。 最新のものが必要な場合は、npmからインストールしてから、 lighthouse https://yoursite.com --viewを実行すると、Chrome監査で慣れているのと同じ形式でスコアを取得できます:)

スコアで大ヒットした他の人にとっては、＃24866も関連しているかもしれません。 Gatsbyがチャンクを処理する方法に一見かなり重要な変更がありました。 この変更は確かに理にかなっているように見えますが、少なくとも私たちにとっては、この変更により、チャンクに分散されたコードがcommonsとappチャンクに集中するようになりました。 非常に大きなjsロード/解析を意味します。

ここで最も懸念されるのは、これらの指標が比較的早くページランクに影響を及ぼし始めることです。

サードパーティのリクエスト（タグマネージャー/タイプキット/ピクセル/アナリティクス/ ReCaptcha）をすべて削除しましたが、スコアの向上は比較的小さいため、他の何かが機能しています。

また、Lighthouse 6をローカルで実行したい方は、Chrome Canaryで利用可能になり、7月中にChromeに出荷される予定です。

最初に： web.devで作業しているGoogleエンジニアと連絡を取り、これについて質問しました。 それがより大きな説明につながるかどうかはわかりませんが、彼らは助けることに熱心であるようです。 彼らとチャットできたらフォローアップします。

私のパフォーマンススコアは94-99から40-55になりました。 😢

私のウェブサイトの最大のコンテンツフルペイントは、主に大きな画像のあるページに適用されます。 なんらかの理由で、画像の読み込みに14秒ほどかかっているとのことです。

最小限のギャツビースターターサイトのいずれかを開くと、画像のあるページは最大70年代のように見えます。

これが私が多くの画像で見た最初の2つのスターターです：

ghost.gatsby.org ：

gcn.netlify.app ：

ただし、 Gatsbyスターターブログのパフォーマンスは98です（もちろん、テキストがいくつか含まれている非常に最小限のページです）。

gatsbyjs.com ：

Chromeで古いスコアと新しいスコアを比較する

CLIを使用しなくても、古い灯台メソッドと新しい灯台メソッドのスコアを比較できます。 何が変わったのかを見るのは便利だと思います。

古い灯台のテストを見る

古いLighthouseスコアを表示するには、ブラウザのツールバーではなく、ChromeデベロッパーツールからLighthouseChrome拡張機能を実行します。

新しい灯台テストを見る

Chrome拡張機能バーのアイコンをクリックします。

私のページが変わります

これらは、まったく同じページに対して私が持っている2つのスコアです。

古い灯台（Chrome開発ツール経由）

新しい灯台（アドレスバーのChrome拡張機能経由）

🤷‍♂️

@nandorojo画像

画像を削除するオプションが常に可能であるとは限らないため、おそらくこれらの70年代のスコアはこのタイプのページの通常のスコアです。

そして、ユーザーがより早くインタラクションを開始できるようにロードを遅らせるオプションは、トリックを実行していないようです（私の場合）

ねえ、答えが遅れてすみません。 私は灯台に取り組んできました、私はできるだけよく説明しようとします。

Chrome開発者は、健全なサイトに不可欠な指標である「WebVitals」を公開しています。 多くのメトリックが含まれていますが、コアとなるのは、 Largest Contentful Paint（LCP） 、 First Input Delay（FID） 、およびCumulative Layout Shift（CLS）です。 Lighthouse FIDのようなツールの場合、 Total Blocking Time（TBT）と交換されます。

Lighthouse v6もこれらの指標を考慮に入れており、シフトしています。 これはギャツビーが遅いという意味ではありません。 いくつかの異なる最適化が必要な場合があります。

これが状況の変化です。

LCPについて詳しく知りたい場合は、 https：//www.youtube.com/watch？v = diAc65p15agをチェックアウトする必要があり

それでは、ギャツビーについて話しましょう。 ギャツビー自体はまだかなり高速であり、私たちはそれをさらに改善しています。 新しいAPIを作成しているので、MDX、Contentfulのリッチテキストなどのページビルダーもバンドルを最適化できます。 LCPを最適化することで、多くのことができます。 フォントと画像を使用するときは、それらが遅延して読み込まれないようにし、できるだけ早く読み込まれるようにしてください。 これらのアセットは、サイトと同じオリジンからロードする必要があります。CDNからロードしないでください。

悲しいことに、TBTは解決するのが難しい問題であり、Reactが最適化していないものです。 TBTを削除する場合は、 preactをチェックアウトする必要があります。 PreactのAPIはReactと同じですが、JavaScriptのフットプリントが小さくなっています。 それらは異なることをしますが、Reactコンポーネントは互換性があります。 gatsby recipes preact実行してインストールします。

gatsbyjs.comとgatsbyjs.orgをプロファイリングするときに気付いたのは、TBTの一部にならないようにするために、現在よりも少し遅れてgoogleanalyticsなどをロードする必要があるということです。

分析とGTMを延期し、フォントの読み込みが速くなることを確認して.comを見ると、すでに+17の改善が見られます。 preactをミックスに追加すると、+ 6が表示されます。

.orgでも同じことができ、スコアは63から始まります。LCPとTBTを最適化すると、75に到達できます。

この問題をどうすればよいかわかりません。 ここでできることは他にあまりないので、閉じることができると思います。 みなさんはどう思いますか？

追加の洞察のための@wardpeetTy 。

私たちは、Contentfulを使用し、複数のサイトで使用される予定の大きなGatsbyプロジェクトでこの問題を深く掘り下げてきました（Gatsbyのテーマは素晴らしいです）。 これを見ている他の人に役立つ場合に備えて、いくつかの調査結果を共有します。

1. あまり一般的ではないかもしれない状況がありますが、Contentfulと.findからの画像を取得するためにuseStaticQueryを使用しなければならなかったのも、それほどユニークではないと信じるのに十分です。識別子で1 .find 。 私たちはこれが間違っていることを常に知っていましたが、サイトの規模が300以上の画像になり、LH6が登場して私たちを襲うまで、目立って罰せられることはありませんでした。

これは、画像がリッチテキスト埋め込みの一部であり、ページクエリレベルで画像をgraphqlできないためです（Contentfulが解析するパッケージを持っているのは基本的にjsonフィールドです）。 Webpackバンドルアナライザーを使用しているときに、巨大なJSONファイル（約720 KB）に気づき、それをそのクエリからのデータとして追跡しました。これは、Webpackによってほとんどのページで使用するテンプレートにグループ化されました。 これは、画像を使用しているかどうかに関係なく、サイトにアクセスするダウンロードしていることを意味し

私たちの側では大きなウープシーですが、他の誰かが大きな静的クエリを実行している場合（もちろん、サイズを縮小するためにパラメータを渡すことはできません）、それらの状況に注意し、バンドルチャンクに注意してください。

1. スクロールせずに見える範囲の画像（ヒーロー画像）でギャツビー画像にloadingプロップを使用することで、今日はある程度の成功を収めました。 私たちは最大のコンテンツフルペイントに取り組んできましたが、これはいくつかの初期テストで良い結果をもたらしました。 これにはほとんど見逃していた重要な部分があります。一番上の画像にloading="eager"を設定した場合、base64と完全に読み込まれた画像の間の遷移のため、その画像にもfadeIn={false}を設定することをお勧めします。画像には時間がかかり、LCPが遅れます。

これが私が参照している小道具のドキュメントであり、 fadeInに関するメモは下部にあります： https ：//www.gatsbyjs.org/packages/gatsby-image/#gatsby -image-props

スクリーンショットを共有したいのですが、許可されているかどうかわかりません。申し訳ありません。 Chrome devtoolsを使用してパフォーマンスパネルを見ると、FP、FCP、FMP、LCPの「タイミング」行の下に素敵な小さなタグが表示されます。 最初の画像をクリティカルロードに切り替えたとき、パフォーマンススコアが最大8〜10増加しただけでなく、私の場合は1秒ほど後にFMPの直後にLCPタグがロードされたことがわかります。

これがトラブルシューティングに役立つことを願っています。これまでに回答してくれたすべての人に感謝します。

gatsbyjs.comとgatsbyjs.orgをプロファイリングするときに気付いたのは、TBTの一部にならないようにするために、Googleアナリティクスなどを私たちが知っているよりも少し遅れてロードする必要があるということです。

@wardpeet分析とGTMをどのように延期していますか？

@wardpeetお返事ありがとう

@Jimmydalecleveland同様の問題が発生し、リソースのすべてのアイテムをロードして、マークダウン内のデータを使用してフィルターを構成し（つまり、GraphQLを使用してフィルタリングできなかった）、さまざまなフラグメントを使用して最適化する必要がありました（フィルタリングのためにすべてのリソースをロードする場合と、完全なリソースをロードする場合のフィールドのはるかに小さいサブセット）。 これにより、JSONが大幅に削減され、バンドルサイズが大幅に削減されました。

@treylesは、統計が不完全であることを意味する可能性があるため、Analyticsのロードを遅らせるように注意する必要があります。 たとえば、報告された直帰率が正確でないことを意味する場合があります。 マーケティングで遅らせることができないスクリプト（ピクセル、分析、ホットジャー、したがってタグマネージャー）がいくつかありますが、インターコムなどの他のスクリプトは問題なく、最適化する価値があります。 これらのスクリプトを遅らせる方法に関しては、サードパーティによって提供されるスクリプトは通常非同期でロードされますが、これだけでは十分ではありません。 おそらくあなたがする必要があるのは、これらのスクリプトをあなた自身のものに置き換えることです。 window.loadをリッスンしてから、ダウンロードをトリガーします。 一部のスクリプトはwindow.loadに依存して初期化するため、注意が必要です。スクリプトのロードに使用した場合、スクリプトは再度起動されないため、手動で初期化する必要があります。 たとえば、インターコムでは次のようになります。

• Intercomが提供するdegault <script>...</script>削除しました。
• window.loadリスナーを追加しました
• このリスナー内に短い遅延を追加しました
• lib非同期をロードする変更バージョンのIntercomのデフォルトスクリプトをトリガーしました。
• スクリプトがいつロードされたかを確認するためにポーリングされました（インターコムは信頼できるイベントを提供しません）
• スクリプトを手動で初期化しました（これは、デフォルトのスクリプトによってpage.loadで実行されました）。

@wardpeet非常に有用な洞察に感謝します！

このソリューションについて：

フォントと画像を使用するときは、それらが遅延して読み込まれないようにし、できるだけ早く読み込まれるようにしてください。 これらのアセットは、サイトと同じオリジンからロードする必要があります。CDNからロードしないでください。

これはギャツビー画像のしくみに反しませんか？ また、ほとんどのCMSはサーバー上で画像変換を処理し、独自のCDNでホストされます。 （これは良いことです、imo）。 しかし、私たちが自分のサイトでそれをホストする場合、これも逆効果ではないでしょうか？

@Undistractionが言ったことにページランキングの更新にこれが含まれていること。

@Jimmydaleclevelandクエリハックなしでcontentfulのリッチテキスト内のgatsby画像を操作する方法を見つけました！ ここに要点があります。 コードはgatsby-source-contentfulからコピーして貼り付けられました。 基本的に、GQLの外部でコンテンツのある流体または固定小道具を生成できます。 これは、contentfulのリッチテキストに最適です。

また、 gatsby-source-contentfulから直接APIにアクセスできるように、プルリクエストを作成しました。

何かが私のために足し合わないだけです。 1ページあたりの画像数が非常に単純なウェブサイトを構築しました。gatsby-imageのない画像にSVGを使用しています。また、Googleアナリティクスを削除してみましたが、それほど大きな違いはありませんでした。パフォーマンスのスコアは約50〜60でした。

私にとって本当に困惑しているのは、ホームページ（index.js）だけが非常に低いスコアを取得しているのに対し、サービスページや連絡先ページなどの他のページは最大80のスコアを取得していることです。 私はこのサイトをかなり一貫して構築したので、ページ間に大きな違いはありませんが、何らかの理由でホームページのスコアは約50で、サービスページのスコアは約80です。

先に述べたように、灯台v5では、スコアは約90でしたが、このような単純なサイトのスコアが約50と低くなることはまったく意味がありません。

ところで、スクロールせずに見える範囲の画像をeager設定してみた人はいますか？
これにより、遅延読み込みが無効になり、スコアが上がる可能性があります。 ブラーまたはsvg
読み込み効果は灯台を混乱させる可能性があります（その場合はそうです
彼らのアルゴリズムの欠陥）。

土、2020年6月13日、10時48分にはAM T2CA [email protected]は書きました：

何かが私のために足し合わないだけです。 私は非常に単純なウェブサイトを構築しました
1ページあたり約1つの画像で、gatsby-imageのない画像にSVGを使用しています。
私もグーグルアナリティクスを削除しようとしましたが、それはあまり効果がありませんでした
違い、私のスコアはパフォーマンスで約50〜60でした。

私にとって本当に困惑しているのは、ホームページだけだということです
（index.js）は非常に低いスコアを取得していますが、
サービスページまたは連絡先ページのスコアは約80です。 私はこれを作りました
サイトはかなり一貫しているので、間に大きな違いはありません
ページとまだ何らかの理由でホームページのスコアは〜50ですが、
サービスページのスコアは約80です。

先に述べたように、灯台v5では、スコアは約90でしたが、
このような単純なサイトの価格が低くなることはまったく意味がありません
〜50のスコア。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-643648423 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAARLB2Q2IVSNVKGGBZ3ZPDRWOUU5ANCNFSM4NHP7XCA
。

@KyleAMathewsありますが、パフォーマンススコアと最初のペイントが大幅に増加しました。 これは、上記の長いコメントでポイント2として概説したものです。 fadeInをキャンセルすることが、最終的にLHを幸せにした理由です。

編集：私は、おそらく無意識のうちに、LCPに焦点を当てることは、画像に関心を持って普遍的に取る正しいアプローチではないと感じています。 明らかに逸話的ですが、画像がコンテンツにとって重要でない限り、すべてのコンテンツが読み込まれ、画像があとがきでフェードインすると、Webサイトの感触がはるかに速くなると思います。

一般的な例の1つは、中程度の記事です。 確かに、これは設計上の欠陥であると言えますが、ほとんどのMediumの記事（および他の多くのブログ）は、ムードの作成や風景のためだけの大きな古い画像で始まり、遅延読み込みされてもかまいません。 。

ところで、スクロールせずに見える範囲の画像をeager設定してみた人はいますか？ これにより、遅延読み込みが無効になり、スコアが上がる可能性があります。 ブラーまたはsvgの読み込み効果は、Lighthouseを混乱させる可能性があります（その場合、アルゴリズムの欠陥です）。
…

今からやってみます。

私はここでいくつかの良い進歩を遂げたと思います。 非常に基本的な変更を加えて、スコアを57から84に上げました。 私のLCPは12秒から

とはいえ、一貫性はありません。 以下で説明する変更を行ったため、私のスコアは69〜84の範囲で変化します。パフォーマンススコアには明らかにランダムな差異があります。

TLDR

まず、 @ KyleAMathewsと@Jimmydaleclevelandが提案したように、スクロールせずに見える範囲にあるギャツビー画像コンポーネントにloading="eager"とfadeIn={false}してみました。

次に、クエリからbase64を削除しました。

これらは大きな違いを生みました。

いいもの

• 画像フラグメントに_noBase64を追加すると、スコアが20ポイント上がりました

  • base64画像がモバイルで大きな重みを加えているようです。 localFile -> childImageSharp -> fluid -> GatsbyImageSharpFluid_withWebp_noBase64を使用して、コンテンツから画像をクエリしています。

• loading="eager"とfadeIn={false}により、コンテンツフルペイントの最大時間が約50％短縮されました。

  • 私の実際のパフォーマンススコアは、何らかの理由で6〜7ポイントしか上昇しませんでしたが、LCPは確実に進歩しています...

私のクエリは次のようになります。

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

そして私のgatsby-imageは次のようになります：

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

あまり良くない

私のウェブサイトのUXは今ではずっと悪く見えます。 base64 +フェードインは素晴らしいUXを提供しました。 今、それは少し途切れています。 それは私たちが今考慮しなければならないトレードオフだと思いますか？

eager ＆ fadeIn={false}前後

これは、まったく同じページを並べて比較したものです。 唯一の違いは、右側の画像にはloading="eager"とfadeIn={false}です。

1.ホームページ

LCPは49％減少しました。 パフォーマンススコアは6ポイント上昇しました。

2.製品ページ

LCPは46％減少しました。 パフォーマンススコアは7ポイント上昇しました。

上記のこの例の奇妙な点：左側のスクリーンショットはデフォルトのgatsby-image動作を持っています（フェードインし、 eagerオンになりません）。それでも、パフォーマンススコアは低くなりますが、下部の小さなスクリーンショットは、右側の画像よりも速く読み込まれているように見えます。

@KyleAMathewsが述べたように、パフォーマンスの判断方法の

画像フラグメントに_noBase64を設定した後

上記の例と同じ画面があります。 それらはすべてGatsbyImageにloading="eager" 、 fadeIn={false}小道具を持っています。 また、graqhqlの画像フラグメントはGatsbyImageSharpFluid_withWebp_noBase64

少し説明がつかないのですが、まったく同じページで灯台テストを何度も実行していて、84、75、69を取得しました。

ちょっと変ですが、とにかくスコアが上がりました。

灯台のアルゴリズムはここでは異常に寛大だと感じていたと思います笑^

さらに調査したところ、灯台がLCPスコアに影響を与えている特定の要素について不平を言っていることがわかりました。

私がしたのは、段落にすぎないこの要素を移動するだけで、スコアが80を超えました。図を見てください。 段落を移動するとスコアが約50から約80に増加した理由が正確にはわかりません。

@nandorojo徹底的な

さらに調査したところ、灯台がLCPスコアに影響を与えている特定の要素について不平を言っていることがわかりました。

私がしたのは、段落にすぎないこの要素を移動するだけで、スコアが80を超えました。図を見てください。 段落を移動するとスコアが約50から約80に増加した理由が正確にはわかりません。

@ t2caこれは私が得たものです（私のものはヘッダータグでしたが）。 しかし、どこに移動しましたか？

@ t2caこれは私が得たものです（私のものはヘッダータグでしたが）。 しかし、どこに移動しましたか？

@michaeljwright私が最初にしたことは、段落を削除して灯台のスコアを確認することでした。 段落を削除した後、私のスコアは約20ポイント増加しました。 念のため、何度もテストを繰り返しました。 また、段落を元に戻し、さらにテストを行ったところ、痛みは再び軽減されました。

最後に、段落を移動することにしました。div内でフレーマーモーションを使用して、段落をdiv外に移動しました。 これにより、段落を削除したときと同じ結果が得られます。

@ t2ca LCPは、ヒーローページのアニメーションにペナルティを

これが私のLCPスコアです。ここで段落タグはLCPです。

アニメーション付き：

アニメーションなし：

@ t2ca LCPは、ヒーローページのアニメーションにペナルティを

これが私のLCPスコアです。ここで段落タグはLCPです。

アニメーション付き：

アニメーションなし：

@ daydream05確認ありがとうございます！

@ daydream05

これはギャツビー画像のしくみに反しませんか？ また、ほとんどのCMSはサーバー上で画像変換を処理し、独自のCDNでホストされます。 （これは良いことです、imo）。 しかし、私たちが自分のサイトでそれをホストする場合、これも逆効果ではないでしょうか？

いいえ、gatsby-imageはローカルイメージでも機能するため、別のCDNでホストする必要はありません。 それはすべて、最初のレンダリング（ビューポートの内容）を最適化することです。 別のドメイン/ CDNでホストすると、新しい接続を開く必要があります（dns resolve、tls handshakeなど）。低速のデバイスでは最大300ミリ秒かかる場合がありますが、それでもイメージをダウンロードする必要があります。

@Undistractionが言ったことにページランキングの更新にこれが含まれていること。

Gatsbyをさらに最適化して、ユーザーが100を無料で入手できるようにします。

@ t2ca LCPは、ヒーローページのアニメーションにペナルティを

画面のペイントが停止することはないため、これは予想されることです。 通常、LCPはCSSアニメーションを無視する必要がありますが、アニメーションの実行方法によって異なります。

@ t2ca

サイトを見せていただければ、それを改善する方法を見つけるお手伝いをすることができますが、それはおそらくイメージを熱心に設定しているでしょう。

@nandorojo

素晴らしい記事！ それらの灯台レポートへのリンクを教えていただけますか？

画面のペイントが停止しないため、これは予想されることです...

@wardpeetこれを拡張して

@DannyHinshaw灯台からこの説明を受けました
「私が考えているのは、LCPは画像が完全に読み込まれることを考慮しており、報告される時間は画像が最初に表示されるときではなく、完全に読み込まれるときです。この時間は、プログレッシブ画像と反復ペイントによって異なる場合があります。 「」

そして、おそらく助けになるこのリンク
https://web.dev/lcp/#when -is-largest-contentful-paint-reported

それまでの間、最大コンテンツペイント（LCP）を画像からテキストに変更し（贅沢な場合）、フォントをプリロード/プリフェッチし、画像を遅延ロードすることもできます。 私の場合、それはモバイルでのヒーロー画像のサイズを縮小することを意味し、問題が議論されている間、スコアを90年代後半に戻しました。

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

画面のペイントが停止しないため、これは予想されることです...

@wardpeetこれを拡張して

確かにこれがどのサイトかはわかりません。このスレッドでURLを見つけようとしましたが、それは大変でした。 LCPは、CSSアニメーション（トランジション、cssのアニメーション小道具）を考慮していません。 ただし、反応コンポーネントを切り替えるsetTimeout / setIntervalを使用するコンテンツがある場合は、それが考慮されます。 後者のアプローチでは、CLSスコアが非常に悪くなります。

したがって、ヒーローのテキスト/画像をアニメーション化する場合。 cssアニメーションを使用してください。

こんにちは、

私は、自分のプロジェクトがGoogle Page Speed Insights、GoogleLighthouse監査などで非常に低いスコアを付けている理由を理解しようとしました。

ゼロから始める以外に、何が問題なのかわかりません。 私はこのスターター/テーマを使用して開始しました： https ：

私は主に、ブルマからチャクラUIに移行するようなCSSを変更する過程にあります。

これは私のリポジトリです： https ：
アカウントのものとgatsby-plugin-appollo-shopifyのものをすべて削除しようとしましたが、変更はありません。

これがライブリンクです： https ：

私がしているように見えることは何も変わりません。 ゼロから始める必要はありません。 誰かが私にヒントや何かを与えることができれば私はそれを感謝します。

ギャツビーが90-100を無料で提供することに慣れすぎたと思います

良い灯台スコアを達成するための議論が必要なので、このスレッドに感謝します。 主に新しいLCPメトリックが原因で、v6では優れたスコアがより困難になっています。 私のサイト（https://www.jamify.org）は、Lighthouse v6で約100から約70に低下しました。

デスクトップで100に戻すには、

• 不要な背景画像を削除します（LCPとして誤って選択されたため）
• 画像のサイズを最適化する
• gatsby-imageをloading="eager"およびfadeIn=false
  （ブラーアップ効果が好きなので、それは本当に残念です）

モバイルでは、LCPが5秒であるため、まだ80のままです。 これは、特にモバイル用に画像のサイズを適切に設定することで改善できます。

全体として、これらの最適化はかなり実行可能ですが、ブラーアップのある遅延読み込み画像または良好なLighhouseスコアのいずれかを選択する必要があることに非常に不満です：roll_eyes：

灯台v6.1でまだテストを行った人はいますか？ パフォーマンススコアの改善に気づきました。

グーグルからアディにぼやけたLCPの問題について尋ねました、そしてそれは彼らが修正するために取り組んでいるものですhttps://twitter.com/addyosmani/status/1277293541878673411

ここでの教訓は、新しいパフォーマンススコアをまだ絶対的なものとして扱わないことです。それらはまだエッジケースを洗練しています。

Lighthouse6.1では問題が悪化すると思います。 LCPを取り巻くいくつかの良い提案がありますが、モバイルでのスコアが悪い最大の理由であり、解決が最も難しいと思うTBTについてはあまり検討していません。

Lighthouse6.1はChromeCanaryでテストできます。 私は自分のサイトを6.0と6.1、およびここで言及した他のいくつかと比較しましたが、TBTは大幅に増加しています。 たとえば、私の6.1テストでは：

• gatsbyjs.org TBT：2550ms
• 私のサイトTBT：2200ms
• @styxlabサイトTBT：1250ミリ秒

TBTの600を超えるものはすべて赤で、計算機によると重量は25％なので、主要な要因です。 TBTは、FCPとTime toInteractiveの間で実行するのに50ミリ秒以上かかる関数が原因で発生します。

上のスクリーンショットは私のサイトのプロフィールです。 ChromeでLighthouseを使用している場合は、[トレースの表示]ボタンをクリックして、結果を[プロファイル]タブに読み込んで同じものを表示できます。 隅に赤い旗が付いたFCP後のタスクは、TBTにカウントされます。 私はまだタスクが何であるかを掘り下げていないので、ギャツビーの知識が豊富な誰かがこの分野で支援でき、

@IanLunnは興味深いトレースですが、これらのタスクが何の下にあるのかを理解できましたか？

各ギャツビーサイトのJSの量と、ブラウザーのメインスレッドでのJSのコストには相関関係がある可能性があります。 しかし、議論の余地はあると思いますが、ギャツビーがクエリとスクリプトを完全にロードする方法によって影響を「軽減」するのに役立つ方法はありますか？

私が現時点でよりよく理解しようとしている3つの領域があります：

• Gatsbyは、スクリプトの数に関係なく、必要なスクリプトごとに（ PRPLパターンに従って）デフォルトで<link rel=preload/>を追加します。 測定されたFCPにいくつかの違いがあることに気づきました（これにはかなり驚いていました）が、これらを削除したときのFCP / LCP間のギャップにほとんどあります（おそらく、他の変更なしで行うのは賢明な考えではありません）。 灯台に関するこの号では、後者について説明しています。
• クエリは、メインスレッドで評価されるJSON（page-data.jsonおよび静的クエリのハッシュ化されたもの）を作成することになります。 https://github.com/gatsbyjs/gatsby/issues/18787を参照してください、クエリサイズのパフォーマンスバジェットは非常に歓迎
• 実際のチャンクは、 </body>の最後に<script src=foo.js async />として追加されます。 これは、ブラウザがHTMLの解析を終了するとすぐに（トレースにすぐに含まれるはずです）、それらのスクリプトの解析と実行を開始することを意味します（スクリプトはすでにプリロードされているため）。 メインスレッドがすべてのJavaScriptを解析して実行するように要求されるため、長いタスクが必然的に発生します。 メインスレッドのブロックを回避するために、これを処理するためのより良い方法はありますか（少なくともそれらのスクリプトが解析され始めたとき）？ 入力フィードバックを遅らせたり（したがってTTIに害を与えたり）、メインスレッドを時間の塊でブロックしたり（したがってTBTに害を与えたり）しない増分の小さなタスクでこれ（解析または実行のいずれか）を行う方法はありますか？

現時点では、LCPがgatsby-imageからのLQIPパターンをまだ認識していないため、ギャツビーサイトは少しペナルティを受けていますが、TBT / TTIに関連するもの（およびおそらくコストに対する大きなペナルティ）については灯台v5と比較したJavascript）灯台チームのロードマップには、現在のスコアから状況が改善されるものは何もないと思います。

@juanferreras最大のタスクはdomready / ready.js（サードパーティ）のようです。 灯台がJavaScriptにペナルティを科すというあなたの発言は正しいと思います。ギャツビーでは小さな最適化が可能かもしれませんが、それは解決できるものではありません。

これがLighthouseでの予定である場合、少なくともTBTの重量を減らすか、目的のテスト環境を設定するオプションを提供するように依頼したいと思います。 予算の電話に基づいてスコアを提供することは、テストされるサイトにとって常に適切であるとは限りません。 たとえば、予算の電話は75のスコアを取得しますが、ユーザーの95％が持っているハイエンドの電話は90のスコアを取得することを上司/クライアントに示すことができるはずです。

• クエリは、メインスレッドで評価されるJSON（page-data.jsonおよび静的クエリのハッシュ化されたもの）を作成することになります。 ＃18787を参照してください。ただし、メインスレッドをブロックしない代替手段は見つかっていないようです（またはある場合）。 データが大きいほど、パフォーマンスへの影響が大きくなります（したがって、クエリサイズのパフォーマンスバジェットは非常に歓迎

@juanferreras 、メインスレッドでjsonデータを解析するこの問題に関して、頭に浮かぶのはWebワーカーです。 Gatsbyは、クライアントで利用可能な場合はWebワーカーを登録し、これらの種類のものをそれにバッファリングできます。水分補給プロセスはすぐには必要ないので、これは実行可能だと思います。

Webワーカーは、ie10を含む主要なブラウザーでサポートされています。

…私たちはTBTをあまり見ていません。これが、モバイルでのスコアが悪い最大の理由であり、解決するのが最も難しいと思います。

Total BlockingTimeに関連すると思われるものを追加したいと思います。 Webpackバンドルアナライザーでバンドルを確認したところ、静的クエリのデータがJavaScriptバンドルに含まれていることに気付きました。 それには正当な理由があると確信していますが、それは低いTBTに対して機能します。

TBTは、特にReactがそのために構築されていないため、解決するのが難しい問題です。 preactへの移行は良い第一歩です。 今後数か月でTBTをますます改善する予定であり、ギャツビーのフットプリントを非常に小さくしたいと考えています。

gatsbyバージョン> 2.24.0では、改良されたポリフィルサポートが出荷されたため、IE11などのレガシーブラウザにのみポリフィルをロードします。 また、数日前にwebpackから静的クエリを削除しました（@MarkosKon）。

@Teclone悲しいことに、WebworkersはJSON解析には適していません。 スレッド間でシリアル化および逆シリアル化するための代償を支払う必要があります。 ShardArrayBufferを使用すると、話は別になります。残念ながら、 Meltdown / spectreのためにデフォルトで無効になっています。

Chromeに組み込まれているLighthouse（6.0）のすべてで100/100をうまく取得してから、web.devバージョン（6.1）を使用しましたが、LCPにより70年代にパフォーマンスが回復しました（約5〜6秒で6.1、6.0では約0.5秒）。 不満を言っているのは、装飾的なヘッダー画像（gatsby-background-imageを使用）です。

私自身のWebサイトを見ると、WebpackランタイムのJavaScript実行時間が最も長くなっています。 ユーザーがページの操作を開始するまで、ページが必要としないもの。

Gatsbyは、これらすべてのリソース（チャンク）を一度にロードするようです。 jsファイル自体は非常に小さく、ローダーです。ファイルを渡すのに2ミリ秒かかることがわかります。 ただし、ファイル自体はチャンクとテンプレートファイルをロードします。

実際、チャンクファイルを調べると、すべてが動的インポートであることがわかりました。必要な場合にのみロードされることを望んでいますが、デフォルトですべてロードされます。 この動作は私が期待するものではありません。

Gatsby-Imageではなく画像を直接使用し、解像度と圧縮を減らすなど、ヘッダー画像をかなり最適化しました。私たちの方がかなり優れています。 ただ、SafariがWebP（grr）をサポートしないという難しい方法を発見したばかりです。 そして、少なくとも私たちの「隠された」開発サイトでは、LighthouseのWebバージョンはChromeに組み込まれているものよりもはるかに寛容ではないというケースが続いています。 集約されたユーザーデータが公開された後、役立つかどうかは時が経てばわかります。現実の世界でMotoG5を使用している人がそれほど多くいるとは思いません。

@derykmarlまもなくサポートされる予定です： https ： //www.macrumors.com/2020/06/22/webp-safari-14/
Appleが広範囲の画像フォーマットをサポートするのにそれほど時間がかかった理由がわかりません...

pagespeedinsightがスコアの計算方法をエミュレートしていることを読みました。 彼らはネットワークを抑制していないようですので、あなたはあなたのレポートをより速く得ることができます。 私は個人的にhttps://lighthouse-metrics.com/を使用してい

lighthouse 6.xの問題は、知覚のタイミングに依存していることです。同じテストを10回実行でき、ネットワークの状態によっては同じ結果が得られません。

LCPにより70年代のパフォーマンスで復活しました

ウェブサイトの背景画像であるLCPを持っていたので、画像を6つのサブ画像に分割することで、LCPを大幅に削減することができました。 各セグメントの高さを知っている限り、これを簡単に実行できるようにPythonスクリプトを作成しました。

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)

また、この画像圧縮Webサイトは、品質をあまり損なうことなく画像のサイズを縮小するのに非常に適していることがわかりました。 通常、20％〜30％の品質マークまで下げて、ファイルサイズを大幅に削減することができました。

私はこれについてオンラインでいくつか質問しました。スクロールせずに見える範囲とスクロールせずに見える範囲で画像を2つに分割することを勧める人もいますが、6つに分割するとはるかにうまく機能することがわかりました。

TBT / TTIノートの@wardpeetでは、

reactjs.org自体（私が知る限りGatsbyで構築されています）は、新しいgatsbyjs.comよりもかなり小さいTTI（7-8〜対12〜）を持っているようです（ちなみに、起動おめでとうございます！）。 NextJSは、Reactベースであるにもかかわらず、TTI / TBTでも非常に良い数値を維持しています（スクリプトの相対的なサイズが原因である可能性もあります-gatsby.comにはPSIによると約628.3kbのスクリプトがあります。reatjs.org466.1kb 、およびnextjs.orgのみ216.8kb）

（これは明らかに1回の実行であり、実際の比較として使用するべきではありませんが、傾向は複数の実行にわたってかなり一貫しています）。

スコアの違いの大部分は、Javascript™の全体的なコストによるものですか？ Gatsbyチームが新しいWebサイトを最適化した場合、gatsbyフレームワークがJavaScriptを内部で処理する方法に追加する魔法があまり残っていない限り、プロセスに関する洞察を共有する絶好の機会となる可能性があります。

@juanferreras @wardpeet 、自分のプロジェクトで見つけたものもあります。 スタイル付きコンポーネントを使用している場合、何らかの理由で、スタイルはハイドレーション中に再計算/再生成され、ブラウザーに再挿入されます。 これには多くのメインスレッドが必要です。

これはギャツビーの水分補給の問題によるものです。 https://github.com/styled-components/styled-components/issues/2171

Gatsbyは、開発中にssrの実行にも取り組んでいます（https://github.com/gatsbyjs/gatsby/issues/25729 ）。これは、この種のパフォーマンスの問題を解決するのに役立ちます。 あまりにも。

@teclone

https://github.com/styled-components/styled-components/issues/2171は解決策を提供していないようです。 プロジェクトでどのように修正しましたか？

@dfguo 、今のところ、その修正はありません。本番環境のgatsbyは再水和エラーの開発ヘルプを提供しないため、再水和中にスタイルが再生成される理由を正確に知る人は誰もいないからです。

つまり、ギャツビーの本番ビルドでは無効になっているため、再水和中のReactポインティングの違いからのコンソールログはありません。

進行中のこの作業＃25729の目的は、開発で真のSSRを実行することであるため、その理由を確認できます。 ギャツビーチームを含む。

ところで、 gatsby build --no-uglifyを使用してGatsbyサイトを構築し、Reactの開発バージョンを使用してサイトを構築してログを表示することができます。 https://www.gatsbyjs.com/docs/gatsby-cli/#build

Dev SSRは、将来このようなものに非常に役立ちます！

そこで、カスタムcss変数を使用してdark-lightモードを実装しながら、サイトを@emotionおよびtheme-uiからlinariaに移行することにしました。

目標は今以来、JSに関連するブロッキング時間/メインスレッド/何かを削減することでしたcssもはや実行時に評価が、ビルド時（でコンパイルされ、実際にlinariaはるかに並ぶようですgatsbyこの点で@emotionよりもgatsbyステートメント）

プロセスは完全にスムーズではありません。 @emotion行ったことのほとんどはlinariaで機能しますが、そうでないものもあり、それらを書き直したり、カスタムcssを使用して再実装したりする必要があります。変数

gatsbyでのDXの経験は__bad__であり、ホットリロードは機能しません（ブラウザーが接続を失ったように見えるため、変更を加えて停止して再開する必要があります）が、全体的にプロセスは良好であり、何についてより意識する必要があります。 @emotionランタイム機能から本当に必要ですか

__とはいえ、灯台の指標は非常に似ています__

2つのnetlifyデプロイを比較できますが、実際には@emotionサイトの70年代は高く、 linariaサイトの70年代は中程度です。

言うまでもなく、私はあまり興奮していません

バンドルの分析：

• サイトドキュメントが14Kbから28kbに増加しました
• フレームワークスクリプトは38.7kbで同一のままです
• アプリスクリプトが58.2kbから46.1kbに減少しました
• そして、4番目のスクリプト（ component--content.. 。その後、 20bae078..なりました）が44.2kbから46.8kbになりました。

したがって、jsのスタイルはcssのスタイルに移行したと思います（そして〜12 kbは重要なIMOです）が、これは灯台のメトリックに実際の影響を与えていません（これが重要ですよね？）

だから、 linaria移動しても意味がないと言っているわけではありません。誰かが同じことをして、より良い結果が得られても驚かないでしょう（理論的にはそうなるはずです（？））、しかし、私の手には、プロセスは価値がありませんでした

それでも、アプリスクリプトを調べて、 jsバンドルを減らす方法を見つけようとして新しい問題を開きましたhttps://github.com/gatsbyjs/gatsby/issues/26655

ギャツビーでのDXの経験は悪く、ホットリロードは機能しません（ブラウザーが接続を失ったように見えるので、変更を加えて停止して再開する必要があります）が、全体的には、何についてより意識する必要があるため、プロセスは良好です。 @emotionランタイム機能から本当に必要ですか

私は同様の問題に遭遇した@kuworking、それが唯一の上に起こったことに気づいgatsbyより新しいバージョン2.24.9 ; 原因が同じかどうかはわかりませんが、問題＃26192でました。

私は同様の問題に遭遇した@kuworking、それが唯一の上に起こったことに気づいgatsbyより新しいバージョン2.24.9 ; 原因が同じかどうかはわかりませんが、問題＃26192でました。

私は"gatsby": "2.24.14"を数週間使っていますが、これまでのところlinariaしか経験していません。
しかし、これを知っていると、これが理解されるまでgatsbyを更新しません、ありがとう👍

私が提案する何を意味するのか@kuworkingことは、あなたがに格下げ多分あればある2.24.9その後、開発・サーバの停止問題もで発生しませんlinaria 。 しかし、それは単なるアイデアです。 それが事実かどうか知りたいのですが。

ギャツビーでのDXの経験は悪く、ホットリロードは機能しません（ブラウザーが接続を失ったように見えるので、変更を加えて停止して再開する必要があります）が、全体的には、何についてより意識する必要があるため、プロセスは良好です。 @emotionランタイム機能から本当に必要ですか

高速リフレッシュを試しましたか？

私は最近、TBTとLCPの改善を期待して、実稼働ギャツビーサイト（〜120ページ）を移行しました。 私たちのサイトは、svgrで生成され、material-uiスタイルを使用してスタイル設定されたreactsvgコンポーネントを使用してsvgが重いです。 平均パフォーマンス結果は初期スコアの+ -5の範囲であり（v6以前の約85から約45のモバイルパフォーマンス）、テーマを使用した移行は比較的簡単でしたが、高速更新への移行が必要でした。そうではありません。

正直なところ、一般的な「未使用のJavaScriptを削除する」灯台の警告以外に、試してみることができる最適化や、より詳細なメトリックがないことに少しがっかりしました。

スピードは私たちがギャツビーを選んだ主な理由の1つであり、ページの読み込みはまだ速いですが、インサイトスコアがこれほど大きなヒットを記録した場合、SEOの観点から正当化するのは困難です...

ささやき：NextJSに切り替えたところ、スコアが上がっています🤭

ささやき：NextJSに切り替えたところ、スコアが上がっています🤭

Svelteはどうですか？

ギャツビーの開発者がロードマップ（予想されたもの以外）でこれに特定の重要性/優先順位を与えているかどうかを知ることは良いことです。これかそれか

gatsbyはgatsby-node *でコンパイルを行うので、その部分を増やしてクライアント部分をデレバレッジする方法を模索しているのではないかと思います。

*使用していたpageContext （公開されたすべての投稿に関するデータ）を減らすために、現在、そのデータのほとんどをjsonファイルに（ gatsby-nodeを介して）保存しています。必要に応じてサイトからそれらをフェッチします。これにより、バンドルサイズが小さくなりますが、より論理的に感じられます。

灯台のスコアにこだわる必要はありません-特に彼らがいるとき
他のサイトに対するベンチマークとして意図されており、私たちがすべき目標ではありません
満点を目指して努力してください。

ギャツビーが純粋な100を釘付けにしたのは最近までではありませんでした-確かに、そこに
対処すべきいくつかの問題がありますが、現在のSEOゲームはスピードとコンテンツです
プラスリンク、そして私たちはそれをカバーしています。

私の2セント。

2020年8月28日金曜日、16：57 kuworking、 notifications @ github.comは次のように書いています。

ささやき：NextJSに切り替えたところ、スコアが上がっています🤭

Svelteはどうですか？

Gatsbyの開発者がこれに特定の情報を提供しているかどうかを知るのは良いことです
ロードマップにおける重要性/優先順位の感覚（予想以外）
1）、私は当面の解決策はないと思いますが、おそらくいくつか
これまたはあれに焦点を当てた将来の方向性と実装の種類

gatsbyはgatsby-node *を使用してコンパイルを行うので、
その部分を増やし、クライアント部分をデレバレッジする方法を模索しています

*私が使用していたpageContextを減らすために（すべてに関するデータ
公開された投稿）、私は現在（gatsby-nodeを介して）ほとんどを保存しています
そのデータをjsonファイルに保存し、必要に応じてサイトから取得します。
バンドルサイズを縮小しますが、より論理的に感じます

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-682664232 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/ALSIKRHQUIKR5YO6OGA3DC3SC7AWPANCNFSM4NHP7XCA
。

応答が遅れて申し訳ありませんが、パフォーマンスに関係することがたくさんあり、負荷メトリックはパズルのほんの一部にすぎません。 私たちは今四半期と次の四半期にギャツビーを小さくし、TBTを減らすことに意欲的です。 現在の最大の問題は、Reactバンドルサイズ、MDX、大きなページ（コンテンツ/スタイリング）、最初のロード時のメインコンテンツとしてのトラッキングスクリプトとフォント/画像です。

現在、gatsby-image＆analyticsスクリプトを調べて、読み込み時間を改善し、分析を延期する方法を確認しています。

残念ながら、見積もりはできません。 また、.comサイトとお客様を調べて、一般的な問題が何であるかを確認し、これらの最適化をgatsbyまたはプラグインに焼き付けることができます。

編集：

私はあなたのソースコードのいずれかを見て、私たちがどのように改善できるかを見るためにあなたがしていることについてより多くの洞察を得ることを嬉しく思います。

私はredditの投稿を作成し、見つけたすべての改善のヒントを集約しようとしました。 あなたがより多くのヒントを思い付くことができるならば、それらをリストしてください

gatsby-image （ホームヒーロー画像と背景画像）だけを削除すると、スコアが10〜20ポイント向上します。

最近行ったいくつかのテストで、 tracedSVGを使用すると、最大のコンテンツフルペイントのパフォーマンススコアが実際に劇的に向上することがわかりました。 これはLighthouseで修正されると思いますが、現時点では、SVGがフル解像度の画像と同じサイズであると見なされているため、LCPターゲットとしてのSVGからフル画像にスワップすることはありません。

base64を使用する場合、解像度が小さいためLCPの候補にはなりません。そのため、Lighthouseは、が読み込まれるたびにフル解像度の画像を使用します。

したがって、トレースされたSVGの外観を気にしない場合（私は個人的にそれらを好む）、それを試してみることをお勧めします。

なぜv5はv6よりも良い結果になるのですか？ NextJSを使用しているので、結果は常に60から85に変わりました。

+1

私はgatsby-imageの後継者に取り組んできました。 まだ100％ではありませんが、独自のgatsby-imageフレーバーを作成できるように、構成可能なバージョンを作成する必要がありますが、灯台の悪いスコアのほとんどは修正されます。

すでに使用できますが、まだ戦闘テストされていません。
https://github.com/wardpeet/gatsby-image-nextgen/tree/main/gatsby-image

npm install --save @wardpeet/gatsby-image-nextgenインストールできます。 gatsby-imageの現在のユーザー向けの互換性レイヤーがあり

まだサポートされていないもの：

• オブジェクトの適合は、コンポーネントの外部のcssによって実行される必要があります
• アートディレクション

現在のgatsby-imageデモ：
サイト： https ：
pagespeed-insights： https ：//developers.google.com/speed/pagespeed/insights/？url =
webpagetest： https ：//webpagetest.org/result/200928_4M_0879160e38bb6c5489f85534de2dd197/

新しいgatsby-image-nextgenデモ：
サイト： https ：
pagespeed-insights： https ：//developers.google.com/speed/pagespeed/insights/？url =
webpagetest： https ：//webpagetest.org/result/200928_C0_63317160bdfc71ece1a2057df8b08133/

@wardpeet現在のデモのpagespeed-insightsリンクはnextgenに移動するため、同じスコアが表示されます。
素晴らしい仕事、ところで。 進歩を見るのは本当にエキサイティングです。

修正ありがとうございます！

このアップデートでは、以前は接続していなかったことが指摘されています。 gatsby-imageを使用していませんが、実際にはgatsby-background-imageを使用しており、内部ではgatsby-image使用していないようです。 ...可能であれば、この新しい@wardpeet/gatsby-image-nextgenそのコンポーネントを書き直す必要があるかもしれません...。

この記事では、いくつかの追加のヒントhttps://www.freecodecamp.org/news/gatsby-perfect-lighthouse-score/をリストしていますが、それらの多くはこのスレッドですでに言及されていると思います...

プラグインが機能完了したときの@DannyHinshaw 。 そのプラグインも見ていきます。 備考画像も見ないといけない

@wardpeet/gatsby-image-nextgen -0.0.2の新しいバージョンを公開しました。

1. HTMLのcssとjsを最小化します
2. 必要なビットのみをロードします。ネイティブイメージのロードが有効になっている場合、約2kb（gzip圧縮されていない）のみをロードします。
3. プレースホルダーが最初の読み込み時にのみ呼び出され、キャッシュされた画像がすぐに読み込まれることを確認してください
4. 非同期をデコードしてブラーアップアニメーションを修正

独自のラッパーを作成できる構成可能なImageコンポーネントが必要な人はどれくらいいるのでしょうか。また、実際にアートディレクションを使用していて、デフォルトでgatsby-image内に配置したい人は何人いますか。 私の最初のアイデアは、機能を無効にすることでしたが、構成可能なgatsby-imageで有効にするため、それをサポートするには独自の画像コンポーネントを作成する必要があります。

最新のデモ： https ：

@wardpeetこれは素晴らしいです！ 私はgatsby-imageの組み込みのアートディレクションに大きく依存しています。 しかし、私は例/スムーズなアップグレードパスも大丈夫だと思います！

私はいつもモバイルで99を受け取り、現在は76です。LCPが7.0で、ヒーローイメージを示していることを除けば、すべてが素晴らしいです。 意味がありません。 私が携帯電話で自分のサイトをプルアップすると、それは非常に速く燃え上がります。 人々はあなたが知っている驚異ですか？ また、画像をwebpなどに配置するように指示されますが、すでにchildImageSharp_withWebpを使用しているため、取得できません。 GastbyImageとbackground-imageがlighthouseとpagespeedinsightでこの新しいバージョンで機能していないことに気づき始めています。 私の心は困惑しています。 私は行ってアニメーションを殺し、すべての画像のサイズを半分に変更しましたが、1点も上がらなかった。 私はこれを読んでいて、私を助けるものが何も見当たりません....ああ、私はちょうど見上げました...私は

@davidpaulssonは、これを行う方法の例を共有しますか？ 新しいgatsby-imageでもアートディレクションが可能であるため、手動でいくつかの手順を実行する必要があります。

@davidpaulssonは、これを行う方法の例を共有しますか？ 新しいgatsby-imageでもアートディレクションが可能であるため、手動でいくつかの手順を実行する必要があります。

承知しました！ 私は現在このように使用しています

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

return <Img fluid={artDirection} />

@wardpeetこんにちはワード。 bullha.shはgatsbyimage nextgenに役立ちますか？

@wardpeet gatsby-image-nextgenプラグインを使用しましたが、実際にはLCP時間が改善されました（約5秒から約1.5秒に短縮されました）。 これありがとう！

ただし、 @ davidpaulssonが使用しているのと同様に、アートディレクションも使用しており、gatsby-imageのように機能させることができないようです。

nextgenプラグインでこれを可能にするために必要な手動の手順について詳しく説明していただけますか？ 再度、感謝します！

@Jimmydaleclevelandありがとうジミー！ GatsbyImageSharpFluid_withWebpをGatsbyImageSharpFluid_withWebp_tracedSVG置き換えると、新しいGatsbyWebisteのパフォーマンススコアが劇的に向上しました。 私は54％を超えていませんでしたが、tracedSVGを使用すると80％を超えています。 それは大きな改善です💯

最近行ったいくつかのテストで、 tracedSVGを使用すると、最大のコンテンツフルペイントのパフォーマンススコアが実際に劇的に向上することがわかりました。 これはLighthouseで修正されると思いますが、現時点では、SVGがフル解像度の画像と同じサイズであると見なされているため、LCPターゲットとしてのSVGからフル画像にスワップすることはありません。

base64を使用する場合、解像度が小さいためLCPの候補にはなりません。そのため、Lighthouseは、が読み込まれるたびにフル解像度の画像を使用します。

したがって、トレースされたSVGの外観を気にしない場合（私は個人的にそれらを好む）、それを試してみることをお勧めします。

@abdullahe以前にチェックアウトしましたが、canvasとnodeに依存しています

@guydumaisは、必ずloading="eager"てください。これにより、スコアも変更されます。

@ BenjaminSnoha ＆ @ davidpaulsson例を少し

@wardpeet @wardpeet/gatsby-image-nextgenでgatsby-remark-images @wardpeet/gatsby-image-nextgenをどのように使用しますか？ gatsby-config.jsでプラグインとしてポイントするだけの場合ですか、それともgatsby monorepoにマージされるまで不可能ですか？

これは灯台とは何の関係もないかもしれませんが、なぜgatsbyページデータのJSONファイルがjsファイルのようにコンテンツハッシュをサポートしていないのか疑問に思っています。

jsファイルのコンテンツハッシュはWebpackによって実行されることは知っていますが、gatsbyはページデータのJSONファイルに対しても同じことを実行できます。 これにより、cdnネットワークリクエストを大幅に節約できます

あなたのキャッシュが正しく設定されている場合@tecloneページdata.jsonファイルがオーバー以上ダウンロードされ、すべきではありません。 それらは一度ロードされ、その後ブラウザがそれらを再検証します。 ページデータ（対JS / CSSファイル）のコンテンツハッシュの問題は、それらが非常に多いことです。 コンテンツハッシュでは、ファイルをロードする前に、ハッシュが予測できないため、 xからx.LONG_HASH変換されるマニフェストをロードする必要があります。 JS / CSSを使用すると、非常に大規模なサイトでもJSファイルが非常に多いため、マニフェストをロードするのが妥当です。 ただし、ページデータの場合、ページごとに1つあるため、マニフェストが非常に大きくなる可能性があります。 以前はこれを行っていましたが、10kページのサイトで、マニフェストはすでに約500k圧縮されていることがわかりました。 https://github.com/gatsbyjs/gatsby/pull/13004

page-data.jsonファイルが何度もダウンロードされている場合— devtoolsでキャッシュが無効になっていないことを確認し、 https： //www.npmjs.com/package/check-gatsby-cachingでキャッシュヘッダーを確認して

@KyleAMathews 、それを明確にしてくれてありがとう。 それは非常に賢明なアプローチです

@wardpeetは、image-nextgenがfadeIn="false"またはfadeIn="{false}"サポートしていないのは事実です。

しかし、それははるかにうまく機能し、〜80から〜95になりました

@MelleNi必要ありません、必要ないと思いますが、喜んで検討します。

https://github.com/gatsbyjs/gatsby/discussions/27950を見て、出荷されているものを確認できます。

@wardpeet @wardpeet/gatsby-image-nextgenでgatsby-remark-images @wardpeet/gatsby-image-nextgenをどのように使用しますか？ gatsby-config.jsでプラグインとしてポイントするだけの場合ですか、それともgatsby monorepoにマージされるまで不可能ですか？

このプラグインにもコメントを移動します:)

@MelleNi必要ありません、必要ないと思いますが、喜んで検討します。

あなたは私たちが出荷しているものを見るために＃27950を見ることができます。

@wardpeet @wardpeet/gatsby-image-nextgenでgatsby-remark-images @wardpeet/gatsby-image-nextgenをどのように使用しますか？ gatsby-config.jsでプラグインとしてポイントするだけの場合ですか、それともgatsby monorepoにマージされるまで不可能ですか？

このプラグインにもコメントを移動します:)

スピードが大幅に向上したので、コメントを聞いてうれしいです。

しかし、Gatsbyのjavascriptを無効にする（そして特定の機能を手動で再統合する）ことなしに99-100を取得できないことに気づきました。 fadeIn={false}を使用して、古いGatsbyイメージをjavascriptなしで動作させることはできますが、image-nextgenを使用することはできません。 （多分私は何かが足りない、そしてそれは絶対に可能ですか？）今javascriptなしで私はnextgenなしで99を下回ることは決してありません。

javascriptを無効にすると、ギャツビーのアイデアが無効になることは理解していますが、まあ。

興味深いことに、セルフホストフォント（fontsource）の使用をやめ、「システム」フォントに切り替えると、モバイルパフォーマンススコアが向上しました（〜70〜〜90）。

@wardpeetアートディレクションで構成可能な画像コンポーネントを構築する方法の例を共有できるチャンスはありますか？ 私は@BenjaminSnohaと@davidpaulssonと同じ船に乗っており、自分のプロジェクトで構成可能なコンポーネントを作成してもかまいません。

私が目にする最大の問題は、メディアクエリとSSRの処理です。 フレネルなどのライブラリは機能しますが、すべてのコンポーネントをロードするためパフォーマンスが低下し、 windowコンポーネントが使用可能になった後にDOMをクリーンアップします。

私のウェブサイトでは、createPageで作成されたすべてのページのソースコード（マークダウンとマークダウンはマークダウン内のコンポーネントに反応します）がpagespeedの重いJavaScript（未使用のJavaScriptを削除）に含まれているようです

純粋なCSSのぼやけたプレースホルダーを作成するために使用できるPlaiceholderを

最新のLighthouse6.4.0とのスコアが高いJamifyBlogStarterのNext.jsバージョンを作成しました。

next.jamify.orgでデモサイトを調べることができます。

私はあなたがNext.js.に切り替えることを示唆するのではなく、ここにこれを掲示していますむしろ、ギャツビーで同じことがどのように達成できるかを学ぶこと。 主な成功要因は次のとおりです。

• 高度に最適化された画像（Nextはラムダオプティマイザーでこれを実現しますが、これはgatsby-plugin-sharpでも実行できます）。
• 単純なプレースホルダーsvg（ぼかしなどの優れた効果によりページの速度が低下します）。
• 交差点オブザーバーを使用して、表示中の画像のみを表示します（次へ/画像を参照）。
• 画像の遅延読み込みを確認します。
• 小さなバンドルサイズ。

これについてさらに議論したい場合は、ツイッターで私に連絡することができます。

@ styxlabweb.dev / measureでわずかに低い結果が得られます

ただし、投稿結果の方が優れており、いずれの場合も非常に優れた値であり、gatsbyバージョンhttps://demo.jamify.org/とは著しく異なり

また、あるサイトでgatsbyを11tyに変更したことを投稿します。パフォーマンスは向上しましたが、劇的ではありません。

（ギャツビー）

（異なるデザイン、本質的​​に同じコンテンツ、11ty）

または同様のページで、今回は画像付き

（ギャツビー）

（異なるデザイン、本質的​​に同じコンテンツ、11ty）

11tyの開発者エクスペリエンスは非常に優れていると言えますが（実験的にjsxとstyled-components使用することもできます）、クライアント側のjsは失われます（それを挿入してwebpackと戦うことができます、その瞬間はあなたがギャツビーを逃すところです）

私が11tyを使用している間、gatsbyが何らかの11tyレンダリング戦略を有効にして、1つのフレームワークにreactとreactlessの混合静的ページをデプロイできるとしたらどうだろうと考えていました...

これに関する更新はありますか？ 画像がなく、合計ブロッキング時間のためにパフォーマンスが76になります