Optimaliseer de Core Web Vitals voor low-end apparaten

Optimaliseer de Core Web Vitals voor low-end apparaten

Core Web Vitals zouden onderdeel moeten zijn van een objectieve benchmark voor websitekwaliteit. In de praktijk is dat niet zo! De statistieken zijn nauw verbonden met de apparaten die gebruikers meebrengen. Als een bedrijf high-end producten of diensten verkoopt, hebben de klanten vaak snelle telefoons, desktops en betrouwbare verbindingen.
Vergelijk dat met bedrijven die zich richten op prijsbewuste kopers of opkomende markten. Hun doelgroepen leunen op verouderde telefoons, zwakke processors of slechte netwerkomstandigheden.
Dezelfde website die fluitend door een test op een vlaggenschip iPhone komt, heeft moeite om acceptabel te laden op een mid-range Android of in landen met een lage bandbreedteverbinding.

Laatst beoordeeld door Arjen Karel in maart 2026

De cijfers vertellen het verhaal

Volgens de 2025 Web Almanac slaagt slechts 48% van de mobiele origins voor Core Web Vitals, tegenover 56% op desktop. Het grootste verschil zit in INP: 97% van de desktop origins slaagt, vergeleken met slechts 77% op mobiel. Dat verschil van 20 procentpunt wordt vrijwel volledig veroorzaakt door tragere CPU's op Android-apparaten.

De mediane mobiele Total Blocking Time is 1.916 milliseconden. Desktop? 92 milliseconden. Dat is een verhouding van 20:1. Als je scripts goed draaien op je MacBook, draaien ze absoluut niet goed op een budgettelefoon.

Volgens onderzoek van Alex Russell is ongeveer 30% van de actieve apparaten low-end (4 cores of minder, 4GB RAM of minder). Deze apparaten hebben single-core prestaties die tot 9x trager zijn dan een huidige iPhone. In de RUM-data van CoreDash zien we dat sites die geoptimaliseerd zijn voor low-end apparaten slagen voor de Core Web Vitals op 62% van de mobiele paginaweergaven, vergeleken met slechts 41% voor sites die uitsluitend op high-end hardware testen.

Stap 1: Genereer een Client Capability Score

Om te beoordelen of een bezoeker een high-end of low-end apparaat gebruikt, kan direct in de browser een Client Capability Score worden berekend. Deze score loopt van 0 (extreem beperkt) tot 100 (top-tier hardware). In de praktijk moet elk apparaat dat onder de 40 scoort als slecht worden geclassificeerd.

De onderstaande functie berekent de Client Capability Score aan de hand van hardware- en netwerkindicatoren die sterk correleren met praktijkgerichte RUM en de Core Web Vitals-data van Google. Een hogere score geeft aan dat het apparaat beter in staat is om snelle paginaprestaties te leveren met minder bronbeperkingen.

function getClientCapabilityScore() {
  const mem = navigator.deviceMemory || 4;
  let cpu = navigator.hardwareConcurrency || 4;
  cpu = Math.min(cpu, 8);

  let net = 4;
  if (navigator.connection) {
    const { effectiveType, rtt = 300 } = navigator.connection;
    const map = { 'slow-2g': 1, '2g': 2, '3g': 3, '4g': 4, '5g': 5 };
    net = map[effectiveType] || 4;
    if (rtt > 500) net = Math.max(net - 3, 1);
    else if (rtt > 300) net = Math.max(net - 2, 1);
    else if (rtt < 150) net = Math.min(net + 1, 5);
  }

  const score = mem + cpu * 0.5 + net * 2;
  return Math.min(100, Math.round(score * 5));
}

getClientCapabilityScore();

Core Web Vitals tip: Deze optimalisaties helpen iedereen. Maar als iemand een trage verbinding heeft of een apparaat met beperkt geheugen gebruikt, zijn ze veel belangrijker. De nadelen van het overslaan ervan worden sneller zichtbaar.
Neem bijvoorbeeld het downloaden van afbeeldingen. Op een normale verbinding maken ze doorgaans ongeveer 10% uit van de Largest Contentful Paint tijd. Op een trage verbinding kan dat zonder veel moeite verdubbelen. Daarom zetten we afbeeldingsoptimalisatie voor de meeste gebruikers niet bovenaan de lijst, maar als we te maken hebben met bezoekers met een lage bandbreedte of beperkt geheugen, wordt het snel een prioriteit.

Schakel HTTP/3 in met QUIC en 0-RTT

Bezoekers die ver van je servers verwijderd zijn of vastzitten op trage netwerken, krijgen te maken met hoge round-trip times (RTT). HTTP/3, samen met QUIC en 0-RTT, verbetert je initiële verbindingssnelheid direct. Dit is een belangrijke optimalisatie voor alle bezoekers, maar cruciaal voor bezoekers met een lage bandbreedte. Volgens Cloudflare Radar verwerkt HTTP/3 inmiddels 21% van het wereldwijde webverkeer. Als je Cloudflare gebruikt, kun je HTTP/3 inschakelen in het Cloudflare-dashboard.

• Snellere verbindingsopbouw: QUIC voegt de transport- en encryptiehandshakes samen tot één. 0-RTT gaat nog een stap verder: terugkerende bezoekers verzenden direct data en slaan handshakes volledig over.
• Lagere latentie voor terugkerende gebruikers: 0-RTT laat clients sessies hervatten en verzoeken verzenden zonder pauze. Dit bespaart honderden milliseconden, wat vooral waardevol is voor mobiele gebruikers of gebruikers op afstand.
• Veerkrachtig over grote afstanden: HTTP/3 (via UDP) omzeilt de head-of-line blocking van TCP. QUIC gaat soepeler om met pakketverlies en onstabiele netwerken. Dit maakt een wezenlijk verschil voor intercontinentale of instabiele mobiele verbindingen.

Comprimeer afbeeldingen agressiever dan je ontwerper lief is

Hogeresolutieafbeeldingen vertragen de LCP, met name op apparaten met beperkte GPU-decompressiekracht. De 2025 Web Almanac laat zien dat de mediane mobiele homepage 911KB aan afbeeldingen inlaadt. Dat is 42% van het totale paginagewicht. Op een budgetapparaat met een P75-downlink van 9 Mbps concurreren die afbeeldingen direct met je kritieke resources.

In plaats van toe te geven aan esthetiek, moet je streven naar kleinere, perceptueel acceptabele afbeeldingen. WebP en AVIF helpen, maar lazy-loading en het serveren van responsieve formaten zijn belangrijker.

Een heldere regel: blijf voor hero-afbeeldingen op low-end apparaten onder de 100KB. Als de ontwerper bezwaar maakt, moeten ze dezelfde site maar eens testen op een Android-telefoon van 100€ voordat ze verder in discussie gaan.

Beperk CSS tot wat strikt noodzakelijk is

Als het om stijlen gaat, is er maar één regel: grote schoonmaak. Verwijder ongebruikte selectors, verlaag specificiteit en voeg overbodige regels samen.

Richt je op voorspelbare, consistente lay-outs met minimale overrides. Gebruik een kleine set utility classes in plaats van complexe componentspecifieke stijlen. Dat helpt zowel bij de opbouw van de CSSOM in de browser als bij de onderhoudbaarheid voor ontwikkelaars.

Voor above-the-fold content inline je alleen wat absoluut noodzakelijk is. Lazy-load de rest, maar houd de opsplitsing minimaal en overzichtelijk. Je kunt de Critical CSS Generator gebruiken als startpunt, maar definieer je kritieke CSS handmatig en chirurgisch voor het beste resultaat.

Wees meedogenloos met scripts

Met een mediane mobiele TBT van 1.916ms (een stijging van 58% ten opzichte van vorig jaar volgens de 2025 Web Almanac), is JavaScript het allergrootste probleem op low-end apparaten. De P75-netwerksnelheid voor budgetapparaten is ongeveer 9 Mbps down met 100ms RTT. Elke kilobyte JavaScript die je meelevert, wordt geparseerd en uitgevoerd op een CPU die 9x trager is dan de telefoon waarop je test.

• Geen enkel script mag rendering blokkeren: Zorg ervoor dat alle niet-essentiële scripts niet-blokkerend zijn. Gebruik async of defer attributen op je <script> tags. Als een script niet essentieel is voor de initiële paginalading of gebruikersinteractie, mag het niet synchroon zijn. Voor een compleet overzicht van uitsteltechnieken, zie 16 methoden om JavaScript uit te stellen.
• Plan niet-kritieke scripts in: Scripts die niet vooraf vereist zijn, moeten worden ingepland. Gebruik requestIdleCallback om scripts af te vuren wanneer de browser inactief is. Hierdoor kun je zware taken verplaatsen zonder de kritieke weergavepaden te verstoren.
• Gebruik de Client Capability Score om scripts selectief te laden: Gebruik de score om te bepalen wat er geladen moet worden. Op low-end apparaten verminder je het aantal scripts en kies je voor lichtere alternatieven. Als de gebruiker beperkt geheugen of een oudere CPU heeft, verspil dan geen resources door zware scripts te laden. Geef prioriteit aan prestaties boven ijdele functies die misschien indruk maken op high-end apparaten maar frustrerend zijn op low-end apparaten.

Gebruik systeemlettertypen of vermijd ten minste zware custom fonts

Het laden van aangepaste lettertypen voegt latentie toe en verstoort de lay-out. Op apparaten met beperkt geheugen kunnen ze bovendien de RAM-druk onnodig verhogen. Volgens de 2025 Web Almanac laadt 88% van de sites minstens één webfont, maar slechts 12% preloadt deze. De beste optie voor prestaties, font-display: optional, wordt door slechts 0,4% van de sites gebruikt.

Systeemlettertypen renderen sneller, respecteren gebruikersinstellingen en verminderen layout shift. Als de merkidentiteit aangepaste typografie vereist, pas dan agressieve subsetting toe en laad lettertypen laat in. Overweeg self-hosting voor je lettertypen zodat je controle hebt over de levering.

Monitor met echte hardware, niet alleen met synthetische tests

Synthetische testtools (zoals Lighthouse, WebPageTest, etc.) simuleren throttling maar bootsen niet alle eigenaardigheden van low-end hardware na: warmteontwikkeling, throttling onder echte belasting, garbage collection pauzes en opslagknelpunten. Let op dat PageSpeed Insights zijn CPU-throttling in december 2024 heeft gewijzigd van 4x naar 1.2x, waardoor labscores nog minder representatief zijn voor de prestaties van echte budgetapparaten.

Koop een goedkope Android-telefoon en browse door je site. Als je het niet op kunt brengen om dat regelmatig te doen, gebruik dan een RUM-tool zoals CoreDash en segmenteer data op apparaatklasse. Als je P75 LCP in orde is op een iPhone 15 maar verschrikkelijk op een Xiaomi Redmi 9, is het tijd om eerlijk te zijn over voor wie je optimaliseert.