Video on your own website: video tag, formats, poster, preload

Putting a video on a web page seems trivial: you upload the file and link it. In practice, a video added without care can slow down page loading, eat into mobile users' data, fail to play in some browsers or shift the content around while it loads. With a few reasoned choices you get a light, compatible and accessible result instead, without necessarily depending on external platforms.

Hosting it yourself or using a platform

There are two options:

• embedding a video platform's player: simple and free of bandwidth costs, but the external player loads its own scripts, shows the platform's branding and may suggest other content at the end;
• hosting the file on your own site or a storage service: full control over appearance, privacy and behaviour, but bandwidth and compatibility become your responsibility.

For short decorative videos, product demos or tutorials of a few minutes, direct hosting is often the best choice. For long, heavily viewed content it is worth considering adaptive streaming.

The video element

HTML provides the <video> element, supported by all modern browsers. A complete, reasoned version looks like this:

<video controls preload="metadata" poster="preview.jpg" width="1280" height="720" playsinline>
  <source src="demo.av1.mp4" type='video/mp4; codecs="av01.0.05M.08"'>
  <source src="demo.h264.mp4" type="video/mp4">
  <track kind="subtitles" src="demo.en.vtt" srclang="en" label="English" default>
</video>

Let us go through the attributes one by one.

Multiple sources

The browser reads the <source> elements in order and uses the first one it can play. By listing a lighter AV1 version first and then an H.264 fallback, recent browsers download less data and older ones keep working. The type attribute with the codecs parameter lets the browser skip a source without downloading it.

Poster

The poster image is shown before playback. Without a poster the browser shows the first frame, which is often black or unrepresentative, and has to download part of the video to get it. A well-compressed WebP or AVIF image weighs very little.

Preload

The preload attribute indicates how much to download before the user presses play:

• none: nothing, the video loads only on click;
• metadata: only duration and dimensions, the balanced choice for most cases;
• auto: the browser may download even the whole file, useful only if you are sure it will be watched.

Dimensions

Specifying width and height, or using the CSS aspect-ratio property, reserves the video's space before it loads. Without this information the page «jumps» when the video appears, an annoying flaw for readers and one penalised by visual stability metrics.

Subtitles

The <track> element links a WebVTT file. It is essential for accessibility and useful for people watching without sound.

Autoplaying video

Decorative background videos, for example in a page header, need a precise combination of attributes:

<video autoplay muted loop playsinline poster="background.jpg">
  <source src="background.mp4" type="video/mp4">
</video>

Browsers usually allow autoplay only if the video is silent: the muted attribute is essential. playsinline stops the video opening full screen on iPhone. For these videos:

• keep the duration short, a few seconds on a loop;
• remove the audio track from the file entirely, rather than just muting it;
• use modest resolution and bitrate, since the video will often be covered by text;
• respect the user's reduced-motion preference by showing only the poster when it is on.

Preparing the file

A file for the web should have:

1. the index at the start of the file (the -movflags +faststart option in FFmpeg), so playback begins before the download is complete;
2. the yuv420p pixel format for compatibility;
3. a resolution suited to the actual space on the page: a video shown 800 pixels wide does not need to be 4K;
4. a bitrate controlled with CRF and a maximum cap.

When to move to adaptive streaming

A single MP4 file is fine as long as the video is short and the audience has similar connections. Adaptive streaming with HLS becomes preferable when:

• videos last more than a few minutes;
• many users watch on variable mobile networks;
• you want to offer several qualities without the user having to choose.

Safari plays HLS natively; other browsers need a JavaScript library, which adds weight to the page but remains light compared with the video itself.

Common mistakes

• uploading the camera's original file, often heavy and in a poorly compatible codec;
• using preload="auto" on pages with several videos;
• forgetting the poster, forcing the browser to download data just to show a preview;
• adding autoplaying videos with sound, which browsers block.

In short

• The video element with multiple sources gives recent browsers light files and others compatibility.
• A poster and preload="metadata" reduce data downloaded before play.
• Declared dimensions prevent the page from shifting.
• Autoplay requires silent, short and light videos.
• For long videos and mobile audiences, adaptive streaming is the better route.