26 video’s op een pagina en maar een halve MB groot – hoe doe ik dat?

5
minuten

Een tijdje geleden, toen ik bezig was met het bouwen van een website, postte ik op LinkedIn dat ik een pagina had gebouwd met 26 video’s, en dat die pagina slechts iets groter halve MB zwaar was in totaal. Natuurlijk ging dat goed rond – hoe de heck heb ik dat gedaan? In deze blogpost leg ik het uit.

Het idee: Foto-naar-video

De pagina in kwestie was de pagina “Team” voor de nieuwe website van Sencity.nl. Sencity is een inclusief muziekfestival voor doven en slechthorenden – maar ook als horende is het ontzettend tof! In de dovencommunity heeft iedereen een naamgebaar: Je naam in gebarentaal.

Mijn contactpersoon Tim had een visie op die pagina alle portretjes interactief waren: bij hover/klik/tap (afhankelijk van je apparaat en browser) zou de portretfoto veranderen in video waarin iemand zijn naamgebaar liet zien. Aan de ene kant vind ik dat een ontzettend tof idee. Aan de andere kant ging ik daar moeilijk hard van steigeren: zoveel video’s op een pagina, dat moet wel goed geoptimaliseerd en zo duurzaam mogelijk gebeuren!

Ik had een aantal goede ideeën, alleen helaas zelf niet alle skills voor de technische uitvoering, dus ik heb hier de hulp van mijn webdeveloper-maatje Sven ingeschakeld.

De uiteindelijke pagina

Okee, stiekem is de titel van deze blogpost een beetje clickbaity. Uiteindelijk, bij oplevering, stonden er 21 foto-naar-naamgebaar portretten op de pagina en 6 portretten zonder naamgebaar. (Er waren 26 naamgebaar-video’s aangeleverd, maar 4 hoefden niet op deze website, vandaar.) Ook is er een vacaturefeed op de pagina gekomen, en een formulier. Uiteindelijk woog deze pagina toen hij af was 816,10 kB (0,27 g CO2, label B) volgens de Digihobbit Ecotool, bij oplevering1.

Preload=none

Bij bovengenoemd paginagewicht gaat het om de assets die geladen worden bij het eerste paginabezoek, zonder verdere gebruikersinteractie. Wat betekent dat? Dat assets met lazy loading of preload-none instellingen niet geladen worden, en dat eventueel dataverkeer van interactie (het bekijken van een video, het invullen en versturen van een formulier) hier niet wordt meegenomen. In dit geval betekent het dat de video’s niet geladen worden zolang ze niet actief bekeken worden (omdat we preload=none hebben ingesteld). Ofwel: Er worden niet onnodig allemaal videobestanden van de server opgehaald wanneer een bezoeker de naamgebaar video’s niet kijkt.

Video-optimalisatie

Daarnaast hebben we natuurlijk de video’s zelf óók geoptimaliseerd:

  • Korte video’s
    We hebben de video’s zo kort mogelijk gehouden. Alléén het naamgebaar, en een halve seconde “padding” aan het begin en eind.
  • De juiste grootte
    Deze video’s hoeven niet schermvullend afgespeeld te worden. Ze spelen af in hetzelfde kader als de porttretfoto zelf. Hierdoor konden we de video’s flink verkleinen. Ze staan namelijk met 4 op een rij in een kader van maximaal 1200 pixels breed. Op mobiel staan ze met 2 naast elkaar. Omdat je wel een beetje speling wilt2, hebben we de video’s van tevoren geschaald van 2048×2048 pixels (aangeleverd) naar 400×400 pixels. Dat scheelt enorm in bestandsgrootte!
  • Moderne codec
    Afhankelijk van de codec die je gebruikt, kan dat invloed hebben op de kwaliteit van je video als je hem schaalt. De video’s waren in verschillende formaten aangeleverd, onder andere ook in 400×400 pixels. Maar die waren behoorlijk wazig. Zonde! Dus hebben we de grotere video’s gepakt en opnieuw geresized met de H264-codec met het programma ffmpeg. Die waren wel mooi scherp.
  • Zonder audio
    Deze video’s hebben geen audio nodig, dus we hebben ze zonder audiospoor geëxporteerd. Scheelt ook weer!

Wat als we niet geoptimaliseerd hadden voor duurzaamheid?

Voor de gein: Wat nou als we geen preload-none hadden toegevoegd aan al die video’s? Alle 21 video’s bij elkaar wegen samen 1831 kB, ofwel 1,8 MB. Dat zou je dan bij ieder bezoek van deze pagina van de server trekken, ook als je de video’s niet zou bekijken.

Was er nog verschil tussen de 400×400 video’s die we zelf hadden geschaald, en de 400×400 video die we aangeleverd hadden gekregen? Jazeker. Dan zouden de video’s samen 44,3 MB hebben gewogen. De aangeleverde video’s hadden AAC en H264 codecs: Wel dezelfde video codec die wij gebruiken, maar er was dus ook een audiospoor mee geëxporteerd, ook al was er geen geluid. Zo zie je maar weer dat 1) wel of niet audio mee exporteren heel veel verschil maakt, en 2) dat het algoritme van de software die je gebruikt om te schalen óók veel verschil kan maken in kwaliteit.

En wat nou als we de video’s niet hadden geschaald? Als we de video’s allemaal 2048×2048 pixels groot hadden gelaten, dan zou dat samen 147,8 MB zijn. Stel je voor dat je op je data-abonnement even deze pagina bekijkt. Dan ben je snel door je MB heen!

Ofwel: Duurzaamheid als integraal onderdeel van webdesign maakt écht verschil.

See you next time, class 😉

Voetnoten

  1. Het kan zijn dat de pagina in de tussentijd is aangepast. Ik geef mijn klanten altijd zelf beheer over hun websitecontent, tenzij ze er expliciet van afzien. ↩︎
  2. Een beeld van exact naar 300px in een ruimte van 300px is minder scherp dan een beeld van iets groter dan 300px geschaald naar een ruimte van 300px. ↩︎

Op de hoogte blijven van mijn duurzame webtips en filosofische hersenspinsels?
Schrijf je in voor mijn nieuwsbrief 👇🏻

Scroll naar boven