Core/Dash Dimension: Operating System

Plattformspezifische Leistungsregressionen isolieren, indem der Traffic nach Betriebssystemen segmentiert wird.

Kostenlos testen

Trusted by market leaders · Client results

aleteiadpg mediaharvarderasmusmcfotocasanestlesaturnvpnloopearplugsworkivamarktplaatsebaymy work featured on web.devcomparemonarchwhowhatwearadevintanina careperionkpnsnvhappyhorizon

Dimension: Operating System (os)

Die Dimension Operating System gruppiert Leistungsdaten nach der Plattform, die auf dem Gerät des Nutzers läuft: Android, iOS, Windows, macOS, Linux oder ChromeOS. Während die Browser-Dimension Unterschiede in Rendering-Engines isoliert, deckt die OS-Dimension Hardware-Einschränkungen, Ressourcenverwaltung auf Systemebene und plattformspezifische Eigenheiten auf, die der Browser erbt.

Das Betriebssystem ist die Schicht zwischen Ihrem Code und der Hardware. Es steuert, wie die CPU Aufgaben plant, wie Speicher zugewiesen wird und wie Netzwerkanfragen priorisiert werden. Zwei identische Browser auf verschiedenen Betriebssystemen können sehr unterschiedliche Core Web Vitals erzeugen.

coredash metric table urls

Die Plattformlandschaft

Laut StatCounter (2025) führt Android den globalen Web-Traffic mit 39 % an, gefolgt von Windows mit 30 %, iOS mit 16 %, macOS mit 8 %, Linux mit 4 % und ChromeOS mit 2 %. Ihre spezifische Traffic-Verteilung variiert je nach Branche. B2B-SaaS-Produkte verzeichnen mehr Windows- und macOS-Traffic. Verbraucher-Apps tendieren zu Android und iOS.

Betriebssystemspezifische Leistungsmerkmale

Android

Android ist die vielfältigste Plattform. Es läuft auf Geräten, die von 80-Dollar-Budget-Smartphones bis zu 1.500-Dollar-Flaggschiffen reichen. Das bedeutet, Ihr Android-Segment enthält sowohl Ihre schnellsten als auch Ihre langsamsten Nutzer. Die wichtigste Erkenntnis: Die durchschnittliche Android-Leistung wird durch den langen Schwanz günstiger Hardware nach unten gezogen. In CoreDash-Daten ist der Android-p75-INP typischerweise 40–60 % höher als bei iOS, da das durchschnittliche Android-Gerät eine schwächere CPU hat.

Filtern Sie den Android-Traffic nach der Client Capability Score-Dimension, um Flaggschiff-Nutzer (die ähnlich wie iOS abschneiden) von Budget-Nutzern (die leichtere Seiten benötigen) zu trennen.

iOS

Apple kontrolliert den Hardware- und Software-Stack, was eine bemerkenswert konsistente Leistung erzeugt. Die Gerätebandbreite ist schmal (iPhone 12 bis iPhone 16), und jedes Gerät nutzt Safaris WebKit-Engine unabhängig von der „Browser"-Bezeichnung. iOS-Traffic in CoreDash zeigt typischerweise 15–25 % bessere LCP- und 30–40 % bessere INP-Werte als Android.

Die Falle: Wenn Sie nur auf iOS testen, fühlt sich Ihre Website schnell an. Ihre Android-Nutzer (die iOS-Nutzer weltweit im Verhältnis 2,5:1 übertreffen) haben eine andere Erfahrung.

Windows

Windows dominiert den Desktop-Traffic. Die Leistung ist hier generell stark, da Desktop-Hardware leistungsfähig ist. Allerdings bringen Unternehmens-Windows-Umgebungen einzigartige Probleme mit sich: Firmen-Proxy-Server erhöhen die TTFB, obligatorische Browser-Erweiterungen injizieren Skripte, die INP verschlechtern, und IT-Richtlinien können ältere Browser-Versionen erzwingen.

macOS

macOS-Traffic stammt von einer relativ hochwertigen Hardware-Basis. Die Leistung ist typischerweise ausgezeichnet. Wenn macOS-Nutzer schlechte Metriken zeigen, liegt das Problem fast sicher in Ihrem Code (schweres JavaScript, nicht optimierte Bilder) und nicht an der Plattform.

Linux und ChromeOS

Diese repräsentieren kleine Traffic-Anteile, aber unterschiedliche Nutzerprofile. Linux-Nutzer sind tendenziell Entwickler mit schneller Hardware. ChromeOS-Nutzer verwenden oft Chromebooks mit begrenztem RAM und Speicher. Wenn ChromeOS schlechte INP-Werte zeigt, prüfen Sie, ob der JavaScript-Speicherverbrauch die Grenzen des Geräts überschreitet.

Debugging-Workflow

  1. Vergleichen Sie zuerst Android mit iOS: Dies zeigt die mobile Hardware-Lücke auf. Wenn der Android-INP bei 250ms und der iOS-INP bei 90ms liegt, haben Sie ein JavaScript-Komplexitätsproblem, das sich nur auf schwächeren CPUs bemerkbar macht. Die Lösung ist die Reduzierung der Main-Thread-Arbeit, nicht der Kauf schnellerer Server.
  2. Prüfen Sie Windows auf Unternehmens-Anomalien: Wenn die Windows-TTFB 200ms höher ist als macOS, untersuchen Sie Firmen-Proxys und VPNs. Dies sind Infrastrukturprobleme auf der Nutzerseite, aber das Verständnis dafür verhindert, dass Sie Phantom-Server-Problemen nachjagen.
  3. Kombinieren Sie OS + Browser für Präzision: „Safari auf iOS" ist ein ganz anderes Tier als „Chrome auf Android". Filtern Sie OS + Browser, um festzustellen, ob eine Regression plattformweit ist oder spezifisch für eine Browser-auf-OS-Kombination.

Technische Faustregel

  • Android-INP unter 200ms: Wenn Ihr iOS-INP besteht, aber Android durchfällt, reduzieren Sie die JavaScript-Ausführungszeit. Die Budget-Android-CPU ist Ihr tatsächliches Leistungsbudget.
  • Kein Betriebssystem sollte 2x schlechter sein als ein anderes: Eine 50%-Lücke ist normal (Hardware-Unterschiede). Eine 100%+-Lücke signalisiert einen plattformspezifischen Bug oder einen nicht optimierten Codepfad.
  • Testen Sie auf echten Android-Geräten: Die CPU-Drosselung in Chrome DevTools simuliert langsame Hardware annähernd, aber echte Gerätetests fangen Scheduling-Probleme auf OS-Ebene ein, die bei der Emulation übersehen werden.

Die Operating System-Dimension zeigt, ob Ihre Leistungsprobleme universell oder plattformspezifisch sind. Diese Unterscheidung bestimmt, ob Sie Ihren Code oder Ihre Bereitstellungsstrategie beheben.