Optimize and compress web videos

Rule Details

Video is often the heaviest single asset on a page. A source file straight off a camera or screen recorder is typically encoded for archival quality, not for the size and bitrate a browser actually needs—re-encoding it for the web can cut file size dramatically with no visible difference at normal playback sizes.

Code Example

Serve the smallest codec/resolution combination the browser supports, with a fallback for older browsers.

<video poster="hero-poster.jpg" preload="metadata" muted playsinline controls>
  <source src="hero-1080p.av1.webm" type="video/webm; codecs=av01.0.05M.08" />
  <source src="hero-1080p.vp9.webm" type="video/webm; codecs=vp9" />
  <source src="hero-1080p.h264.mp4" type="video/mp4" />
  Your browser does not support the video tag.
</video>

# FFmpeg: re-encode to H.264 at a reasonable quality/size tradeoff
ffmpeg -i input.mov -c:v libx264 -crf 23 -preset slow -c:a aac -b:a 128k output.mp4
 
# FFmpeg: VP9/WebM, smaller than H.264 at the same visual quality
ffmpeg -i input.mov -c:v libvpx-vp9 -crf 32 -b:v 0 -an output.webm
 
# Strip audio entirely from a silent background/looping video
ffmpeg -i input.mp4 -c copy -an output-no-audio.mp4

Why It Matters

Unoptimized video is frequently the single heaviest asset on a page—an uncompressed or oversized video can dwarf every image and script combined, delaying Largest Contentful Paint and burning mobile data budgets.

Resolution and Bitrate

Match the delivered resolution to how large the video will actually render, not the resolution it was captured at.

Serving a 4K background video behind a 400px-tall hero section wastes bandwidth the same way an oversized <img> does.

Codec Choice

Framework Examples

Codec fallback via <source> solves format negotiation, but the native <video> element still has no way to pick a resolution per breakpoint the way <picture> does for images with media queries on <source>. A naive fix either ships every resolution in one hidden-by-CSS <video> per size (the browser downloads all of them regardless of display: none) or requires manual JS to swap sources after the fact.

import ReactResponsiveVideo from '@damiarita/react-responsive-video'
 
function ResponsiveHero() {
  return (
    <ReactResponsiveVideo
      videoProps={{ autoPlay: true, muted: true, loop: true, playsInline: true }}
      sizes={[
        {
          width: 1920,
          height: 1080,
          mediaQuery: '(min-width: 1200px)',
          videoSources: [
            { url: '/hero-1080p.webm', format: 'video/webm' },
            { url: '/hero-1080p.mp4', format: 'video/mp4' },
          ],
          posterSources: [
            { url: '/hero-1080p.webp', format: 'image/webp' },
            { url: '/hero-1080p.jpg', format: 'image/jpeg' },
          ],
        },
        {
          width: 640,
          height: 360,
          videoSources: [
            { url: '/hero-360p.webm', format: 'video/webm' },
            { url: '/hero-360p.mp4', format: 'video/mp4' },
          ],
          posterSources: [
            { url: '/hero-360p.webp', format: 'image/webp' },
            { url: '/hero-360p.jpg', format: 'image/jpeg' },
          ],
        },
      ]}
    />
  )
}

This component renders an SSR-safe <picture> placeholder first, then swaps in the <video> for the resolution matching the resolved media query once it's running in the browser—so only one poster/video pair downloads instead of one per breakpoint.

Common Mistakes

Verification

Automated Checks

• Check transferred file size in DevTools' Network tab, filtered to Media
• Run Lighthouse and review any "Efficiently encode video" or LCP-related flags

Manual Checks

• Confirm the player-rendered size roughly matches the delivered resolution (no visible downscaling of a much larger source)
• Play the video on a throttled mobile network profile to confirm reasonable start time