Auf dem großen Bildschirm sieht der Player passend aus. Auf dem schmalen Bildschirm ragt er über den Artikel hinaus oder behält eine unpraktisch hohe Fläche. Häufig muss dann der Websiteblock geprüft werden, der den Player aufnimmt. Ein anderes Videofile ist nicht automatisch die Lösung.
Dieser Artikel betrachtet die Größe der Einbettung auf der Website. Ob freie Ränder schon in einer Aufnahme enthalten sind, ist eine andere Frage. Für ein brauchbares mobiles Layout müssen zunächst verfügbare Breite, Rahmenhöhe und der eingebettete Inhalt zusammenpassen.
Der Platz kommt vom Websiteblock
Eine Browserbreite von 390 CSS-Pixeln steht dem Video nicht vollständig zur Verfügung. Seitenabstände, Spalten und ein sichtbarer Scrollbalken können den Inhaltsbereich verkleinern. Eine feste iframe-Breite von beispielsweise 640 Pixeln passt dann nicht ohne zusätzliche Layoutregeln hinein.
Ein iframe bettet ein eigenes Dokument ein. Deine Website bestimmt seinen äußeren Rahmen; der darin geladene Player gestaltet seinen eigenen Inhalt. Diese Grenze ist wichtig: Eine CSS-Regel an deiner Seite kann den Rahmen verändern, ohne die inneren Playerregeln zu ersetzen.
Prüfe zuerst den vorgesehenen Einbettungscode des Dienstes. Enthält er schon eine responsive Hülle, arbeite mit diesem Aufbau. Eine weitere pauschal darübergelegte Hülle kann zusätzliche Höhenregeln und unerwartete Abstände verursachen. Im Website-CMS muss außerdem ein Block verwendet werden, der den benötigten Code tatsächlich annimmt.
Ein konkretes Muster für einen eigenen iframe
Unser eigenes lokales Beispiel verwendet einen umgebenden Block mit der Klasse „atlas-embed“. Darin liegt der iframe. Der äußere Block bekommt die verfügbare Breite und ein Seitenverhältnis. Der iframe füllt anschließend diesen berechneten Rahmen.
Die beiden zusammengehörigen CSS-Regeln lauten im Beispiel:
.atlas-embed { width: 100%; aspect-ratio: 16 / 9; }
.atlas-embed iframe { display: block; width: 100%; height: 100%; border: 0; }
Das ist ein eigenes allgemeines Layoutmuster. Übernimm die echte Playeradresse und dessen benötigte Attribute aus dem vorgesehenen Anbieter-Code. Ersetze sie nicht durch eine gewöhnliche Ansehseite, wenn der Anbieter eine eigene Einbettungsadresse verlangt.
MDN erklärt, dass „aspect-ratio“ in die automatische Größenberechnung eingreift. Sind Breite und Höhe anderweitig beide fest vorgegeben, setzt ein zusätzliches Seitenverhältnis diese Festlegungen nicht einfach außer Kraft. Prüfe bei einer Abweichung deshalb die tatsächlich wirksamen CSS-Regeln am Rahmen und am iframe, einschließlich fester Höhen aus dem Theme.
Hochformat bewusst begrenzen
Für ein Hochformat ersetzt unser Beispiel am äußeren Block das Verhältnis durch 9 / 16 und ergänzt „max-width: 240px“. Die Breite bleibt mit „width: 100%“ an den verfügbaren Platz gebunden, wächst aber nicht über die gewählte Obergrenze hinaus. Das ist eine Gestaltungsentscheidung für diesen Test, keine allgemeine Vorgabe für jedes Hochformatvideo.
Auf einer sehr breiten Artikelseite würde ein uneingeschränkt breiter 9:16-Rahmen sehr hoch. Wähle die Obergrenze passend zum Inhalt und zur gewünschten Lesefolge. Prüfe weiterhin, ob Beschriftungen und Bedienelemente im tatsächlichen Player ausreichend erkennbar sind. Ein rechnerisch korrektes Verhältnis ist noch kein vollständiger Bediennachweis.
Was der eigene Chrome-Test ergeben hat
Am 22.10.2026 haben wir zwei eigene iframe-Inhalte mit synthetischen Videos in Chrome 155 unter Windows geprüft. Die tatsächlichen Viewportbreiten betrugen 320, 390 und 768 CSS-Pixel. Der vorhandene Browserzoom blieb erhalten; Scrollbalken und die realen Elementgrenzen wurden mitgemessen.
Der 16:9-Rahmen hatte in diesem Seitenaufbau ungefähr folgende Größen:
- Bei 320 CSS-Pixeln Viewport: 274 mal 154 CSS-Pixel.
- Bei 390 CSS-Pixeln Viewport: 344 mal 194 CSS-Pixel.
- Bei 768 CSS-Pixeln Viewport: 723 mal 406 CSS-Pixel.
Die gerundeten Werte gehören zu unserem konkreten Aufbau mit Seitenabständen und Desktop-Scrollbalken. Sie sind keine Zielmaße für deine Website. Das Seitenverhältnis blieb erhalten; in allen drei finalen Messungen war die Seitenbreite nicht durch einen horizontalen Überlauf vergrößert. Der Hochformatrahmen blieb bei ungefähr 240 mal 427 CSS-Pixeln.
Das war eine Größenprüfung eigener Inhalte in einem Desktopbrowser. Ein reales Touchgerät, andere Browser und ein fremder Hostingplayer wurden damit nicht geprüft. Für deinen Einsatz folgt deshalb eine zusätzliche Prüfung auf den vorgesehenen Geräten und in der tatsächlich veröffentlichten Website.
Rahmenproblem und Bildbeschnitt auseinanderhalten
„object-fit: contain“ kann ein direktes Videoelement vollständig in dessen Fläche einpassen. „cover“ kann bei anderem Verhältnis Bildteile abschneiden. Laut MDN wirkt „object-fit“ jedoch nicht auf den Inhalt eines äußeren iframe. Eine solche Regel am iframe ist deshalb kein verlässlicher Weg, einen fremden Player innen umzubauen.
Bleibt der Rahmen korrekt innerhalb des Artikels, aber im Player fehlt Bildinhalt, prüfe dessen eigene Darstellung und die Quelle. Ragt dagegen der gesamte Player aus der Seite, untersuche zuerst den umgebenden Block und die wirksamen Breiten. So änderst du die Ebene, auf der das Problem tatsächlich auftritt.
Die fertige Seite prüfen
Öffne die veröffentlichte Website in einer schmalen und einer breiten Ansicht. Suche nach seitlichem Überlauf, unpassenden Leerflächen und abgeschnittenen Bedienelementen. Starte das Video bewusst und kontrolliere wichtige Beschriftungen. Prüfe anschließend ein tatsächliches Zielgerät, statt eine Desktop-Größenansicht als Smartphoneabnahme auszugeben.
Vionetos Originalhilfe verlangt nach der bestätigten Freigabe und Übernahme des Codes ebenfalls die Prüfung auf der eigenen Seite als Zuschauer. Die normale Redaktions- oder Websitebearbeitung ist dafür ein anderer Kontext. Ein passender Rahmen ist erreicht, wenn dein konkreter Inhalt innerhalb der vorgesehenen Breite verständlich und bedienbar bleibt.
MDN: Seitenverhältnis und automatische Größen
MDN: der äußere iframe und sein Dokument
MDN: Wirkung und Grenzen von object-fit