Simon Hearne

Web Performance Architect

Email Twitter LinkedIn Github RSS

Fast and Responsive Hero Videos for Great UX

Published , last modified on

Responsive landing page hero videos are increasingly popular, here we show how to make them as fast as possible.

❤️ 46 likes 🔁 15 reposts 💬 9 comments 🔗 3 shares as of 15:00, November 22


Landing page hero videos are increasingly popular, especially in high fashion and luxury goods. Hero videos can have a detrimental effect on user experience though, delaying page load times and causing the page to jump around. In this post we will take an example homepage and see how we can optimise it to deliver fast, responsive videos for great UX.

Jump straight to the conclusion to see the results for each optimisation (in total we halve the video load time) and see the final working demo with code!

The example website uses different aspect ratio videos for narrow and wide viewports

Consider this simple homepage with a hero video and content below the video. The video has been created in two aspect ratios: one for mobile / portrait viewports and another for desktop / landscape viewports. It is common to see this developed along the following lines:

<!-- ==== homepage.html ==== -->

<video
  class="full-width-video" id="hero-video"
  playsinline muted loop autoplay
  src="desktop.mp4"
  data-src-mobile="mobile.mp4"
  data-src-desktop="desktop.mp4">
    <div class="video-error">Uhoh, no video for you.</div>
</video>
/* ==== style.css ==== */

.full-width-video {
  background-color: black;
  width: 100%;
}
/* ==== app.js ==== */

const DESKTOP_BREAKPOINT = 480;
window.addEventListener("load",function() {
  let heroVideoEl = document.getElementByID("hero-video");
  let heroVideoSrc = heroVideoEl.dataset.srcMobile
  let viewportWidth = window.innerWidth;
  if (viewportWidth >= DESKTOP_BREAKPOINT) {
    heroVideoSrc = heroVideoEl.dataset.srcDesktop;
  }
  heroVideoEl.src = heroVideoSrc;
})

Note that the <video> element no size attributes and has a src which will be replaced for mobile visitors. This causes two types of issue:

Performance

  1. The desktop video will likely always be requested, even for mobile visitors who will never see it. The browser should cancel the request when the src is replaced, at least.
  2. The mobile video doesn’t start downloading until after app.js has downloaded, parsed and executed - delaying the mobile experience. On a 3G connection we must wait six seconds to see the first frame of the video!
Slow hero videos can detract from landing page experience.

Layout

The browser cannot allocate the correct vertical space for the video until the first chunk is downloaded, causing an unpleasant layout shift at 5.5s in the filmstrip above.

The following four sections will take us from this six second experience to under three seconds, and with no layout shifts!

Optimisation 1: Preventing the Layout Shift

The layout shift above is caused by the lack of size information on the video element. In this case there are two different video aspect ratios - wide for desktop and narrow for mobile - so we cannot simply add width and height attributes to the <video> element.

aspect-ratio to the rescue!

aspect-ratio in CSS has only recently gained widespread browser support, but it is now safe to use across all evergreen browsers and Safari! This makes it simple to resolve the layout shift with just a few lines of CSS:

/* ==== style.css ==== */

/* default to mobile */
.full-width-video {
  width: 100%;
  background-color: black;
  aspect-ratio: 1280 / 960; /* width and height of the mobile video */
}
/* override for desktop */ 
@media only screen and (min-width: 480px) {
  .full-width-video {
    aspect-ratio: 1280 / 720;
  }
}

The result is that the browser knows how much space to allocate for the video, for both aspect-ratios, as soon as it is able to render the first frame. No more layout shift!

A few lines of CSS removes layout shift entirely (view filmstrip)

We haven’t yet made the video load faster, though…

Optimisation 2: Better source selection

We’re currently over-downloading on mobile by requesting the desktop video, then switching it out when our application JavaScript runs. Note that the desktop video continues to download until after app1.js has completely loaded at 3.6s.

Late-running JavaScript means that both Desktop and Mobile videos download

Ideally, we would use native browser support to select the desktop or mobile video to avoid using JavaScript and remove the redundant request on mobile. Unfortunately this is not as easy as it should be. Intuitively we would use the familiar media query to determine which video version to load:

<video>
  <source src="desktop.mp4" type="video/mp4" media="all and (min-width:480px)">
  <source src="mobile.mp4"  type="video/mp4" media="all and (max-width:479px)">
</video>

Whilst this was once possible, it has now been removed from the spec and no browsers support it (except WebKit). So for now, we must use JavaScript. But we can still improve on the initial implementation!

The initial implementation had application code to set the video source that ran late in the page, well after the first paint. Moving the logic to be adjacent to the video will ensure that the code runs immediately after the video element is parsed by the browser, bringing the video render earlier.

First, we should remove the potentially wasteful desktop src value, then move the source selection logic out of app.js and into the HTML. I’m not generally a fan of inline scripts, but this is exactly the type of scenario where it makes sense. We can wrap this logic in a function and call it on resize to ensure that the correct video is always rendered. You will also want to add a <noscript> container with a fallback video at this point.

November 4, 2021: Updated based on Anthony Ricaud's feedback, thanks Anthony!

<!-- ==== homepage.html ==== -->

<video
  class="full-width-video" id="hero-video"
  playsinline muted loop autoplay
  data-src-mobile="mobile.mp4"
  data-src-desktop="desktop.mp4">
    <div class="video-error">Uhoh, no video for you.</div>
</video>
<script>
    const WIDE_VIEWPORT = 480;

    function resizeVideo(wideViewport) {
      let videoEl = document.getElementById("hero-video");
      let src = videoEl.dataset.mobileSrc;
      if (wideViewport.matches) {
        src = videoEl.dataset.desktopSrc;
      }
      if (videoEl.src !== src) {
        videoEl.src = src
      }
    }
    const wideViewport = window.matchMedia(`(min-width: ${WIDE_VIEWPORT}px)`)
    wideViewport.addListener(resizeVideo)
    resizeVideo(wideViewport)
</script>

The result is a slightly faster render, both of the page and the first frame of the video.

A few lines of inline JS improves render time slightly (view filmstrip)

Removing the redundant download of the desktop video also saves some transmitted bytes, 350kB in this test.

350kB of unnecessary video bytes removed with the inline-JS change

We are seeing some improvement, but 5.5s is still slow!

Optimisation 3: Poster Images

The HTML5 <video> element supports the poster attribute, this lets us define an image to use as a placeholder until the browser has downloaded enough of the video to start playing it. This is a more elegant solution than attempting to preload the entire video file, preserving early bandwidth for more important assets such as CSS and JavaScript.

Placeholder images can be heavily optimised as they are only shown for a short period of time. Use a gaussian blur and a high image compression level to get the image size to around 10kB for each video.

We’ll add our optimised placeholder images using the same dataset logic that we have used for the video files:

<!-- ==== homepage.html ==== -->

<video
  class="full-width-video" id="hero-video"
  playsinline muted loop autoplay
  data-src-mobile="mobile.mp4"
  data-src-desktop="desktop.mp4"
  data-poster-mobile="mobile.jpg"
  data-poster-desktop="desktop.jpg">
    <div class="video-error">Uhoh, no video for you.</div>
</video>
<script>
    const WIDE_VIEWPORT = 480;

    function resizeVideo(wideViewport) {
      let videoEl = document.getElementById("hero-video");
      let src = videoEl.dataset.mobileSrc;
      let poster = videoEl.dataset.mobilePoster;
      let widthDisplay = 'MOBILE';
      if (wideViewport.matches) {
        src = videoEl.dataset.desktopSrc;
        poster = videoEl.dataset.desktopPoster;
        widthDisplay = 'DESKTOP';
      }
      if (videoEl.src !== src) {
        videoEl.src = src;
        videoEl.poster = poster;
      }
    }
    const wideViewport = window.matchMedia(`(min-width: ${WIDE_VIEWPORT}px)`);
    wideViewport.addListener(resizeVideo);
    resizeVideo(wideViewport);
</script>

The result of this is the biggest improvement we’ve seen so far - almost two whole seconds faster! This is especially important for low bandwidth users who may not see the video play for another ten seconds after the poster image is shown.

Valid poster images dramatically improve perceived performance (view filmstrip)

Optimisation 4: Preload the Poster Image

If you look carefully at the waterfall chart of the last test, you’ll notice that the poster image is requested quite late - after the blocking script has downloaded and executed.

Poster images delayed

We can help the browser here by using preload hints, directives which instruct the browser to download files that it hasn’t yet discovered:

<!-- ==== homepage.html ==== -->
  <!-- preloads should be at the bottom of the head -->
  <link rel="preload" href="desktop_poster.jpg" as="image" media="all and (min-width:480px)">
  <link rel="preload" href="mobile__poster.jpg"  as="image" media="all and (max-width:479px)">
</head>

These allow the browser to request the poster images early, and do support media queries so that we can fetch the correct image! The result is a slightly faster render of the poster image:

Preload poster images for the final performance gains!

Another alternative that I have seen used is to Base64 encode the poster image and insert it directly into the attribute. I am not a fan of this method: it bloats the HTML document and causes the browser to download unnecessary content (at least one of the poster images is not required). I would not recommend this unless the encoded images are under 1kB, for example a simple play icon on a plain background.

It may be possible to further improve performance, specifically by deferring the application JavaScript bundle and further optimising the video files. For now, though, we should be happy with a 50% improvement in render performance!

Conclusion

We have applied four simple optimisations to a landing page hero video, removing a layout shift and improving the render time for the video from six seconds to three on a 3G connection. Videos don’t have to slow down your site, as long as we pay attention to the details.

Implementing all of these recommendations makes for a much faster user experience (view filmstrip)

There are five key steps to ensuring your responsive hero videos render quickly:

  1. Set the video src as soon as possible
  2. Use CSS to allocate the correct space for the video
  3. Use the poster attribute for a fast rendering first frame
  4. Use responsive preloads to optimise poster image delivery
  5. Optimize your video assets

We didn’t cover it in this post, but it is critical that your video assets are optimised! Some simple tricks are to remove the audio track from muted videos, scale the video to the size it will be rendered and use the optimal format for the vistor’s browser. Most of these are relatively simple to do, but for responsive videos it can be difficult to determine the optimal widths and formats. Here I would recommend using a video hosting & optimisation service which can automate these tasks:

Each of these (and a number of other services) can automatically serve the best format and width for each visitor, dramatically reducing file size and improving render performance.

To get started with your hero video, you can view the full working demo below or directly on CodePen. This code should be enhanced with error handling and support for browsers with JavaScript disabled: use a <noscript> element to contain a fallback video behaviour - perhaps just showing the poster image.

See the Pen fast-responsive-video by Simon Hearne (@simonhearne) on CodePen.


Join the conversation

The comments on this page are fed by tweets, using brid.gy, webmention.io and a modified version of jekyll-webmention_io. To comment, just send a webmention or use a link below to interact via twitter.




Recent comments

  1. Brian Louis Ramirez

    Nice post! Yeah, it’s a drag that Chrome doesn’t support media queries on video source tags.

    view
  2. Tim Bednar

    I like that you added the autoplay to this as it helps if you are using video for short animations. Thanks.

    view
  3. Simon Hearne

    I was honestly surprised when I tried it and it didn’t work. Definitely a gap in the video spec at the moment.

    view
  4. Brian Louis Ramirez

    Same here, was trying to optimize away an ATF animated GIF and was unpleasantly surprised by the missing media query support

    view
  5. Joan León 🏞⚡️

    Great post, thank you Simom 😊

    view
  6. Simon Hearne

    Thanks for the feedback Joan!

    view
  7. Anthony Ricaud

    Lots of great points!

    Why are you using device-width media queries for the preload instead of viewport-width?

    I took your request for event debouncing enhancement and used window.matchMedia for that: codepen.io/Rik/pen/VwzQPe…

    view
  8. Simon Hearne

    Amazing, thanks for sharing! I’ve updated the codepen and post (plus fixed a few inconsistencies in the code blocks). May need a hard-refresh (HTML has a 1hr cache). simonhearne.com/2021/fast-resp…

    view
  9. Sergey Chernyshev

    Must be a very powerful base

    view

Recent shares