A web background video is not a cinema master. It is a short, silent visual layer that must begin quickly, loop cleanly and leave enough bandwidth for the page itself. Uploading the original export to WordPress often produces a file with excessive resolution, bitrate, audio and metadata.
Prepare a separate delivery copy while preserving the source outside the public Media Library.
Define the visual requirement first
Record the largest rendered dimensions, expected crop and loop duration. A 4K file is difficult to justify when the video appears inside a 1,400-pixel-wide hero with a dark overlay.
Trim frames that visitors never see. Prefer a short loop without a visible cut. If the page needs a 40-second narrative, it is probably content video and should have controls rather than behave as a background.
Remove audio from a purely decorative autoplay file. Browsers generally require autoplay media to be muted, and an unused audio track still adds data.
Create a controlled MP4 derivative
FFmpeg can create an H.264 delivery file with broad browser support:
ffmpeg -i hero-master.mov
-vf "scale=1600:-2"
-c:v libx264
-preset slow
-crf 25
-an
-movflags +faststart
hero-web.mp4
scale=1600:-2 limits width and calculates an even height. CRF controls the quality-to-size trade-off; a lower number retains more detail and usually creates a larger file. -an removes audio, while +faststart moves MP4 metadata toward the beginning so playback can start before the complete file downloads.
Treat these values as a test point, not a universal preset. Fine text, gradients and fast movement can require different settings.
Inspect visual quality at the displayed size
Watch the derivative on an ordinary mobile screen and desktop at the page’s actual crop. Look for blocking in shadows, banding in gradients and stuttering motion.
Background overlays can hide some detail, so encode for the final design rather than judging the raw video full-screen. Export two or three controlled variants and choose the smallest one that still looks intentional.
Keep the original master backed up. Re-encoding the already compressed web copy later will accumulate artefacts.
Prepare the poster separately
Extract or design a representative still image, crop it to the same aspect ratio and compress it through the normal responsive image workflow. The poster should work as the permanent presentation when video does not play.
Do not embed promotional text inside the video or poster if the same message can be real HTML. HTML remains searchable, accessible and editable, and it can adapt at mobile widths.
Give the video container a fixed aspect ratio or suitable minimum height so the poster-to-playback transition does not shift the page.
Verify server support for media delivery
The web server should return the correct Content-Type: video/mp4 and support byte-range requests. Range support lets a browser request portions of the file instead of restarting the complete transfer.
Check response headers:
curl -I https://example.com/wp-content/uploads/hero-web.mp4
Look for a successful status, the media content type, an appropriate content length and Accept-Ranges: bytes where supported. Run diagnostic commands only against a URL you control.
If a CDN sits in front of WordPress, inspect the public response as well as the origin. Security rules or hotlink protection can interfere with range requests.
Avoid unnecessary WordPress processing
WordPress does not generate video sizes in the same way it generates image thumbnails. The file you upload is generally the file visitors receive. Prepare it before upload rather than expecting an image optimiser to compress it.
Check hosting upload and post limits, but do not raise them merely to accept an unsuitable master. Large media also increases backups, migrations and disk usage.
For high traffic or a library of content video, object storage or a specialised streaming platform may be more appropriate. A single short background can still be served locally if the server and CDN deliver it correctly.
Integrate it without forcing the download
Use a poster, muted autoplay attributes and a conservative preload value. Do not preload the full file in the page head. Consider showing only the poster on small screens or when reduced motion is requested.
After publishing, inspect the final markup because page builders may duplicate sources or add a mobile video without removing the desktop request.
Test the complete page
Test a cold load on mobile data, not just direct playback of the MP4 URL. Confirm the poster appears promptly, the heading remains readable, video starts without blocking the call to action and the loop does not cause high CPU use.
Compare the media bytes with the page’s other critical resources. A successful encode that saves 50% may still be inappropriate if several megabytes transfer before visitors can act.
If media headers, CDN caching, page-builder markup or responsive fallbacks are unclear, request a scoped performance assessment. An initial review needs the public page and source specifications, not hosting passwords.