テーマコンポーネントとLargest Contentful Paint (LCP)

開発
1

サイトのウェブバイタル、特にLCPを改善したいと考えています。LCPの時間が約2.7秒（2.5秒未満であるべき）となっており、問題が発生しています。Optimize Largest Contentful Paint  |  Articles  |  web.dev によると：

具体的には、LCPは、ユーザーがページの読み込みを開始してから、ビューポート内で最大の画像またはテキストブロックがレンダリングされるまでの時間を測定します。

問題は、私が作成したバナーテーマコンポーネントに起因していると特定しました。ウィジェット「above-main-container」としてマウントされるバナー画像が、ほぼすべてのページで画面に描画される最大のオブジェクトです。

コード 
  <script type="text/discourse-plugin" version="0.8">
  const h = require("virtual-dom").h;

  api.createWidget("my-banner", {
    tagName: "div",

    html() {
      return  h("img.banner-center", {src: settings.banner_image, fetchpriority: "high", style: "aspect-ratio: 925 / 359 ; width: 100%"})
    }
  });
  </script>

  <script type="text/x-handlebars" data-template-name="/connectors/above-main-container/banner">
  {{mount-widget widget="my-banner"}}
  </script>

私の推測では、画像を含むdivはJavaScriptを使用してマウントされるため、このJavaScriptコードが実行される前に、Discourseページの更新時に一連の前提条件を満たす必要があります。これにより、バナーが2.5秒後にフェッチされ、LCPメトリックに悪影響を与えていると考えられます。

コードにあるように、fetchpriority="high" を使用してバナー画像を優先しようと試みましたが、根本的なタイミングの問題は解決されていないようです。

この特定のテーマコンポーネントのレンダリングを優先するための提案はありますか？プラグインに変換する方が良いでしょうか？バナーをできるだけ早く注入する他の方法はありますか？よろしくお願いします！

「いいね！」 3
2

質問が詳細すぎたかもしれません。もし答えを知っている方がいれば、もっと簡単な質問です。

ページがリロードされたとき、プラグインの要素はテーマのコンポーネントよりも早くレンダリングされますか？

3

もしあなたのバナーが、Introducing Discourse Splash - A visual preloader displayed while site assets load で使用されている要素よりも大きい場合、LCP（Largest Contentful Paint）で問題が発生するでしょう。

画像アセットのダウンロードが主な問題だとお考えの場合は、次のようなものを追加できます。

<link rel="prefetch" href="http://example.com/myimage.webp" />

テーマのHEAD要素に。

「いいね！」 2
4

現在、大変な時期を過ごしています :slight_smile: ははは

CDN に切り替えましたが、改善されませんでした。前述したように、バナーを取得する呼び出しが遅すぎるのだと思います。取得時間ではなく。違いが出るか、プリフェッチを試してみます！

解決策が見つかるまでの間、ログインしている場合以外はバナーを表示しないようにしました。Google は LCP を主に検索トラフィックから計算しているようで、私の場合は通常、ログインしていないユーザーです。

「いいね！」 1
5

LCPは、Android、Windows、MacOS、Linux、Chromebookなど、Google Chromeを使用するすべてのユーザーから取得されます。

ログインユーザーよりも、これらのデバイスで匿名ユーザーからのページビューが多い場合、LCPはそれらの匿名ユーザーのパフォーマンスを反映します。

「いいね！」 2
6

なるほど。

スプラッシュスクリーンのアニメーションを大きくすることで、この問題を回避できると思いますか？

7

これは非常に複雑です。

まず、スプラッシュスクリーンがすでに画面全体（100vhと100%幅）を使用していることを確認しました。

ただし、Discourseの起動が十分に速い場合、一部のユーザーにはスプラッシュスクリーンが表示されません。その場合、LCPは十分な大きさの要素によって設定されます。あなたの場合はバナーなので、それに縛られます。

prefetchメタタグを試してみて、それが非常に最適化されたアセットであり、すべての資産がユーザーに近いPoPを持つCDN経由で配信されていることを確認してください。

「いいね！」 4
8

それはそうでなければなりませんか？

9

もはや定番と言えるほど、ユーザーに愛されています。

10

そして、それはどのような方法でも調整できませんか？

11

もちろん、小さくしたりすることはできますが、美観を損なわない解決策を希望します。

12

この可能な解決策を試してみましたが、残念ながら違いは見られませんでした。また、確認のためにバナー画像を非常に小さな画像に置き換えてみましたが、LCPへの影響はありませんでした。提案ありがとうございました。

テーマコンポーネントがどのようにページに注入されるかの内部構造はわかりませんが、バナーコンポーネントが注入される時点ではすでに手遅れであるという印象です。次の試みは、プラグインとして試してみることです。

13

理想とは程遠いですが、これは機能しています。

Screenshot_20230412_125237
Screenshot_20230412_1252371080×1206 97.7 KB

同様の問題が発生した方のために