ソーシャルフィードプラグインと埋め込みウィジェットの比較：両方を試してみた（本当の違いとは）

Instagramの埋め込みコードをページに貼り付け、数ヶ月間は問題なく表示されていたのに、ある時、フィードがあったはずの場所に真っ白な空白ができてしまったという経験があるなら、この記事で取り上げる問題について、すでにご存じでしょう。

WordPressでソーシャルフィードを運用している人のほとんどが、何らかの形でこの問題に直面します。フィードが真っ白になってしまい、ダッシュボードには修正すべき項目が何も表示されません。また、テーマのフォントが反映されないため、いつもどこか場違いな印象を与えてしまいます。

あるいは、更新作業は常に手作業だったため、その作業が後回しにされてしまい、投稿がどんどん古くなっていく一方で、何ヶ月も問題なく表示され続けることもあります。

初日では、そのいずれの兆候も見られない。どちらのアプローチも、初日時点では問題ないように見える。

つまり、この比較は6ヶ月目についてです。ページビューごとにそれぞれが何を読み込むか、ソースからの応答が途絶えた際にそれぞれが何を表示するか、そしてフィードが破損した際の修正がどこで行われるか――自分のダッシュボードか、それとも他者のダッシュボードか、という点についてです。

この記事の中で

ソーシャルフィードプラグインと埋め込みウィジェットの比較：簡単な答え

どちらもセットアップには10分ほどかかります。だからこそ、セットアップの時間を比較するのは適切ではありません。

ソーシャルフィードプラグインは、フィードデータをWordPressのインストール環境内に保存し、サイト独自のコードを使って表示します。一方、埋め込みウィジェットは、管理者が制御できない場所からデータを取得して表示します。

後になって問題となることのほとんどは、あの1つの分裂に起因している。

	ソーシャルフィードプラグイン	ウィジェットを埋め込む
フィードデータの保存場所	WordPressのインストール環境内	プラットフォームのサーバー上で
ページ上に表示される内容	サイト独自のHTMLおよびCSS	別の場所から読み込まれたブロックまたはiframe
ソースにアクセスできない場合	ローカルデータからのレンダリングを維持します	フィードがあったはずの空白部分
壊れたら、誰が直してくれるの？	ダッシュボード上のあなた	壊れたものの所有者は誰であれ

最後の行こそ、注目すべきところです。埋め込みが機能しなくなった場合、通常はその不具合の原因となっている部分はあなたのサイトには一切存在しないため、変更できる設定はなく、ただ待つしかありません。

ちょっと待って、埋め込みウィジェットってソーシャルフィードと同じものなの？

一言で言えば、いいえ。どちらもソーシャルメディアのコンテンツを埋め込むために使われますが、それらは別物です。

Instagramの埋め込みコードとは、個々の投稿からコピーするコードのことです。YouTubeやTwitter/Xのiframeも同様の仕組みです。プラットフォームからコードを取得し、自分のページに貼り付けると、そのプラットフォームがコンテンツを配信します。

その最後の部分がすべてです。ページ上に表示されているのは、ブラウザにどこからそのコンテンツを取得すればよいかを指示する単なるプレースホルダーに過ぎません。

つまり、ページが読み込まれるたびに、訪問者のブラウザはホストに対してページをリクエストし、そのプレースホルダーを読み取った後、まったく別の場所に対して2回目のリクエストを行うことになります。

そのラウンドトリップが完了して初めて、あなたの投稿が表示されます。それより一瞬でも早く表示されることはありません。

ソーシャルフィードは逆の仕組みで動作します。プラグインがアカウントに接続し、投稿をWordPress環境に取り込み、そこに保存します。ユーザーがページを読み込むと、フィードはすでにページ内に表示されています。取得する必要も、誰かの応答を待つ必要もありません。

もう一つの違いは、そもそもページに何を掲載するかという点です。埋め込みは、貼り付けた瞬間の状態が固定された1つの投稿です。一方、フィードは、投稿を行うたびに自動的に更新される、継続的な投稿の集合体です。

だからこそ、この2つはよく比較されるものの、入れ替わることはめったにありません。一方は特定の投稿を表示するためのもので、もう一方は最後に投稿したものを表示するためのものです。

フィードがすでに正常に動作している状態で、実際には何が故障するのか

フィードについて話をしたサイト運営者のほぼ全員が、同じような経緯を語ります。設定は問題なく完了しました。数ヶ月後、何か問題が発生しました。そして、それを修正しようとしたところ、ダッシュボードには修正すべき項目が何もなかったことに気づいたのです。

その話には、3つのバージョンが繰り返し語られている。興味深いのは、失敗そのものではない。それに対して何か手を打つことができたのは誰か、ということだ。

かつてフィードがあった空白のスペース

これは、無音の部分が最も長いものです。フィードのレンダリングが停止し、投稿があったはずの場所には空白が残っています。

そのような事態が発生しても、誰にも通知は届きません。WordPressはフィードがなくなっていることを認識しません。というのも、インストール環境の観点からは、サイト上の何も変わっていないからです。

つまり、人々は偶然その事実を知るのです。訪問者がそのことを口にすることもありますし、あるいは数ヶ月後、全く別の理由でそのページを編集している最中に、その抜けに気づくこともあります。

テーマを無視するフィード

これは失敗ではない。じわじわと募る苛立ちが、やがて一つのプロジェクトへと変わるのだ。

サイト運営者は、フィードのデザインが場違いに見えることに気づきます。フォントが違っていたり、リンクの色が違っていたり、角が丸すぎたり、逆に丸みが足りなかったりします。そのサイトには独自のデザインがあるのに、フィードは明らかにそのデザインに馴染んでいないのです。

そこで彼らはスタイルを変更しようと試みるのですが、そこで手が止まってしまいます。そのスタイルは、テーマのカスタマイザーやブロックの設定にはありません。というのも、そのマークアップは彼らのものではないからです。どこから読み込まれたにせよ、すでにスタイルが適用された状態で届いているのです。

故障することなく古くなってしまったフィード

これが一番厄介なものなので、空白のブロックとは区別しておく価値があります。

空白のブロックが表示されています。明らかに何かが欠けているため、遅かれ早かれ誰かがそれを報告することになるでしょう。古いフィードでは何も表示されません。フィードがレンダリングされます。画像が読み込まれます。レイアウトは正常に見えます。

その投稿は、わずか3ヶ月前に投稿されたものです。

これは、埋め込みフィードが単なるフィードではないためです。それは、ページを作成した当日に埋め込んだ投稿の数であり、その投稿がそのまま維持されるのです。

新しい動画を公開しても、その動画はサイトではなくチャンネルに表示されます。その動画を自分のページに表示させるには、一度戻って別の埋め込みコードをコピーし、それを貼り付けるしかありません。

1ヶ月目ならそれでいい。しかし8ヶ月目になると、それはいつの間にかやることリストから消えてしまった面倒な作業となり、何も壊れていないため、誰も気づかない。

この件はひどい結果になった。そのサイトではキャンペーンを実施中だが、トップページにはフィードが表示されており、その最新記事は1シーズン前のものだった。訪問者全員がそれを見ていた。報告すべき点など何一つなかったため、誰も報告しなかった。

これら3つすべてに共通するパターンです。空白部分、スタイルの不統一、古くなった投稿。いずれの場合も、必要な作業はダッシュボードでは対応できないものでした。

つまり、そのまま待つか、その状態を受け入れるか、あるいはそもそもフィードがページに表示される仕組み自体を変えるかのいずれかです。

ソーシャルフィードとウィジェットを試してみました：その結果はこちらです

ここまでは、フィードデータの保存場所について説明してきました。このセクションでは、その内容を具体的な数値に落とし込んでいきます。

WordPressのステージングサイトに2つのページを作成しました。テーマも、ページテンプレートも、レイアウト上の配置も同じです。一方のページでは、生の埋め込みコードが動作していました。

もう一方は、Smash Balloonのプラグインフィードを運用していました。コンテンツも投稿数も同じです。そこで、両方をPageSpeed Insights、Chrome DevTools、Pingdomで測定してみました。

まずはページ全体から始めましょう。なぜなら、そこが誰も予想していない部分だからです。

	Raw埋め込みページ	プラグインの埋め込み
ページサイズ	8.4 MB	1.1 MB
リクエスト	176	42

8.4 MBのページは、単に読み込みが遅いというわけではありません。これは、何か巨大なデータをダウンロードしているページであり、その原因を説明できるほど大きな要素は、そのページ内のフィードだけなのです。そこで、実際に誰がデータを送信しているのかを確認するために、ペイロードをドメインごとに分類してみました。

ページの埋め込み、ドメインごとのコンテンツサイズ：

ドメイン	サイズ	ページのシェア
www.youtube.com	7.5 MB	91.31%
fonts.gstatic.com	292.3 KB	3.56%
www.google.com	211.5 KB	2.58%
c0.wp.com	71.4 KB	0.87%

一番上の行をもう一度読んでみてください。そのページの91.31%はYouTubeから配信されていました。私のWordPressインストール環境が提供したのは、テーマ、テキスト、私がアップロードした画像だけで、それ以外の要素は実質的にゼロでした。そのページの大部分は、他者のサーバーによって構成されていたのです。

プラグインのフィードページ、連絡先のドメインは同じ：

• www.youtube.com — widgetapi.js 9 KiBで、 iframe_api 4 KiBで、どちらも誰かがクリックするまでプレーヤーは読み込まれません
• i.ytimg.com — サムネイル（1つあたり約49～57 KiB）

これが外部への影響のすべてです。プラグインのページは依然としてYouTubeと通信していますが、ページそのものをYouTubeに引き渡すことはありません。プレイヤーが表示されるのは、訪問者が動画をリクエストしたときであり、それ以前ではありません。

DevToolsは、サードパーティの視点から同じことを示しており、さらに実際に痛手となる部分も付け加えています。

第三者費用	Raw埋め込みページ	プラグインのフィードページ
YouTubeのペイロード	8,772 KiB	457 KiB
メインスレッドの時間	6,036ミリ秒	—
総ブロック時間	4,510ミリ秒	0 ms

ペイロードは約95%減少しました。しかし、私が注目したいのは、「総ブロッキング時間」が4,510ミリ秒から0ミリ秒に短縮されたという点です。というのも、これはダウンロードサイズとは全く関係がないからです。

これは、サードパーティ製のJavaScriptの実行によってブラウザのメインスレッドが占有されている状態であり、その間、ページはタップやスクロールに応答できなくなります。「一見問題なさそうだった」ページで、この状態が4.5秒も続いたのです。

実際に走られるタイムにまとめると：

	以前（iFrame埋め込み）	（プラグインフィード）の後
PageSpeed（モバイル版）	49	72
PageSpeed（デスクトップ版）	52	99
モバイル速度指数	15.1s	4.9s

注目すべきは「モバイル・スピード・インデックス」です。15.1秒と4.9秒という差は、ユーザーが待っている間にページが表示される状態と、アクセスした時点でほぼ表示されている状態との違いに他なりません。

仕組みは他のケースと同じです。埋め込みページのフィードは、私が管理していないサーバー上にあったため、訪問者一人ひとりがその取得にかかる全額を負担することになり、ダッシュボードにはそのコストを削減できる設定が一切ありませんでした。

このプラグインのページは、WordPressのインストール環境にすでに存在するデータからフィードを提供していたため、取得する必要があったのは、訪問者が実際にリクエストしたメディアだけでした。

専門家からのアドバイス：さらに詳しく知りたい方は、ソーシャルメディアのフィードがウェブサイトの表示速度を低下させるかどうかについて、より詳しく解説したガイドをご用意しています。

そのフィードは、あなたのサイトにふさわしいものに見えますか？

埋め込み機能について、私が最もよく耳にする質問は、たいてい少し苛立ちをにじませた口調でこう言われます。「なぜ、これがサイトの他の部分とは全然違う見た目になっているの？」

同じ2つのステージングページで、どちらにも同じテーマが適用されています。Smash Balloonを使って作成したフィードを配置し、先ほどの手動埋め込みと比較してみました。

プラグインのフィードはテーマの設定を反映しています。見出しにはテーマで設定されたフォントが、リンクにはテーマで設定された色が使用されています。これは、そのマークアップがページ上の他のコンテンツと同様に、サイト独自のスタイルシートを通じてレンダリングされるためです。

埋め込みフィードはそうではありませんでした。別の場所で決定されたタイポグラフィや色が設定された状態で表示され、テーマの設定に関わらず、それらの設定が適用されてしまいます。

これが仕組みのすべてです。一方のフィードはサイト側でスタイルが適用され、もう一方はサイトに届く前にスタイルが適用されます。

プラットフォームがレンダリングを行わなくなった場合でも、プラグインフィードがレンダリングを継続する仕組み

この行より上のすべてが問題です。このセクションは、その問題に対する解決策を提示する仕組みです。各要素が、これまでに読んだ不具合とどのように対応しているかを以下に示します。

フィードのローカルコピーを保存します

Smash Balloonのような高品質なソーシャルフィードプラグインを使えば、WordPressのインストール環境内にフィードデータを保存するバックアップ・キャッシュシステムを利用できます。

Instagramがダウンしたり、APIからの応答が途絶えたりしても、このプラグインには表示用のコンテンツが用意されています。フィードに空白ができることなく、表示され続けます。

そこが、この投稿全体の成否を分ける違いです。プラグインのページには、データベースに投稿データが保存されているため、プラットフォームから応答がない場合でも、表示すべきコンテンツがあります。

しかし、埋め込みページにはプレースホルダーとアドレスがあり、そのアドレスから何も返ってこない場合、何も表示されません。

サードパーティのiframeは読み込まれません

Smash Balloonは、ページの表示速度を低下させるサードパーティ製のiframeを読み込むことなく、レンダリングを行います。

そのため、プラグインのページは外部ドメインへのアクセスが少なく、ファイルサイズも埋め込みページの8.4 MBに対し1.1 MBにとどまりました。取得すべきものが何もないため、リクエストチェーンは発生しません。

レイジーローディングとスマートキャッシュを採用しています

画像は、訪問者がスクロールしてその位置に到達した時点で読み込まれます。また、フィードデータがキャッシュされるため、ページが表示されるたびにサーバーがAPIを呼び出す必要がなくなります。

「トータルブロッキングタイム」の結果は以下の通りです：埋め込みページで4,510 ms、プラグインページで0 ms。

解決策は、あなた自身のダッシュボードにあります

コーディングは一切必要ありません。フィードの設定は、WordPressの管理画面内の、他の管理項目と同じ場所に表示されます。

私が最も重要視するのはこの点です。万が一何か問題が発生したとしても、すでにアクセス権限のある画面を開くか、サポートチームに連絡すれば済みます。一方、手動での埋め込みの場合、自分が管理できないインフラに依存することになり、ただ待つしかありません。

約175万人がWordPressサイトでSmash Balloonのフィードを利用しています。この事実が知っておく価値があるのは、主に、上記の障害パターンが実際に発生し、大規模なレベルで対処されてきたことを意味するからです。

では、どちらを使うべきでしょうか？

これを決定づけるのは、どちらの設定が簡単かということではありません。重要なのは、フィードに不具合が生じた際、その修正は自分のダッシュボードで行うのか、それとも他者のダッシュボードで行うのか、という点です。

実際に開発している内容に応じて、次のように回答します。

• 記事内に1つの投稿または1つの動画を埋め込む場合、プラットフォームの埋め込みコードを使用してください。これは更新を想定していない単一のコンテンツであるため、基本的ではあるものの機能に制限のあるオプションが適しています。
• 高速かつインデックス登録を早めたいページで、継続的なフィードを配信している場合、プラグインを利用しましょう。その理由は、この記事の前半で紹介したパフォーマンス数値にあります。8.4 MB 対 1.1 MB、176 リクエスト 対 42 リクエストという差です。ライブフィードはアクセスするたびに読み込まれるため、その負荷がどれほどであれ、繰り返し発生することになります。
• 毎週サイトにログインするわけでもなく、クライアントやフリーランサーに管理を任せてあるわけでもないでしょう。プラグインを活用しましょう。この場合の不具合は「何の前触れもない」というものです。エラー通知は表示されず、フィードの表示が突然止まるだけで、ページの読み込み自体は問題なく続きます。
• 複数のプラットフォームからフィードを配信しているのですね。プラグインを活用し、それらすべてに対応したものを使用しましょう。サイトごとに埋め込みコードが異なると、5通りの方法で不具合が発生する可能性があります。「Smash Balloon Social Wall」を使えば、これらすべてのプラットフォームのフィードを作成できるだけでなく、それらを1つのソーシャルウォールに統合することも可能です。

真の違い

最初はどちらもかなり似ているように見えますが、何か問題が発生した時にその違いが明らかになります。両方のフィードのソースにアクセスできないようにしたところ、プラグインのページでは、WordPressのインストール先に保存されているデータから投稿が表示され続けました。

埋め込みページには、代替となるローカルなデータが何もありませんでした。そこが最大の違いです。一方のアプローチでは、フィードデータを自社のサーバーに保管し、修正も自社のダッシュボードで行います。もう一方のアプローチでは、その両方が自社の手の届かない場所に保管されています。

継続的にフィードを配信しているなら、「Smash Balloon Instagram Feed Pro」は最適なスタート地点であり、世界一のビジュアルプラットフォーム向けのフィードを作成することができます。

Instagramフィードプロを入手

複数のプラットフォームのフィードを運用していますか？「オールアクセス・バンドル」なら、Instagram、Facebook、YouTube、Xの設定を1つの画面でまとめて管理できます。