Video Optimization
Compress and format video files correctly so they load fast without sacrificing playback quality.
Metrics
This technique can move up to 100% of LCP's share of the Lighthouse score.
This technique can move up to 33% of TBT's share of the Lighthouse score.
This technique does not move CLS.
This technique can move up to 33% of FCP's share of the Lighthouse score.
This technique can move up to 67% of SI's share of the Lighthouse score.
This technique does not move TTFB.
Overview
Video files are the heaviest assets on any web page — an unoptimized background video can be 50–200 MB, and even a short product demo can weigh 10–30 MB without compression. The key levers are codec selection (H.264 for compatibility, H.265/AV1 for efficiency), bitrate targeting, resolution capping, and adding the right HTML attributes so the browser handles autoplay, preloading, and responsive sizing correctly. Properly optimized videos can be 5–15× smaller than originals with no perceptible quality loss.
Impact grade, A+ to D: how much of the Lighthouse score this technique can move. Unaffected: CLS, TTFB.
The Problem
WordPress has no built-in video optimization pipeline. Videos are uploaded as-is and served directly. A videographer’s original 1080p export at 50 Mbps bitrate, suitable for broadcast but catastrophic for web delivery, gets placed on a homepage background with no compression step. The browser must download megabytes of video data before it can render the LCP element if the video is above the fold. Even when the video is not the LCP element, initiating a large video download competes with critical resources for bandwidth.
Performance Impact
LCP
30–80%
when the video is the LCP element, smaller file size directly cuts time-to-first-frame
TBT
Indirect
less bandwidth competition from the video means critical scripts and CSS load faster
FCP
Indirect
reduced bandwidth pressure benefits the critical path to first paint
SI
Significant
a background video that loads faster means the hero section appears complete sooner
Risk: Low
compression settings are tunable — test output quality before replacing originals
How it works
01
Choose the right codec
H.264 (MP4) has near-universal browser support and is the safe default. WebM/VP9 achieves 20–40% better compression at the same quality. AV1 (WebM or MP4) achieves 30–50% better compression than H.264 but requires modern browsers — serve as a
<source>fallback chain: AV1 first, then VP9, then H.264.02
Target appropriate bitrate and resolution
A 1080p background video at 1.5 Mbps is visually indistinguishable from one at 8 Mbps for most content types. Cap resolution at 1280×720 for background videos — they are never viewed full-screen. Use
ffmpeg -crf 28for H.264 (lower = larger file, higher quality) or-crf 35for AV1 to target visually lossless output.03
Add the correct HTML attributes
Background videos must have
autoplay muted playsinline loop. Withoutmuted, autoplay is blocked by browsers. Withoutplaysinline, iOS Safari fullscreens the video on tap. Addpreload="none"for videos below the fold, orpreload="metadata"for above-fold videos where you only need the first frame.04
Use the poster attribute
The
posterattribute specifies an image to display before the video loads. A well-chosen, compressed poster image (typically a WebP screenshot of the first frame at 80–100 KB) ensures the hero section looks complete immediately while the video continues loading in the background.
Code Example
<!-- Original upload: 45 MB MP4 at 1080p, 25 Mbps bitrate -->
<video src="/wp-content/uploads/hero.mp4" autoplay loop></video><!-- Optimized: 3.2 MB WebM (AV1) + 5.1 MB MP4 (H.264) fallback, 720p, correct attributes -->
<video autoplay muted loop playsinline preload="metadata"
poster="/wp-content/uploads/hero-poster.webp">
<source src="/wp-content/uploads/hero.webm" type="video/webm; codecs=av01.0.05M.08">
<source src="/wp-content/uploads/hero.mp4" type="video/mp4">
</video>Encode with ffmpeg: ffmpeg -i original.mp4 -c:v libx264 -crf 28 -vf scale=1280:-2 -an hero.mp4 for H.264, and ffmpeg -i original.mp4 -c:v libaom-av1 -crf 35 -vf scale=1280:-2 -an hero.webm for AV1.
Limitations
- AV1 encoding is CPU-intensive and slow — a 30-second clip can take 10–30 minutes to encode. Budget encoding time into your publishing workflow or use a cloud encoding service.
- WordPress does not generate optimized video formats on upload. Encoding must happen before upload, in a post-upload hook, or via an external service.
- Autoplaying video on mobile burns battery and data. Consider using
prefers-reduced-motionmedia query to disable autoplay for users who opt out of motion.
Common Mistakes
Uploading the original high-bitrate source video directly to WordPress
Always encode a web-optimized version before uploading. Store the original in cloud storage (S3, Bunny Storage) and serve only the compressed version from the site.
Forgetting the muted attribute on autoplay videos
Chrome, Firefox, and Safari all block autoplay for videos with audio unless the video is muted or the user has previously interacted with the site. Without muted, the video will not play automatically, leaving a static poster image.
Using a video as a background when a CSS animation or image would suffice
If the visual effect is subtle (a slow colour shift, a gentle texture), a CSS animation or a well-compressed AVIF image achieves the same result at a fraction of the byte cost.