Core/Dash-dimensie: besturingssysteem

Isoleer platformspecifieke performance-regressies door verkeer te segmenteren per besturingssysteem.

Gratis proefperiode

Trusted by market leaders · Client results

nestlenina careadevintawhowhatwearmarktplaatsperionsaturnsnvkpndpg mediaerasmusmcmy work featured on web.devaleteialoopearplugscompareharvardworkivahappyhorizonvpnfotocasamonarchebay

Dimensie: besturingssysteem (os)

De dimensie besturingssysteem groepeert performance-data op basis van het platform dat op het apparaat van de gebruiker draait: Android, iOS, Windows, macOS, Linux of ChromeOS. Waar de dimensie Browser verschillen in rendering-engines isoleert, legt de dimensie OS hardwarebeperkingen, resourcebeheer op systeemniveau en platformspecifieke quirks bloot die de browser erft.

Het OS is de laag tussen je code en de hardware. Het regelt hoe de CPU taken inplant, hoe geheugen wordt toegewezen en hoe netwerkverzoeken worden geprioriteerd. Twee identieke browsers op verschillende besturingssystemen kunnen heel verschillende Core Web Vitals opleveren.

coredash metric table urls

Het platformlandschap

Volgens StatCounter (2025) leidt Android het wereldwijde webverkeer met 39%, gevolgd door Windows met 30%, iOS met 16%, macOS met 8%, Linux met 4% en ChromeOS met 2%. Je specifieke verkeersverdeling verschilt per sector. B2B SaaS-producten zien meer Windows- en macOS-verkeer. Consumenten-apps neigen meer naar Android en iOS.

OS-specifieke performance-kenmerken

Android

Android is het meest diverse platform. Het draait op apparaten variërend van budgettelefoons van $80 tot flagships van $1.500. Dit betekent dat je Android-segment zowel je snelste als je langzaamste gebruikers bevat. Het belangrijkste inzicht: de gemiddelde performance van Android wordt omlaag getrokken door de long tail van budgethardware. In CoreDash-data ligt de p75 INP van Android doorgaans 40-60% hoger dan die van iOS, omdat het mediane Android-apparaat een zwakkere CPU heeft.

Filter Android-verkeer op de dimensie Client Capability Score om flagship-gebruikers (die presteren als iOS) te scheiden van budgetgebruikers (die lichtere pagina's nodig hebben).

iOS

Apple heeft de controle over de hardware- en softwarestack, wat leidt tot opvallend consistente performance. Het aanbod van apparaten is beperkt (iPhone 12 tot en met iPhone 16), en elk apparaat draait op de WebKit-engine van Safari, ongeacht het "browser"-label. iOS-verkeer in CoreDash laat doorgaans een 15-25% betere LCP en 30-40% betere INP zien dan Android.

De valkuil: als je alleen op iOS test, voelt je site snel aan. Je Android-gebruikers (die wereldwijd 2,5:1 in de meerderheid zijn ten opzichte van iOS-gebruikers) hebben een heel andere ervaring.

Windows

Windows domineert het desktopverkeer. De performance is hier over het algemeen goed omdat desktop-hardware krachtig is. Zakelijke Windows-omgevingen introduceren echter unieke problemen: zakelijke proxyservers verhogen de TTFB, verplichte browserextensies injecteren scripts die de INP verslechteren en het IT-beleid kan oudere browserversies afdwingen.

macOS

macOS-verkeer is afkomstig van een relatief premium hardwarebasis. De performance is doorgaans uitstekend. Als macOS-gebruikers slechte resultaten laten zien, ligt het probleem vrijwel zeker in je code (zware JavaScript, niet-geoptimaliseerde afbeeldingen) en niet aan het platform.

Linux en ChromeOS

Deze vertegenwoordigen een klein verkeersaandeel, maar hebben duidelijke gebruikersprofielen. Linux-gebruikers zijn vaak developers met snelle hardware. ChromeOS-gebruikers werken vaak op Chromebooks met beperkt werkgeheugen en opslagruimte. Als ChromeOS een slechte INP laat zien, controleer dan of het geheugengebruik van je JavaScript de limieten van het apparaat overschrijdt.

Debugging-workflow

  1. Vergelijk eerst Android met iOS: Dit onthult het verschil in mobiele hardware. Als de Android-INP 250 ms is en die van iOS 90 ms, heb je een JavaScript-complexiteitsprobleem dat zich alleen voordoet op zwakkere CPU's. De oplossing is het verminderen van werk op de main thread, niet het kopen van snellere servers.
  2. Controleer Windows op zakelijke afwijkingen: Als de Windows-TTFB 200 ms hoger is dan die van macOS, onderzoek dan zakelijke proxies en VPN's. Dit zijn infrastructuurproblemen aan de kant van de gebruiker, maar door dit te begrijpen voorkom je dat je achter fictieve serverproblemen aanjaagt.
  3. Combineer OS + Browser voor precisie: "Safari op iOS" is heel anders dan "Chrome op Android". Filter op OS + Browser om te bepalen of een regressie platformbreed is of specifiek voor één browser-OS-combinatie.

Vuistregels voor engineers

  • Android-INP onder 200 ms: Als je iOS-INP voldoet maar Android faalt, verminder dan de uitvoeringstijd van JavaScript. De budget-Android-CPU is je werkelijke performance-budget.
  • Geen enkel OS mag 2x slechter scoren dan een ander: Een verschil van 50% is normaal (hardwareverschillen). Een verschil van 100%+ wijst op een platformspecifieke bug of een ongeoptimaliseerd codepad.
  • Test op echte Android-apparaten: CPU-throttling in Chrome DevTools is een benadering van trage hardware, maar testen op echte apparaten brengt scheduling-problemen op OS-niveau aan het licht die emulatie mist.

De dimensie besturingssysteem onthult of je performance-problemen universeel of platformspecifiek zijn. Dat onderscheid bepaalt of je je code aanpast of je distributiestrategie.