Artikel

Video performance — Lazy loading, formater og indlæsningsstrategi

Video er dyrere end billeder. preload='none' forhindrer at videofiler downloades ved sideload. Facade patterns erstatter YouTube-embeds med en thumbnail der kun loader spilleren ved klik.

Video er den tyngste ressource-type på nettet målt på bandwidth og parsing-tid, og dårlig video-håndtering er en direkte årsag til dårlige Core Web Vitals — særligt LCP og INP. For SEO er video-performance relevant fordi Google bruger CrUX field-data som rankinggrundlag, og sider med video er særligt udsatte for performance-problemer på mobile enheder og langsomme forbindelser. Strategierne er velkendte: preload=‘none’, facade patterns til YouTube-embeds og moderne videoformater reducerer videoens performance-impact markant.

preload-attributten

preload styrer browserens forhåndsindlæsningsadfærd:

<!-- Download ingen videodata ved sideload -->
<video preload="none" poster="/video-thumbnail.jpg">
  <source src="video.webm" type="video/webm">
  <source src="video.mp4" type="video/mp4">
</video>

<!-- Download kun metadata (varighed, dimensioner) -->
<video preload="metadata">
  <source src="video.webm" type="video/webm">
  <source src="video.mp4" type="video/mp4">
</video>

<!-- Download hele videofilen — kun til hero-video over fold -->
<video preload="auto">
  <source src="video.webm" type="video/webm">
</video>

Brug preload="none" som default. Tilføj preload="auto" kun til hero-videoer der er over fold og central for siden.

Poster-billede

poster viser et statisk billede mens videoen ikke afspilles. Det er kritisk for LCP hvis videoen er det primære over-fold-element:

<video
  preload="none"
  poster="/hero-poster.webp"
  width="1280"
  height="720"
>
  <source src="hero.webm" type="video/webm">
  <source src="hero.mp4" type="video/mp4">
</video>

Poster-billedet skal optimeres som et normalt billede (WebP, korrekt størrelse). Hvis det er LCP-elementet: fetchpriority="high"<link rel="preload"> for posterbildedet.

Lazy loading af video

loading="lazy" fungerer ikke på <video> (kun <img> og <iframe>). Brug Intersection Observer til at indlæse video-src on-demand:

const videos = document.querySelectorAll('video[data-src]');

const observer = new IntersectionObserver((entries) => {
  entries.forEach((entry) => {
    if (entry.isIntersecting) {
      const video = entry.target;
      video.src = video.dataset.src;
      video.load();
      observer.unobserve(video);
    }
  });
}, { rootMargin: '200px' });

videos.forEach(video => observer.observe(video));
<video data-src="video.mp4" preload="none" poster="/thumb.webp">
</video>

YouTube og Vimeo facade patterns

En standard YouTube-embed indlæser 400-500 KB JavaScript, etablerer 20+ netværksforbindelser og tilføjer typisk 300-500ms til TBT. Facade patterns eliminerer dette:

Lite YouTube Embed (lite-youtube-embed):

<lite-youtube videoid="dQw4w9WgXcQ" playlabel="Afspil video"></lite-youtube>
<script src="/lite-youtube-embed.js" defer></script>

Viser kun et thumbnail med play-knap. Selve YouTube-spilleren indlæses ved klik. Sparer typisk 400+ KB og eliminerer YouTube’s tracking-scripts ved sideload.

Custom facade:

<div class="video-facade" data-videoid="dQw4w9WgXcQ">
  <img
    src="/thumbnails/dQw4w9WgXcQ.webp"
    alt="Video titel"
    width="1280"
    height="720"
    loading="lazy"
  >
  <button aria-label="Afspil video">▶</button>
</div>

<script>
document.querySelectorAll('.video-facade').forEach(facade => {
  facade.querySelector('button').addEventListener('click', () => {
    const id = facade.dataset.videoid;
    facade.innerHTML = `
      <iframe
        src="https://www.youtube-nocookie.com/embed/${id}?autoplay=1"
        width="1280" height="720"
        allow="autoplay; encrypted-media"
        loading="lazy"
      ></iframe>
    `;
  });
});
</script>

youtube-nocookie.com er Googles privacy-enhanced mode — reducerer tracking og færre cookies.

Moderne videoformater

FormatCodecKomprimeringBrowser-support
MP4H.264BaselineAlle browsere
WebMVP9~30% bedre end H.264Chrome, Firefox, Edge
WebMAV1~50% bedre end H.264Chrome 70+, Firefox 67+

Serv WebM/AV1 som primær kilde med MP4/H.264 fallback:

<video preload="none">
  <source src="video.av1.webm" type="video/webm; codecs=av01">
  <source src="video.vp9.webm" type="video/webm">
  <source src="video.mp4" type="video/mp4">
</video>

Autoplay og performance

Autoplay med lyd blokeres af alle moderne browsere (undtagen i iOS med playsinline muted). Lydløs autoplay er tilladt og bruges til baggrundsvideo-loops:

<video autoplay muted loop playsinline preload="auto"
  poster="/poster.webp" width="1280" height="720">
  <source src="background.webm" type="video/webm">
  <source src="background.mp4" type="video/mp4">
</video>

Baggrundsvideo er performance-intensiv: overvej at erstatte med en animeret GIF eller CSS-animation for simple bevægelser. → Denne artikel er en del af Web Performance — Core Web Vitals og teknisk hastighed.

Andre artikler i samme emne

Ofte stillede spørgsmål

Hvad er den vigtigste video performance-optimering?
Brug preload='none' på alle video-elementer der ikke er kritiske for siden, og facade patterns til YouTube og Vimeo-embeds. En enkelt YouTube iframe indlæser 400-500 KB JavaScript ved sideload uanset om brugeren nogensinde klikker på den. Facade patterns eliminerer denne overhead komplet.
Hvad er forskellen på WebM og MP4 til web?
MP4 med H.264 er det universelle format — understøttes i alle browsere og enheder. WebM med VP9 er 30-50% mere komprimeret end MP4/H.264 ved sammenlignelig kvalitet og understøttes i Chrome, Firefox og Edge. AV1 i WebM er 50% mere komprimeret end H.264 men CPU-intensiv at afkode på ældre enheder. Brug picture-source-mønsteret til at servere WebM med MP4 fallback.
Påvirker YouTube-embeds Core Web Vitals?
Ja markant. En standard YouTube-iframe injicerer 400-500 KB JavaScript, etablerer 20+ netværksforbindelser og øger Total Blocking Time med 300-500ms. Det er direkte skadeligt for INP og LCP. Facade patterns (lite-youtube-embed eller custom thumbnail) eliminerer denne overhead — YouTube-spilleren loades kun ved klik og påvirker ikke sideindlæsningens performance.
Hvornår er baggrundsvideo-loops en dårlig idé for performance?
Baggrundsvideo er performance-intensiv fordi den typisk autoloader (preload='auto') og streamet. En 10-sekunders loop kan fylde 5-20 MB afhængigt af komprimering. På mobile enheder med dataspar er det et reelt problem. Overvej CSS-animationer eller animerede WebP/AVIF som alternativer til simple bevægelser. Hvis baggrundsvideo er nødvendig: brug korte loops (3-5 sek.), aggressiv komprimering og serve kun til desktop via media queries.
Hvad er lazy loading af video og hvorfor er det anderledes end billeder?
loading='lazy'-attributten virker på <img> og <iframe> men ikke på <video>-elementet. For selvhostede videoer bruges Intersection Observer API til at tilsætte video src-attributten når elementet er ved at komme i viewporten. For YouTube- og Vimeo-embeds via <iframe> virker loading='lazy' og er den anbefalede metode. Facade patterns er dog bedre end lazy iframe fordi de eliminerer script-overhead helt frem for blot at udskyde det.

Placering i ordbogen

Video performance — Lazy loading, formater og indlæsningsstrategi