How to improve core web vitals by optimising your video
- Step 1Confirm the video is actually your LCP element — Run Lighthouse or PageSpeed Insights and check the LCP element. If it's the hero video (or its poster), this workflow applies. If LCP is a heading or image, fix that first — optimising the video won't move the score.
- Step 2Optimise the video file with Web Optimize — Drop the source (MP4/MOV/MKV/WebM, up to your tier's 1 GB / 10 GB / 100 GB limit). The fixed recipe applies 1280px cap + CRF 23 + AAC 128k + faststart. Output is MP4.
- Step 3Add a lightweight poster image — This is the highest-impact LCP step and it's done in markup, not in this tool:
<video poster="hero-poster.webp">. The poster is what paints first — a small, optimised WebP/AVIF poster lets LCP complete before any video bytes are even needed. Export a frame with thumbnail-extractor if you need one. - Step 4Set preload and autoplay attributes correctly — Use
preload="metadata"(notauto) so the browser doesn't fetch the whole file eagerly and contend with LCP resources. For autoplay loops addmuted playsinline autoplay loop. Faststart (already applied) ensures playback can start without the full download. - Step 5Keep the video off the critical request chain — Don't preload the video; let the poster carry the first paint and the (now smaller, faststart) video stream in after. The combination of a small poster + a faststart MP4 keeps LCP about the poster, which is fast.
- Step 6Re-measure in the field, not just the lab — Lab tools (Lighthouse) and field data (CrUX) can differ. After deploying the optimised file + poster, watch your Core Web Vitals report over a few weeks. The smaller, faststart file improves both lab and field LCP, especially on mobile.
What moves video LCP — and which side fixes it
Web Optimize handles the file side; the markup side is on you. Both are needed.
| Factor | Fixed by Web Optimize? | What to do |
|---|---|---|
| Bytes before first frame | Yes | 1280px cap + CRF 23 cut the data on the critical path |
| moov atom at end (full-file wait) | Yes | +faststart moves it to the front |
| First-frame decode speed | Yes (indirectly) | yuv420p H.264 hardware-decodes everywhere |
| Poster image (what LCP usually measures) | No | Add a small WebP/AVIF poster in markup |
| Eager full-file download | No | Set preload="metadata", don't preload the video |
| Render-blocking / layout shift | No | Reserve dimensions, lazy-load below the fold |
LCP targets and how this tool helps hit them
Google's Core Web Vitals thresholds and the file-side contribution.
| Metric | "Good" threshold | Web Optimize contribution |
|---|---|---|
| LCP | ≤ 2.5 s | Smaller + faststart file → first frame paints sooner; poster does the rest |
| CLS | ≤ 0.1 | No direct effect — reserve width/height in markup |
| INP | ≤ 200 ms | Smaller asset frees the main thread/network — indirect help |
Cookbook
An LCP-friendly hero-video setup: the optimised file (this tool) plus the markup (you). JAD runs the FFmpeg equivalent in your browser.
The recipe Web Optimize runs for the LCP file
Smaller bytes + faststart so the first frame is reachable early. This handles the file side of LCP.
ffmpeg -i hero.mp4 \ -vf "scale='min(1280,iw)':-2:flags=lanczos" \ -c:v libx264 -preset medium -crf 23 -pix_fmt yuv420p \ -c:a aac -b:a 128k -movflags +faststart \ hero-web.mp4 Result: 1280-wide, faststart MP4 — first frame decodable from the earliest bytes.
LCP-friendly <video> markup (the part this tool can't do)
The poster is what LCP usually measures for a video. A small WebP poster + metadata preload keeps LCP fast and lets the faststart MP4 stream in behind it.
<video poster="hero-poster.webp" <!-- small; this is LCP --> preload="metadata" <!-- don't fetch whole file --> width="1280" height="720" <!-- reserve space, no CLS --> muted playsinline autoplay loop> <source src="hero-web.mp4" type="video/mp4"> </video>
Generating the poster frame
Export a clean frame as the poster, then compress it as WebP/AVIF. A small poster is the single biggest LCP win for hero videos.
1. Pull a frame: /video-tools/thumbnail-extractor (set intervalSec to land on a good frame, format jpg) 2. Convert/compress to WebP or AVIF (image tooling) 3. Reference it as poster="hero-poster.webp" LCP now completes on the ~20 KB poster, not the MP4.
Before/after LCP on a throttled mobile profile
The combined effect: smaller file + faststart + poster. Numbers are illustrative of the pattern, not a guarantee.
Before: 60 MB MP4, moov at end, no poster, preload=auto LCP ≈ 6.8 s (waits on full video fetch) — FAILS After: 15 MB faststart MP4 + 20 KB WebP poster, preload=metadata LCP ≈ 1.9 s (poster paints fast) — PASSES (<2.5 s)
When the video isn't your LCP — don't optimise it for LCP
If Lighthouse reports a heading or hero image as the LCP element, this tool won't help your score. Fix the real LCP element first.
Lighthouse → 'Largest Contentful Paint element': <h1 class="hero-title"> ← LCP is the heading Then optimising the background video won't move LCP. Fix font loading / heading paint first.
Edge cases and what actually happens
LCP didn't improve after optimising the video
Wrong elementFor many pages the LCP element isn't the video — it's a hero image, heading, or the video's poster. If you optimised the video but LCP is something else, the score won't move. Check the LCP element in Lighthouse/PSI first, then optimise that.
Video has no poster, so the file itself is the LCP
Add a posterWithout a poster, the browser must decode and paint a video frame to register LCP, which is slower than painting a small image. Web Optimize makes that faster (smaller + faststart), but adding a lightweight WebP/AVIF poster is the bigger win and is done in markup, not this tool.
preload="auto" defeats the optimisation
Markup issueIf your <video> uses preload="auto", the browser eagerly fetches the whole file, contending with LCP-critical resources even though the file is smaller. Use preload="metadata" (or none for below-the-fold) so the video doesn't steal bandwidth from the first paint.
Layout shift (CLS) from the video, not LCP
Different metricWeb Optimize doesn't affect CLS. If the video pops in and shifts content, set explicit width/height (or an aspect-ratio box) in CSS to reserve space. That's a markup fix, separate from this tool's job.
Autoplay blocked, so first frame never paints
Policy issueBrowsers block autoplay without muted + playsinline. If the hero is meant to autoplay and doesn't, the first frame may not paint quickly, hurting LCP. Add the required attributes — faststart and the smaller file are already in place.
Source over the tier size limit
RejectedA raw 4K hero master can exceed Free's 1 GB cap. Upgrade (Pro 10 GB / Pro + Media 100 GB) or trim with lossless-trimmer first. The optimised output you actually ship will be far smaller than the source.
4K master OOMs on a phone
OOM on mobileOptimising a 4K hero in a mobile browser can exhaust the WebAssembly heap (Aborted(OOM)). Do the optimisation on desktop; the file your users download is small either way, so field LCP is unaffected by where you encoded it.
1280px cap looks soft on a huge full-bleed hero
By designWeb Optimize caps width at 1280px. On a 4K monitor a full-bleed hero stretched from 1280px may look slightly soft up close. That's the speed/quality trade. If you need a larger source resolution for the hero, use video-transcoder — but bigger files cost LCP.
Field LCP differs from lab LCP
ExpectedLighthouse (lab) runs one simulated environment; CrUX (field) aggregates real users on varied devices/networks. A smaller faststart file helps both, but field numbers move slowly as the 28-day rolling window updates. Don't expect instant field improvement after deploy.
Video below the fold counted against LCP
Lazy-load itOnly above-the-fold content competes for LCP. A below-the-fold video set to preload="none" and lazy-loaded won't affect LCP. If a below-fold video is hurting your score, the markup is fetching it too eagerly — defer it.
Frequently asked questions
Does optimising my video actually improve LCP?
It helps the file side: the 1280px cap + CRF 23 cut the bytes on the critical path, and +faststart means the first frame is decodable from the early bytes instead of after the whole download. But for a <video>, LCP is usually measured against the poster or first painted frame — so you also need a lightweight poster and correct preload in markup. Web Optimize is necessary but not sufficient on its own.
What's the single biggest LCP win for a hero video?
Adding a small, optimised poster image (WebP/AVIF). The browser paints the poster as the LCP element, completing LCP fast without waiting for video bytes. Web Optimize handles the video file; the poster is a markup change you make yourself.
Why does the moov atom matter for LCP?
If the moov atom is at the end (FFmpeg/recorder default), the browser must download the whole file before it can decode any frame — so a frame-based LCP can't complete until the full fetch finishes. +faststart, which Web Optimize always applies, moves the moov to the front so the first frame is reachable from the early bytes.
Should I use preload="auto" on my hero video?
No — that eagerly downloads the whole file and competes with LCP-critical resources. Use preload="metadata" for above-the-fold autoplay heroes, or preload="none" for below-the-fold videos. Faststart (already applied) lets playback start without a full download anyway.
Does Web Optimize affect CLS or INP?
Not directly. CLS is about layout stability — set explicit width/height in markup. INP is interactivity — a smaller asset frees the main thread and network a little, which can help indirectly, but Web Optimize's job is the file, not the markup or JS.
My LCP element is a heading, not the video — will this help?
No. If the LCP element is a heading or image, optimising the video won't change the score. Confirm the LCP element in Lighthouse/PSI and fix that one. Optimise the video for LCP only when the video (or its poster) is the LCP element.
How do I get a poster frame?
Export a frame with thumbnail-extractor, then compress it to WebP/AVIF with image tooling. Reference it as poster="...". A ~20 KB poster lets LCP complete almost immediately.
Will the 1280px cap hurt a full-bleed hero?
On large displays a hero stretched from 1280px may look slightly soft up close. That's the speed trade-off. If sharpness on big screens matters more than LCP, use video-transcoder for a higher resolution — but expect a larger file and a worse LCP.
Is the video uploaded during optimisation?
No. Web Optimize runs in your browser via FFmpeg.wasm — nothing is uploaded. You can run it as part of asset prep locally without sending media to any service, which also keeps it out of your build pipeline's third-party dependencies.
Why does my field LCP lag behind the lab score?
Lab tools test one environment; field data (CrUX) aggregates real users over a 28-day window across many devices and networks. A smaller faststart file improves both, but field numbers update gradually. Give it a few weeks after deploying the optimised file and poster.
How large a source can I optimise for this?
Free up to 1 GB, Pro 10 GB, Pro + Media 100 GB. Optimise on desktop for large 4K masters (mobile may OOM), and ship the small output. The limit is file size, not duration.
Does the smaller file also help on mobile field data?
Yes — mobile users on slower networks benefit most from fewer bytes plus faststart, and yuv420p H.264 hardware-decodes on virtually all phones for a fast first-frame paint. Mobile is usually where Core Web Vitals are worst, so this is where the optimisation pays off most.
Privacy first
Every JAD Video tool runs entirely in your browser via WebCodecs and FFmpeg (WebAssembly). Your video files never leave your device — verified by zero outbound network requests during processing.