Eine Kamera zeichnet ein Video in hoher Qualität auf.

Nach dem Schnitt entsteht eine Datei mit vielleicht mehreren hundert Megabyte oder sogar einigen Gigabyte.

Technisch könnte man diese Datei auf einen Webserver laden und anschließend mit einem <video>-Element einbinden.

Das bedeutet jedoch nicht, dass man es tun sollte.

Ein Produktionsvideo und ein Webvideo erfüllen unterschiedliche Aufgaben.

Das Produktionsmaterial soll möglichst viel Bearbeitungsreserve erhalten. Ein Webvideo soll dagegen schnell zum Nutzer gelangen, auf dessen Gerät zuverlässig abgespielt werden und dabei gerade genug Qualität besitzen, um in seiner tatsächlichen Darstellungsgröße gut auszusehen.

Der grundsätzliche Workflow lautet daher:

Kamera
↓
Rohmaterial
↓
Schnitt
↓
hochwertiger Master
↓
Webkomprimierung
↓
Webvideo

Der Master wird bewahrt. Die Website erhält ein dafür optimiertes Derivat.

Genau dieses Prinzip kennen wir bereits von Bildern für Websites.

Warum Kamera- und Schnittdateien selten gute Webdateien sind

Eine Kamera muss während der Aufnahme andere Probleme lösen als ein Browser bei der Wiedergabe. Sie soll beispielsweise hohe Qualität aufzeichnen, genügend Reserve für Farbkorrekturen bieten und Daten in Echtzeit zuverlässig auf die Speicherkarte schreiben.

Der Webbrowser benötigt dagegen ein Video, das effizient über ein Netzwerk übertragen und auf sehr unterschiedlichen Geräten dekodiert werden kann. Moderne Webcodecs sind deshalb auf starke Kompression ausgelegt; MDN beschreibt Videokompression ausdrücklich als notwendig, weil unkomprimierte Videodaten selbst bei vergleichsweise normalen Auflösungen enorme Speicher- und Bandbreitenmengen verursachen. (MDN Web Docs)

Ein sinnvoller Produktionsweg trennt deshalb:

Aufnahmeformat
≠
Schnittformat
≠
Masterformat
≠
Webformat

Was bestimmt die Dateigröße eines Videos?

Bei einem Webvideo wirken mehrere Faktoren zusammen:

Laufzeit, Bitrate, Auflösung, Bildrate, Codec, Ton und Bildinhalt.

Die wichtigste direkte Beziehung besteht zunächst zwischen Laufzeit und Bitrate.

Vereinfacht:

Bitrate
×
Laufzeit
≈
Dateigröße

Ein Video mit hoher Datenrate benötigt bei gleicher Länge mehr Speicher als eines mit niedriger Datenrate.

Was bedeutet Bitrate?

Die Bitrate beschreibt die Datenmenge, die für einen bestimmten Zeitraum des Videos verwendet wird.

Bei Video begegnen beispielsweise Angaben in:

Mbit/s

also Megabit pro Sekunde.

Angenommen, ein Video verwendet ungefähr:

8 Mbit/s

und dauert:

60 Sekunden

Dann werden für den Videostream grob:

8 × 60
=
480 Megabit

benötigt.

Da acht Bit ungefähr einem Byte entsprechen:

480 ÷ 8
=
60 Megabyte

Hinzu kommen Ton, Containerinformationen und weitere Daten.

Die Rechnung ist nur eine Näherung, zeigt aber hervorragend, warum die Bitrate für Webvideos so wichtig ist.

Eine Halbierung der Bitrate kann die Datei ungefähr halbieren

Wenn alle anderen Bedingungen vergleichbar bleiben:

8 Mbit/s
→ ungefähr 60 MB pro Minute

gegen:

4 Mbit/s
→ ungefähr 30 MB pro Minute

Der entscheidende Punkt lautet allerdings:

Die Bitrate lässt sich nicht beliebig reduzieren.

Irgendwann fehlen dem Codec genügend Daten, um das Bild glaubwürdig zu beschreiben. Dann entstehen sichtbare Kompressionsartefakte. Höhere Bitraten führen im Allgemeinen zu größeren Dateien und können höhere Qualität ermöglichen; wie viel tatsächlich nötig ist, hängt jedoch stark von Codec und Inhalt ab. (MDN Web Docs)

Warum gibt es keine perfekte Bitrate für alle Videos?

Stell dir zwei einminütige Videos vor.

Video A zeigt:

Person
+
ruhige Wand
+
statische Kamera

Video B zeigt:

Wald
+
Blätter
+
Wasser
+
schnelle Kamerabewegung
+
Konfetti

Video B enthält von Frame zu Frame wesentlich mehr Veränderungen.

Es ist daher schwieriger zu komprimieren.

Dieselbe Bitrate kann bei Video A nahezu perfekt aussehen und bei Video B deutliche Artefakte erzeugen. MDN weist deshalb darauf hin, dass nicht nur Codec und Einstellung, sondern auch Format und tatsächlicher Bildinhalt maßgeblich für Dateigröße und Qualität sind. (MDN Web Docs)

Was macht Videos schwer komprimierbar?

Besonders anspruchsvoll sind beispielsweise:

Wasser,

Rauch,

Schnee,

Regen,

Blätter,

Gras,

Menschenmengen,

Filmgrain,

Sensorrauschen,

schnelle Bewegungen.

Warum?

Weil sich sehr viele kleine Strukturen ständig verändern.

wenig Veränderung
→ leicht vorherzusagen
→ effizient komprimierbar

viel Veränderung
→ wenig Vorhersagbarkeit
→ mehr Daten erforderlich

Deshalb kann Rauschen die Webdatei vergrößern

Rauschen besteht aus scheinbar zufälligen feinen Veränderungen.

Für den Codec sieht ein Teil davon aus wie:

Frame 1
→ Detail A

Frame 2
→ etwas anderes

Frame 3
→ wieder anders

Der Encoder kann diese Unterschiede schlechter als gleichbleibenden Hintergrund beschreiben.

Eine sinnvolle Rauschreduzierung vor dem finalen Encoding kann deshalb nicht nur das Bild ruhiger machen, sondern auch die Komprimierbarkeit verbessern. Zu starke Rauschreduzierung wiederum vernichtet echte Details.

Auflösung beeinflusst den Datenbedarf

Ein Full-HD-Frame enthält:

1920 × 1080
≈
2,1 Millionen Pixel

Ein UHD-4K-Frame:

3840 × 2160
≈
8,3 Millionen Pixel

Damit enthält 4K etwa viermal so viele Pixelpositionen pro Frame wie Full HD.

Je mehr potentielle Bildinformation vorhanden ist, desto mehr Daten können nötig werden, um diese Information sinnvoll zu erhalten. Die resultierende Dateigröße vervierfacht sich allerdings nicht automatisch, weil Codec, Bitrate und Bildinhalt ebenfalls entscheidend sind. (MDN Web Docs)

Muss ein Websitevideo überhaupt 4K sein?

Oft nicht.

Die entscheidende Frage lautet:

Wie groß wird das Video
tatsächlich dargestellt?

Wenn ein Tutorial in einem Inhaltsbereich mit beispielsweise deutlich weniger als voller Desktopbreite erscheint, kann eine 4K-Auslieferung wenig sichtbaren Nutzen bringen.

Das bedeutet jedoch nicht, dass die Aufnahme ebenfalls nur in der späteren Webauflösung erfolgen sollte.

Aufnahmeauflösung und Webauflösung trennen

Ein sinnvoller Workflow kann beispielsweise lauten:

4K-Aufnahme
↓
4K-Schnittmaster
↓
1080p-Webvideo

Dadurch behältst du im Produktionsprozess Reserve für:

Cropping,

Stabilisierung,

Reframing.

Der Websitebesucher muss diese Reserve aber nicht herunterladen.

Ein Master darf größer sein als jede Ausgabe

Das ist sogar sinnvoll.

4K-Master
├── 1080p Website
├── 720p kleinere Variante
├── Social-Version
└── zukünftiger Export

So lässt sich das Video später für neue Anforderungen erneut aus hochwertiger Quelle erzeugen.

720p ist nicht automatisch schlechte Qualität

Eine Rastergröße wie:

1280 × 720

kann beispielsweise für:

kleine eingebettete Videos,

mobile Varianten,

Hintergrundvideos

ausreichen.

Ob das Ergebnis gut aussieht, hängt stark von:

Darstellungsgröße,

Bildinhalt,

Bitrate,

Codec

ab.

1080p ist für viele Webvideos ein sinnvoller Arbeitsbereich

Full HD bietet mit:

1920 × 1080

bereits eine hohe Detailauflösung.

Für viele:

Tutorials,

Interviews,

Produktvideos,

Erklärvideos

ist das eine sehr brauchbare Webauflösung.

4K-Auslieferung hat trotzdem ihren Platz

Zum Beispiel wenn:

das Video groß beziehungsweise fullscreen angesehen wird,

feine Details wichtig sind,

die Zielgruppe hochauflösende Displays nutzt,

eine Videoplattform ohnehin adaptive Qualitätsstufen erzeugt.

Der Fehler liegt nicht darin, 4K anzubieten.

Der Fehler wäre:

jedem Nutzer
immer ausschließlich
die größte Datei schicken

Bildrate kostet ebenfalls Daten

Wie unter Videoauflösung und Bildrate beschrieben, besitzt ein 60-fps-Video doppelt so viele Frames pro Sekunde wie ein 30-fps-Video.

30 fps
→ 30 Frames

60 fps
→ 60 Frames

Bei sonst vergleichbaren Bedingungen steigt damit die Menge der zeitlich zu beschreibenden Bildinformation. MDN führt höhere Bildraten ebenfalls als Faktor auf, der die komprimierte Videogröße erhöhen kann. (MDN Web Docs)

Websitevideos brauchen nicht automatisch 60 fps

Ein Interview:

Person sitzt
+
spricht

profitiert häufig nur wenig davon.

Ein:

Sportvideo,

Gamingclip,

Video mit schnellen Bewegungen

kann dagegen sichtbar von hoher Bildrate profitieren.

Für ein ruhiges Hero-Hintergrundvideo kann eine hohe Bildrate sogar reine Datenverschwendung sein.

Nicht mehr Frames übertragen als gestalterisch nötig

Das ist die Webperspektive:

Benötigte Qualität
↓
gerade ausreichende Daten

und nicht:

maximale technische Einstellung
↓
anschließend hoffen,
dass die Verbindung schnell genug ist

Welcher Codec eignet sich fürs Web?

Hier existiert keine ewige Einzelantwort, weil Codecunterstützung von Browser, Betriebssystem und Hardware abhängt und sich weiterentwickelt. MDN empfiehlt deshalb, Webvideo als Kompatibilitätsfrage des gesamten Systems zu betrachten und gegebenenfalls mehrere Quellen anzubieten. (MDN Web Docs)

Zwei wichtige Grundstrategien sind:

breit kompatible Variante

und:

modernere effizientere Variante
+
Fallback

H.264 als verbreitete Basis

H.264 beziehungsweise AVC ist weiterhin eine sehr verbreitete Kombination für Webvideo, häufig in einem MP4-Container zusammen mit AAC-Audio. MDN führt diese Kombination als besonders breit kompatible Weboption auf. (MDN Web Docs)

Konzeptionell:

MP4
├── H.264 Video
└── AAC Audio

AV1 als effizientere Weboption

AV1 wurde speziell für moderne Internetvideoanwendungen entwickelt und zielt auf hohe Kompressionseffizienz. Die praktische Unterstützung hängt jedoch auch 2026 noch von Gerät und Hardware ab; MDN empfiehlt deshalb für breite Nutzung gegebenenfalls eine alternative Quelle für ältere beziehungsweise nicht unterstützende Systeme. (MDN Web Docs)

Ein Konzept könnte daher sein:

AV1
→ bevorzugte effiziente Variante

H.264
→ kompatibler Fallback

Browser können mehrere Videoquellen erhalten

HTML erlaubt innerhalb des <video>-Elements mehrere <source>-Elemente. Der Browser kann die erste Quelle auswählen, die er versteht. Auch der konkrete Codec kann im MIME-Typ näher angegeben werden. (MDN Web Docs)

Beispiel:

<video controls poster="video-poster.jpg">
  <source
    src="video.webm"
    type='video/webm; codecs="av01,opus"'>
  <source
    src="video.mp4"
    type="video/mp4">
</video>

Damit wird aus Codeckompatibilität kein Entweder-oder.

Nicht jede Website braucht mehrere Codecs selbst zu verwalten

Wenn du einen spezialisierten Videodienst einsetzt, kann dieser solche Aufgaben übernehmen.

Dazu gehören je nach Dienst beispielsweise:

Transcoding,

mehrere Auflösungen,

Streamingvarianten,

Player.

Beim Self-Hosting musst du wesentlich mehr davon selbst planen.

Was bedeutet qualitätsbasiertes Encoding?

Statt eine starre Bitrate festzulegen, kann ein Encoder versuchen, eine bestimmte visuelle Qualität einzuhalten.

Dann bekommt:

eine einfache Szene

weniger Daten,

eine schwierige Szene

mehr.

ruhige Wand
→ wenig Bitrate nötig

Wasser + Bewegung
→ mehr Bitrate nötig

Das kann für Video-on-Demand besonders effizient sein.

VBR: Variable Bitrate

Ein ähnlicher Grundgedanke:

Die Bitrate darf sich über das Video verändern.

Sekunde 1
ruhig
→ wenig Daten

Sekunde 20
Action
→ mehr Daten

Der Encoder verteilt seine Ressourcen dort, wo sie benötigt werden.

CBR: Constant Bitrate

Bei konstanter Bitrate soll die Datenrate wesentlich gleichmäßiger bleiben.

Sekunde 1
→ ungefähr X

Sekunde 2
→ ungefähr X

Sekunde 3
→ ungefähr X

Das kann bei bestimmten Streaming-, Live- oder Bandbreitenanforderungen praktisch sein.

Für eine normale fertige Webdatei ist eine intelligente variable beziehungsweise qualitätsorientierte Datenverteilung häufig naheliegend.

Zwei-Pass-Encoding

Wenn die gewünschte Endgröße stärker kontrolliert werden muss, kann ein Encoder das Material zunächst analysieren.

Pass 1
↓
Szenen analysieren

danach:

Pass 2
↓
Daten gezielt verteilen

Das kann bessere Entscheidungen ermöglichen als ein Encoder, der jeden Frame sofort endgültig behandeln muss.

Offline-Encoding darf langsam sein

Das ist ein entscheidender Unterschied zur Kamera.

Die Kamera muss:

jetzt aufnehmen
↓
jetzt komprimieren
↓
jetzt speichern

Ein Webencoder darf dagegen:

analysieren
↓
rechnen
↓
optimieren

Wenn ein Webexport fünf Minuten statt einer Minute benötigt, kann das akzeptabel sein, sofern das Ergebnis anschließend hunderttausendfach effizient ausgeliefert wird.

Kompressionszeit wird einmal bezahlt

Bandbreite dagegen bei jedem Abruf.

Das ist ein wichtiger wirtschaftlicher Gedanke:

Encoding
→ einmal

Auslieferung
→ pro Besucher

Deshalb kann sich ein etwas aufwendigeres Encoding bei stark frequentierten Videos lohnen.

Das Hero-Video ist ein Spezialfall

Ein Hero-Hintergrundvideo hat meist eine völlig andere Aufgabe als ein 20-minütiges Tutorial.

Es vermittelt:

Atmosphäre,

Bewegung,

Markenwirkung.

Der Ton ist häufig unwichtig.

Die Laufzeit kann kurz sein.

Hero-Videos radikal kürzen

Angenommen, eine gewünschte Bewegung dauert:

6 Sekunden

Dann braucht man möglicherweise keine:

90-Sekunden-Datei

Ein sinnvoller Loop kann wesentlich effizienter sein.

kurzer Clip
↓
Loop
↓
wahrgenommene kontinuierliche Bewegung

Loop möglichst unauffällig gestalten

Anfang und Ende sollten visuell zusammenpassen.

Zum Beispiel:

ruhige Bewegung,

keine abrupte Kameraposition,

kein plötzlich wechselndes Licht.

Dann kann eine sehr kurze Datei deutlich länger wirken.

Audio beim Hintergrundvideo vermeiden

Ein Hintergrundvideo benötigt normalerweise keinen Ton.

Das reduziert nicht nur Audiodaten, sondern vermeidet auch Konflikte mit Browser-Autoplayregeln. Browser schränken automatisch startende hörbare Medien typischerweise ein; stumme beziehungsweise unhörbare Videos sind davon wesentlich weniger betroffen. (MDN Web Docs)

Ein typischer Hintergrundvideoplayer kann deshalb beispielsweise enthalten:

<video autoplay muted loop playsinline>
  <source src="hero.mp4" type="video/mp4">
</video>

Ob Autoplay tatsächlich erfolgt, bleibt allerdings vom Browser und Nutzungskontext abhängig. (MDN Web Docs)

Autoplay nicht gedankenlos einsetzen

Nur weil ein Video automatisch starten kann, heißt das nicht, dass es das sollte.

Autoplay bedeutet:

Daten werden benötigt,

Bewegung startet ungefragt,

Aufmerksamkeit wird beansprucht.

Bei einem normalen Inhaltsvideo ist:

Poster
↓
Nutzer klickt Play
↓
Video lädt beziehungsweise spielt

oft die bessere Lösung.

Das Posterbild ist wichtiger, als es aussieht

Das HTML-poster-Attribut ermöglicht ein Bild, das vor beziehungsweise während der anfänglichen Videoladung angezeigt wird. (MDN Web Docs)

Beispiel:

<video
  controls
  poster="interview-poster.webp">
  <source src="interview.mp4" type="video/mp4">
</video>

Das Poster erfüllt mehrere Aufgaben:

Es zeigt sofort Inhalt.

Es kann visuell wesentlich schneller bereitstehen als ein Videoframe.

Es verhindert einen leeren schwarzen Player.

Und es ermöglicht dem Nutzer eine bewusste Play-Entscheidung.

Poster als eigenständiges Webbild optimieren

Nicht einfach:

beliebigen Frame exportieren

Sondern behandeln wie ein:

Thumbnail beziehungsweise Titelbild.

Das bedeutet:

klare Bildkomposition,

gut erkennbares Hauptmotiv,

passende Bildauflösung,

effiziente Kompression.

Das Poster kann Performance-relevant sein

web.dev weist darauf hin, dass ein Video beziehungsweise sein Poster im sichtbaren Hauptbereich für Largest Contentful Paint relevant sein kann. Wird das Poster als LCP-Element benötigt, sollte es nicht einfach lazy geladen werden; seine Ladepriorität muss dann gezielt betrachtet werden. (web.dev)

Das zeigt ein allgemeines Prinzip:

Above the Fold
→ früh laden

weit unten
→ später laden

Was bedeutet preload beim Video?

Das HTML-preload-Attribut gibt dem Browser einen Hinweis, wie viel Medieninhalt bereits vor dem Start geladen werden sollte. Mögliche Werte sind none, metadata und auto; der Browser darf diesen Hinweis allerdings je nach Situation anders behandeln. (MDN Web Docs)

preload="none"

<video
  controls
  preload="none"
  poster="poster.webp">
  <source src="video.mp4" type="video/mp4">
</video>

Das signalisiert:

Video vorerst nicht laden.

Für Videos, bei denen der Nutzer selbst Play drücken muss, kann das erheblich Daten sparen. web.dev nennt preload="none" ausdrücklich als sinnvolle Möglichkeit, unnötige Vorabdownloads nutzerinitiierter Videos zu vermeiden. (web.dev)

preload="metadata"

Hier signalisiert die Seite:

Nur so viel laden,
wie für Metadaten benötigt wird.

Das kann beispielsweise die Videolänge verfügbar machen.

Aber auch preload bleibt ein Hinweis und keine Garantie. Browser dürfen die konkrete Ladeentscheidung anpassen. (MDN Web Docs)

preload="auto"

Signalisiert stärker:

Der Browser darf
umfangreich vorladen.

Das kann bei unmittelbar benötigtem Video sinnvoll sein.

Bei mehreren Videos auf einer langen Artikelseite kann es dagegen sehr viel unnötigen Datentransfer verursachen.

Lazy Loading für Videos

Aktuelle Browserplattformen entwickeln auch Lazy-Loading-Möglichkeiten für Medien weiter. Das loading="lazy"-Attribut für Video wird inzwischen von web.dev und MDN dokumentiert, wobei nicht unterstützende Browser es ignorieren können. Es arbeitet mit poster und preload zusammen, ersetzt diese Attribute also nicht. (MDN Web Docs)

Beispiel:

<video
  controls
  loading="lazy"
  preload="none"
  poster="poster.webp">
  <source src="video.mp4" type="video/mp4">
</video>

Lazy Loading nicht für kritisches Hero-Material

Ein Video beziehungsweise Poster direkt im ersten sichtbaren Bereich sollte nicht blind verzögert werden.

web.dev weist ausdrücklich darauf hin, dass ein LCP-relevantes Video nicht wie ein unwichtiges Element unterhalb des sichtbaren Bereichs lazy geladen werden sollte. (web.dev)

Die Frage lautet deshalb immer:

Ist diese Ressource
für den ersten sichtbaren Eindruck nötig?

Video weiter unten im Artikel

Hier ist dagegen häufig sinnvoll:

Poster
+
Lazy Loading
+
kein unnötiges Preload

Der Besucher liest vielleicht nur den oberen Teil der Seite.

Dann muss er das weiter unten befindliche Video niemals herunterladen.

Ein 20-MB-Video, das niemand startet, sollte möglichst keine 20 MB übertragen

Das klingt trivial.

In der Praxis ist genau das ein wichtiger Teil guter Webperformance.

Progressive Wiedergabe

Eine einzelne Videodatei muss nicht zwangsläufig vollständig heruntergeladen werden, bevor der Nutzer abspielen beziehungsweise innerhalb der Datei navigieren kann.

HTTP unterstützt sogenannte Range Requests. Damit kann ein Client nur bestimmte Bytebereiche einer Ressource anfordern, was unter anderem für Medienplayer und zufälligen Zugriff auf große Dateien nützlich ist. (MDN Web Docs)

Konzeptionell:

große Videodatei
↓
Browser benötigt Abschnitt
↓
nur benötigten Bytebereich anfordern

Server muss Teilanfragen unterstützen

HTTP-Range-Unterstützung lässt sich unter anderem über den Accept-Ranges-Header erkennen; ein Server kann damit signalisieren, dass Teilbereiche einer Ressource angefordert werden können. (MDN Web Docs)

Für Self-Hosting sollte daher nicht nur geprüft werden:

Datei ist erreichbar?

sondern auch:

funktioniert Medienauslieferung sinnvoll?

Progressive Datei und adaptives Streaming sind nicht dasselbe

Bei einer einzelnen Datei existiert beispielsweise:

video-1080.mp4

Der Player lädt benötigte Teile dieser einen Version.

Adaptive Systeme dagegen können mehrere Varianten bereitstellen.

360p
480p
720p
1080p
4K

Der Player kann abhängig von Verbindung und Wiedergabesituation zwischen diesen Repräsentationen wählen.

Warum ist adaptives Streaming sinnvoll?

Ein Nutzer besitzt:

schnelles Glasfaserinternet

und:

großen Monitor.

Ein anderer:

langsames Mobilnetz

und:

kleines Smartphone.

Beiden dieselbe 4K-Datei aufzuzwingen ist ineffizient.

schnelle Verbindung
→ höhere Qualitätsstufe

schwache Verbindung
→ kleinere Qualitätsstufe

Responsive Video ist mehr als CSS

Bei Bildern bedeutet responsive Webdesign unter anderem:

nicht jedem Gerät dasselbe riesige Rasterbild senden.

Bei Video ist das Problem noch größer.

Denn eine Videodatei kann hundert- oder tausendmal größer als ein einzelnes Bild sein.

Drei Ebenen von Responsive Video

Man kann unterscheiden:

Layout
→ Wie groß erscheint der Player?

Art Direction
→ Welcher Bildausschnitt beziehungsweise welches Seitenverhältnis?

Delivery
→ Welche Auflösung und Datenrate?

Alle drei sind unterschiedliche Probleme.

Layout

Der Player passt sich beispielsweise an seine Containerbreite an.

video {
  width: 100%;
  height: auto;
}

Damit wird das Element responsive.

Aber:

Die heruntergeladene Datei bleibt möglicherweise trotzdem riesig.

Responsive CSS spart keine Videodaten

Das ist dieselbe Falle wie bei Bildern.

4K-Datei
+
CSS zeigt sie klein

bedeutet nicht:

kleine Datei

Die Netzwerkressource bleibt dieselbe.

Art Direction für Hochkant und Querformat

Ein 16:9-Interview kann auf dem Smartphone zwar verkleinert werden.

Ein vertikales Socialvideo benötigt aber möglicherweise einen völlig anderen Crop.

16:9
→ Person + Umgebung

9:16
→ Person enger

Das sollte bereits beim Dreh beziehungsweise Schnitt berücksichtigt werden.

Automatisches Reframing

Ein KI- beziehungsweise Vision-System kann das Hauptmotiv verfolgen und daraus unterschiedliche Ausgaben erzeugen.

16:9-Master
↓
Person erkennen
↓
Crop verfolgen
↓
9:16-Derivat

Das ist besonders bei großen Contentmengen nützlich.

Aber:

Automatische Crops sollten visuell geprüft werden.

Self-Hosting oder Videoplattform?

Für kleine Videos kann Self-Hosting vollkommen sinnvoll sein.

Für große Videobibliotheken wird die Frage komplexer.

Vorteile von Self-Hosting

Du behältst Kontrolle über:

Dateien,

Server,

Player,

Datenauslieferung.

Es gibt keine fremde Plattformoberfläche im Video.

Du kannst den Workflow exakt auf deine Website abstimmen.

Dafür musst du selbst lösen

Zum Beispiel:

Encoding
+
Speicher
+
Bandbreite
+
Caching
+
Range Requests
+
Browserkompatibilität
+
gegebenenfalls mehrere Qualitäten

Je umfangreicher die Videonutzung, desto mehr wird daraus ein eigenes technisches System.

Ein externer Videodienst übernimmt Infrastruktur

Je nach Anbieter beispielsweise:

Upload,

Transcoding,

mehrere Qualitätsvarianten,

Streaming,

Player,

CDN-Auslieferung.

Der Vorteil ist weniger Betriebsaufwand.

Dafür entstehen andere Abhängigkeiten:

Kosten,

Datenschutz,

Branding,

Plattformintegration.

Keine pauschale Antwort

Die richtige Entscheidung hängt davon ab, ob Video auf deiner Website:

gelegentliche Ergänzung

oder:

zentrales Produkt

ist.

Drei kurze Clips im Jahr

Self-Hosting kann überschaubar sein.

Hunderte längere Videos

Dann werden:

Transcoding,

Streaming,

Bandbreitenoptimierung

zu einem relevanten Infrastrukturthema.

Ein spezialisierter Dienst kann wesentlich einfacher skalieren.

WordPress ist nicht automatisch ein Videostreamingserver

WordPress kann Medien in Inhalte integrieren. Die eigentliche Qualität der Videoauslieferung hängt aber weiterhin von Datei, Hosting, Serverkonfiguration und Player ab.

Die Frage lautet daher nicht:

Kann ich die MP4
in die Mediathek laden?

sondern:

Soll diese Datei
so an Besucher ausgeliefert werden?

Große Kamera-MP4 nicht direkt als WordPress-Master behandeln

Besser:

Rohmaterial
↓
Schnitt
↓
Master außerhalb der Website
↓
Webexport
↓
WordPress beziehungsweise Videoinfrastruktur

Das Archiv und die Website erfüllen unterschiedliche Aufgaben.

Webserver als Auslieferungspunkt

Für kleinere selbstgehostete Videos sollte der Server zumindest:

zuverlässig Medien liefern,

Teilabfragen unterstützen,

ausreichende Bandbreite besitzen,

korrekte MIME-Typen senden.

Bei hoher Nutzung wird ein CDN zunehmend interessant.

CDN bei Video

Ein CDN kann Videodateien näher an Nutzern zwischenspeichern.

Ursprungsserver
↓
CDN-Knoten
↓
Nutzer

Das kann:

Origin-Last reduzieren,

Übertragungswege verkürzen,

skalierbare Auslieferung erleichtern.

Video belastet Bandbreite schnell

Beispiel:

Ein Video besitzt:

20 MB

und wird:

50.000-mal

vollständig übertragen.

Dann entstehen ungefähr:

1.000.000 MB

also rund:

1 TB

Datentransfer.

Eine Einsparung von nur 5 MB pro Abruf würde bei derselben Nutzung bereits ungefähr:

250 GB

Übertragung vermeiden.

Deshalb ist Webvideo-Kompression bei Reichweite keine Nebensache.

Das kürzere Video ist häufig die beste Kompression

Man kann lange über:

Codec,

Bitrate,

Auflösung

optimieren.

Aber wenn ein Video von:

4 Minuten

auf:

2 Minuten

gekürzt werden kann, sinkt die potentielle Datenmenge drastisch.

Und häufig verbessert sich gleichzeitig der Inhalt.

Inhaltliche Kompression vor technischer Kompression

unnötige Szene entfernen
↓
weniger Sekunden
↓
weniger Daten

Das ist effizienter als zu versuchen, langweilige 60 Sekunden mit extrem niedriger Bitrate zu retten.

Webvideo sollte schnell zum Punkt kommen

Besonders bei:

Tutorials,

Produktdemos,

Wissensvideos.

Ein Nutzer will möglicherweise wissen:

Wo muss ich klicken?

und nicht zunächst:

45 Sekunden Intro ansehen.

Videooptimierung ist deshalb auch redaktionelle Optimierung.

Ton beeinflusst ebenfalls die Dateigröße

Die Audiospur benötigt ebenfalls Daten.

Bei einem einfachen gesprochenen Tutorial ist der Videoanteil allerdings typischerweise wesentlich größer als der Tonanteil.

Trotzdem sollte Audio nicht in unnötig überdimensionierter Qualität ausgeliefert werden.

Ton nicht einfach maximal reduzieren

Schlechte Sprachqualität ist sofort störend.

Darum sollte die Audiooptimierung primär fragen:

Ist Sprache klar verständlich?

Der folgende Artikel /wissen/ton-video/ behandelt Aufnahme und Bearbeitung ausführlicher.

Video ohne benötigten Ton

Ein reines Hintergrundvideo kann möglicherweise komplett ohne Audiospur exportiert werden.

keine Audiospur
→ keine Audiodaten

Zusätzlich vereinfacht das Autoplay.

Untertitel

Bei Informationsvideos sind Untertitel nicht nur Komfort. WCAG 2.2 fordert für voraufgezeichnete synchronisierte Medien Untertitel für vorhandene Audioinhalte, soweit die definierte Ausnahme nicht greift. (W3C)

Für einen professionellen Websiteworkflow sollten Untertitel daher von Anfang an mitgedacht werden.

Separate Untertitel statt eingebrannter Schrift

Separate Captions besitzen mehrere Vorteile:

ein-/ausschaltbar
+
übersetzbar
+
zugänglicher
+
nicht Teil der Videopixel

Eingebrannter Text kann für bestimmte Socialformate sinnvoll sein.

Für flexible Websitevideos ist eine eigenständige Untertitelspur häufig leistungsfähiger.

Transkript

Ein vollständiges Transkript kann zusätzlich hilfreich sein.

Der Nutzer kann:

scannen,

suchen,

Text kopieren,

Inhalt ohne Video erfassen.

Video und Text müssen sich nicht gegenseitig ersetzen.

Poster und Untertitel können automatisiert werden

Eine Video-Pipeline könnte beispielsweise:

Master
↓
Transkription
↓
Untertitel erzeugen
↓
Posterframe auswählen
↓
Webversionen encodieren
↓
Website

Das spart bei wiederkehrender Produktion viel Handarbeit.

Automatisierte Qualitätsstufen

Ein Master kann zum Beispiel automatisch verarbeitet werden zu:

1080p
↓
720p
↓
kleinere Mobile-Version

Zusätzlich gegebenenfalls:

moderner Codec
+
Fallback-Codec

Die genauen Profile sollten zur tatsächlichen Nutzung passen und nicht nur deshalb erzeugt werden, weil technisch zehn Varianten möglich sind.

Nicht jede Auflösung braucht eine eigene Datei

Bei einem kleinen Portfolio mit wenigen kurzen Clips reicht möglicherweise:

eine gut optimierte 1080p-Datei.

Komplexe adaptive Streaminginfrastruktur wäre unnötig.

Automatisierung ab dem Punkt, an dem Wiederholung entsteht

Ein guter Grundsatz:

3 Videos
→ manuell gut machbar

300 Videos
→ Pipeline bauen

Die Grenze ist natürlich nicht exakt.

Entscheidend ist:

Wiederholen sich dieselben Schritte ständig?

Ein automatisierter Webvideo-Workflow

neuer Master
↓
technische Analyse
↓
Auflösung bestimmen
↓
Webcodecs erzeugen
↓
Audio optimieren
↓
Poster erstellen
↓
Untertitel zuordnen
↓
Dateigrößen prüfen
↓
Upload
↓
Website aktualisieren

Technische Metadaten erfassen

Für jedes Asset können gespeichert werden:

Asset-ID
Laufzeit
Masterauflösung
Bildrate
Codec
Webvarianten
Untertitel
Poster
Nutzungsrechte

So entsteht ein echtes Videoarchiv statt eines Ordners namens:

video_final_neu_2.mp4

Videomaster und Webderivate trennen

Beispielsweise:

video-4711/
├── master/
├── web/
│   ├── video-1080.mp4
│   └── video-720.mp4
├── poster/
├── captions/
└── metadata/

Der genaue Ordnername ist weniger wichtig als das Prinzip.

Keine Webdatei zurück zum Master machen

Wenn eine neue Websitegeneration plötzlich eine andere Auflösung benötigt:

Master
↓
neu encodieren

Nicht:

alte 720p-Webdatei
↓
hochskalieren
↓
neu komprimieren

Damit vermeidest du unnötigen Generation Loss.

Qualität in tatsächlicher Größe beurteilen

Ein häufiger Fehler:

Webvideo wird im Schnittprogramm fullscreen auf einem großen Monitor bei 200 Prozent betrachtet.

Dabei werden Artefakte sichtbar, die im realen Websiteplayer niemand erkennen würde.

Die entscheidende Prüfung lautet:

Wie sieht es
in tatsächlicher Nutzung aus?

Desktop prüfen

Auf normaler Playergröße.

Smartphone prüfen

Auf realem Mobilgerät.

Langsame Verbindung simulieren

Wenn möglich.

Denn ein Video, das lokal von SSD perfekt startet, sagt nichts über seine Netzwerkwirkung.

Decoding ebenfalls berücksichtigen

Nicht nur Netzwerkbandbreite entscheidet. Das Endgerät muss den verwendeten Codec auch effizient dekodieren können. Die Media Capabilities API kann bei konkreten Konfigurationen unter anderem Informationen dazu liefern, ob ein Format unterstützt, flüssig und energieeffizient dekodierbar ist. (MDN Web Docs)

Das zeigt, warum:

kleinste Datei

nicht immer gleich:

beste Nutzererfahrung

ist.

Mobilgeräte besitzen Akku

Ein Codec, der softwareseitig sehr viel Rechenleistung braucht, kann trotz kleinerer Datei energetisch ungünstig sein.

Hardwareunterstützung ist deshalb ein wichtiger Teil moderner Medienauslieferung. (MDN Web Docs)

Webkompression ist ein mehrdimensionales Problem

Man optimiert gleichzeitig:

Bildqualität
+
Dateigröße
+
Startzeit
+
Kompatibilität
+
Decoderlast
+
Bandbreite

Es gibt daher keinen einzelnen Qualitätsregler, der für jede Website perfekt ist.

Typische Kompressionsartefakte

Zu starke Kompression kann sichtbar werden als:

Blockbildung,

Banding,

Detailverlust,

flimmernde Kanten,

matschige Texturen,

temporales Wabern.

MDN beschreibt solche Qualitätsverluste als typische Folge verlustbehafteter Videokompression, deren Stärke von Codec und Kompressionseinstellung abhängt. (MDN Web Docs)

Blockbildung

Besonders sichtbar in:

dunklen Flächen,

schneller Bewegung,

niedriger Bitrate.

glatte Fläche
↓
sichtbare Blöcke

Banding

Ein Himmel sollte weich verlaufen:

hellblau
↓
mittelblau
↓
dunkelblau

Stattdessen entstehen:

Stufe
Stufe
Stufe

Bittiefe und Encodingqualität spielen dabei eine Rolle. Höhere Farbbittiefe kann feinere Abstufungen ermöglichen und Bearbeitungsreserve erhöhen. (MDN Web Docs)

Feine Details

Gras und Haare können zu einer undefinierten Masse werden.

Das ist häufig ein Hinweis:

zu wenig Daten
für zu viel Detail

Dunkle Szenen besonders prüfen

Hier treffen oft mehrere Probleme zusammen:

wenig Tonwertreserve,

Rauschen,

Kompression.

Das kann schnell zu:

Blockbildung,

Farbflecken,

Banding

führen.

Nicht nur die hellste Szene testen

Ein Encoderpreset sollte mit dem schwierigsten Material geprüft werden.

Zum Beispiel:

dunkle Szene,

schnelle Bewegung,

feine Struktur.

Wenn diese gut aussieht, sind ruhige helle Szenen meist weniger problematisch.

Bildschirmvideos brauchen andere Aufmerksamkeit

Bei einem Tutorial mit Softwareoberfläche sind kleine Texte entscheidend.

Ein zu aggressiv komprimiertes Video kann Menüpunkte unlesbar machen.

Hier kann eine saubere Auflösung wichtiger sein als bei einem atmosphärischen Hintergrundvideo.

Hero-Hintergrund darf weicher sein

Ein Video hinter:

Text,

Overlay,

Navigation

muss nicht jedes Haar pixelgenau darstellen.

Hier kann stärker komprimiert werden, sofern keine störenden Artefakte entstehen.

Unterschiedliche Assettypen brauchen unterschiedliche Profile

Zum Beispiel:

hero-loop
→ kurz
→ kein Audio
→ starke Weboptimierung

tutorial
→ Sprache wichtig
→ Schrift lesbar
→ längere Laufzeit

produktdemo
→ Details wichtig
→ Bewegung sauber

interview
→ Haut + Sprache
→ relativ ruhiges Bild

Das ist besser als ein universelles Exportpreset für alles.

Ein Presetsystem

Beispielsweise konzeptionell:

web-video-hero
web-video-interview
web-video-tutorial
web-video-product

Jedes Preset definiert:

Zielauflösung,

Bildrate,

Codecstrategie,

Qualitätsziel,

Audio,

Posterregeln.

Nicht mit festen Zahlen dogmatisch werden

Ein Preset sollte Ausgangspunkt sein.

Wenn:

Konfetti,

Wasser,

Grain

in einem Clip vorkommen, kann dieser mehr Daten brauchen als ein ruhiges Interview.

Qualitätskontrolle bleibt notwendig.

Ein einfacher manueller Kompressionsworkflow

Schritt 1: Master festlegen

Nicht aus einer bereits stark komprimierten Socialversion arbeiten.

Schritt 2: Laufzeit kürzen

Alles entfernen, was inhaltlich nicht notwendig ist.

Schritt 3: Zielgröße bestimmen

Braucht das Video wirklich 4K?

Oder genügt 1080p beziehungsweise weniger?

Schritt 4: Bildrate prüfen

Braucht das Endvideo wirklich 60 fps?

Schritt 5: geeigneten Webcodec wählen

Kompatibilität und Effizienz abwägen. Für breit kompatible Webauslieferung bleibt H.264/MP4 eine verbreitete Basis; modernere Alternativen können zusätzlich angeboten werden. (MDN Web Docs)

Schritt 6: Qualität beziehungsweise Bitrate testen

Nicht blind maximal.

Eine kurze repräsentative Sequenz exportieren.

Schritt 7: Ton optimieren

Sprache verständlich halten, unnötige Audiospuren vermeiden.

Schritt 8: Poster erzeugen

Eigenständiges optimiertes Vorschaubild.

Schritt 9: echte Wiedergabe testen

Desktop, Smartphone, Browser.

Schritt 10: Website-Ladeverhalten konfigurieren

Poster, preload, gegebenenfalls Lazy Loading und Autoplay bewusst wählen. (MDN Web Docs)

Eine einfache HTML-Einbindung für Inhaltsvideo

Zum Beispiel:

<video
  controls
  preload="none"
  poster="/media/video-poster.webp">
  <source
    src="/media/video.webm"
    type='video/webm; codecs="av01,opus"'>
  <source
    src="/media/video.mp4"
    type="video/mp4">
  Dein Browser kann dieses Video nicht wiedergeben.
</video>

Mehrere <source>-Elemente ermöglichen dem Browser, eine unterstützte Quelle auszuwählen. (MDN Web Docs)

Für ein Video weiter unten

Je nach Zielbrowser und konkretem Setup zusätzlich:

<video
  controls
  loading="lazy"
  preload="none"
  poster="/media/video-poster.webp">
  <source src="/media/video.mp4" type="video/mp4">
</video>

Die aktuelle Browserunterstützung für loading="lazy" bei Medien ist nicht überall identisch; nicht unterstützende Browser ignorieren das Attribut. preload und poster bleiben daher weiterhin relevante Bestandteile. (web.dev)

Für ein Hero-Hintergrundvideo

Konzeptionell:

<video
  autoplay
  muted
  loop
  playsinline
  poster="/media/hero-poster.webp">
  <source src="/media/hero.mp4" type="video/mp4">
</video>

Stummes Video ist für Autoplay deutlich unkomplizierter als hörbare Medien; Browser dürfen Autoplay trotzdem abhängig von ihren Richtlinien und dem Nutzungskontext einschränken. (MDN Web Docs)

Bewegte Inhalte und Nutzerpräferenzen

Nicht jeder Nutzer möchte automatisch abgespielte Bewegung.

Ein guter Webauftritt sollte daher auch berücksichtigen, dass manche Nutzer reduzierte Bewegung bevorzugen.

Das kann beispielsweise bedeuten:

Posterbild statt Hintergrundvideo

oder:

Bewegung reduzieren.

Video ist Gestaltung – und Gestaltung sollte nicht gegen den Nutzer arbeiten.

Häufige Fehler bei Webvideos

Kameraexport direkt hochladen

Die Datei enthält mehr Daten als die Website benötigt.

4K überall ausliefern

Hohe Aufnahmequalität und nötige Webauflösung werden verwechselt.

60 fps ohne erkennbaren Nutzen

Mehr Frames erhöhen Ressourcenbedarf, ohne das Video zwingend besser zu machen. (MDN Web Docs)

Nur auf Dateigröße schauen

Eine winzige Datei kann deutlich sichtbare Artefakte besitzen.

Nur auf Qualität schauen

Eine visuell perfekte 500-MB-Datei kann für eine normale Website völlig ungeeignet sein.

MP4 mit Codec verwechseln

MP4 beschreibt einen Container; der enthaltene Codec ist eine separate Eigenschaft. (MDN Web Docs)

Nur einen modernen Codec ohne Fallback anbieten

Codecunterstützung kann je nach Gerät variieren; mehrere <source>-Quellen können eine robuste Strategie bilden. (MDN Web Docs)

Autoplay mit Ton

Browser schränken hörbares Autoplay typischerweise ein, und ungefragter Ton ist auch aus Nutzersicht problematisch. (MDN Web Docs)

Alle Videos sofort preloaden

Der Nutzer lädt Daten, obwohl er das Video möglicherweise nie startet. preload="none" kann bei nutzerinitiierten Videos genau das vermeiden helfen. (web.dev)

Hero-Poster lazy laden

Wenn das Poster LCP-relevant ist, kann verzögertes Laden kontraproduktiv sein. (web.dev)

Kein Poster verwenden

Der Player besitzt vor dem Start keine optimierte visuelle Darstellung, obwohl HTML dafür ausdrücklich das poster-Attribut vorsieht. (MDN Web Docs)

Untertitel vergessen

Voraufgezeichnete synchronisierte Medien mit Audio benötigen nach WCAG 2.2 in den entsprechenden Fällen Captions. (W3C)

Webvideo als Archivmaster verwenden

Spätere Varianten müssen dann aus bereits stark komprimiertem Material entstehen.

Nur lokal testen

Eine Datei, die von SSD sofort startet, kann übers Netz völlig anders wirken.

Nur Desktop testen

Mobile Nutzer besitzen andere Displaygrößen, Verbindungen und Hardware.

Eine sinnvolle Entscheidungslogik

Zuerst:

Welche Aufgabe
hat das Video?

Hero?

Tutorial?

Interview?

Produktdemo?

Dann die Laufzeit

Kann etwas weg?

Jede entfernte Sekunde spart:

Daten,

Ladezeit,

Aufmerksamkeit.

Dann die Auflösung

Wie groß wird es
realistisch dargestellt?

Danach die Bildrate

Brauche ich
wirklich hohe zeitliche Auflösung?

Dann Codec und Qualitätsziel

Wie viel Kompression
ist visuell akzeptabel?

Danach Ladeverhalten

Autoplay?
User-initiated?
Above the Fold?
Weiter unten?

Dann Infrastruktur

Self-Hosting?
Videodienst?
CDN?

Abschließend echte QA

Desktop
+
Smartphone
+
verschiedene Browser
+
langsamere Verbindung

Ein Export ist erst fertig, wenn die reale Nutzererfahrung funktioniert.

Ein kompakter Websitevideo-Workflow

Rohmaterial
↓
Schnitt
↓
hochwertiger Master
↓
Laufzeit optimieren
↓
Zielauflösung wählen
↓
Webcodec + Qualität
↓
Audio optimieren
↓
Poster erzeugen
↓
Untertitel
↓
Upload
↓
Ladeverhalten konfigurieren
↓
Performance prüfen

Für Hero-Videos

kurz
+
ruhig
+
stumm
+
loopfähig
+
stark komprimiert
+
Poster

Für Tutorials

lesbare Details
+
klarer Ton
+
Untertitel
+
nutzerinitiierte Wiedergabe
+
angemessene Auflösung

Für Interviews

saubere Hauttöne
+
verständliche Sprache
+
ruhiges Bild
+
Poster
+
Untertitel

Für Produktdemos

Details
+
saubere Bewegung
+
passende Auflösung
+
kurze Laufzeit

Für lange Wissensvideos

Hier wird ein spezialisiertes Streaming- beziehungsweise Videoplattformsystem zunehmend interessant.

Denn der Nutzer benötigt möglicherweise:

verschiedene Qualitätsstufen,

komfortables Seeking,

Untertitel,

skalierbare Auslieferung.

Webvideo und Core Web Vitals

Videos können um Netzwerkbandbreite mit anderen kritischen Ressourcen konkurrieren. web.dev weist insbesondere darauf hin, Posterbilder und Ladeverhalten abhängig davon zu behandeln, ob das Video beziehungsweise Poster für LCP relevant ist. (web.dev)

Ein Video im Hero sollte deshalb nicht einfach:

als riesige Ressource
sofort alles blockieren

Nur weil Bewegung visuell spektakulär ist.

Manchmal ist ein Bild die bessere Lösung

Ein optimiertes statisches Hero-Bild kann:

wesentlich kleiner,

schneller,

ruhiger

sein.

Die wichtigste Videoentscheidung lautet daher manchmal:

kein Video verwenden

Wann lohnt Video?

Wenn die Bewegung tatsächlich etwas beiträgt.

Zum Beispiel:

Produktmechanismus,

Arbeitsprozess,

Atmosphäre,

Demonstration,

Bewegungsablauf.

Wann reicht ein Bild?

Wenn nur gezeigt werden soll:

wie etwas aussieht.

statische Information
→ Bild

zeitliche Information
→ Video kann helfen

Das ist eine sehr brauchbare Grundregel.

Was du dir über Webvideo-Kompression merken solltest

Ein Webvideo sollte nicht einfach die möglichst hochwertige Produktionsdatei sein. Es ist eine eigenständige Ausgabe für ein konkretes Nutzungs- und Übertragungsszenario.

Der wichtigste Workflow lautet:

Rohmaterial
↓
Schnitt
↓
Master
↓
Webderivat

Der Master bewahrt Qualität und zukünftige Bearbeitungsreserve.

Das Webderivat optimiert:

Qualität
+
Dateigröße
+
Kompatibilität
+
Ladeverhalten

Die Dateigröße wird besonders beeinflusst durch:

Laufzeit
+
Bitrate
+
Auflösung
+
Bildrate
+
Codec
+
Bildinhalt

Die direkteste Stellschraube ist die Bitrate.

mehr Bitrate
→ größere Datei
→ potentiell mehr Qualität

weniger Bitrate
→ kleinere Datei
→ höheres Artefaktrisiko

Der Codec entscheidet mit, wie effizient diese Daten genutzt werden. Moderne Codecs können bei vergleichbarer visueller Qualität effizienter sein, doch Webkompatibilität und Hardware-Decoding müssen mitberücksichtigt werden. (MDN Web Docs)

Auch Auflösung und Bildrate sollten nicht höher als nötig gewählt werden.

4K-Master
↓
1080p-Webderivat

kann ein sehr sinnvoller Workflow sein.

Dasselbe gilt für hohe Bildraten:

60 fps Aufnahme
↓
30 fps Webvideo

kann je nach Produktion sinnvoller sein als permanente 60-fps-Auslieferung.

Ein weiterer wichtiger Hebel ist die Laufzeit:

weniger unnötige Sekunden
=
weniger Daten

Keine Codecoptimierung ist so effektiv wie ein inhaltlich unnötiger Abschnitt, der vollständig entfernt wird.

Für nutzerinitiierte Videos sind Poster und bewusstes Preloading zentrale Werkzeuge. HTML bietet dafür poster und preload; preload="none" kann verhindern helfen, dass ein Video bereits umfangreich geladen wird, obwohl der Nutzer es noch nicht gestartet hat. (MDN Web Docs)

Videos weiter unten auf einer Seite können zusätzlich für verzögertes Laden geeignet sein. Aktuelle Browserunterstützung für loading="lazy" bei Media-Elementen entwickelt sich weiter, weshalb poster und preload weiterhin eigenständig geplant werden sollten. (web.dev)

Hero-Videos benötigen dagegen eine andere Strategie:

kurz
+
stumm
+
ruhig
+
optimiert
+
Poster

Autoplay sollte nur eingesetzt werden, wenn die Bewegung tatsächlich zur Seitengestaltung gehört; hörbares Autoplay wird von Browsern typischerweise eingeschränkt. (MDN Web Docs)

Bei Informationsvideos gehört außerdem Barrierefreiheit zum Produktionsworkflow. Für voraufgezeichnetes synchronisiertes Audio fordert WCAG 2.2 unter den entsprechenden Bedingungen Captions. (W3C)

Die eigentliche Infrastrukturfrage lautet schließlich:

wenige einfache Clips
→ Self-Hosting kann reichen

viele lange Videos
→ Streaming-/Videodienst prüfen

Je größer die Videobibliothek wird, desto stärker werden:

Transcoding,

mehrere Qualitätsstufen,

Bandbreite,

CDN,

Untertitel,

Player

zu eigenen Infrastrukturaufgaben.

Der zentrale Merksatz lautet:

Ein gutes Webvideo ist nicht das Video mit der höchsten Auflösung oder der größten Bitrate. Es ist die kleinste technisch robuste Datei, die in der tatsächlichen Nutzung noch genau die visuelle und akustische Qualität liefert, die der Inhalt benötigt.