Core/Dash Dimension: Betriebssystem
Isolieren Sie plattformspezifische Performance-Regressionen, indem Sie den Traffic nach Betriebssystemen segmentieren.
Dimension: Betriebssystem (os)
Die Dimension Betriebssystem gruppiert Performance-Daten 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 den Rendering-Engines isoliert, deckt die OS-Dimension Hardware-Einschränkungen, das Ressourcenmanagement auf Systemebene und plattformspezifische Eigenheiten auf, die der Browser erbt.
Das Betriebssystem (OS) ist die Schicht zwischen Ihrem Code und der Hardware. Es steuert, wie die CPU Aufgaben plant, wie Arbeitsspeicher zugewiesen wird und wie Netzwerkanfragen priorisiert werden. Zwei identische Browser auf unterschiedlichen Betriebssystemen können völlig unterschiedliche Core Web Vitals erzeugen.

Die Plattform-Landschaft
Laut StatCounter (2025) führt Android den weltweiten 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-Aufteilung wird je nach Branche variieren. B2B-SaaS-Produkte verzeichnen mehr Windows- und macOS-Traffic. Consumer-Apps tendieren eher zu Android und iOS.
OS-spezifische Performance-Eigenschaften
Android
Android ist die vielfältigste Plattform. Sie läuft auf Geräten, die von 80-Dollar-Budget-Smartphones bis hin zu 1.500-Dollar-Flaggschiffen reichen. Das bedeutet, dass Ihr Android-Segment sowohl Ihre schnellsten als auch Ihre langsamsten Nutzer enthält. Die wichtigste Erkenntnis: Die durchschnittliche Performance von Android wird durch den langen Schwanz an Budget-Hardware nach unten gezogen. In den CoreDash-Daten ist der Android p75 INP in der Regel 40–60 % höher als bei iOS, da das durchschnittliche Android-Gerät über eine schwächere CPU verfügt.
Filtern Sie den Android-Traffic nach der Dimension Client Capability Score, um Flaggschiff-Nutzer (die ähnlich wie iOS abschneiden) von Budget-Nutzern zu trennen (die leichtere Seiten benötigen).
iOS
Apple kontrolliert den Hardware- und Software-Stack, was eine bemerkenswert konsistente Performance liefert. Die Geräteauswahl ist eng gefasst (iPhone 12 bis iPhone 16), und jedes Gerät führt die WebKit-Engine von Safari aus, unabhängig vom "Browser"-Label. Der iOS-Traffic in CoreDash zeigt typischerweise einen 15–25 % besseren LCP und einen 30–40 % besseren INP 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) machen jedoch eine andere Erfahrung.
Windows
Windows dominiert den Desktop-Traffic. Die Performance ist hier im Allgemeinen stark, da Desktop-Hardware leistungsfähig ist. Windows-Unternehmensumgebungen bringen jedoch einzigartige Probleme mit sich: Proxy-Server in Unternehmen blähen den TTFB auf, obligatorische Browser-Erweiterungen injizieren Skripte, die den INP verschlechtern, und IT-Richtlinien können die Nutzung älterer Browser-Versionen erzwingen.
macOS
Der macOS-Traffic stammt von einer relativ hochwertigen Hardware-Basis. Die Performance ist typischerweise exzellent. Wenn macOS-Nutzer schlechte Metriken aufweisen, liegt das Problem fast sicher an Ihrem Code (viel JavaScript, unoptimierte Bilder) und nicht an der Plattform.
Linux und ChromeOS
Diese machen zwar nur kleine Anteile am Traffic aus, weisen aber ausgeprägte Nutzerprofile auf. Linux-Nutzer sind in der Regel Entwickler mit schneller Hardware. ChromeOS-Nutzer sind oft auf Chromebooks mit begrenztem Arbeitsspeicher und Speicherplatz unterwegs. Wenn ChromeOS einen schlechten INP aufweist, überprüfen Sie, ob der Speicherbedarf Ihres JavaScript die Beschränkungen des Geräts überschreitet.
Debugging-Workflow
- Vergleichen Sie zuerst Android mit iOS: Dies deckt die Lücke bei der mobilen Hardware auf. Wenn der Android INP bei 250ms und der von iOS bei 90ms liegt, haben Sie ein JavaScript-Komplexitätsproblem, das sich nur auf schwächeren CPUs bemerkbar macht. Die Lösung besteht darin, die Arbeit im Main-Thread zu reduzieren, nicht darin, schnellere Server zu kaufen.
- Prüfen Sie Windows auf Unternehmensanomalien: Wenn der Windows TTFB 200ms höher ist als bei macOS, untersuchen Sie Unternehmens-Proxys und VPNs. Das sind Infrastrukturprobleme auf Seiten des Nutzers, aber wenn Sie diese verstehen, verhindern Sie, dass Sie Phantom-Serverproblemen hinterherjagen.
- Kombinieren Sie OS + Browser für mehr Präzision: "Safari auf iOS" ist etwas völlig anderes als "Chrome auf Android". Filtern Sie nach OS + Browser, um herauszufinden, ob eine Regression plattformübergreifend ist oder spezifisch für eine bestimmte Browser-OS-Kombination auftritt.
Technische Faustregeln
- Android INP unter 200ms: Wenn Ihr iOS INP in Ordnung ist, aber Android fehlschlägt, reduzieren Sie die JavaScript-Ausführungszeit. Die Budget-Android-CPU ist Ihr tatsächliches Performance-Budget.
- Kein OS sollte 2-mal schlechter sein als ein anderes: Eine Diskrepanz von 50 % ist normal (Hardware-Unterschiede). Eine Lücke von 100 % oder mehr signalisiert einen plattformspezifischen Bug oder einen unoptimierten Code-Pfad.
- Testen Sie auf echten Android-Geräten: Das CPU-Throttling der Chrome DevTools simuliert langsame Hardware zwar recht gut, aber Tests auf echten Geräten erfassen Scheduling-Probleme auf OS-Ebene, die bei der Emulation unbemerkt bleiben.
Die Dimension Betriebssystem zeigt, ob Ihre Performance-Probleme universell oder plattformspezifisch sind. Diese Unterscheidung bestimmt, ob Sie Ihren Code oder Ihre Bereitstellungsstrategie anpassen müssen.