まず結論から言うと…
JavaScriptの遅延読み込み。SEOに効くか、っていう話。
効く。…でも、やり方次第。下手にやると、逆にCore Web Vitalsを悪化させて、順位に悪影響が出る可能性もある。特にLCP(Largest Contentful Paint)には注意が必要。そこが今日のメモの核心。
で、なんでSEOに関係あるの?
すごくシンプル。Googleが「ページの表示体験」をランキング要因にしてるから。 その指標が「Core Web Vitals」。
具体的には、この3つ。
- LCP (Largest Contentful Paint): 主要なコンテンツがどれだけ早く表示されるか。
- INP (Interaction to Next Paint): クリックとかの操作にどれだけ速く反応するか。(以前はFIDだったけど、今はINPが主流)
- CLS (Cumulative Layout Shift): 読み込み中にレイアウトがガタガタ動かないか。
JavaScriptの読み込みが重いと、ブラウザの処理がブロックされて、LCPやINPが悪化する。 遅延読み込みは、この「ブロック」を避けて、体感速度を上げるためのテクニック。だから、間接的にSEOに効くってわけ。
JavaScriptを遅延させる、主な方法
やり方はいくつかある。昔からあるものと、最近のモダンなやり方と。
| 方法 | どんな感じか | 使いどころ |
|---|---|---|
|
HTMLの解析は止めない。でも、スクリプトの実行はHTML解析が終わってから。順番は保証される。 | 複数のJSファイルがあって、実行順が大事なときに。とりあえずこれ使っとけば大きな失敗は少ないかも。 |
|
HTMLの解析を止めずに、ダウンロードでき次第すぐに実行。順番はバラバラ。 | 他のスクリプトに依存しない、独立したやつ。アクセス解析タグとか。でも、扱いがちょっと難しいかな。 |
| Intersection Observer API | 「この要素が画面に入ったら、このJSを実行して」って感じで、もっと細かく制御できる。 | 画面の下の方にあるコメント欄とか、SNSの埋め込みとか、無限スクロールとか。 今どきはこれが本命。 |
Dynamic import() |
ユーザーがボタンをクリックした時とか、特定の操作をきっかけにJSモジュールを読み込む。 | SPA(Single Page Application)で、必要な機能だけ後から読み込みたいとき。ちょっと高度な話。 |
昔はscrollイベントで頑張ってたけど、あれはパフォーマンスが悪いから今は非推奨。 Intersection Observerがずっと効率的。
// Intersection Observer の簡単な例
const observer = new IntersectionObserver((entries, observer) => {
entries.forEach(entry => {
// 要素が画面内に入ったら
if (entry.isIntersecting) {
// ここでスクリプトを読み込む処理とか…
console.log('見えた!');
// 一回見えたら監視をやめる
observer.unobserve(entry.target);
}
});
});
// #heavy-component を監視開始
observer.observe(document.querySelector('#heavy-component'));
ここが一番大事。やってはいけない遅延読み込み
遅延読み込みは万能じゃない。一番やっちゃいけないのは、「ファーストビュー(最初に表示される画面領域)にある重要な要素」を遅延させること。
特に、ページのLCPになる要素。だいたい、一番大きな画像とか、テキストブロック。 これを遅延読み込みすると、当然LCPのスコアは悪化する。 当たり前のようで、意外とやってしまいがちなミス。
WordPressは一時期、すべての画像をデフォルトで遅延読み込み(loading="lazy")にしたせいで、多くのサイトでLCPが悪化したという有名な話がある。 Google自身の分析でも、遅延読み込みがLCPを悪化させるケースが確認されている。
だから、まずやるべきはPageSpeed InsightsやChromeのデベロッパーツールで、自分のページのLCP要素が何かを特定すること。 そして、その要素だけは絶対に遅延させない。むしろpreloadを使って最優先で読み込ませるくらいがいい。
画像だけじゃない、何を遅らせるか
「遅延読み込み」って言うと、画像のloading="lazy"が有名だけど、本当に重いのはJavaScriptの場合が多い。 特に遅延読み込みの対象にすべきなのは、こういうやつら。
- サードパーティのウィジェット(SNSのタイムライン、天気予報とか)
- 広告配信のスクリプト
- コメントシステム(Disqusとか)
- アクセス解析ツール(でも、これは計測漏れのリスクも考える必要あり)
- あまり使われない機能のコンポーネント
Googleのweb.devの記事でも、不要なJavaScriptを避けることがINP改善の鍵だと述べられている。 これは日本のサイトでよくある、多機能なウィジェットをたくさん埋め込んでいる場合に特に重要。海外のシンプルなサイトと比べて、サードパーティJSの最適化がパフォーマンスに直結しやすい。
もっと先の話:Speculation Rules APIとか
遅延読み込みは、あくまで「最初の表示」を速くするための守りの施策。
最近GoogleがI/Oなんかで話しているのは、もっと攻めの施策。例えば「Speculation Rules API」。 これは、ユーザーが次に押しそうなリンク先を、事前に先読み(prefetch/prerender)しておく技術。 うまく使えば、ページ遷移がほぼ一瞬になる。
遅延読み込みで初期表示を軽くして、Speculation Rules APIで次の表示を速くする。この組み合わせが、これからのウェブパフォーマンスの標準になっていくのかもしれない。
で、結局どうすればいいの?
まとめると、こんな感じの手順かな。
- 現状把握: PageSpeed Insightsで自分のサイトを計測。LCP、INPのスコアと、原因になってる要素を確認する。
- LCP要素の保護: LCPになってる画像やテキストブロックを特定し、絶対に遅延読み込みの対象から外す。
loading="lazy"が入ってたら消す。 - 不要なJSの遅延: ファーストビューより下にある重そうなコンポーネント(コメント欄、関連記事件、SNS埋め込みなど)にIntersection Observerを適用して、画面に入るまで読み込まないようにする。
- スクリプトの整理:
タグにdeferを適切につけて、レンダリングブロックを防ぐ。 - 再計測: 対策したら、もう一度計測。スコアが改善したか、意図しない副作用が出てないか確認する。
全部一気にやろうとすると大変だから、一番影響の大きいところから一つずつ試すのがいいと思う。正直、これだけでスコアが劇的に改善することもある。
あなたのサイトで一番重いJSって、正直なんですか?もしよかったら、コメントで教えてください。
