ソーシャルウォール 
フィード分析 
PageSpeed Insightsを実行したところ、レポートが真っ赤に点灯しました。その原因は？ ソーシャルメディアの埋め込みが、スコアを低下させている要因として指摘されたのです。そして、見つける記事のどれもが同じことを言っています。「削除すればいい」と。
この問題に直面している多くのサイト運営者と話をしました。彼らは自分のフィードをとても気に入っています。それはコンバージョンにつながる「ソーシャルプルーフ」だからです。しかし、サイトの表示が遅くなる原因になっているのではないかと心配しており、できれば削除したくないと考えています。
そこで、自分でテストを行ってみました。WordPressサイト1つについて、生の埋め込みとプラグインによるフィードを比較し、PageSpeed Insights、Chrome DevTools、Pingdomを使って測定しました。
その数値には私自身も驚かされました。あるテストでは、埋め込みを置き換えただけでページのサイズが90％近く削減され、ブロッキング時間が4,510ミリ秒からゼロに短縮されました。
フィードがフラグ付けされた理由、そのコスト、そしてCore Web Vitalsの基準を満たしている間もフィードを維持する方法について解説します。難しい方法と簡単な方法がありますが、その両方について説明します。
- 【クイックアンサー】SNSのフィードは削除すべき？
- PageSpeedがフィードに警告を表示した理由（想像していることとは違います）
- なぜ「単に削除する」という方法は間違った解決策なのか
- ソーシャルフィードの実際のコストとは（実際に測定してみました）
- この問題を解決する「難しい方法」と「簡単な方法」
- Smash Balloonのフィードが各指標をどのように支えているか
- これは他のSmash Balloonのフィードでも有効ですか？（はい — 対処法は同じです）
- フィードを維持しましょう。コア・ウェブ・バイタルをクリアしましょう。今すぐ始めましょう。
【クイックアンサー】SNSのフィードは削除すべき？
いいえ。何も削除する必要はありません。
フィード自体が本当の問題だったわけではありません。問題は、あなたが貼り付けた生の埋め込みコードにあります。そのサードパーティ製のiframeやoEmbedは、ユーザーが何かをクリックする前から、プレイヤー全体を読み込んでしまうのです。
その生の埋め込みコードを、WordPressネイティブのフィードに置き換えてください。これにより、画像が遅延読み込みされ、プレーヤーの読み込みも遅延されるため、埋め込みが正常に機能していても、ページの読み込みが速くなります。
各修正で保護される内容は以下の通りです：
- iframeは使わず、画像を遅延読み込みし、WebP形式で配信しましょう。これが実証済みの改善策です。これによりページの容量が削減され、Largest Contentful Paint（LCP）の表示速度が向上します。まさに、生の埋め込みコードでは遅れをとっていた部分です。
- 各画像用にスペースを確保してください。これにより、レイアウトが固定され、累積レイアウトシフトが抑制されます。
- 誰かがクリックするまで、サードパーティ製プレーヤーの読み込みを遅らせる。これにより、ブラウザの動作が重くなるのを防ぎ、ページの応答性を維持し、読み込み中にページがフリーズするのを防ぐことができる。
これを成し遂げるには、難しい方法と簡単な方法があります。ここではその両方を紹介します。結局、簡単な方法の方が優れています。
PageSpeedがフィードに警告を表示した理由（想像していることとは違います）
なぜPageSpeedは、特にあなたのソーシャルフィードを問題視したのでしょうか？それは、単にフィードを追加しただけではないからです。メディアプレーヤーそのものを追加してしまったからです。
ここで、多くの人が見落としがちな点があります。InstagramのoEmbedやYouTubeの埋め込みは、単に静かに写真を表示するだけではありません。ページが読み込まれるやいなや、そのプラットフォームのプレイヤー全体、スクリプト、iframeを読み込んでしまうのです。
誰かがクリックした時ではありません。誰かが何かをする前のことです。
そこで、ブラウザはページのレンダリングを中断し、まずInstagramやYouTubeのコードを取得しに行きます。その取得処理は負荷が高く、しかも最悪のタイミングで発生してしまうのです。
私がWordPressサイトで実施したPingdomテストでは、9つのYouTube埋め込みコードが、再生ボタンを押す前から約7.5 MBのプレイヤーコードを読み込んでいました。
これはページの負荷の約92％を占めていました。ただプレイヤーがそこに座って、読み込み中だっただけです。
これが「Largest Contentful Paint（LCP）」に影響を与える要因であり、これはメインコンテンツが読み込まれる速さを示す指標です。プレイヤーが本来のコンテンツの前に割り込んでしまい、訪問者を待たせてしまうのです。
さて、埋め込みが複数あるページを想像してみてください。それぞれが、そのすべてを繰り返しています。
そのスクリプトのすべてが、メインスレッド――ブラウザがクリックやタップに応答するために使用する唯一の処理経路――を占有してしまいます。これが詰まってしまうと、さらに2つの点で悪影響が生じます：
- 「Next Paint」への反応。これは、ユーザーがタップした際にページがどれほど速く反応するかを示す指標です。
- 累積レイアウトシフト（Cumulative Layout Shift）とは、後続のコンテンツが表示される際に、画面上の要素が飛び回る現象のことです。
つまり、PageSpeedの指摘は間違っていない。ページの読み込みが遅いことを正しく検知しているのだ。ただ、実際の負荷の原因はページに組み込まれたサードパーティ製のプレーヤーにあるにもかかわらず、PageSpeedは単に「フィード」を指摘しているに過ぎない。
フィードは必要な部分です。プレイヤーの負荷は不要な部分です。
なぜ「単に削除する」という方法は間違った解決策なのか
ここには正しい部分が半分あります。Rawの埋め込みは確かに遅いです。私自身のテストでもそれが証明されました。その数値を以下に示します。
フィードがあなたにもたらす効果について考えてみてください。それは「ソーシャルプルーフ」です。実際に製品を使っている人々の姿、本物のレビュー、本物の投稿がそこに映し出されています。それが信頼を築き、その信頼が売上につながります。
スピードテストに合格するためにそれを削除するのは、得策ではありません。グリーンスコアは獲得できても、コンバージョンにつながる要素を失うことになります。
つまり、本当の選択肢は「残す」か「削除する」かというものではなかった。それは誤った二者択一だ。
本当の選択はこれです：
- 未加工の埋め込みコンテンツは、プラットフォームの重いプレーヤーに読み込まれ、パフォーマンスを低下させてしまいます。
- ネイティブプラグインのフィードでは、同じ投稿が表示されますが、画像は遅延読み込みされ、プレーヤーの読み込みは後回しにされます。
同じフィード。同じソーシャルプルーフ。しかし、そのスピードは大きく異なり、訪問者により良い体験を提供します。
読み進めてください。ここからのすべての修正は、その1つの変更に基づいています。
ソーシャルフィードの実際のコストとは（実際に測定してみました）
理論についてはすでにご存知でしょう。それでは、具体的な数値をご紹介します。
公開されているWordPressサイトで、一方のバージョンでは生の埋め込みを、もう一方のバージョンではプラグインのフィードを使用するという形で、実際のテストを実施しました。測定にはPageSpeed Insights、Chrome DevTools、Pingdomを使用しました。
9つのYouTube埋め込みタグが当該ページに与えた影響と、プラグインのフィードがどのように変更されたかを以下に示します：
| 私が測定した内容 | Rawの埋め込み | プラグインのフィード |
|---|---|---|
| YouTubeのコードが読み込まれました | 8.8 MB（ページ容量の92%） | 457 KB（約95％減少） |
| 総ブロック時間 | 4,510ミリ秒 | 0ミリ秒 |
| モバイル速度指数 | 15.1s | 4.9s |
| モバイル版 PageSpeed スコア | 49 | 72 |
| デスクトップ版のPageSpeedスコア | 52 | 99 |
一番上の行を見てください。誰かが「再生」ボタンを押す前に、8.8 MB近くのYouTubeプレーヤーのコードが読み込まれています。
これはページ全体の約92%に相当しました。プラグインのフィード機能により、その容量はおよそ95%削減され、457 KBになりました。
「合計ブロッキング時間」が 4,510 ミリ秒から 0 になりました。これは、ページがフリーズしてタップに反応できなくなる時間のことです。これは「次のペイントまでのインタラクション時間」と直接関連しています。
そこで、確認のためにPingdomでページ全体をチェックしてみました。その結果も一致していました。埋め込みページの生データは、176回のリクエストで合計8.4 MBでした。
これに対し、WordPressプラグインのフィードページは、42回のリクエストで合計1.1 MBでした。
同じページでテストした2つの異なるツールが、同じ結果を示しました。
Instagramでも、より小規模ながら同様の現象が見られました。正常に動作するiframeの埋め込みでも、モバイル版の「Largest Contentful Paint」が3.2秒を記録しました。これは不合格です。
しかし、プラグインのフィードに埋め込まれたInstagramの投稿については、同じ数でも2.3秒でした。
率直に申し上げておきます。そうすれば、その後の内容も信頼していただけるでしょう。ここでいくつか注意点があります。
- 実験室でのテストでは、一部の未加工の埋め込み動画で動画のLCPが低く表示されることがありました。これは測定上の誤差によるものでした。テストに使用したブラウザでは、サムネイルをレンダリングできなかったためです。実際の訪問者にとっては、LCPはより高くなるでしょう。
- InstagramのLCP値は1回のテスト結果に過ぎないため、最終的な判断ではなく、参考となるデータとして捉えてください。
- これはあくまで一例です。実際の数値は、使用しているテーマ、ホスティングサービス、コンテンツによって異なります。
あえて弱点を指摘しているんです。重要なのは、たった一つの完璧な数値ではありません。重要なのは、その差の大きさであり、2つのツールがその点で一致しているかどうかです。
ご自身のサイトを確認してみたいですか？PageSpeed Insightsを実行し、Chrome DevToolsを開き、Pingdomでページをテストしてみてください。私が使用したのと同じ3つのツールです。上記の数値はすべて、再度確認することができます。
この問題を解決する「難しい方法」と「簡単な方法」
つまり、フィードを維持しつつ試験に合格したいということですね。そのための方法は2つあります。
1つは手動です。すべての修正を手作業で行います。もう1つは、それらの修正を自動的に行ってくれるプラグインです。
どちらも有効です。しかし、必要な労力は同じではありません。それぞれに実際にどれだけの労力がかかるのか、ご説明しましょう。
手動での方法：自分でコードを書く
これを自分で手作業で修正したいですか？ 可能です。ただ、コードの量が膨大で、終わりが全く見えないのです。
「自分でやる」とはどういうことか、簡単に説明するとこうなります。以下の各項目を、一つずつ順にこなしていく必要があります：
- oEmbedを削除してください。容量の大きいプレーヤーを読み込む生の埋め込みコードを削除してください。
- サムネイルを独自にホストします。各画像をダウンロードし、自分のサイトから配信してください。
- すべての画像に幅と高さを指定してください。これによりスペースが確保され、レイアウトがずれるのを防ぐことができます。
- ファサードを作成してください。偽のプレイヤー画像を表示し、ユーザーがクリックしたときにのみ、実際のYouTubeプレイヤーを読み込むようにしてください。
- 画像を遅延読み込みします。スクロールして画面内に表示されるまで、ブラウザに画像の読み込みをスキップするよう指示します。
- 各画像を手作業でWebP形式に変換します。私のテストでは、この軽量な形式が効果的でした。
これがその構成です。さて、ここからが誰も教えてくれない部分です。
これらすべてをメンテナンスし続けなければなりません。InstagramやYouTubeがマークアップを変更するたびに、コードが動作しなくなる可能性があります。そうなると、またそのコードを修正し直さなければなりません。
それは立派な仕事だ。誠実な仕事だ。だが、その仕事にはいつまでも手をかけていなければならないだろう。
簡単な方法：WordPressネイティブのフィードプラグイン
もっと簡単な方法があります。Smash BalloonのようなWordPress標準のフィードプラグインを使えば、上記の手順をすべて自動的に行ってくれます。
コーディングは一切不要です。このプラグインは、埋め込みコードを削除し、画像を独自ホスティングして遅延読み込みを行い、表示スペースを確保し、WebP形式で配信し、クリックがあるまでプレイヤーの表示を遅延させます。これらすべてを、プラグインが自動的に行います。
これでマニュアル設定の一覧はすべて完了です。すべて自動的に処理されます。技術に詳しくない方でも、簡単に設定できます。
そして、このアプリを利用したのはあなたが初めてではありません。「Smash Balloon」には175万人以上のアクティブユーザーがおり、5点満点中4.9点の評価を得ています。
こうした導入状況からは、あることがうかがえます。多くのサイト運営者はすでに「手っ取り早い方法」を選んできましたが、それが十分に機能してきました。次に、各指標を具体的にどのように保護しているのか、詳しくご説明しましょう。
Smash Balloonのフィードが各指標をどのように支えているか
では、1つのプラグインで、これら3つの指標をすべて同時に改善できるのでしょうか？その理由は、指標を悪化させている根本的な原因、つまり「初期段階での負荷」に直接対処しているからです。
各修正はメトリックに対応しています。以下に平易な説明を示します。
| メカニズム | 機能 |
|---|---|
| サードパーティのプレーヤーやiframeが最初に読み込まれない | 誰かがクリックする前に、冗長なプレイヤーコードを削除する |
| WebP画像の最適化 | より軽量な画像を配信し、ダウンロードを高速化します |
| 遅延読み込みとスマートキャッシュ | 必要なときにのみ画像を読み込み、その後キャッシュに保存しておく |
一番上の行を見てください。その1つの変更こそが、私のテストの結果をすべて物語っています。
再生ボタンを押す前から、9つの未加工のYouTube埋め込みコードによって、約8.8 MBのプレイヤーコードが読み込まれていました。
プラグインのフィードはその部分をスキップし、代わりにサムネイルを表示しました。YouTubeのデータ使用量は約95%減少し、457 KBになりました。
読み込むデータ量が少ないほど、メインコンテンツが際立ちます。つまり、Largest Contentful Paintの基準をクリアできるということです。
2つ目は画像そのものです。「Smash Balloon Instagram Feed Pro」は、写真をより軽量な形式であるWebPで配信します。画像が軽量であればあるほど表示が速くなり、これもまたLCPの向上につながります。
3つ目は、タイミングと再利用です。画像は、訪問者がスクロールするにつれて読み込まれ、一度にすべて読み込まれるわけではありません。キャッシュされた画像は、次回の訪問時に素早く読み込まれます。
これが、ラボの数値がそのような動きをした理由です。フィードが魔法のように軽くなったわけではありません。誰かがそれを要求するまで、プレイヤーが読み込まなかったため、軽くなったのです。
訪問者が目にするのと同じ投稿。あなたが築き上げたのと同じソーシャルプルーフ。しかし、その影響力ははるかに小さい。
これは他のSmash Balloonのフィードでも有効ですか？（はい — 対処法は同じです）
これはInstagramでのみ有効なのでしょうか？いいえ。Smash Balloonのすべてのフィードで同じ対処法が適用されます。
YouTubeの場合、姉妹プラグインは「YouTube Feed Pro」です。機能も結果も同じで、サムネイルが先に表示され、必要に応じてプレーヤーが表示されます。
根本的な原因は決して変わらない。生の埋め込みコードでは、プラットフォームの重いプレーヤーが最初に読み込まれてしまう。
一方、YouTube Feed Proではサムネイルが表示され、ユーザーがクリックするまでプレーヤーの表示は保留されます。
テストの結果から、YouTubeがこの中で最も問題が多いサービスであることを覚えておいてください。
再生ボタンを押す前に、9つの未処理のYouTube埋め込みコードが約8.8 MBのプレーヤーコードを読み込みました。「合計ブロック時間」は4,510ミリ秒でした。
YouTube Feed Pro を使用することで、その状況が一変しました。サムネイルには同じ動画が表示され、クリックしたときにのみプレーヤーが読み込まれるようになりました。YouTube のリソース使用量は約 95% 減少し、総ブロック時間は 0 ミリ秒にまで低下しました。
それだけではありません。Smash Balloonのフィードプラグインはすべて、高速性と読み込みの速さを重視して開発されています。対象となるのは、Facebook、Instagram、TikTok、YouTube、そしてX（旧Twitter）です。
今すぐフィードの表示速度を向上させましょう
フィード用に「Smash Balloon」プラグインを導入して、ソーシャルプルーフを理想的な状態に保ちつつ、Core Web Vitalsの指標を良好な状態に維持しましょう。
よくある質問
埋め込みを削除すると、ページ上のフィードは消えてしまいますか？
いいえ、埋め込みを削除しても、ページ上のフィードが消えることはありません。Smash Balloonなどのツールを使って、プラグインのフィードブロックやショートコードに切り替えるだけです。投稿の内容も表示位置も同じまま、負荷が大幅に軽減されます。
プラグインを追加すると、サイトの表示速度がさらに遅くなってしまうのではないでしょうか？
すべてのプラグインがサイトの表示速度を低下させるわけではないため、適切なものを選べば、さらに表示が遅くなることはありません。生の埋め込みコードでは、プラットフォームのプレイヤー全体が最初に読み込まれます。一方、プラグインによるフィードでは、画像を遅延読み込みし、プレイヤーの読み込みを先送りします。そのため、私のテストではページの重量が87％近く軽減されました。
自分のフィードが本当に問題なのか、どうすればわかりますか？
フィードに問題があるかどうかは、数分で確認できます。PageSpeed Insights を実行し、次の 2 点を確認してください。LCP 要素と、最大のネットワーク転送量です。フラグが立てられた要素が埋め込みコンテンツである場合、または最大の転送量がプレーヤーのスクリプトである場合は、それが原因です。
ソーシャルフィードの表示速度を改善するには、コードを修正する必要があるのでしょうか？
いいえ、コードをいじる必要は一切ありません。プラグインをインストールし、アカウントを連携させ、ブロックを1つ貼り付けるだけです。技術に詳しくない方でも、これだけで完了です。
フィードを維持しましょう。コア・ウェブ・バイタルをクリアしましょう。今すぐ始めましょう。
ここで覚えておくべきことが一つあります。フィード自体に問題があったわけではありません。問題は、ユーザーがクリックする前からプラットフォームのフルプレイヤーを読み込んでしまう、生の埋め込みコードにあったのです。
その埋め込みコードを、Smash Balloonのようなソーシャルフィードプラグインに置き換えてみてください。そうすれば、ソーシャルプルーフを適切な場所に維持したまま、サイトの表示速度が向上するのを実感できるでしょう。
ですから、フィードを削除する必要はありません。そのまま残しておき、代わりに軽量な方法で読み込ませましょう。
最も手軽な方法は「All Access Bundle」です。このバンドルにはSmash Balloonのすべてのフィードプラグインが含まれているため、Instagram、YouTube、Facebook、TikTok、Xのいずれを利用している場合でも、すべて対応しています。
「オールアクセス・バンドル」を手に入れ、埋め込みコードを切り替えれば、PageSpeedレポートが緑色に変わるのを確認できます。
