こんにちは。エンジニアの鈴木（@yamotuki）です。

以前、こちらの記事で速度改善の前の測定のためにSpeedCurveを導入したという話を書きました。今回はSEOの観点から Google Search Console で警告が出たページについて速度改善を試みた話を書いていきます。

ページ速度とSEOの関係

Google Search Console のなかの「ウェブに関する主な指標」というところでヘルプに書かれている指標は以下の3種類でした。以下の3つはCore Web Vitals とも呼ばれています。

LCP（Largest Contentful Paint）: ページが最大の視認可能な要素をレンダリングするまでの時間
FID（First Input Delay: 初回入力遅延）: ユーザーの操作に対してページがレスポンスを開始するまでの時間
CLS（Cumulative Layout Shift）: ページの読み込み中にページの UI 要素がどの程度移動するかを示します。

ページ速度でいうとLCPとFIDが関わりますが、今回の記事での話はLCPの値について焦点を当てて対応したところについてです。

この指標のいずれかに問題があると「不良」や「改善が必要」となるようです。具体的には、LCPだと閾値が4.0秒以上で不良、2.5秒以上で「改善が必要」と表示されていました。

具体的に速度の問題がなくなるとどれくらい検索順位が上がるかは明確には分かりませんがこちらのドキュメントでgoogleの考え方が示されています。

取り組みの結果

先に、今回の記事で取り上げる改善だけでなく、一連の改善を行なった結果について記載しておきます。

LCPの改善だけではなく他の指標に対する改善も合わせてチームで取り組みました。その結果、以下のように大幅に指標の改善を行うことができました。

f:id:yamotuki:20201009174908p:plain — Google Search Console での経時での状態

LCP改善への取り組み

取り組む対象の特定

Google Search Console では問題があったページがどこなのか教えてくれます。今回は、募集詳細ページ（例）のLCPに問題があることが分かったので取り組むことにしました。

LCPを分解する

LCP は以下の定義でした（再掲）。

LCP（Largest Contentful Paint）: ページが最大の視認可能な要素をレンダリングするまでの時間

要するに、ファーストビューの最大の要素が見える状態になるまでの時間です。目立つのでそれが読み込まれると「大体表示されたな」と感じるユーザも多くなるラインです。

今回の対象のページでいうとファーストビューの大きな画像の部分です。

f:id:yamotuki:20201009180322p:plain — ファーストビューの画像

LCPを本当にざっくり分解すると以下のようになりそうです

バックエンドの応答を受け取る
HTMLの内容からJavaScriptやCSS, 画像などダウンロードし始める
JavaScriptが差し込むHTMLも含めて解釈する（ダウンロードする時の設定による。詳細については、私はまだ理解が甘いですし長くなるので省きます）
まだダウンロード完了していない画像など待つ
表示する

どこが遅かった？

今回のケースだとバックエンドが明らかに遅く、TTFB（Time To First Byte）が3~4秒でした。表示している内容からすると1秒切っても良さそうなものなので、これを改善することにしました。他にも沢山改善ポイントはありますが、速度改善は改善効果の大きいものから行うのが原則です。

f:id:yamotuki:20201009181049p:plain — 左のほうが改善前。3~4秒かかっている

対応

そうと分かればバックエンドの改善です。 TTFBを遅くしていた原因は、ページ下部にあった「類似の募集」の項目でした。画面表示に必要な情報を集めるためにSQLを多く発行するN+1問題が発生していました。今回はちょうど機能改善のタスクもあり、速度改善と合わせて行うことになりました（実際には、バックエンド部分の実装自体は同僚の@kubotakさんが行いました。私は事前の速度測定とマークアップなど担当したタスクでした。）そこまで複雑な処理でもなかったので問題の詳細箇所特定は Laravel Debugbar で適当に挟んで計測したと聞いています。

qiita.com

改善の結果、バックエンドのレスポンスが3~4秒程度だったものが1秒切るくらいになりました。