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" på <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
| Format | Codec | Komprimering | Browser-support |
|---|---|---|---|
| MP4 | H.264 | Baseline | Alle browsere |
| WebM | VP9 | ~30% bedre end H.264 | Chrome, Firefox, Edge |
| WebM | AV1 | ~50% bedre end H.264 | Chrome 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
- Animation performance — Frame rate og jank-fri bevægelse
- Billedoptimering — Formater, størrelser og SEO
- Browser rendering pipeline — Fra HTML til pixels
- CLS-problemer — Årsager til Cumulative Layout Shift og løsninger
- Core Web Vitals — LCP, INP og CLS forklaret
- CSS — Cascading Style Sheets og SEO
- CSS containment — Isolér rendering og accelerér layout
- Font-optimering — Webfonts, FOUT og SEO
- HTTP/2 og HTTP/3 — Protokoller der eliminerer latency-overhead
- INP-optimering — Interaction to Next Paint og Core Web Vitals
- JavaScript bundle-optimering — Code splitting, tree shaking og analyse
- Kritisk renderingsti — Hvad browseren gør før du ser noget
- Latency — Forsinkelse i netværket og hvad du kan gøre ved det
- Lazy loading — Udskyd indlæsning af billeder og ressourcer
- LCP-optimering — Sådan forbedrer du Largest Contentful Paint
- Long Tasks og LoAF — Hvad blokerer main thread
- Navigation og resource timings — Browserens performance-API
- PageSpeed og SEO — Hastighed som rankingfaktor
- Performance budgets — Grænser der forhindrer regressioner
- Performance timings — Hvornår er det for langsomt?
- Resource hints — Preload, prefetch og preconnect til SEO
- Responsive images — srcset, sizes og art direction
- Responsivt design — Mobile-first og SEO
- RUM vs. syntetisk monitoring — To syn på web performance
- Service Workers — Offline caching og PWA performance
- Speculative loading — Prefetch og prerender af næste side
- Startup performance — Hurtig app-start og time to interactive
- Tredjeparts-scripts og performance — Impact og strategier
- Tredjepartsscripts — Analytics, ads og performance-konsekvenser
- TTFB og hosting — Server response time og SEO
- Viewport tag — Meta viewport og mobil-rendering
- Web Workers — Parallel JavaScript uden main thread-blokning
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
- Animation performance — Frame rate og jank-fri bevægelse
- Billedoptimering — Formater, størrelser og SEO
- Browser rendering pipeline — Fra HTML til pixels
- CLS-problemer — Årsager til Cumulative Layout Shift og løsninger
- Core Web Vitals — LCP, INP og CLS forklaret
- CSS — Cascading Style Sheets og SEO
- CSS containment — Isolér rendering og accelerér layout
- Font-optimering — Webfonts, FOUT og SEO
- HTTP/2 og HTTP/3 — Protokoller der eliminerer latency-overhead
- INP-optimering — Interaction to Next Paint og Core Web Vitals
- JavaScript bundle-optimering — Code splitting, tree shaking og analyse
- Kritisk renderingsti — Hvad browseren gør før du ser noget
- Latency — Forsinkelse i netværket og hvad du kan gøre ved det
- Lazy loading — Udskyd indlæsning af billeder og ressourcer
- LCP-optimering — Sådan forbedrer du Largest Contentful Paint
- Long Tasks og LoAF — Hvad blokerer main thread
- Navigation og resource timings — Browserens performance-API
- PageSpeed og SEO — Hastighed som rankingfaktor
- Performance budgets — Grænser der forhindrer regressioner
- Performance timings — Hvornår er det for langsomt?
- Resource hints — Preload, prefetch og preconnect til SEO
- Responsive images — srcset, sizes og art direction
- Responsivt design — Mobile-first og SEO
- RUM vs. syntetisk monitoring — To syn på web performance
- Service Workers — Offline caching og PWA performance
- Speculative loading — Prefetch og prerender af næste side
- Startup performance — Hurtig app-start og time to interactive
- Tredjeparts-scripts og performance — Impact og strategier
- Tredjepartsscripts — Analytics, ads og performance-konsekvenser
- TTFB og hosting — Server response time og SEO
- Viewport tag — Meta viewport og mobil-rendering
- Web Workers — Parallel JavaScript uden main thread-blokning