ミスによる遅延 vs 設計による遅延: ウェブパフォーマンスのフレームワーク

ミスによる遅延 vs 設計による遅延

あなたが私を雇ってCore Web Vitalsの修正や相談をする際、どこかのタイミングで必ずミスによる遅延と設計による遅延についての話を聞くことになるでしょう。私はこの区別をつけることが非常に重要だと考えており、この記事ではそれがCore Web Vitalsの改善にどのように役立つかを説明します。

最終レビュー: Arjen Karel、2026年3月

誰かからCore Web Vitalsのコンサルティングや修正を依頼される場合、そこには常に何らかの問題が存在しています。遅延は常にアンチパターンから生じます。たとえば、「遅延読み込みされた Largest Contentful Paint 画像」、「最適化されていない巨大な画像」、「スライダー」、「レンダリングをブロックする JavaScript」などです。

アンチパターンを持ち込むのに多くの手間はかかりません。単にプラグインをインストールしたり、ベストプラクティスを少しの間忘れたりするだけで、アンチパターンを作り出してしまうことがあります。

私はこれらのアンチパターンを「ミスによる遅延」と「設計による遅延」に分類するのが好きです。なぜなら、これらに対する修正のアプローチは完全に正反対だからです。

2025 Web Almanacによると、モバイルのオリジンで3つのCore Web Vitalsをすべてクリアしているのはわずか48%です。私の経験上、これらの失敗の大部分は数時間で修正可能な「ミスによる遅延」の問題によるものです。

ミスによる遅延

私は「ミスによる遅延」のアンチパターンが大好きです。あなたがページを遅くする何かをした、つまりミスをしたわけですが、もっとずっと速い方法があることを知らなかっただけです。心配は無用です。私はミスを修正することができます。

したがって、これらの「ミス」を分類することは理にかなっています。これにより、あなたの開発チームに送る（あるいは私自身で修正する）ための、簡単に修正できて影響度の高い改善リストができあがります。通常、議論の余地はほとんどありません。これらのアンチパターンを改善することは、あらゆる角度から見ても理にかなっています。これらが修正されれば、Core Web Vitalsは確実に向上します。

以下は、私が日常的に遭遇するアンチパターンの例です。私が「何を」「なぜ」修正するのかを説明すると、大抵「ああ、それがページを遅くしているとは知らなかった」という反応が返ってきます。

1. 遅延読み込みされていない画像

最も一般的なアンチパターンは、遅延読み込みされていない画像です。遅延読み込みされていない画像は、ページの読み込みの初期段階でダウンロードキューに入れられます。これによりネットワークとCPUのリソースが消費されます。まだ画面に表示すらされていない画像に貴重なリソースを割り当てるのは理にかなっていませんよね？オフスクリーン画像の遅延読み込みについて詳しく学びましょう。

これとは正反対のミスも同じくらいよく見られます。それは、LCP画像を遅延読み込みすることです。約15%のサイトがこれを行っており、結果としてページ上で最も重要な画像の読み込みが速くなるどころか、逆に遅くなってしまいます。

2. サードパーティ製フォント

Webフォントは素晴らしいものです。ページの見た目や雰囲気をカスタマイズし、向上させてくれます。しかし残念ながら、Google Fontsのようなサードパーティのプロバイダーを使用しても、あなたの特定の状況に合わせてフォントが最適化されるわけではありません。

サードパーティ製のフォントは、追加のレンダリングブロックとなるスタイルシートや、Webサーバーへの新たな接続（オリジンサーバーとはすでに非常に高速な接続が確立されているにもかかわらず）を必要とし、さらには実際に使用する以上のフォントをブラウザに追加する可能性があります。

フォントをセルフホストし、それらをプリロードして、各フォントファイルにカスタムのフォント読み込み戦略を割り当てる方がはるかに理にかなっています。これもまた、すぐに実践できる改善の1つです！

3. サードパーティ製スクリプト

サードパーティ製スクリプト自体に悪いところはありませんが、ページへの追加方法が原因で多くの問題を引き起こします。私は、重要ではないサードパーティ製スクリプト（Facebookのトラッキングピクセル、ソーシャルメディアのボタン、評価ウィジェットなど）が、実際にページ全体のレンダリングをブロックしているケースに遭遇することがあります。

ブラウザがより重要な作業を終えるまで、これらのスクリプトを遅延させてスケジューリングするのは比較的簡単であり、理にかなっています。最終的に、サイトの重要な部分は何も変えておらず、見た目も同じままですが、読み込みははるかに速くなります。私は単に、処理が行われる順序を変えただけです。

4. 背景画像

Core Web Vitalsの観点から見ると、背景画像を使用することはあまり理にかなっていません。背景画像にはネイティブの遅延読み込みのサポートがなく、レスポンシブでもありません。さらに、そのタイミングや優先度を制御することもほとんどできません。

いくつかの簡単な修正を加えることで、これらの背景画像を通常の画像に変換し、遅延読み込みを可能にし、レスポンシブにして優先度を調整することができます。これにより、Largest Contentful Paintが確実に向上します。

5. 巨大なスタイルシート

スタイルシートはレンダリングブロックのリソースです。つまり、ブラウザがスタイルシートを読み込んでいる間、ページは真っ白なままになります。これを修正するためにできることはたくさんあります。例えば、未使用の CSS を削除する、スタイルシートを分割する、ブラウザのキャッシュを改善する、あるいは Critical CSS を追加するなどです。

スタイルシートを改善すれば、Largest Contentful PaintとFirst Contentful Paintは劇的に改善されるでしょう！

設計による遅延

設計による遅延こそが、あなたが心配すべき部分です。あなたはページを遅くするような構造的な選択をしてしまったのです。これらは通常、UXデザインの選択や、ページの目に見える部分を大きく変更するような JavaScript のコードに関係しており、優れた回避策は存在しません。

「設計による遅延」の問題点は、小さな変更を加えるだけではすぐには修正できないことです。より綿密な計画と、サイトのコア機能のいくつかの書き直しが必要になります。

私が最初に行うべきことは、その意図を探ることです。なぜこれを行ったのか？どのような検討事項があり、具体的に何を達成したかったのか？ そして、そのパラメーターの範囲内でより良い代替案を見つけるのです！

以下は、最も一般的な「設計による遅延」のミスの例です。

1. スライダー

スライダーは通常、次のように機能します：ページがレンダリングされる際、JavaScript がスライダーをページに注入します。この JavaScript がないと、ページはまったく違った見た目になります。これにより、Largest Contentful Paintが遅くなり、おそらく Layout Shift が発生し、高い確率でInteraction to Next Paint (INP)の問題を引き起こします。

手っ取り早い解決策はありません。JavaScript を遅延させればペイントの指標は改善しますが、スライダーの表示が遅れ、Layout Shift を引き起こします。スライダーのスクリプトをクリティカルなものにすれば Layout Shift は解決しますが、ペイントの指標が遅くなります。

解決策は、ページをプログレッシブエンハンスメントで構築することです。まず、JavaScript なしでもスライダーがレンダリングされるようにし、その後ページを拡張して、すでに存在しているスライダー画像を完全なスライダーに変換します。

面白いことに、実際にスライダーをクリックする訪問者はわずか約1%にすぎません。私がこのことを説明すると、10回中9回は、サイト所有者がすぐにスライダーの削除を提案してきます。だからこそ、これらのスライダーの意図や検討事項について尋ねることが重要なのです。大抵の場合、それらは「ただそこにあっただけ」なのです。

2. 商品の拡大（ズーム）

商品のズーム機能は次のように機能します：一般的なオンラインショップで商品画像にカーソルを合わせると、商品の一部を拡大して見ることができます。「商品のズーム」は通常、スライダーと同じ問題を抱えています。JavaScript のコードが画像を取得して非表示にし、それをズーム可能な画像としてページに書き直します。これにより、Largest Contentful Paintが遅くなり、おそらく Layout Shift が発生し、高い確率でInteraction to Next Paint (INP)の問題を引き起こします。

スライダーと違うのは、プロダクトオーナーが「ああ、この機能は単に削除しよう」と言うことは決してないという点です。これは重要であり、コンバージョンを高める機能だからです。

解決策はスライダーの修正と同じです。ズームのスクリプトは元の画像を非表示にするのではなく、商品画像の機能を拡張するべきです。残念ながら、ズーム機能は簡単に修正できることは少なく、完璧に機能させるためにはある程度の作業が必要になります。

3. インラインの jQuery / インラインの JavaScript 依存関係

インラインの jQuery は、当初は「ミスによる遅延」として始まりましたが、時間の経過とともに悪化した問題です。私が見るサイトの約50%がこの問題に苦しんでいます。W3Techsによると、jQuery は依然としてすべてのウェブサイトの約70%で実行されているため、これがすぐになくなることはありません。インラインスクリプトは以前のスクリプト（通常は jQuery）に依存しているため、もうjQueryを遅延させることはできません。これにより、すべてのペイントの指標が遅延します。

修正は簡単です：これらのスクリプトを外部スクリプトに移動するだけです。これで、jQuery とカスタムスクリプトの両方を遅延させることができます。

では、なぜ私がこれを「設計による遅延」のカテゴリーに入れたのでしょうか？私が意図と検討事項について尋ねると、大抵「あぁ、わからない」という答えが返ってきます。そして、それこそが本当の問題なのです。JavaScript がどのように機能するかについての知識が不足しているのです。私は、このミスが将来も繰り返されるだろうと確信しています。つまり、解決策は修正することと同じではありません。開発チームに対して、JavaScript の依存関係とタイミングについて教育する必要があるのです。

4. 巨大な（ヒーロー）画像

設計による遅延のもう1つの問題は、巨大な画像です。一部のサイトでは、多くのフルサイズの画像を使用して「オーディエンスを驚かせる」必要があります。ポスターを販売していると想像してみてください。おそらく、高品質で巨大な画像を訪問者に提供したいと思うでしょう。これらの画像は、どれほど最適化しても、小さな画像よりも常にダウンロードに時間がかかります。

この時点で（画像がすべて最適化されていると仮定して）私にできる唯一のことは、調整の余地があるかどうかを確認することです。本当に4K画像が必要ですか？それともフルHDでも十分でしょうか？実用的なテクニックについては、遅いヒーロー画像を修正する方法をご覧ください。

5. インタラクティブなマップ

私が頻繁に遭遇するもう1つの問題は、インタラクティブなマップです。ページにインタラクティブなマップがある場合、そのページの目的全体が、訪問者にマップを操作してもらうことです。当然のことながら、そのマップが読み込まれるまでにはある程度の時間がかかります。

これを回避する方法はありません。私たちはある程度の遅延を受け入れる必要があります。しかし、私たちにできることはあります。マップが最も高い優先度で読み込まれるようにすることはできます。通常、これらのページは JavaScript の早期実行向けに最適化されていません。このケースでは、それは誤った選択でした。スクリプトを可能な限り早くダウンロードして実行させる必要があります！私は、PageSpeed を落とさずに Google Maps を埋め込む方法についての完全なガイドを書きました。

6. 遅い API

遅い API から生じる設計による遅延の問題は、通常、React、Next.js、Angular などの SPA サイトで見られます。コンポーネントがユーザーのインタラクションの後に遅れてレンダリングされるため、遅い API は通常、大規模な Layout Shift を引き起こします。このような問題は通常、複数のチームにまたがるアプローチを必要とします。

Core Web Vitals に関して言えば、ミスによる遅延と設計による遅延を区別することは有用です。ミスによる遅延は通常簡単に修正できますが、設計による遅延にはより徹底した多角的なアプローチが必要になります。「ミスによる遅延」の問題を分類して修正したら、Real User Monitoring を設定してその影響を追跡しましょう。フィールドデータは、あなたの修正が実際の訪問者の体験を本当に改善したかどうかを教えてくれます。そうすれば、「設計による遅延」の問題は、残された課題としてあなたのデータの中で明確に浮かび上がってくるでしょう。