LCPの改善は難しい

Core Web VitalsにおけるLCP (Largest Contentful Paint)を改善できないという話をよく聞きます。

HTMLとCSSを丁寧に直せば改善できるCLS (Cumulative Layout Shift)と違い、確かに難しいと思います。

結論

LCP改善の実践的なノウハウを紹介したいと思います。

以下のグラフは通販サイトを中心に1000ページほどPageSpeed Insightsを実行して得られたFCP (First Contentful Paint)とLCPの関係(それぞれ対数目盛)です。

なんとなく相関が見て取れますが、大事なのは以下の点です。

右下の領域にはサンプルがひとつもありません。つまり、

LCPがFCPより早くなることはなく、FCPが遅いのを放置してLCPだけを改善できないということです。

それも当然で、

である以上、最大コンテンツが最初のコンテンツより早く表示されることは論理的にもありえません。

FCPの改善はブラウザのタイムラインと格闘する必要があります。

大雑把に言うと、HTMLとCSSが解析され、どこに何を表示するかをとにかく早く決めさせることです。それを邪魔するよくあるパターンは、

FCPの改善には、とにかくブラウザにスタートダッシュでHTMLとCSSに集中してもらうことを徹底的に行います。

最大コンテンツは画像であることが多いので、画像を軽量化するとLCPを改善できると期待されがちですが、実際はどうでしょうか。

先ほどの1000ページのPageSpeed Insightsの結果について、画像データ転送量とLCPの関係(それぞれ対数目盛)を見ると次の通りです。

相関係数0.48なのでなくはないけど微妙といった感じです。

これはあくまでページ全体の画像データ量との比較で、メイン画像のデータ量との相関ではありません。

ただ、画像の読み込み時間よりFCPの方がよほど大きく、先ほども述べたようにLCPはFCPを土台としています。

画像を軽くするだけで悪いLCPをよくできるということはまずもってありません。

ファーストビューにカルーセルスライダーがあるページでは、それがLCP悪化の原因になっていることがあります。

ライブラリの種類によりますが、JavaScriptが動作しないとカルーセルスライダーが表示されないようだとLCPは劇的に悪化します。

よく行う対策は、以下です。

ただ本音としては「せめてファーストビューではカルーセルスライダーを使うのはやめましょう」と言いたいです。

よくLCPの改善ノウハウとして、メイン画像の先読み(link要素のrel="preload")を指定するとよい、という記事を見かけます。

<link rel="preload" href="メイン画像のURL">

これは一概によい方法とは言えません。別に魔法のように画像を別に読み込んでくれるわけではなく、たいていの場合、CSSの読み込みを押しのけて画像を読み込むだけです。

CSSが押し除けられた結果、FCPが悪化して結果としてLCPも悪化する結果になることがあります。

ただ、CSSが軽量であったり、FCPが十分に短ければ、多くのユーザーにとってメイン画像の並列読み込みはLCPに有利に働くと想像できます。双刃の剣で、実際にやってみないとわかりません。

記事中で引用した、通販サイトを中心とした1000ページのPageSpeed Insightsの結果について、指標間の相関性、指標とリソースタイプごとの転送量の相関性を記載しておきます。

いろいろ気づきを得られるデータなので、また別のテーマで記事にしたいと思います。

それぞれ自然対数による目盛。

それぞれ自然対数による目盛。