Met tools voor browserontwikkelaars kun je de datasnelheid beperken, bijvoorbeeld om mobiel gebruik na te bootsen. Als je dat eenmaal hebt geprobeerd, zul je meer gemotiveerd zijn om je website op te schonen en te comprimeren.
Afbeeldingen hebben meestal de grootste besparingspotentie – geen enkele andere maatregel werkt zo snel als het optimaliseren daarvan. Het is duidelijk dat een afbeelding niet groter mag zijn dan de maximale breedte van het scherm. Wat de zaak nog ingewikkelder maakt, zijn de Retina-schermen die beelden kunnen schalen naar hogere resoluties. Een iPhone geeft met de standaardschaling elke CSS-pixel bijvoorbeeld weer op 2,2 apparaatpixels. Een 500×300 pixels grote afbeelding zal er goed uitzien in een CSS-container van die grootte, maar het apparaat zou ook 1000 × 600 pixels in die ruimte kunnen weergeven – de afbeelding ziet er dan gewoon scherper uit.
Om met dergelijke gevallen en verschillende beeldformaten om te gaan via een responsive layout, hebben front-end-ontwikkelaars CSS-mediaquery’s en vooral de HTML-attributen srcset en sizes tot hun beschikking. De browser gebruikt die om te bepalen welk afbeeldingsbestand het beste past en downloadt alleen dat bestand, bijvoorbeeld:
<img alt=“afbeelding” srcset=“standard.jpg 1x, retina.jpg 2x”>
Een JPEG-kwaliteitsniveau van meer dan 80 of een verliesvrij gecomprimeerde PNG afbeelding is meestal een verspilling van bandbreedte. Het verwijderen van metadata of een efficiëntere compressie zal ook heel wat kilobytes besparen. Dat kun je doen met gewone beeldbewerkings- en weergavesoftware of met console-gereedschappen zoals jpegtran, jpegoptim en optipng. Die hulpmiddelen kunnen grote hoeveelheden afbeeldingen verwerken en kunnen worden geïntegreerd in de build-pipeline. De volgende instructie verkleint sommige foto’s tot een tiende van hun bestandsgrootte (pas op, overschrijft de bronbestanden!):
jpegoptim -o -m75 –strip-all
–all-progressive *.jpg
Voor JPEG’s wordt progressieve rendering aanbevolen, waarbij het beeld vanaf het begin op ware grootte verschijnt en gedetailleerder wordt naarmate het laadt – dat voelt voor een gebruiker sneller aan. Voor pictogrammen worden tegenwoordig vectorafbeeldingen in de vorm van SVG’s of pictogramlettertypes gebruikt. PNG’s zijn vooral interessant voor transparantie.
Het nieuwe WebP-formaat beslaat slechts ongeveer 80 tot 90 procent van een equivalent JPEG-bestand, maar je hebt eventueel een fall-back nodig voor Internet Explorer. Tot nu toe werkt alleen Chrome met AVIF, dat zijn sterke punten uitspeelt bij hoge compressieverhoudingen en GIF-achtige animaties mogelijk maakt.
Voor video doen veel sites een beroep op externe dienstverleners die bij het streamen de afspeelkwaliteit aanpassen aan de bandbreedte. Maar waar een <video> of <audio> wordt gebruikt die een mediabestand opvraagt, kan een goede compressie megabytes aan data besparen. Tools zoals ffmpeg doen dat werk betrouwbaar. Helaas is er geen equivalent voor srcset voor gestreamde media.
Je moet ook websitecode comprimeren. Codereductietools bestaan voor CSS en HTML, maar dat levert meer op bij JavaScript. Het populairste hulpmiddel daarvoor heet Uglify – de uitvoer ervan is nauwelijks leesbaar voor mensen, maar voor de computer maakt dat niet uit.
Het is moeilijker, maar lonender, om overbodige code er helemaal uit te gooien. JavaScript-bibliotheken laten de code enorm groeien. Daarom moet je je bij elk script van derden afvragen: heb ik dat echt nodig? Moet ik moments.js toevoegen als ik één keer een datum converteer? Is de carrousel-plug-in de moeite waard, heb ik jQuery echt nodig omdat $(…) zo lekker kort is?
Niet te vergeten: de browser is niet klaar na het downloaden, hij moet de code ook verwerken. Terwijl dat bij afbeeldingen een kwestie van milliseconden is, is het harder werken bij JavaScript, dat de hoofdthread vaak secondenlang blokkeert. Op een apparaat met weinig rekenkracht kan het compileren en uitvoeren langer duren dan het downloaden. Tests met echte hardware bij verschillende netwerkkwaliteiten leveren soms verrassende resultaten op, maar zijn tijdrovend.
Bij projecten die in de loop der jaren steeds gegroeid zijn, kom je vaak een verbazingwekkende warboel aan code tegen, zoals verschillende jQuery-versies of polyfills die eigenlijk al jaren niemand meer nodig heeft. Maar test de site grondig en gooi er niet overhaast code uit! Een JavaScript-exception stopt dan bijvoorbeeld verdere uitvoering van de code, en als die niet meer werkt is zelfs de beste optimalisatie nutteloos.
Chrome heeft bij de ontwikkelaarstools het tabblad Coverage (in het menu onder ‘More tools’) dat ongebruikte CSS-selectors en JavaScript-functies rood markeert. Bij de meeste websites het aandeel daarvan ver boven de 50 procent. De Node.js-tool UnCSS geeft de werkelijk gebruikte CSS weer – zelfs overkoepelend voor meerdere pagina’s en schermformaten.
Zoals Chromes Coverage-tool laat zien, zijn veel gekoppelde scripts en stijlen niet noodzakelijk op de huidige webpagina.
Bij het importeren van modules is het vaak mogelijk om dat te beperken tot afzonderlijke componenten. Moderne bundlers zoals webpack en Rollup kunnen overweg met die ‘tree-shaking’ en kopiëren met import {func1} from ‘bigFile.js’ alleen de code die bij func1 hoort naar het project in plaats van het hele scriptbestand.
