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 de allerbelangrijkste eerste filter in elk performance-onderzoek, omdat mobiel en desktop fundamenteel verschillende computeromgevingen zijn. Verschillende CPU's, verschillende netwerkcondities, 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 zachtst gezegd misleidend.

De Mobiele Performance Gap

Mobiele apparaten zijn goed voor ruwweg 62% van het wereldwijde webverkeer volgens Statista (2025). Toch presteert mobiel consequent slechter dan desktop. Volgens de 2025 Web Almanac haalt slechts 48% van de mobiele origins alle drie de Core Web Vitals, vergeleken met 56% op desktop. Dat is een gat 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 ruwweg 3-5x minder rekenkracht dan een desktop. JavaScript dat op desktop in 50ms wordt uitgevoerd, kan er op mobiel 200ms over doen, waardoor INP de drempelwaarde voor "good" overschrijdt.
• Network latency: Mobiele verbindingen (4G/5G) hebben hogere round-trip times en meer variantie dan bedrade verbindingen. Dit verhoogt TTFB en LCP Load Delay.
• Viewport size: Kleinere schermen veranderen welk element de LCP wordt. Je desktop hero-afbeelding kan op mobiel onder een tekstblok verschuiven, wat het optimalisatiedoel volledig verandert.

CoreDash Apparaattype Distributie

Over alle CoreDash-projecten heen 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 performance gap in 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 primaire 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 contention op een tragere CPU. Als je desktop LCP onder de 2,0s ligt maar mobiel de 3,0s overschrijdt, is het probleem zelden het afbeeldingsbestand zelf. Het is de delivery pipeline.

Interaction to Next Paint (INP)

Dit is waar het verschil tussen apparaten het hardst aankomt. JavaScript event handlers die op een desktop i7 direct aanvoelen, kunnen de main thread op een Snapdragon 665 voor 300ms of langer blokkeren. Filter op mobiel, sorteer op INP-impact en je vindt de exacte interacties die op echte telefoons stuklopen. Ik zie dit constant: developers 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 tot responsive design. Advertentieblokken die ruimte reserveren op desktop, kunnen op mobiel inzakken of van grootte veranderen. Font fallback metrics die op desktop netjes uitlijnen, veroorzaken zichtbare verschuivingen op kleinere viewports. Web fonts worden verschillend gerenderd in mobiele en desktop browsers, en de fysieke pixeldichtheid beïnvloedt sub-pixel rounding.

Debugging Workflow

1. Start elk onderzoek met het apparaatfilter: Voordat je naar een 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 good/needs-improvement/poor distributie voor elk apparaattype. Een desktop met 85% good en een mobiel met 45% good vertelt een heel ander verhaal dan de p75 alleen.
3. Combineer met andere dimensies: Zodra je het apparaattype hebt geïsoleerd, voeg je een tweede filter toe. Apparaattype + Land onthult of de mobiele kloof wereldwijd is of zich concentreert in regio's met tragere netwerken. Apparaattype + Navigatietype laat zien of mobiele back-forward navigaties correct gecachet worden.

Engineering Vuistregels

• Mobiele LCP onder 2,5s: Dit is de drempelwaarde die Google hanteert voor "good". Als je desktop slaagt maar mobiel faalt, richt je dan op het reduceren 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 uitsluitend voor desktop: Als je mobiele verkeer de 50% overschrijdt (en dat doet het vrijwel zeker), is mobiele performance je search ranking signaal. Google gebruikt mobiele CrUX-data voor 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.