Videoformater i WordPress: MOV, MP4 eller WebM (Adobe effects & web)

Et vanlig problem for motion designere og videoredigerere som begynner med nettsider: “Jeg laget en flott animasjon i Adobe After Effects, rendret til .mov (i beste kvalitet!), lastet den opp i WordPress, og ingenting skjer. Svart skjerm, en feilmelding, eller filen veier 500 MB og laster i en evighet.”

Filen er ikke ødelagt. Den er laget for et redigeringsprogram, og en nettleser er ikke et redigeringsprogram.

#Hvorfor MOV-filer ikke spilles av i WordPress

Formatet .mov (QuickTime-containeren) er standard i kreativt arbeid, særlig på Mac. .mov er en container, ikke en kodek. Det som gjør den ubrukelig på nettet, er som regel innholdet: ProRes eller ukomprimerte bilderuter.

Størrelsene er ikke en smakssak. Apple publiserer dem. Ved 1920x1080 og 29,97 fps oppgir ProRes-hvitboken måldatarater på 45 Mbps for 422 Proxy, 102 Mbps for 422 LT, 147 Mbps for 422, 220 Mbps for 422 HQ, 330 Mbps for 4444 og 495 Mbps for 4444 XQ. Vedlegget i samme dokument gjengir dem som gigabyte per time: 422 HQ er 99 GB per time, altså rundt 1,65 GB for ett eneste minutt med opptak. En hero-loop på tjue sekunder rett ut av After Effects kan dermed være større enn hele resten av nettstedet.

Deretter går to ting galt i WordPress, i denne rekkefølgen.

Opplastingen blir kanskje aldri ferdig. wp_max_upload_size() leser upload_max_filesize og post_max_size fra PHP og returnerer den minste av de to. På delt webhotell står disse ofte på beskjedne standardverdier, og en POST på flere hundre megabyte dør før mediebiblioteket i det hele tatt ser den.

Blir den ferdig, spilles den likevel ikke av. WordPress godtar filen fordi wp_get_mime_types() inneholder 'mov|qt' => 'video/quicktime'. Men wp_get_video_extensions(), funksjonen som avgjør hva kjernen regner som en avspillbar videokilde, returnerer bare mp4, m4v, webm, ogv og flv. MOV står ikke på den listen. Vedlegget ligger derfor i biblioteket og ser ut som en video, men oppfører seg som en nedlasting.

Det hjelper heller ikke å tvinge inn markupen for hånd. Ifølge MDNs guide til containere støttes QuickTime bare av eldre Safari-versjoner og av andre nettlesere som hadde Apples QuickTime-plugin. Guiden markerer alle kodekene i QuickTime-tabellen som ustøttet i Firefox, og påpeker at QuickTime-rammeverket ikke lenger finnes i det hele tatt fra og med macOS 10.15 Catalina. ProRes er ikke blant kodekene MDNs guide til videokodeker dokumenterer for nettlesere.

#Hvorfor ProRes ikke passer for nettet

ProRes ble laget for profesjonell redigering, der det viktigste er å bevare maksimal kvalitet gjennom flere runder med fargekorrigering og rekomponering. Hver bilderute lagres med lett komprimering innenfor bilderuten, noe som gjør filene enorme, men enkle å spole i og klippe i etterarbeidet.

Nettet har andre prioriteringer. Besøkende forventer at videoen starter i løpet av sekunder. Mobilforbindelser har begrenset båndbredde. Nettlesere trenger kodeker bygget for effektiv dekoding, og MDN sier det samme i kodekguiden sin: ingen tapsfri eller nesten tapsfri kodek er generelt tilgjengelig i nettlesere, fordi ukomprimert 1080p med 4:2:0-subsampling allerede krever minst 1,5 Gbps.

#Gir eksport i maksimal kvalitet bedre video på nettet

Mange designere tar for gitt at bedre kvalitet betyr bedre opplevelse. En masterfil som bruker minutter på å komme fram gir en dårligere opplevelse enn en komprimert kopi som starter med en gang, og som en vanlig seer ikke skiller fra masteren på en laptopskjerm.

#Hvilke videoformater WordPress støtter

To formater dekker hele nettet, og valget mellom dem er mindre dramatisk enn da denne artikkelen først ble skrevet.

#1. MP4 med H.264 (AVC)

Det trygge standardvalget. caniuse oppgir 97,26 prosent global støtte for H.264 i MP4 (data sjekket 12. oktober 2026), helt tilbake til Chrome 4 og Safari 3.2. Leverer du én fil, lever denne.

To innstillinger avgjør om eksporten faktisk fungerer, og begge er usynlige i en forhåndsvisningsspiller.

Chroma-subsampling. ProRes 422 er, som navnet sier, 4:2:2, og 422-familien er 10 bit. Gir du det til libx264 uten instruks, koder den en strøm i High 4:2:2-profilen som nettlesere ikke dekoder. Vi sjekket dette med en testfil i ProRes 422 HQ: uten flagg for pikselformat rapporterte ffprobe resultatet som High 4:2:2 med yuv422p10le. Tving fram 8 bit 4:2:0 med -pix_fmt yuv420p.

Hvor indeksen ligger. FFmpegs dokumentasjon for muxere beskriver -movflags +faststart som et valg som kjører en ekstra runde og flytter indeksen (moov-atomet) til begynnelsen av filen, og påpeker at det ikke er slått på som standard. Uten det kan ikke nettleseren starte avspillingen før hele filen er kommet fram, og det er nettopp symptomet “laster i en evighet”.

Eksporterer du fra Adobe Media Encoder i stedet for kommandolinjen, velg H.264 som format, ikke QuickTime, og sjekk deretter begge innstillingene på resultatet. Det er formatlisten som teller; navnene på forhåndsinnstillingene flytter seg mellom versjoner.

#Anbefalte eksportinnstillinger for H.264

For forutsigbare resultater når du eksporterer for WordPress:

• Oppløsning: 1920x1080 for innholdsvideo, 1280x720 for sekundære klipp.
• Kvalitet: CRF mellom 23 og 28 i libx264, i stedet for å jage en fast bitrate.
• Bildefrekvens: behold kildens frekvens (vanligvis 24, 25 eller 30 fps).
• Lyd: AAC på 128 til 192 kbps stereo, eller ingen lydspor i det hele tatt hvis klippet er dekorativt.
• Pikselformat: yuv420p, verifisert med ffprobe på den eksporterte filen.
• Profil og nivå: lås dem med -profile:v high -level:v 4.0 for 1080p, slik at filen stemmer med codecs-strengen du oppgir i markupen (mer om det nedenfor).

#2. WebM med VP9

Et åpent format utviklet av Google. Ifølge Googles VP9-side kan kodeken redusere videobitraten med så mye som 50 prosent sammenlignet med andre kjente kodeker. Se på det som et tak som nås på krevende innhold, ikke et tall du treffer på hvert klipp, men besparelsen på en flat motion-grafikk er reell.

Det utdaterte rådet om dette temaet er at WebM er et format for Chrome og Firefox. Det har det ikke vært på mange år. caniuse registrerer full WebM-støtte i Safari på macOS fra versjon 16 og i Safari på iOS fra 17.4, og Safari 14.1 til 15.6 spilte det allerede av på macOS 11.3 Big Sur eller nyere. Det gir full støtte på 96,05 prosent globalt, litt over ett prosentpoeng bak H.264 i MP4.

#Nettleserstøtte for AV1-kodeken

AV1 ligger én generasjon lenger fram og komprimerer bedre enn VP9, men utrullingen henger etter. caniuse gir den 80,39 prosent full støtte, som stiger til 95,02 prosent bare hvis du regner med delvis støtte. Safari er det delvise tilfellet: på macOS og iOS dekoder den AV1 bare på enheter med maskinvaredekoder, som iPhone 15 Pro eller en MacBook Pro med M3.

MDNs guide til videokodeker anbefaler nå WebM med AV1 og Opus som førstevalg for et typisk nettsted, og MP4 med AVC og AAC som det bredt kompatible andrevalget. Dermed blir AV1 en første <source>, aldri den eneste. AV1-koding er også mye tregere enn H.264 eller VP9, så det lønner seg på innhold som kodes én gang og spilles av mange ganger.

#HTML5 video-tagg med WebM- og MP4-kilder

Må du hoste selv, for eksempel som hero-bakgrunn, list opp kildene med den beste først. Nettleseren tar den første den kan dekode og ser aldri på resten.

<video autoplay loop muted playsinline preload="none"
       poster="/media/hero-poster.avif"
       width="1920" height="1080">
  <source src="/media/hero.webm" type='video/webm; codecs="vp9, opus"'>
  <source src="/media/hero.mp4" type='video/mp4; codecs="avc1.640028, mp4a.40.2"'>
  Nettleseren din støtter ikke video.
</video>

Attributtene har hver sin konkrete jobb:

• muted pluss playsinline: mobilnettlesere nekter autoplay uten begge. Uten playsinline åpner iOS videoen i fullskjerm i det øyeblikket den starter, og det ødelegger en bakgrunnsloop.
• preload="none": ingenting hentes før avspilling blir bedt om, så posteren står for den første visningen. Bruk metadata hvis du trenger varigheten på forhånd, og auto nesten aldri.
• poster: et stillbilde i AVIF eller WebP er en brøkdel av videoen og er det besøkende faktisk ser de første sekundene.
• codecs=-delen av type-strengen: den lar nettleseren avvise en kilde uten å laste ned en eneste byte av den.
• width og height: sett dem alltid, slik at plassen reserveres før videoen lastes. Det hindrer Cumulative Layout Shift, en av Core Web Vitals.

#Slik skriver du codecs-strengen for MP4 og WebM

Tidligere versjoner av denne artikkelen oppga avc1.42E01E for MP4-kilden. Den strengen angir Baseline-profilen (42) på nivå 3.0, mens FFmpeg-kommandoen lenger ned lager en fil i High-profilen. En codecs-streng som beskriver en annen strøm enn den du leverer, er en feil påstand overfor nettleseren.

MDNs guide til codecs-parameteren definerer AVC-formen som avc1.PPCCLL: to heksadesimale sifre for profilen, to for begrensningsflaggene og to for nivået. High-profilen er 64 med begrensninger 00, og nivå 4.0 er desimalt 40, heksadesimalt 28. High på nivå 4.0 blir altså avc1.640028. AAC-LC-lyd i MP4 er mp4a.40.2. For WebM lister MDN opp kortformene vp9, vp8, opus og vorbis.

Les de faktiske verdiene fra den eksporterte filen i stedet for å gjette:

ffprobe -v error -select_streams v:0 \
  -show_entries stream=profile,level,pix_fmt -of csv=p=0 web.mp4

I testen vår kom en 1080p-koding med -preset slow og uten nivåflagg tilbake som High,50, nivå 5.0, fordi forhåndsinnstillingen slow bruker flere referansebilder enn nivå 4.0 tillater ved den oppløsningen. Med -profile:v high -level:v 4.0 kom den tilbake som High,40, som er det avc1.640028 angir.

#Attributter for videoblokken i blokkredigereren

I blokkredigereren trenger du ikke skrive taggen for hånd. block.json for kjerneblokken Video har autoplay, controls, loop, muted, playsInline, poster, preload, src og tracks som attributter, med preload satt til metadata som standard, og playsInline har sin egen bryter i sidepanelet. Cover-blokken har ikke noe slikt attributt: block.json oppgir ingen playsInline-nøkkel, og lagringsutdataene hardkoder autoPlay, muted, loop og playsInline på bakgrunnsvideoen, så en videoloop i Cover spilles alltid inline, og det finnes ingen bryter å sjekke. Ingen av blokkene skriver en codecs-parameter inn i markupen.

#Slik velger video-shortcoden kilder

Klassisk innhold og mange sidebyggere går fortsatt via shortcoden [video], som kjernen gjengir med wp_video_shortcode(). Kildekoden, i wp-includes/media.php, forklarer flere ting folk rapporterer som feil.

• En MOV blir en lenke. Når src peker på en fil med en filendelse som ikke står i wp_get_video_extensions(), returnerer funksjonen en vanlig lenke <a class="wp-embedded-video"> til filen i stedet for en spiller.
• Rekkefølgen på kildene er fast. Du kan sende inn ett attributt per filendelse (mp4, m4v, webm, ogv, flv), og funksjonen skriver ut <source>-elementene i den rekkefølgen. [video webm="a.webm" mp4="a.mp4"] setter derfor MP4 først, og alle nettlesere som dekoder H.264 velger den.
• Typen har ingen codecs. Hver <source> får en ren MIME-type fra wp_check_filetype(), for eksempel video/mp4.
• Standardverdier. preload er metadata, muted er false, og spilleren er 640x360 med mindre du sender inn width og height; en større bredde skaleres ned til temaets $content_width.
• Spillerbibliotek. Utdataene pakkes som standard inn for MediaElement.js; filteret wp_video_shortcode_library endrer det.

Legger du til mov via filteret wp_video_extensions, gjengir shortcoden en spiller for filen, men det gir ikke Chrome eller Firefox en dekoder, så løsningen er fortsatt å kode om.

#MIME-typer på serveren for MP4 og WebM

En fil kan være perfekt kodet og likevel serveres med feil Content-Type. Sjekk responsheaderen i fanen Nettverk i nettleseren. Standardfilen mime.types i nginx kobler allerede mp4 til video/mp4, webm til video/webm og mov til video/quicktime. På Apache, hvis headeren kommer tilbake som text/plain eller application/octet-stream, legger du til koblingen i .htaccess:

AddType video/mp4 .mp4
AddType video/webm .webm

#Optimalisering av videofilstørrelse

Filstørrelsen betyr noe for brukeropplevelsen og for SEO. En video som bruker for lang tid på å laste øker fluktfrekvensen og trekker ned Core Web Vitals.

Det finnes ingen universell tabell over målstørrelser: det samme sekundet med opptak veier svært ulikt i et statisk bilde og i en kornete panorering. Lås kvaliteten med CRF, mål den ferdige filen og ta avgjørelsen ut fra det tallet.

#Gratis verktøy for komprimering

1. HandBrake: gratis og åpen kildekode. Funksjonslisten nevner AV1, H.265, H.264, MPEG-4, MPEG-2, VP8 og VP9 som videokodere, med MP4, MKV og WebM som containere.
2. FFmpeg: kommandolinjeverktøyet bak de fleste av de andre, og det som brukes i alle eksemplene her.
3. Shutter Encoder: et grafisk grensesnitt over FFmpeg, enklere å komme i gang med.

#Slik komprimerer du video med FFmpeg

# MOV til MP4 for nettet (H.264, High-profil, nivå 4.0)
ffmpeg -i input.mov -c:v libx264 -preset slow -crf 23 \
  -profile:v high -level:v 4.0 -pix_fmt yuv420p \
  -c:a aac -b:a 128k -movflags +faststart output.mp4

# MOV til WebM med VP9 og Opus
ffmpeg -i input.mov -c:v libvpx-vp9 -crf 33 -b:v 0 -row-mt 1 \
  -pix_fmt yuv420p -c:a libopus -b:a 96k output.webm

# 720p-versjon for mobil
ffmpeg -i input.mov -vf scale=1280:720 -c:v libx264 -preset slow -crf 23 \
  -pix_fmt yuv420p -movflags +faststart output-mobile.mp4

Verdien -crf styrer kvaliteten: lavere verdier gir høyere kvalitet og større fil. For nettet er en CRF på 23 til 28 for H.264 eller 30 til 35 for VP9 et fornuftig område å begynne å måle fra.

Verifiser eksporten i stedet for å anta, for en manglende +faststart sier ikke fra:

grep -abo -m2 -e moov -e mdat output.mp4

Det skriver ut byteposisjonen til den første moov og den første mdat. Du vil at posisjonen til moov skal være den minste. På testfilen vår uten flagget kom mdat først ved byte 44, og moov lå på slutten av filen; med flagget lå moov ved byte 36.

#Slik publiserer du video med gjennomsiktighet (alfakanal)

VP9 i WebM bærer en alfakanal hvis du koder til yuva420p. MDNs kodekguide oppgir VP9 i alle gjeldende versjoner av Chrome, Edge, Firefox, Opera og Safari, med merknaden om at Safari ikke støtter alfagjennomsiktighet i den; caniuse har samme merknad for WebM i Safari. Apples vei er HEVC med alfa, som selskapet dokumenterer i HEVC Video with Alpha Interoperability Profile. Trenger en komposisjon fra After Effects en ekte alfakanal på nettet, leverer du to filer og en reserve med ensfarget bakgrunn.

#Egen hosting av video eller YouTube og Vimeo

Egen hosting gir deg én fil med én bitrate, levert via progressiv HTTP-nedlasting. Det finnes ingen adaptiv stige. WordPress lager skalerte versjoner av bilder ved opplasting og gjør ingenting tilsvarende for video, fordi kjernen ikke har noen transkoder. En besøkende på svak mobilforbindelse får 1080p-filen din eller ingenting, og står og venter mens den bufrer.

Regelen handler derfor om hva videoen er, ikke hvor stor den er.

#Når du bør hoste video på egen server

• Bakgrunnsvideo: korte, lydløse animasjoner bak en hero-overskrift.
• Privat video: innhold som ikke skal ligge på en offentlig plattform.
• Krav fra merkevaren: når spilleren skal være helt din egen, uten logoer fra tredjeparter.
• Vekt ved lasting: for svært korte klipp drar en YouTube-innbygging med seg en tredjepartsspiller og informasjonskapslene dens for noe som ligger nærmere et bevegelig bakgrunnsbilde.

#Når du bør bruke YouTube eller Vimeo

• All video med lyd lengre enn rundt 30 sekunder som en besøkende kom for å se: et intervju, en veiledning, en gjennomgang av et kundecase.
• Opplærings- eller markedsføringsinnhold som har nytte av YouTube-søk.
• Video du vil at skal deles i sosiale medier.
• Nettsteder med begrenset båndbredde, der adaptiv strømming betyr noe.

Båndbredde er den andre halvdelen av den avgjørelsen. En loop på 10 MB på en side med femti tusen visninger i måneden er en halv terabyte med utgående trafikk, og på et rimelig webhotell blir det en samtale med leverandøren.

#Slik indekserer Google video du hoster selv

Googles beste praksis for video-SEO legger til en tredje vinkel på formatspørsmålet, og den sammenfaller ikke med nettleservinkelen.

Google kan behandle MOV, nettlesere kan ikke spille den av. Googles liste over støttede videofiltyper inkluderer MOV, MP4, M4V, WebM, OGV med flere. Det gjør en MOV indekserbar i prinsippet og likevel ubrukelig for den besøkende, så det er ikke et argument for å levere en.

Bare en visningsside får hele settet med videofunksjoner. Google definerer en visningsside som en side der hovedformålet er å vise én enkelt video. Et blogginnlegg som anmelder en innebygd video, eller en produktside med en 360-video, er uttrykkelig ikke en visningsside; slike sider kan fortsatt vises som tekstresultater og i Google Bilder med et videomerke. En dekorativ hero-loop blir aldri et videoresultat, og det trenger den heller ikke.

Posteren fungerer også som miniatyrbilde. Bruker du <video>-elementet, leser Google poster-attributtet som foretrukket miniatyrbilde. Støttede formater for miniatyrbilder er BMP, GIF, JPEG, PNG, WebP, SVG og AVIF, på minst 60x30 piksler, på en stabil URL som Googlebot har lov til å hente.

Ikke skjul videoen bak en interaksjon. Google ber om at videoer ikke er avhengige av sveiping, klikking eller skriving for å lastes, og at en video som settes inn med JavaScript vises i den gjengitte HTML-en i verktøyet for URL-inspeksjon. Det har betydning for lazy loading-mønsteret nedenfor: greit for en dekorativ loop, risikabelt for en video du vil ha indeksert.

Strukturerte data. Dokumentasjonen for VideoObject lister opp tre obligatoriske egenskaper: name, thumbnailUrl og uploadDate (ISO 8601, med tidssone). contentUrl bør peke på selve videofilen og er å foretrekke; embedUrl peker på en spiller og er alternativet når filens URL ikke er tilgjengelig. For en MP4 du hoster selv er contentUrl rett og slett filens URL i wp-content/uploads.

#Slik gjør du video responsiv i WordPress

WordPress tilpasser ikke video du hoster selv til skjermstørrelser på egen hånd, så den delen skriver du selv.

#CSS for responsiv video

/* Responsiv container for video */
.video-container {
    position: relative;
    width: 100%;
    padding-bottom: 56.25%; /* forhold 16:9 */
    height: 0;
    overflow: hidden;
}

.video-container video,
.video-container iframe {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
    object-fit: cover;
}

#Ulike oppløsninger for ulike enheter

<video autoplay loop muted playsinline>
  <!-- Mobil: 720p -->
  <source
    src="video-720p.webm"
    type="video/webm"
    media="(max-width: 768px)"
  >
  <!-- Desktop: 1080p -->
  <source src="video-1080p.webm" type="video/webm">
  <source src="video-1080p.mp4" type="video/mp4">
</video>

Attributtet media på en video-<source> er en gammel funksjon med et hull i midten: ifølge kompatibilitetsdataene til MDN respekterte Firefox 53 til 119 det bare inne i <picture>, og støtten for <audio> og <video> kom tilbake i Firefox 120.

#Slik gjør du video tilgjengelig i WordPress

Tilgjengelig video er påkrevd for offentlig sektor i Europa under webtilgjengelighetsdirektivet, og utenfor den gjør det rett og slett innholdet forståelig for flere. De relevante suksesskriteriene i WCAG 2.2 er korte og konkrete:

• 1.2.2 Teksting (forhåndsinnspilt), nivå A: teksting for all forhåndsinnspilt lyd i synkroniserte medier.
• 1.2.5 Synstolking (forhåndsinnspilt), nivå AA: synstolking for forhåndsinnspilt videoinnhold.
• 1.4.2 Styring av lyd, nivå A: lyd som spilles av automatisk i mer enn 3 sekunder trenger en måte å pause eller stoppe den på, eller en volumkontroll uavhengig av systemvolumet.
• 2.2.2 Pause, stopp, skjul, nivå A: innhold i bevegelse som starter automatisk, varer mer enn fem sekunder og vises sammen med annet innhold, trenger en måte å pause, stoppe eller skjule det på.

Det siste kriteriet er det hero-looper bryter. En lydløs bakgrunnsvideo med loop og uten kontroller går i det uendelige, så den trenger en synlig pauseknapp, eller den bør stoppe etter noen sekunder.

#Slik legger du til teksting med track-elementet

Teksting på en video du hoster selv er en WebVTT-fil som det refereres til i et <track>-element. caniuse oppgir støtten for WebVTT til 97,26 prosent, det samme som for selve <video>-elementet.

<video controls>
  <source src="video.mp4" type="video/mp4">
  <track kind="captions" src="captions.vtt" srclang="nb" label="Norsk" default>
  <track kind="descriptions" src="descriptions.vtt" srclang="nb" label="Synstolking">
</video>

En minimal WebVTT-fil ser slik ut:

WEBVTT

00:00:00.000 --> 00:00:04.000
Velkommen til denne videoen.

00:00:04.000 --> 00:00:08.000
[Rolig musikk i bakgrunnen]

Kjerneblokken Video lagrer det samme i attributtet tracks, så teksting du legger til i redigereren ender opp som <track>-elementer i den lagrede markupen.

#Minimumssjekkliste for tilgjengelig video

1. Teksting: for døve og hørselshemmede, som en WebVTT-fil i et <track>-element.
2. Synstolking: for blinde, som beskriver det som bare er synlig.
3. Tastaturkontroll: spilleren må kunne brukes uten mus.
4. Tekstalternativ: posteren eller miniatyrbildet trenger en meningsfull beskrivelse der det bærer informasjon.
5. Ingen autoplay med lyd: video med lyd skal aldri starte av seg selv.

#Slik utsetter du lasting av en video du hoster selv

Håndteringen av loading="lazy" i WordPress-kjernen gjelder bilder og iframes, ikke <video>-elementet, som ikke støtter det attributtet. For en video du hoster selv er det preload="none" sammen med en poster som utsetter nedlastingen. Trenger du mer, last inn kilden fra JavaScript med en IntersectionObserver når elementet kommer inn i visningsområdet, og husk Googles merknad over for alle videoer du vil ha indeksert.

#Slik konverterer du MOV til MP4 for WordPress

1. Rediger og lag masteren i After Effects eller Premiere med .mov og ProRes. Den delen var aldri feil.
2. Eksporter for nettet som H.264 i MP4, og tving fram -pix_fmt yuv420p, -movflags +faststart og en profil og et nivå som du deretter oppgir i codecs.
3. Kontroller eksporten: moov på en lavere byteposisjon enn mdat, og ffprobe som rapporterer yuv420p og High,40, ikke yuv422p10le.
4. Legg til en WebM-kopi med VP9 og list den før MP4-filen i <video>-elementet. Legg AV1 over begge hvis du jakter på de siste hundre kilobytene.
5. Gi elementet et posterbilde og preload="none", og behold muted og playsinline på alle looper med autoplay, pluss en pausekontroll hvis den varer lenger enn fem sekunder.
6. Sett alltid width og height for å unngå forskyvning av layouten.
7. Har klippet lyd og er ment å ses fra start til slutt, legg det heller på YouTube eller Vimeo og bygg det inn.

Er dette en del av et nettsted vi drifter, setter vi opp kodingssteget én gang i deploy-pipelinen, slik at ingen trenger å huske flaggene. Det er en del av våre tjenester innen WordPress-utvikling.