Social-Feed-Plugin vs. Einbettungs-Widget: Ich habe beides getestet (das ist der eigentliche Unterschied)

Wenn du schon einmal den Einbettungscode von Instagram in eine Seite eingefügt hast, einige Monate lang beobachtet hast, wie er einwandfrei funktionierte, und dann an der Stelle, an der zuvor der Feed zu sehen war, nur noch eine leere weiße Lücke vorgefunden hast, dann kennst du das Problem, um das es in diesem Beitrag geht, bereits.

Die meisten Nutzer, die einen Social-Feed auf WordPress betreiben, stoßen irgendwann auf dieses Problem. Der Feed wird leer, und im Dashboard gibt es nichts, was man beheben könnte. Er ignoriert die Schriftarten Ihres Themes, sodass er immer etwas deplatziert wirkt.

Oder es wird monatelang munter weitergestaltet, während die Beiträge darin immer älter werden, weil die Aktualisierung immer manuell erfolgte und diese Aufgabe irgendwann von der Liste gestrichen wurde.

Am ersten Tag lässt sich davon noch nichts erkennen. Beide Ansätze sehen am ersten Tag gut aus.

Bei diesem Vergleich geht es also um den sechsten Monat. Was bei jedem Seitenaufruf geladen wird, was angezeigt wird, wenn die Quelle nicht mehr antwortet, und wo die Lösung zu finden ist, wenn der Feed ausfällt: in Ihrem Dashboard oder in dem eines anderen.

In diesem Artikel:

Social-Feed-Plugin vs. Einbettungs-Widget: Die kurze Antwort

Beide lassen sich in etwa zehn Minuten einrichten. Deshalb ist die Einrichtungszeit kein geeigneter Vergleichsmaßstab.

Ein Social-Feed-Plugin speichert Ihre Feed-Daten in Ihrer WordPress-Installation und stellt sie mithilfe des Codes Ihrer Website dar. Ein Einbettungs-Widget wird von einer Quelle aus dargestellt, auf die Sie keinen Einfluss haben.

Fast alles, was später schiefgeht, lässt sich auf diesen einen Bruch zurückführen.

	Plugin für Social-Media-Feeds	Widget einbetten
Wo sich die Feed-Daten befinden	In Ihrer WordPress-Installation	Auf den Servern der Plattform
Was wird auf der Seite dargestellt?	Der HTML- und CSS-Code Ihrer Website	Ein Block oder Iframe, der von einer anderen Stelle geladen wurde
Wenn die Quelle nicht erreichbar ist	Führt das Rendern anhand lokaler Daten durch	Leerzeichen an der Stelle, an der der Feed stand
Wer kann es reparieren, wenn es kaputt geht?	Sie in Ihrem Dashboard	Wem auch immer das kaputte Ding gehört

Auf diese letzte Zeile würde ich besonders achten. Wenn eine Einbettung nicht mehr funktioniert, befindet sich das fehlerhafte Element in der Regel gar nicht auf Ihrer Website. Es gibt also keine Einstellung, die Sie ändern könnten, und Ihnen bleibt nichts anderes übrig, als abzuwarten.

Moment mal, ist ein Einbettungs-Widget dasselbe wie ein Social-Feed?

Kurze Antwort: Nein, es handelt sich um unterschiedliche Dinge, auch wenn beide dazu dienen, Social-Media-Inhalte einzubetten.

Der Einbettungscode von Instagram ist der Codeausschnitt, den Sie aus einem einzelnen Beitrag kopieren. Ein Iframe von YouTube oder Twitter/X funktioniert auf die gleiche Weise. Sie kopieren den Code von der Plattform, fügen ihn in Ihre Seite ein, und die Plattform stellt den Inhalt bereit.

Dieser letzte Teil ist das Wesentliche. Was auf Ihrer Seite zu sehen ist, ist lediglich ein Platzhalter, der dem Browser mitteilt, wo er die Inhalte abrufen soll.

Bei jedem Laden der Seite fordert der Browser Ihres Besuchers Ihre Seite von Ihrem Host an, liest diesen Platzhalter und sendet anschließend eine zweite Anfrage an eine völlig andere Stelle.

Dein Beitrag wird erst angezeigt, wenn dieser Hin- und Rückvorgang abgeschlossen ist, und keinen Moment früher.

Ein Social-Feed funktioniert genau umgekehrt. Ein Plugin stellt eine Verbindung zu Ihrem Konto her, ruft Ihre Beiträge in Ihre WordPress-Installation ab und speichert sie dort. Wenn jemand die Seite aufruft, ist der Feed bereits vorhanden. Es muss nichts mehr abgerufen werden, niemand muss warten.

Ein weiterer Unterschied besteht darin, was Sie überhaupt auf die Seite stellen. Ein eingebetteter Beitrag ist ein einzelner Beitrag, der in dem Moment eingefroren wird, in dem Sie ihn einfügen. Ein Feed ist eine fortlaufende Reihe von Beiträgen, die sich automatisch aktualisiert, sobald Sie neue Beiträge veröffentlichen.

Deshalb werden die beiden zwar oft verglichen, aber selten verwechselt. Das eine dient dazu, einen bestimmten Beitrag anzuzeigen. Das andere dient dazu, den zuletzt geposteten Beitrag anzuzeigen.

Was geht eigentlich kaputt, wenn der Feed bereits funktioniert?

Fast jeder Websitebetreiber, mit dem ich über Feeds spreche, schildert denselben Ablauf. Die Einrichtung verlief reibungslos. Monate später trat ein Problem auf. Und als sie versuchten, das Problem zu beheben, stellten sie fest, dass es in ihrem Dashboard nichts gab, was sie hätten beheben können.

Drei Varianten dieser Geschichte tauchen immer wieder auf. Das Interessante daran ist nicht das Scheitern an sich, sondern die Frage, wer etwas dagegen unternehmen konnte.

Die Leerstelle, an der früher der Feed war

Das ist der mit dem längsten „stillen“ Ende. Der Feed wird nicht mehr aktualisiert, und anstelle der Beiträge bleibt nur noch ein leerer Bereich zurück.

Niemand erhält eine Benachrichtigung, wenn das passiert. WordPress weiß nicht, dass der Feed nicht mehr vorhanden ist, da sich aus Sicht Ihrer Installation auf Ihrer Website nichts geändert hat.

So kommen die Leute eher zufällig dahinter. Ein Besucher erwähnt es. Oder sie bearbeiten diese Seite Monate später aus einem ganz anderen Grund und bemerken die Lücke.

Der Feed, der dein Thema ignoriert

Das hier ist kein Misserfolg. Es ist ein schleichender Ärger, der sich zu einem Projekt entwickelt.

Dem Betreiber fällt auf, dass der Feed wie angeheftet wirkt. Falsche Schriftart, falsche Linkfarbe, Ecken zu rund oder nicht rund genug. Die Website hat einen bestimmten Stil, und der Feed passt eindeutig nicht dazu.

Also versuchen sie, das Design anzupassen, und dabei bleibt es dann auch. Die Gestaltung ist weder im Theme-Customizer noch in den Blockeinstellungen zu finden, da der Quellcode nicht von ihnen stammt. Er wurde bereits mit einem Design geladen, egal von wo er stammt.

Der Feed, der ohne Fehler abgestanden wurde

Das ist das fieseste Exemplar, und es lohnt sich, es vom leeren Block zu trennen.

Ein leerer Block ist zu sehen. Es fehlt offensichtlich etwas, sodass es früher oder später jemand meldet. Ein veralteter Feed zeigt überhaupt nichts an. Der Feed wird dargestellt. Die Bilder werden geladen. Das Layout sieht korrekt aus.

Die Beiträge sind erst drei Monate alt.

Das liegt daran, dass ein eingebetteter Feed kein Feed ist. Es handelt sich vielmehr um die Beiträge, die Sie am Tag der Erstellung der Seite eingebettet haben, und es bleiben immer diese Beiträge.

Wenn du ein neues Video veröffentlichst, wird es auf deinem Kanal angezeigt, nicht auf deiner Website. Es erscheint nur dann auf deiner Seite, wenn du zurückgehst, einen anderen Einbettungscode kopierst und diesen einfügst.

Im ersten Monat ist das noch in Ordnung. Im achten Monat ist es eine lästige Pflicht, die still und leise von der Liste verschwunden ist, und niemand bemerkt es, weil nichts kaputt gegangen ist.

Ich habe gesehen, wie das schiefgelaufen ist. Die Website führt eine Kampagne durch, auf der Startseite wird ein Feed angezeigt, und der neueste Beitrag darin stammt bereits aus der letzten Saison. Jeder Besucher hat das gesehen. Niemand hat darauf hingewiesen, weil es nichts zu beanstanden gab.

Das ist das Muster, das sich bei allen dreien zeigt: die leeren Stellen, die uneinheitliche Gestaltung, die veralteten Beiträge. In jedem Fall war das, was zu tun war, nichts, was Ihr Dashboard für Sie erledigen konnte.

Man kann also entweder abwarten, sich damit abfinden oder die Art und Weise ändern, wie der Feed überhaupt auf die Seite gelangt.

Ich habe Social-Feeds und Widgets getestet: Das sind meine Erkenntnisse

Bisher ging es ausschließlich darum, wo sich die Feed-Daten befinden. In diesem Abschnitt wird daraus nun eine konkrete Zahl.

Ich habe zwei Seiten auf einer WordPress-Staging-Seite eingerichtet. Gleiches Theme, gleiche Seitenvorlage, gleiche Position im Layout. Auf einer Seite wurden Roh-Einbettungen verwendet.

Der andere betrieb einen Feed mit dem Smash-Balloon-Plugin. Gleiche Inhalte, gleiche Anzahl an Beiträgen. Anschließend habe ich beide mit PageSpeed Insights, Chrome DevTools und Pingdom gemessen.

Fang mit der ganzen Seite an, denn das ist der Teil, den niemand erwartet.

	Raw-Einbettungsseite	Plugin einbetten
Seitengröße	8,4 MB	1,1 MB
Anfragen	176	42

Eine 8,4-MB-Seite ist keine langsame Seite. Es handelt sich um eine Seite, auf der etwas sehr Großes heruntergeladen wird, und der Feed ist das einzige Element auf dieser Seite, das groß genug ist, um dies zu erklären. Deshalb habe ich die Datenlast nach Domains aufgeschlüsselt, um zu sehen, wer sie tatsächlich gesendet hat.

Seite einbetten, Inhaltsgröße nach Domain:

Domäne	Größe	Seite teilen
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%

Lies dir die oberste Zeile noch einmal durch. YouTube hat 91,31 % dieser Seite bereitgestellt. Meine WordPress-Installation hat das Theme, den Text und die von mir hochgeladenen Bilder beigesteuert – und sonst so gut wie nichts. Die Seite bestand größtenteils aus den Servern anderer Anbieter.

Plugin-Feed-Seite, dieselben Domains wurden kontaktiert:

• www.youtube.com — widgetapi.js bei 9 KiB und iframe_api mit einer Größe von 4 KiB, und bei keinem der beiden wird der Player geladen, bis jemand darauf klickt
• i.ytimg.com — Miniaturansichten, jeweils etwa 49–57 KiB

Das ist der gesamte externe Fußabdruck. Die Plugin-Seite kommuniziert weiterhin mit YouTube, übergibt die Seite jedoch nicht an YouTube. Der Player wird erst dann geladen, wenn ein Besucher ein Video anfordert, nicht vorher.

DevTools schildert dieselbe Situation aus der Perspektive eines Drittanbieters und fügt noch den Teil hinzu, der wirklich wehtut.

Kosten Dritter	Raw-Einbettungsseite	Plugin-Feed-Seite
YouTube-Nutzdaten	8.772 KiB	457 KiB
Zeit für den Hauptthread	6.036 ms	—
Gesamtblockierzeit	4.510 ms	0 ms

Die Nutzlast ist um etwa 95 % gesunken. Aber die Zahl, auf die ich besonders hinweisen möchte, ist die „Total Blocking Time“, die von 4.510 ms auf 0 ms gesunken ist, denn dabei geht es überhaupt nicht um die Download-Größe.

Das bedeutet, dass der Hauptthread des Browsers mit der Ausführung von JavaScript von Drittanbietern ausgelastet ist – und in dieser Zeit kann Ihre Seite nicht auf ein Antippen oder Scrollen reagieren. Viereinhalb Sekunden lang, auf einer Seite, die „ganz normal aussah“.

Zusammengefasst in der Punktzahl, die die Leute tatsächlich laufen:

	Vorher (iFrame-Einbettung)	Nach (Plugin-Feed)
PageSpeed für Mobilgeräte	49	72
PageSpeed für Desktop-Computer	52	99
Mobilgeschwindigkeitsindex	15.1s	4.9s

Der Mobile Speed Index ist der entscheidende Faktor. 15,1 Sekunden gegenüber 4,9 Sekunden – das ist der Unterschied zwischen einer Seite, die sich erst während des Wartens auflädt, und einer Seite, die bereits größtenteils geladen ist, wenn der Nutzer sie aufruft.

Es ist derselbe Mechanismus wie bei den anderen: Der Feed der eingebetteten Seite befand sich auf Servern, über die ich keine Kontrolle habe, sodass jeder Besucher die vollen Kosten für das Abrufen trug, und es gab in meinem Dashboard keine Einstellung, mit der sich diese Kosten senken ließen.

Die Plugin-Seite stellte den Feed aus Daten bereit, die bereits in der WordPress-Installation vorhanden waren, sodass nur noch die Medien abgerufen werden mussten, die ein Besucher tatsächlich angefordert hatte.

Expertentipp: Wenn Sie mehr darüber erfahren möchten, finden Sie bei uns einen Leitfaden zum Thema „Verlangsamen Social-Media-Feeds Ihre Website?“, in dem wir näher darauf eingehen.

Sieht der Feed so aus, als gehöre er auf Ihre Website?

Das ist die Frage, die mir am häufigsten zum Thema Einbettungen gestellt wird – meist mit einer gewissen Frustration formuliert: Warum sieht dieses Ding überhaupt nicht so aus wie der Rest meiner Website?

Es handelt sich um dieselben beiden Staging-Seiten, auf denen jeweils dasselbe Theme aktiv ist. Ich habe einen mit Smash Balloon erstellten Feed eingefügt und ihn mit der zuvor manuell eingebetteten Version verglichen.

Der Plugin-Feed hat das Theme übernommen. Die Überschriften verwenden die vom Theme festgelegte Schriftart, und die Links die vom Theme festgelegte Farbe, da dieses Markup wie jeder andere Inhalt auf der Seite über das eigene Stylesheet Ihrer Website gerendert wird.

Der eingebettete Feed tat dies nicht. Er wurde mit einer Typografie und Farben geliefert, die an anderer Stelle festgelegt wurden, und wendet diese unabhängig von den Einstellungen Ihres Themes an.

Das ist der gesamte Mechanismus. Ein Feed wird von Ihrer Website gestaltet. Der andere wird gestaltet, bevor er Ihre Website erreicht.

Wie ein Plugin-Feed weiterhin gerendert wird, wenn die Plattform dies nicht tut

Alles oberhalb dieser Zeile ist das Problem. Dieser Abschnitt beschreibt den Mechanismus, der darauf eine Antwort gibt. Im Folgenden wird erläutert, wie die einzelnen Bestandteile mit einem Fehler zusammenhängen, über den Sie bereits gelesen haben.

Es speichert eine lokale Kopie Ihres Feeds

Mit einem hochwertigen Social-Feed-Plugin wie Smash Balloon erhalten Sie ein Backup-Caching-System, das Ihre Feed-Daten innerhalb Ihrer WordPress-Installation speichert.

Wenn Instagram ausfällt oder die API keine Antworten mehr liefert, kann das Plugin dennoch Inhalte anzeigen. Ihr Feed wird weiterhin angezeigt, anstatt eine Lücke zu hinterlassen.

Genau darin liegt der entscheidende Unterschied, um den es in diesem Beitrag geht. Auf der Plugin-Seite sind Ihre Beiträge in der Datenbank gespeichert, sodass dort Inhalte angezeigt werden können, wenn die Plattform nicht reagiert.

Die Einbettungsseite enthält jedoch einen Platzhalter und eine Adresse, und wenn von dieser Adresse keine Daten zurückkommen, wird nichts angezeigt.

Es lädt keine Iframes von Drittanbietern

Smash Balloon stellt Feeds bereit, ohne Iframes von Drittanbietern zu laden, die die Seiten verlangsamen.

Aus diesem Grund hat die Plugin-Seite weniger externe Domains aufgerufen und war mit 1,1 MB deutlich kleiner als die Einbettungsseite mit 8,4 MB. Es gibt keine Anfragekette, da nichts abgerufen werden muss.

Es nutzt Lazy Loading und intelligentes Caching

Bilder werden geladen, sobald der Besucher zu ihnen scrollt, und dank der zwischengespeicherten Feed-Daten muss Ihr Server nicht bei jedem Seitenaufruf die API aufrufen.

Dies ist das Ergebnis der „Total Blocking Time“: 4.510 ms auf der Einbettungsseite, 0 ms auf der Plugin-Seite.

Die Lösung finden Sie in Ihrem eigenen Dashboard

Es ist keine Programmierung erforderlich. Die Feed-Einstellungen finden Sie in Ihrem WordPress-Adminbereich neben allen anderen Funktionen, die Sie verwalten.

Dies ist der Punkt, den ich am wichtigsten erachte. Selbst in dem seltenen Fall, dass etwas schiefgeht, öffnet man einfach einen Bildschirm, auf den man bereits Zugriff hat, oder wendet sich an den Support. Bei manuellen Einbettungen ist man hingegen auf eine Infrastruktur angewiesen, die man nicht selbst kontrollieren kann.

Rund 1,75 Millionen Menschen betreiben Smash-Balloon-Feeds auf ihren WordPress-Seiten – eine Information, die vor allem deshalb interessant ist, weil dies bedeutet, dass die oben genannten Fehlerfälle bereits in großem Umfang aufgetreten sind und bewältigt wurden.

Welches sollten Sie also verwenden?

Die entscheidende Frage ist dabei nicht, welche Variante einfacher einzurichten ist. Die Frage lautet vielmehr: Wenn der Feed ausfällt, liegt die Lösung dann in Ihrem Dashboard oder in dem eines anderen?

So würde ich die Frage beantworten, je nachdem, was du gerade entwickelst.

• Sie binden einen Beitrag oder ein Video in einen Artikel ein. Verwenden Sie dazu den Einbettungscode der Plattform. Da es sich um einen einzelnen Inhalt handelt, der nicht aktualisiert werden soll, ist die einfache, wenn auch eingeschränkte Option die beste Wahl.
• Sie betreiben einen fortlaufenden Feed auf einer Seite, die schnell geladen und indexiert werden soll. Verwenden Sie ein Plugin. Die zuvor in diesem Beitrag genannten Leistungsdaten sprechen dafür: 8,4 MB gegenüber 1,1 MB, 176 Anfragen gegenüber 42. Ein Live-Feed wird bei jedem einzelnen Besuch geladen, sodass Ihnen die damit verbundenen Kosten immer wieder entstehen, egal wie hoch sie sind.
• Sie melden sich nicht jede Woche auf Ihrer Website an, oder ein Kunde bzw. ein Freiberufler kümmert sich um die Pflege. Verwenden Sie ein Plugin. Das Problem dabei ist, dass es keine Fehlermeldung gibt; der Feed wird einfach nicht mehr angezeigt, während die Seite weiterhin problemlos geladen wird.
• Sie betreiben Feeds von mehr als einer Plattform. Nutzen Sie ein Plugin – und zwar eines, das alle Plattformen abdeckt. Separate Einbettungscodes für verschiedene Websites bedeuten, dass es auf fünf verschiedene Arten zu Fehlern kommen kann. Mit der Smash Balloon Social Wall können Sie Feeds für all diese Plattformen erstellen und sie sogar zu einer Social Wall zusammenfassen.

Der wahre Unterschied

Beide scheinen auf den ersten Blick ziemlich ähnlich zu sein, aber der Unterschied wird deutlich, sobald etwas schiefgeht. Als ich die Quelle beider Feeds unzugänglich machte, zeigte die Plugin-Seite weiterhin Beiträge an, die auf den in der WordPress-Installation gespeicherten Daten basierten.

Die Einbettungsseite hatte keine lokale Ausweichlösung. Das ist der eigentliche Unterschied. Bei dem einen Ansatz werden Ihre Feed-Daten auf Ihrem eigenen Server gespeichert und die Korrektur erfolgt in Ihrem eigenen Dashboard. Beim anderen Ansatz werden beide an einem Ort gespeichert, auf den Sie keinen Zugriff haben.

Wenn Sie einen fortlaufenden Feed betreiben, ist „Smash Balloon Instagram Feed Pro“ ein hervorragender Ausgangspunkt, und Sie können damit Feeds für die beliebteste visuelle Plattform überhaupt erstellen.

Instagram Feed Pro herunterladen

Betreiben Sie Feeds auf mehreren Plattformen? Mit dem „All Access“-Paket können Sie Instagram, Facebook, YouTube und X über einen einzigen Einstellungsbildschirm verwalten.