Video-bakgrunner, autoplay og Core Web Vitals i WordPress

En stemningsfull videobakgrunn i toppen av nettsiden (hero section) kan gi et sterkt førsteinntrykk og løfte merkevaren umiddelbart. Samtidig er få designelementer mer beryktet blant utviklere for å ødelegge ytelsesmålinger: Tunge videofiler som blokkerer nettverket, høyt minneforbruk på mobile enheter og feilslåtte Core Web Vitals-skår i Google PageSpeed Insights.

I 2026 krever et profesjonelt nettsted at estetikk og ekstrem ytelse forenes. Moderne nettlesere stiller strenge krav til ressursforbruk og brukeropplevelse, og søkemotoralgoritmene straffer nettsteder som forsinker Largest Contentful Paint (LCP) eller forårsaker hakking i grensesnittet.

I denne veiledningen går vi gjennom den komplette tekniske arkitekturen for videobakgrunner: Fra kodekomprimering med FFmpeg og optimalisering av LCP med plakatbilder, til batteribesparende JavaScript med Intersection Observer og tilgjengelighetskrav (WCAG).

Ønsker du en helhetlig gjennomgang av hastigheten på din installasjon, kan du lese mer om vår WordPress-hastighetsoptimalisering.

#Hvordan videobakgrunner påvirker Core Web Vitals

For å optimalisere en video må man forstå hvordan nettleseren prioriterer ressurser under sideinnlasting:

• Largest Contentful Paint (LCP): Hvis en video deklareres direkte som LCP-elementet i HTML-koden, må nettleseren laste ned de første videosegmentene før målingen avsluttes. På et tregt mobilnettverk kan dette ta fire til seks sekunder, noe som resulterer i en rød LCP-skår.
• First Contentful Paint (FCP): Hvis du benytter en tredjeparts iframe (for eksempel fra YouTube eller Vimeo), må nettleseren etablere nye DNS-oppslag, fullføre TLS-håndtrykk og laste inn store mengder JavaScript før noe som helst vises på skjermen.
• Interaction to Next Paint (INP): Dekoding av tunge videostrømmer i nettleserens hovedtråd kan føre til at knapper og menyer reagerer tregt på brukerklikk fordi prosessoren er overbelastet.

#Plakatbilde som LCP-element for bakgrunnsvideo

Nøkkelen til en lynrask hero-video er å la et stillbilde ta LCP-støyten. Ved å definere et lett, men knivskarpt plakatbilde (poster) i moderne formater, kan nettleseren tegne ferdig hero-seksjonen før videoen i det hele tatt er lastet ned:

<div class="hero-videobeholder">
    <img src="/images/hero-plakat.avif"
         alt=""
         fetchpriority="high"
         decoding="async"
         class="hero-plakatbilde" />

    <video class="hero-video"
           autoplay
           muted
           loop
           playsinline
           preload="none">
        <source src="/video/hero.av1.mp4" type="video/mp4; codecs=av01.0.05M.08">
        <source src="/video/hero.webm" type="video/webm; codecs=vp9">
        <source src="/video/hero.mp4" type="video/mp4">
    </video>
</div>

Ved å sette preload="none" forhindrer vi at videoen stjeler båndbredde fra kritiske CSS-filer og skrifttyper. Selve videostrømmen startes deretter i bakgrunnen via et lettvekts skript så snart siden er interaktiv.

Står det en src som kan hentes på <video> allerede i den første HTML-koden, kan nettleseren laste ned byte og dekode bilder mens LCP-vinduet pågår. Det konkurrerer med skrifttyper, CSS og plakatbildet. Tryggere rekkefølge:

1. Et komprimert plakatbilde (AVIF eller WebP med JPEG som reserve) i riktig størrelse for hero-oppsettet.
2. preload="none", slik at videofilen ikke hentes tidlig.
3. Sett src eller legg til <source> først etter load, etter en synlighetssjekk og etter en sjekk av redusert bevegelse.

Plakatbildet kan selv bli LCP-elementet. Det er greit så lenge det er raskt: riktige dimensjoner, moderne format, hurtigbufferhoder fra CDN og ingen layoutforskyvning når videolaget dukker opp. Ikke bytt ut et lite miniatyrbilde med et bilde i full bredde etter innlasting; det mønsteret gir Cumulative Layout Shift (CLS) og en sen LCP-kandidat. Er det første viste bildet i videoen større eller skarpere enn plakatbildet, kan LCP flytte seg til videoen. Hold derfor plakatbildet visuelt nær bilde null, så overgangen føles sømløs og målingen holder seg stabil.

#Hvilket bilde i videoen som teller for LCP

LCP-definisjonen på web.dev regner <video> blant elementene som kan bli Largest Contentful Paint, og oppgir hvilket tidspunkt som brukes: lastetiden for plakatbildet eller visningstiden for første bilde, det som kommer først. Et raskt plakatbilde er derfor spaken du styrer: det setter LCP-tiden selv om videoen kommer senere. Uten plakatbilde venter målingen på det første dekodede bildet, og det avhenger av videonedlastingen.

Målet er det samme for hero-seksjoner med video: LCP på 2,5 sekunder eller mindre, målt ved 75. persentil av sidevisningene og delt opp på mobil og datamaskin. En hero som består på kontorets Wi-Fi, men stryker ved 75. persentil på mobil, stryker.

#Video preload none, metadata eller auto

Attributtet preload på <video> antyder hvor mye nettleseren skal hente før avspilling:

• none: ingen forhåndslasting. Det beste utgangspunktet for bakgrunnsvideo i hero-seksjoner.
• metadata: henter varighet og dimensjoner. Nyttig når oppsettet trenger størrelsen uten full nedlasting.
• auto: nettleseren bestemmer selv, ofte for aggressivt for en dekorativ loop.

For dekorative bakgrunner starter du med preload="none" og en tom eller utsatt src. Koble på adressen etter load-hendelsen på window (eller når Intersection Observer melder at elementet er synlig), slik at tekst og CTA tegnes først.

Unngå preload="auto" på hero-loops. Det inviterer til tidlig båndbreddebruk på sider der bevegelsen er sekundær. Er videoen selve produktet (en kurstrailer eller en demovideo brukeren kom for å se), kan en annen strategi forsvares, men da er det ikke lenger en bakgrunn.

<video class="hero-video" muted loop playsinline preload="none"
       poster="/images/hero-plakat.avif" data-src="/video/hero.webm"></video>
<script>
  const video = document.querySelector('.hero-video');
  const allowMotion = !matchMedia('(prefers-reduced-motion: reduce)').matches;
  if (video && allowMotion && matchMedia('(min-width: 768px)').matches) {
    addEventListener('load', () => {
      video.src = video.dataset.src;
      video.play().catch(() => {});
    }, { once: true });
  }
</script>

#Komprimere bakgrunnsvideo med FFmpeg

En vanlig tabbe blant innholdsprodusenter er å laste opp 50 MB store ProRes- eller H.264-filer direkte fra videoredigeringsprogrammet. En effektiv bakgrunnsvideo bør aldri overstige 1,5 til 2,5 MB i total filstørrelse for et klipp på 6 til 10 sekunder.

#Fjerne lydsporet fra bakgrunnsvideo

Siden bakgrunnsvideoer uansett må være dempet for å kunne spilles av automatisk, er lydsporet fullstendig overflødig. Å fjerne lydstrømmen kutter filstørrelsen med det lydsporet veier, og gjør filen spillbar automatisk på iOS uansett hva et skript gjør med muted:

# Fjern lydspor med parameteren -an
ffmpeg -i radata.mp4 -an -c:v copy hero-uten-lyd.mp4

#AV1, WebM eller H.264 for bakgrunnsvideo

For maksimal komprimeringseffektivitet bør du tilby tre formater i prioritert rekkefølge:

1. AV1 (AOMedia Video 1): Den mest moderne åpne videokodeken. Gir mindre filer enn H.264 ved samme opplevde bildekvalitet. Støttes i dag av Chrome, Firefox og Safari på nyere Apple-maskinvare.
2. WebM (VP9): Utmerket balanse mellom komprimering og prosessorbruk, bredt støttet i alle moderne nettlesere.
3. MP4 (H.264): Den universelle reserveløsningen for eldre nettlesere og enheter.

Her er de konkrete FFmpeg-kommandoene for produksjonsklar konvertering:

# 1. AV1-koding med SVT-AV1 (høy komprimering, ingen lyd)
ffmpeg -i hero-uten-lyd.mp4 -c:v libsvtav1 -crf 34 -preset 6 -pix_fmt yuv420p hero.av1.mp4

# 2. WebM / VP9-koding
ffmpeg -i hero-uten-lyd.mp4 -c:v libvpx-vp9 -crf 32 -b:v 0 -pix_fmt yuv420p hero.webm

# 3. Universell H.264 MP4 med faststart for rask streaming
ffmpeg -i hero-uten-lyd.mp4 -c:v libx264 -crf 24 -preset slow -movflags +faststart hero.mp4

Flagget -movflags +faststart flytter metadata (moov atom) til starten av MP4-filen, slik at nettleseren kan starte avspillingen umiddelbart uten å måtte laste ned hele filen først.

#Hvorfor autoplay ikke fungerer på mobil

Nettleserprodusenter (særlig Apple og Google) har innført strenge retningslinjer for å hindre uønsket støy og unødvendig databruk for sluttbrukere:

• Muted er obligatorisk: Hvis et videoelement ikke har attributtet muted, vil nettleseren kategorisk nekte automatisk avspilling med mindre brukeren eksplisitt har klikket på siden.
• Playsinline for iOS: På iPhone vil en video uten playsinline automatisk forsøke å starte i Apples native mediespiller, noe som ødelegger hele sideoppsettet.
• Data Saver og lavstrømsmodus: Hvis en bruker har aktivert batterisparingsmodus eller “Datasparemodus” i operativsystemet, kan nettleseren overstyre koden og stanse videoen. Nettsiden må håndtere dette grasiøst ved å vise plakatbildet som fallback.

// Sikker start av video med feilhåndtering
const heroVideo = document.querySelector('.hero-video');

if (heroVideo) {
    const playPromise = heroVideo.play();
    if (playPromise !== undefined) {
        playPromise.catch((error) => {
            // Autoplay ble blokkert av nettleseren (f.eks. strømsparingsmodus)
            // Vis plakatbilde og skjul videokontroller
            heroVideo.classList.add('is-paused');
        });
    }
}

#Autoplay-reglene i Chrome og Media Engagement Index

Chromes regler er publisert på Chrome for Developers-siden om autoplay. Retningslinjene kom i Chrome 66 for lyd- og videoelementer, og den første regelen avgjør spørsmålet om bakgrunnsvideo: dempet autoplay er alltid tillatt. Autoplay med lyd er bare tillatt når ett av disse vilkårene er oppfylt:

• brukeren har samhandlet med domenet (klikk, trykk og lignende),
• på datamaskin har brukeren passert terskelen for Media Engagement Index,
• på mobil har brukeren lagt nettstedet til på startskjermen, eller på datamaskin installert det som PWA.

Media Engagement Index (MEI) måler hvor tilbøyelig en person er til å spille av medier på et bestemt nettsted. En avspilling teller bare når den varer mer enn sju sekunder, har lyd som ikke er dempet, fanen er aktiv og videoen er større enn 200x140 px. En stille loop i hero-seksjonen bygger derfor aldri MEI, og den trenger det heller ikke. Dine egne verdier ser du på about://media-engagement.

Iframes følger samme logikk. En iframe fra samme opprinnelse kan spille av automatisk som standard, mens en iframe fra en annen opprinnelse (en YouTube- eller Vimeo-spiller) må få tillatelsen delegert med allow="autoplay". Uten den avvises play() med NotAllowedError, og autoplay-attributtet ignoreres.

#Sjekk om autoplay er tillatt før du kaller play

HTMLMediaElement.play() returnerer et Promise. MDNs autoplay-veiledning viser mønsteret: avvises Promiset og feilnavnet er NotAllowedError, har nettleseren nektet avspilling av tillatelsesgrunner, så vis en avspillingsknapp eller behold plakatbildet. Alle andre feil peker på et problem med lasting eller dekoding som bør logges.

const video = document.querySelector('.hero-video');
video.play().catch((error) => {
  if (error.name === 'NotAllowedError') {
    video.closest('.hero')?.classList.add('is-static'); // behold plakatbildet
  }
});

Det finnes også navigator.getAutoplayPolicy('mediaelement'), som svarer "allowed", "allowed-muted" eller "disallowed" før du prøver noe. Ifølge MDNs data om nettleserkompatibilitet finnes den bare i Firefox (fra versjon 112), så bruk den som en valgfri snarvei bak en funksjonssjekk, aldri som eneste vei.

På serversiden styrer headeren Permissions-Policy hvilke opprinnelser som får spille av automatisk. Standardverdien er self. Permissions-Policy: autoplay=() slår av autoplay for hele dokumentet, en grov, men effektiv bryter på sider der bevegelse aldri skal starte av seg selv.

#Hva Safari på iOS gjør med en autoplay-video

WebKit beskrev iOS-reglene i New video policies for iOS (juli 2016, iOS 10), og de forklarer fortsatt de fleste tilfeller av typen “fungerer på datamaskinen, står stille på iPhone”:

• <video muted> kan spille av uten brukerhandling, og det samme kan en video der filen ikke har noe lydspor i det hele tatt.
• <video playsinline> spilles av inne på siden på iPhone i stedet for å bytte til fullskjerm.
• En video med autoplay settes på pause når den ikke lenger er synlig, for eksempel når den rulles ut av visningsfeltet.
• Får en video et lydspor eller blir den udempet uten brukerhandling, settes avspillingen på pause.

To praktiske følger: Fjern lydsporet ved koding (-an i FFmpeg), fordi en fil uten lyd fortsatt kan spilles av automatisk selv om et skript senere endrer muted. Og husk at Intersection Observer-mønsteret i neste seksjon er avgjørende i Chrome og Firefox, mens iOS allerede setter videoen på pause utenfor skjermen.

#Pause bakgrunnsvideo med Intersection Observer

Når en besøkende scroller nedover en lang artikkel eller produktside, fortsetter ofte videobakgrunnen i toppen å spinne og dekode i bakgrunnen. Dette tapper batteriet på mobile enheter og trekker unødvendig prosessorkraft som ellers kunne vært brukt til smidig scrolling.

Med IntersectionObserver kan vi pause avspillingen i samme sekund som videoen forsvinner ut av syne:

document.addEventListener('DOMContentLoaded', () => {
    const video = document.querySelector('.hero-video');
    if (!video) return;

    // Respekter preferanser for redusert bevegelse
    const prefersReducedMotion = window.matchMedia('(prefers-reduced-motion: reduce)').matches;
    if (prefersReducedMotion) {
        video.pause();
        return;
    }

    const observer = new IntersectionObserver((entries) => {
        entries.forEach((entry) => {
            if (entry.isIntersecting) {
                // Videoen er synlig i vinduet: Fortsett avspilling
                video.play().catch(() => {});
            } else {
                // Videoen har forlatt skjermen: Sett på pause for å spare ressurser
                video.pause();
            }
        });
    }, {
        threshold: 0.15 // Trigges når minst 15 % er synlig
    });

    observer.observe(video);
});

#Universell utforming av videobakgrunner etter WCAG

En profesjonell implementering må ivareta brukere med nedsatt funksjonsevne eller kognitive utfordringer:

• Stoppknapp for bevegelse: Ifølge WCAG 2.2-krav (suksesskriterium 2.2.2 Pause, Stop, Hide) må enhver automatisk bevegelse som varer lenger enn 5 sekunder kunne pauses av brukeren. En diskret pause/play-knapp i hjørnet av videoen er god praksis.
• Respekter prefers-reduced-motion: Mange brukere med vestibulære lidelser eller migrene konfigurerer operativsystemet til å minimere bevegelser. Gjennom CSS og JavaScript kan vi erstatte videoen med et statisk bilde for disse brukerne:

@media (prefers-reduced-motion: reduce) {
    .hero-video {
        display: none !important;
    }
    .hero-plakatbilde {
        display: block !important;
        opacity: 1 !important;
    }
}

#Hva WCAG 2.2.2 krever av en pauseknapp

Suksesskriterium 2.2.2 er på nivå A og gjelder all informasjon i bevegelse som (1) starter automatisk, (2) varer mer enn fem sekunder og (3) vises parallelt med annet innhold. Da må brukeren ha en mekanisme for å pause, stoppe eller skjule den, med mindre bevegelsen er nødvendig. Understanding 2.2.2-siden forklarer at fem sekunder ble valgt fordi det er lenge nok til å fange brukerens oppmerksomhet, men kort nok til at brukeren kan vente ut forstyrrelsen.

En loop i hero-seksjonen oppfyller alle tre vilkårene, og prefers-reduced-motion erstatter ikke knappen, fordi mange som forstyrres av bevegelse aldri endrer den systeminnstillingen. Knappen bør:

• være en ekte <button> som kan nås med tastatur, plassert ved videoen og synlig både over plakatbildet og over de bevegelige bildene,
• ha et tilgjengelig navn som beskriver handlingen (“Pause bakgrunnsvideo”), oppdatert når tilstanden endres,
• holde pausetilstanden minst gjennom den aktuelle sidevisningen, slik at Intersection Observer-koden over ikke starter loopen igjen ved neste rulling.

Lyd er et eget kriterium. Spiller et klipp noen gang lyd automatisk, viser WCAG til 1.4.2 Audio Control, enda en grunn til å holde bakgrunnsloops stille.

#Bakgrunnsvideo i WordPress sitt mediebibliotek

WordPress lagrer opplastinger under wp-content/uploads og leverer det du laster opp, uten videre behandling. Det gir noen feller som går igjen for bakgrunnsvideo:

Originalfiler fra kamera i full oppløsning. Redaktører laster opp en MP4 på 50 til 200 MB fra telefon eller kamera. Mediebiblioteket godtar den, og temaet legger adressen inn i en hero. Mobilbesøkende betaler for en fil i kinokvalitet som brukes som en loop på seks sekunder.

Ingen ny koding. I motsetning til bilder lager ikke WordPress egne “videostørrelser”. Det finnes ingen automatisk WebM-variant, ingen AV1-versjon og ingen bitratestige med mindre du legger til en utvidelse eller et eksternt kodingssteg (FFmpeg, Mux, Cloudinary, Bunny Stream).

Temabyggere og sidebyggere. Blokkmønstre og sidebyggere setter ofte inn YouTube- eller Vimeo-iframes med full spillergrensesnitt. Det laster tredjeparts JavaScript ved hver visning. For en ekte bakgrunn bør du hoste et kort klipp selv eller bruke en fasade som først monterer iframen ved klikk.

CDN og MIME-oppsett. Noen leverandører serverer video uten lange hurtigbufferhoder eller med feil Content-Type. Sjekk at svarene har video/mp4 eller video/webm og fornuftig levetid i hurtigbufferen. Feil MIME-type gir stille avspillingsfeil, mens plakatbildet blir stående for alltid.

Vaner fra responsive bilder brukt feil. srcset virker ikke på <video> slik det gjør på <img>. Trenger du flere oppløsninger, leverer du separate filer og velger med medieforespørsler eller JavaScript (min-width, connection.saveData, navigator.connection.effectiveType). WordPress-kjernen velger ingen “medium” videostørrelse for deg.

Praktisk arbeidsflyt i WordPress:

1. Kod filen lokalt: kort varighet, uten lydspor, begrenset oppløsning (ofte 1280 px bredde for en hero), moderne kodeker med H.264 som reserve.
2. Last opp de komprimerte versjonene, ikke kameraoriginalen.
3. Lagre plakatbildet som et vanlig bildevedlegg og optimaliser det som enhver annen LCP-kandidat.
4. Hold råfilen utenfor temaets repo og utenfor opplastingene i produksjon.

#Slå av bakgrunnsvideo på mobil og ved Save-Data

En dempet loop koster fortsatt megabyte. På mobilnett er den kostnaden ekte penger og ekte ventetid. Planlegg for dette:

• Ingen video på små skjermer som standard. Mange team viser bare plakatbildet under 768px og setter src kun på bredere skjermer.
• navigator.connection.saveData. Når Save-Data er slått på, hopper du over nedlastingen.
• effectiveType. På 2g og slow-2g beholder du plakatbildet. 3g er en vurderingssak; velg plakatbildet med mindre klippet er svært lite.
• Avspilling startet av brukeren. Er bevegelsen viktig på mobil, gir du en kontroll i stedet for autoplay.

Mål datamengden i fanen Network i DevTools med strupingsprofiler, og sammenlign bare plakatbilde mot plakatbilde pluss video. Er videofilen større enn noen få megabyte for en dekorativ loop, koder du den på nytt eller kutter lengden før du diskuterer CDN-noder.

Tredjeparts innbygginger forsterker problemet: spillerkode, sporingskall og adaptive strømmer du ikke styrer. Fasader i stil med lite-youtube-embed holder startkostnaden nær et miniatyrbilde til den besøkende selv velger å spille av.

#Egen hosting via CDN vs. YouTube/Vimeo

Mange utviklere velger av gammel vane å bygge inn en bakgrunnsvideo via en skjult YouTube- eller Vimeo-iframe med parameteren ?background=1. For en kritisk hero-seksjon er dette en suboptimal løsning.

Tallene for YouTube og Vimeo i tabellen er våre egne målinger fra 22. september 2026: en side med bare én iframe i bakgrunnsmodus, lastet i Brave med tom hurtigbuffer, seks ganger for hver av dem. JavaScript er målt som overførte byte; utpakket er spillerkoden 1,2 MB hos Vimeo og 3,5 MB hos YouTube. Vimeo startet ikke avspillingen i den automatiserte nettleseren, så startforsinkelsen gjelder bare YouTube.

Ved å lagre videofilene på en skylagringsløsning knyttet til et CDN med støtte for HTTP Byte Range Requests (slik at nettleseren kan hente nøyaktig de byte-pakkene den trenger), oppnår du lynrask levering med full kontroll over ytelsen.

#Sjekk AV1-dekoding med Media Capabilities

At AV1 står først blant <source>-elementene forteller bare om nettleseren kan spille av kodeken, ikke om enheten dekoder den i maskinvare. Programvaredekoding av AV1 på en eldre telefon kan hakke og tappe batteriet, altså det motsatte av hva en dekorativ loop skal gjøre.

Media Capabilities API svarer på det spørsmålet. navigator.mediaCapabilities.decodingInfo() gir tre boolske verdier: supported (innholdet kan dekodes), smooth (spilles av med angitt bildefrekvens uten tapte bilder) og powerEfficient. For type: "file" krever konfigurasjonen contentType, width, height, bitrate og framerate; mangler en verdi, kastes en TypeError. MDNs kompatibilitetsdata oppgir Chrome 66, Firefox 63 og Safari 13.

const av1 = {
  type: 'file',
  video: {
    contentType: 'video/mp4; codecs="av01.0.05M.08"',
    width: 1280,
    height: 720,
    bitrate: 1500000,
    framerate: 30,
  },
};

const pickSource = async () => {
  if (!('mediaCapabilities' in navigator)) return '/video/hero.mp4';
  const r = await navigator.mediaCapabilities.decodingInfo(av1);
  return r.supported && r.smooth && r.powerEfficient
    ? '/video/hero.av1.mp4'
    : '/video/hero.mp4';
};

Bruk de samme dimensjonene og den samme bitraten som filen faktisk er kodet med, ellers beskriver svaret en annen fil.

#Dempet video i stedet for animert GIF

Er “bakgrunnen” egentlig en kort animasjon, er GIF den tyngste måten å levere den på. web.dev-veiledningen om å erstatte GIF med video gjør en GIF på 3,7 MB om til en MP4 på 551 KB og en WebM på 341 KB med disse kommandoene:

ffmpeg -i my-animation.gif -b:v 0 -crf 25 -f mp4 -vcodec libx264 -pix_fmt yuv420p my-animation.mp4
ffmpeg -i my-animation.gif -c vp9 -b:v 0 -crf 41 my-animation.webm

Erstatningselementet bruker de samme attributtene som en bakgrunnsloop: <video autoplay loop muted playsinline>. Resten av denne veiledningen (plakatbilde, utsatt lasting, pauseknapp) gjelder uendret.

#Når du ikke bør bruke bakgrunnsvideo på en nettside

Dropp loopen når ett av disse punktene stemmer:

• Budskapet i hero-seksjonen er teksttungt, og LCP sliter allerede med skrifttyper eller et stort stillbilde.
• Klippet tilfører ingen informasjon etter de første to sekundene (generiske kontoropptak, abstrakte partikler).
• Juridiske krav eller merkevareregler krever teksting av det samme innholdet. Teksting på en dempet loop blir klønete; bruk heller en egen videoblokk.
• Publikum er i stor grad på mobilnett med datakvote (mange lokale markeder, reisesammenhenger).
• Teamet kan ikke vedlikeholde en kodingsprosess. En uoptimalisert opplasting i mediebiblioteket gir tilbakefall ved hvert redesign.
• Brukere som ber om redusert bevegelse, utgjør en merkbar andel av målgruppen (helse, vestibulær sensitivitet, tette dashbord).
• Du trenger pålitelig autoplay med lyd. Nettleserne blokkerer det; bruk en tydelig avspillingsknapp.

Et sterkt stillbilde, godt komprimert og i riktig størrelse, slår ofte en lat video som aldri starter. Bevegelse er et verktøy, ikke et krav til en moderne hero.

#Sjekkliste for implementering av bakgrunnsvideo

1. Avgjør om bevegelsen er nødvendig eller dekorativ. Er den dekorativ, planlegger du for plakatbildet først.
2. Kod korte, dempede klipp i WebM og MP4 (eller AV1 og H.264), og hold filene små nok til sekundær innlasting.
3. Optimaliser plakatbildet som en LCP-kandidat: moderne format, riktige dimensjoner, stabilt oppsett.
4. Bruk muted, playsinline, loop og utsatt src med preload="none".
5. Styr avspillingen etter prefers-reduced-motion, skjermbredde og Save-Data der det finnes.
6. Unngå tidlige YouTube- eller Vimeo-iframes til pynt; host selv eller bruk en fasade.
7. Last aldri opp kameraoriginaler til hero-seksjoner i WordPress; kod dem på nytt først.
8. Kontroller hvilket element som er LCP i DevTools Performance eller Lighthouse før og etter publisering.
9. Bekreft at mislykket autoplay faller tilbake til plakatbildet uten støy i konsollen eller hopp i oppsettet.

#Hvordan måle effekten av bakgrunnsvideo på LCP

Suksess kan observeres; den lar seg ikke annonsere som en universell prosentsats:

• LCP-elementet forblir plakatbildet eller en stabil tekstblokk, ikke et sent dekodet videobilde.
• Ingen stor, uventet nedlastingsrekke for .mp4 eller .webm under mobilstruping når bevegelse er slått av.
• Feil fra play() etterlater en brukbar hero.
• Ved redusert bevegelse og Save-Data hentes videoadressen aldri.
• CLS holder seg flat når videolaget dukker opp (en opasitetsovergang over et plakatbilde i nøyaktig samme størrelse hjelper).

Bruk laboratorieverktøy for å fange tilbakefall og feltdata (CrUX, RUM) for ekte enheter. Sammenlign den samme adressen med video slått på og med bare plakatbilde bak et funksjonsflagg når du trenger en ren A/B-sammenligning av målingene.