A preview has a different job from a summary.
A summary explains the main points. A preview helps someone decide whether the full video is worth opening. Select a compelling moment that represents the source accurately, and avoid misleading context or unnecessary spoilers.
Define the preview rules.
Agree duration, sound behavior, sensitive-content exclusions and opening frames. Connect the source ID and destination URL so every preview remains linked to the correct full asset.
Make discovery usable.
Keep a static poster fallback. Respect reduced-motion preferences and avoid loading a large library of moving previews at once. Test the implementation on smaller screens and slower connections.
Measure downstream value.
Count preview impressions, clicks and actual viewing of the full asset. Compare equivalent placements and traffic cohorts. A higher click-through rate is useful only when the audience finds content that matches its expectations.
Video preview best practices: start muted.
Browsers decide whether a preview may play on its own. Chrome's autoplay policy states that muted autoplay is always allowed, while autoplay with sound needs the visitor to have interacted with the site, a history of watching video with sound there, or an installed web app. Design previews to work silently: no story that depends on dialogue, and an explicit control for anyone who wants sound. Chrome's guidance also says never to assume a video will play. When the play request is refused, show the poster and a play button rather than a pause button for a video that is not running. On iPhone, inline autoplay also needs the playsinline attribute.
How long should a preview run?
There is no single correct duration, but accessibility rules set a useful boundary. WCAG 2.2 success criterion 2.2.2 (Pause, Stop, Hide, level A) requires a way to pause, stop or hide moving content that starts automatically, lasts more than five seconds and is shown alongside other content. The W3C's explanation counts motion triggered by hover, focus or scrolling into view as starting automatically, which covers most hover and in-feed previews. Either keep each automatic preview within five seconds or give it a visible pause control. Longer teasers that the visitor starts deliberately are a different format with their own rules.
Respect motion and data preferences.
Some visitors ask their device to reduce motion; MDN notes that animations such as scaling or panning large objects can trigger discomfort for people with vestibular disorders. Check the prefers-reduced-motion media feature and show the static poster instead of a moving preview when it is set. Do not rely on motion alone to convey what a video is about: the title and poster should still describe it.
Load previews only when they are needed.
A grid of moving previews can cost more data than the page it sits on. Google's web.dev guidance on lazy-loading video recommends a poster image with preload set to none, so no video data loads until playback starts, and loading each clip only as it approaches the viewport, either with the loading attribute where browsers support it or with an Intersection Observer. The exception is a preview that is the largest element on screen: do not lazy-load it, and give its poster high fetch priority so the page does not appear to load slowly.
A checklist before rollout.
Each preview represents the full video honestly and links to the correct asset. It plays muted, with a poster fallback when autoplay is refused. Automatic motion stops within five seconds or has a pause control. Reduced-motion settings show the poster only. Off-screen previews do not download video. Measurement compares downstream viewing, not only clicks, against a static thumbnail in the same placement. Minute-ly.com Video Previews produces previews from live and VOD libraries automatically; the player rules above still belong to the site that shows them.