Core/Dash Dimensie: Apparaattype

Dimensie: Apparaattype (d)

De dimensie Apparaattype splitst je Real User Monitoring-data in twee categorieën: mobile en desktop. Dit is het allerbelangrijkste eerste filter in elk prestatieonderzoek, omdat mobiel en desktop fundamenteel verschillende computeromgevingen zijn. Verschillende CPU's, verschillende netwerkomstandigheden, verschillende viewport-groottes, verschillende browser-engines.

Als je naar geaggregeerde Core Web Vitals kijkt zonder te filteren op apparaattype, neem je het gemiddelde van twee populaties die vrijwel niets met elkaar gemeen hebben. Dat gemiddelde is op zijn best misleidend.

De Mobiele Prestatiekloof

Mobiele apparaten zijn goed voor ongeveer 62% van het wereldwijde webverkeer volgens Statista (2025). Toch presteert mobiel consequent slechter dan desktop. Volgens de 2025 Web Almanac slaagt slechts 48% van de mobiele origins voor alle drie de Core Web Vitals, vergeleken met 56% op desktop. Dat is een kloof van 8 procentpunt.

De kloof bestaat omdat mobiele apparaten te maken hebben met drie beperkingen die desktops niet hebben:

• CPU throttling: Een mid-range Android-telefoon heeft ongeveer 3-5x minder rekenkracht dan een desktop. JavaScript dat op een desktop in 50ms wordt uitgevoerd, kan op een mobiel apparaat 200ms duren, waardoor de INP de grens van "goed" overschrijdt.
• Netwerklatentie: Mobiele verbindingen (4G/5G) hebben hogere round-trip times en meer variantie dan bekabelde verbindingen. Dit verhoogt de TTFB en LCP Load Delay.
• Viewport-grootte: Kleinere schermen veranderen welk element de LCP wordt. Je desktop hero-afbeelding kan op mobiel tot onder een tekstblok krimpen, wat het optimalisatiedoel volledig verandert.

CoreDash Apparaattype-verdeling

Binnen CoreDash-projecten is de typische verkeersverdeling 65% mobiel en 35% desktop. E-commerce sites neigen sterker naar mobiel (70-75%), terwijl B2B SaaS-producten vaak een 50/50 verdeling of zelfs een dominantie van desktop zien.

De prestatiekloof in de CoreDash-data weerspiegelt de wereldwijde trend. Mobiele p75 LCP is gemiddeld 2,8s vergeleken met 1,9s op desktop. Voor INP is de kloof nog groter: mobiele p75 ligt rond de 220ms, terwijl desktop rond de 120ms schommelt.

Metriek-specifieke Analyse

Largest Contentful Paint (LCP)

Mobiele LCP is bijna altijd slechter dan desktop. De voornaamste oorzaak is Load Delay: mobiele browsers ontdekken de LCP-afbeelding later omdat de HTML er langer over doet om aan te komen (hogere TTFB) en de preload-scanner moet concurreren met meer resource-conflicten op een tragere CPU. Als je desktop LCP onder de 2,0s ligt maar de mobiele LCP de 3,0s overschrijdt, ligt het probleem zelden aan het afbeeldingsbestand zelf. Het ligt aan de delivery pipeline.

Interaction to Next Paint (INP)

Dit is waar de apparaatkloof het hardst aankomt. JavaScript event handlers die instant aanvoelen op een desktop i7, kunnen de main thread voor meer dan 300ms blokkeren op een Snapdragon 665. Filter op mobiel, sorteer op INP-impact, en je zult exact de interacties vinden die stuklopen op echte telefoons. Ik zie dit constant: ontwikkelaars testen op MacBook Pro's en leveren interacties op die onbruikbaar zijn op de apparaten die 65% van hun gebruikers daadwerkelijk bij zich dragen.

Cumulative Layout Shift (CLS)

CLS-verschillen tussen apparaattypen zijn meestal te herleiden naar responsive design. Advertentieslots die op desktop ruimte reserveren, kunnen op mobiel inzakken of van formaat veranderen. Font fallback-metrieken die op desktop netjes uitlijnen, veroorzaken zichtbare verschuivingen op kleinere viewports. Web fonts worden anders gerenderd in mobiele en desktopbrowsers, en de fysieke pixeldichtheid beïnvloedt sub-pixel afronding.

Debugging Workflow

1. Start elk onderzoek met het apparaatfilter: Voordat je naar enige andere dimensie kijkt, splits je op Apparaattype. Als je geaggregeerde LCP 2,5s is, vind je desktop misschien op 1,8s en mobiel op 3,1s. Het "probleem" is exclusief mobiel.
2. Vergelijk distributies, niet alleen p75: Controleer de goed/needs-improvement/poor verdeling voor elk apparaattype. Een desktop met 85% goed en een mobiel met 45% goed vertelt een compleet ander verhaal dan alleen de p75.
3. Combineer met andere dimensies: Zodra je het apparaattype hebt geïsoleerd, voeg je een tweede filter toe. Apparaattype + Land toont of de mobiele kloof wereldwijd is of geconcentreerd in regio's met tragere netwerken. Apparaattype + Navigatietype toont aan of mobiele back-forward navigaties correct gecachet worden.

Vuistregel voor Engineering

• Mobiele LCP onder 2,5s: Dit is de drempelwaarde die Google gebruikt voor "goed". Als je desktop slaagt maar mobiel faalt, richt je dan op het verlagen van Load Delay (fetchpriority, preload) en TTFB (edge caching, CDN).
• Mobiele INP onder 200ms: Test elke interactieve feature op een echt mid-range Android-apparaat. Chrome DevTools CPU-throttling (4x) benadert dit, maar testen op een echt apparaat is beter.
• Optimaliseer nooit alleen voor desktop: Als je mobiele verkeer de 50% overschrijdt (en dat is vrijwel zeker zo), is de mobiele prestatie je ranking-signaal in zoekmachines. Google gebruikt mobiele CrUX-data voor de ranking.

Apparaattype is geen nice-to-have filter. Het is de eerste vraag die je stelt: "Is dit een mobiel probleem of een desktop-probleem?" Elke optimalisatiebeslissing vloeit voort uit dat antwoord.