Optimaliseer de Core Web Vitals voor low-end devices

Optimaliseer de Core Web vitals voor low-end devices

Core Web Vitals horen een objectieve benchmark voor sitekwaliteit te zijn. In de praktijk zijn ze dat niet! De metrics zijn onlosmakelijk verbonden met de devices die gebruikers hebben. Als een bedrijf high-end producten of diensten verkoopt, hebben de klanten doorgaans snelle telefoons, desktops en betrouwbare verbindingen. 
Vergelijk dat met bedrijven die zich richten op prijsbewuste consumenten of opkomende markten. Hun doelgroepen gebruiken verouderde telefoons, zwakke processors of hebben te maken met slechte netwerkomstandigheden. 
Dezelfde website die moeiteloos door een test op een flagship iPhone komt, heeft moeite om acceptabel te laden op een mid-range Android of in landen met een lage bandbreedte. Dit artikel onderzoekt hoe je de Core Web Vitals optimaliseert voor low-end devices.

Stap 1: Genereer een Client Capability Score

Om te bepalen of een bezoeker een high-end of low-end device gebruikt, kun je direct in de browser een Client Capability Score berekenen. Deze score loopt van 0 (extreem beperkt) tot 100 (top-tier hardware). In de praktijk moet elk device met een score onder de 40 als slecht worden geclassificeerd.

De functie hieronder berekent de Client Capability Score aan de hand van hardware- en netwerkindicatoren die sterk correleren met real-world RUM- en Google Core Web Vitals-data. Een hogere score geeft aan dat het device beter in staat is om snelle paginaprestaties te leveren met minder resourcebeperkingen en soepelere interacties kan verwerken.

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 of een device met beperkt geheugen heeft, zijn ze veel belangrijker. De nadelen van het overslaan ervan worden sneller zichtbaar.
Neem het downloaden van afbeeldingen. Op een normale verbinding zijn ze meestal goed voor ongeveer 10% van de Largest Contentful Paint-tijd. Op een trage verbinding kan dat zonder veel moeite verdubbelen. Daarom zetten we beeldoptimalisatie voor de meeste gebruikers niet bovenaan de lijst, maar voor bezoekers met een lage bandbreedte of beperkt geheugen wordt het al snel een prioriteit.

Activeer http/3 met QUIC en 0-RTT

• Snellere verbindingsopzet: QUIC voegt de transport- en encryptie-handshakes samen tot één. 0-RTT gaat nog verder: terugkerende bezoekers versturen data onmiddellijk en slaan de handshakes volledig over.
• Lagere latency voor terugkerende gebruikers: Met 0-RTT kunnen clients sessies hervatten en requests versturen zonder pauze. Honderden milliseconden bespaard – bijzonder waardevol voor gebruikers op grote afstand of mobiele gebruikers.
• Veerkrachtig over lange afstanden: HTTP/3 (over UDP) omzeilt TCP’s head-of-line blocking. QUIC gaat eleganter om met packet loss en onstabiele netwerken – ideaal voor verbindingen tussen continenten of wankele mobiele verbindingen.

Comprimeer afbeeldingen agressiever dan je designer prettig vindt

Afbeeldingen met een hoge resolutie vertragen de LCP (Largest Contentful Paint), vooral op devices met beperkte GPU-decompressiekracht. Geef niet toe aan esthetiek, maar streef naar kleinere, perceptueel acceptabele afbeeldingen. WebP en AVIF helpen, maar lazy-loading en het serveren van responsive formaten zijn belangrijker.

Een duidelijke regel: voor hero-afbeeldingen op low-end devices, blijf onder de 100KB. Als de designer bezwaar maakt, moet diegene de site eerst maar eens testen op een Android-telefoon van € 100 voordat er verder gediscussieerd wordt.

Strip CSS tot wat strikt noodzakelijk is

Als het op styles aankomt, is er maar één regel: grote schoonmaak. Verwijder ongebruikte selectors, verminder de specificiteit en voeg overbodige regels samen.

Focus op voorspelbare, consistente layouts met minimale overrides. Gebruik een kleine set utility classes in plaats van complexe, componentspecifieke stijlen. Dat helpt zowel bij de CSSOM-constructie door de browser als bij de onderhoudbaarheid voor de developer.

Voor above-the-fold content, inline alleen wat absoluut noodzakelijk is. Lazy-load de rest, maar houd de splitsing minimaal en duidelijk. Vermijd tools die raden wat "critical CSS" is; definieer dit handmatig en chirurgisch.

Wees meedogenloos met Scripts

• Geen enkel script mag de rendering blokkeren: Zorg ervoor dat alle niet-essentiële scripts non-blocking zijn. Gebruik async- of defer-attributen op je <script>-tags. Als een script niet essentieel is voor de initiële pageload of user interaction, mag het niet synchroon zijn. Anders gooi je kostbare milliseconden weg.
•  Plan niet-kritieke scripts in Scripts die niet direct nodig zijn, moeten worden ingepland. Maar laad ze niet willekeurig. Gebruik de requestIdleCallback-functies om scripts uit te voeren wanneer de browser idle is. Hiermee kun je zware taken uitstellen zonder de kritieke renderingpaden te verstoren.
• Gebruik de Client Capability Score om nice-to-have scripts selectief te laden:  De Client Capability Score is niet alleen een metric, maar een tool om de user experience te optimaliseren.  Op low-end devices, laad je minder scripts en kies je lichtere alternatieven. Als de gebruiker beperkt geheugen of een oudere CPU heeft, verspil dan geen resources aan het laden van zware scripts. Geef prioriteit aan prestaties boven overbodige features die misschien indruk maken op high-end devices, maar frustreren op low-end devices.

Gebruik systeemfonts of vermijd in ieder geval zware custom fonts

Het laden van custom fonts voegt latency toe en veroorzaakt jank in de layout. Op devices met beperkt geheugen kunnen ze ook onnodig de druk op het RAM-geheugen verhogen.

Systeemfonts renderen sneller, respecteren gebruikersinstellingen en verminderen layout shift. Als de branding custom typografie voorschrijft, maak dan agressieve subsets en laad de fonts laat.

Monitor met echte hardware, niet alleen met synthetische tests

Tot slot, synthetische testtools (zoals Lighthouse, WebPageTest, etc.) simuleren throttling, maar bootsen niet alle eigenaardigheden van low-end hardware na: thermische problemen, throttling onder reële belasting, pauzes door garbage collection en opslag-bottlenecks.

Koop een goedkope Android-telefoon en browse naar je site. Als je dat niet regelmatig kunt opbrengen, gebruik dan een RUM-tool zoals Coredash en segmenteer data per deviceklasse. Als je P75 LCP prima is op een iPhone 15 maar verschrikkelijk op een Xiaomi Redmi 9, is het tijd om eerlijk te zijn voor wie je aan het optimaliseren bent.