Core/Dash Dimension: Gerätetyp

Dimension: Gerätetyp (d)

Die Dimension Gerätetyp teilt deine RUM-Daten in zwei Kategorien auf: mobile und desktop. Dies ist der wichtigste erste Filter bei jeder Performance-Analyse. Mobilgeräte und Desktops sind grundlegend verschiedene Systemumgebungen. Andere CPUs, andere Netzwerkbedingungen, andere viewport-Größen, andere Browser-Engines.

Wenn du dir die aggregierten Core Web Vitals ohne Filterung nach Gerätetyp ansiehst, bildest du den Mittelwert aus zwei Gruppen, die fast nichts gemeinsam haben. Dieser Mittelwert ist bestenfalls irreführend.

Die mobile Performance-Lücke

Mobilgeräte machen laut Statista (2025) rund 62 % des weltweiten Web-Traffics aus. Dennoch schneiden Mobilgeräte durchweg schlechter ab als Desktops. Laut dem 2025 Web Almanac bestehen nur 48 % der mobilen Origins alle drei Core Web Vitals, verglichen mit 56 % auf dem Desktop. Das ist eine Lücke von 8 Prozentpunkten.

Diese Lücke existiert, weil Mobilgeräte drei Einschränkungen unterliegen, die Desktops nicht haben:

• CPU throttling: Ein Android-Smartphone der Mittelklasse hat etwa 3- bis 5-mal weniger Rechenleistung als ein Desktop. JavaScript, das auf dem Desktop in 50 ms ausgeführt wird, kann auf dem Mobilgerät 200 ms dauern. Das schiebt den INP über den Grenzwert für „gut“.
• Network latency: Mobilfunkverbindungen (4G/5G) haben höhere Roundtrip-Zeiten und stärkere Schwankungen als kabelgebundene Verbindungen. Das treibt TTFB und LCP Load Delay in die Höhe.
• Viewport-Größe: Kleinere Bildschirme verändern, welches Element zum LCP wird. Dein Desktop-Hero-Bild schrumpft auf Mobilgeräten möglicherweise unter einen Textblock, was das Optimierungsziel komplett verändert.

Gerätetyp-Verteilung in CoreDash

Bei CoreDash-Projekten liegt das typische Traffic-Verhältnis bei 65 % Mobilgeräten und 35 % Desktop. E-Commerce-Seiten tendieren noch stärker zu Mobilgeräten (70–75 %). B2B-SaaS-Produkte sehen oft eine 50/50-Verteilung oder sogar eine Desktop-Dominanz.

Die Performance-Lücke in den CoreDash-Daten spiegelt den globalen Trend wider. Der mobile p75-LCP liegt im Schnitt bei 2,8 Sekunden, verglichen mit 1,9 Sekunden auf dem Desktop. Beim INP ist die Lücke noch größer: Der mobile p75-Wert liegt bei rund 220 ms, während der Desktop bei etwa 120 ms liegt.

Analyse einzelner Metriken

Largest Contentful Paint (LCP)

Der mobile LCP ist fast immer schlechter als der auf dem Desktop. Die Hauptursache ist der Load Delay: Mobile Browser entdecken das LCP-Bild später. Das liegt daran, dass das HTML länger braucht (höherer TTFB) und der Preload-Scanner mit mehr Ressourcenkonflikten auf einer langsameren CPU kämpfen muss. Wenn dein Desktop-LCP unter 2,0 Sekunden liegt, das Mobilgerät aber 3,0 Sekunden überschreitet, liegt das Problem selten an der Bilddatei selbst. Es liegt an der Auslieferungs-Pipeline.

Interaction to Next Paint (INP)

Hier schlägt die Geräte-Lücke am härtesten zu. JavaScript-Event-Handler, die sich auf einem Desktop-i7 verzögerungsfrei anfühlen, können den main thread auf einem Snapdragon 665 für über 300 ms blockieren. Filtere nach Mobilgeräten, sortiere nach INP-Auswirkung und du findest genau die Interaktionen, die auf echten Smartphones scheitern. Ich sehe das ständig: Entwickler testen auf MacBook Pros und liefern Interaktionen aus, die auf den Geräten von 65 % ihrer Nutzer unbrauchbar sind.

Cumulative Layout Shift (CLS)

CLS-Unterschiede zwischen Gerätetypen gehen meist auf Responsive Design zurück. Ad-Slots, die auf dem Desktop Platz reservieren, fallen auf Mobilgeräten in sich zusammen oder verändern ihre Größe. Font-Fallback-Metriken, die auf dem Desktop passen, verursachen auf kleineren viewports sichtbare Verschiebungen. Web-Fonts rendern auf mobilen und Desktop-Browsern unterschiedlich, und die physische Pixeldichte beeinflusst die Subpixel-Rundung.

Debugging-Workflow

1. Beginne jede Analyse mit dem Gerätefilter: Bevor du dir andere Dimensionen ansiehst, filtere nach Gerätetyp. Wenn dein aggregierter LCP bei 2,5 Sekunden liegt, liegt der Desktop vielleicht bei 1,8 Sekunden und Mobilgeräte bei 3,1 Sekunden. Das „Problem“ ist ausschließlich mobil.
2. Vergleiche Verteilungen, nicht nur den p75-Wert: Prüfe die Verteilung (gut/verbesserungsbedürftig/schlecht) für jeden Gerätetyp. Ein Desktop mit 85 % „gut“ und ein Mobilgerät mit 45 % „gut“ erzählen eine völlig andere Geschichte als der p75-Wert allein.
3. Kombiniere Dimensionen: Sobald du den Gerätetyp isoliert hast, füge einen zweiten Filter hinzu. Gerätetyp + Land zeigt, ob die mobile Lücke global ist oder sich auf Regionen mit langsameren Netzwerken konzentriert. Gerätetyp + Navigationstyp zeigt, ob mobile Back-Forward-Navigationen korrekt gecached werden.

Faustregeln für Entwickler

• Mobiler LCP unter 2,5 Sekunden: Dies ist der Grenzwert von Google für „gut“. Wenn dein Desktop diesen Wert erreicht, das Mobilgerät aber scheitert, konzentriere dich auf die Reduzierung von Load Delay (fetchpriority, preload) und TTFB (Edge-Caching, CDN).
• Mobiler INP unter 200 ms: Teste jede interaktive Funktion auf einem echten Android-Mittelklassegerät. Die CPU-Drosselung (4x) der Chrome DevTools simuliert dies zwar näherungsweise, aber das Testen auf echten Geräten ist besser.
• Optimiere niemals nur für den Desktop: Wenn dein mobiler Traffic über 50 % liegt (und das tut er fast sicher), ist die mobile Performance dein Ranking-Signal für die Suche. Google nutzt mobile CrUX-Daten für das Ranking.

Der Gerätetyp ist kein Nice-to-have-Filter. Es ist die erste Frage, die du stellen musst: „Ist das ein mobiles Problem oder ein Desktop-Problem?“ Jede Optimierungsentscheidung leitet sich aus dieser Antwort ab.