Core/Dash Dimension: Gerätetyp

Dimension: Gerätetyp (d)

Die Gerätetyp-Dimension teilt Ihre Real User Monitoring Daten in zwei Kategorien auf: mobile und desktop. Dies ist der wichtigste erste Filter bei jeder Performance-Untersuchung, da Mobile und Desktop grundlegend unterschiedliche Computing-Umgebungen sind. Verschiedene CPUs, verschiedene Netzwerkbedingungen, verschiedene Viewport-Größen, verschiedene Browser-Engines.

Wenn Sie sich aggregierte Core Web Vitals ohne Filterung nach Gerätetyp ansehen, mitteln Sie zwei Populationen, die fast nichts gemeinsam haben. Dieser Durchschnitt ist bestenfalls irreführend.

Die mobile Performance-Lücke

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

Die Lücke besteht, weil mobile Geräte drei Einschränkungen haben, die Desktops nicht haben:

• CPU-Drosselung: Ein Android-Mittelklasse-Telefon hat etwa 3-5x weniger Rechenleistung als ein Desktop. JavaScript, das auf dem Desktop in 50ms ausgeführt wird, kann auf dem Mobilgerät 200ms dauern und den INP über die "gut"-Schwelle treiben.
• Netzwerklatenz: Mobile Verbindungen (4G/5G) haben höhere Round-Trip-Zeiten und mehr Varianz als kabelgebundene Verbindungen. Dies erhöht TTFB und LCP Load Delay.
• Viewport-Größe: Kleinere Bildschirme verändern, welches Element zum LCP wird. Ihr Desktop-Hero-Bild kann auf dem Mobilgerät unter einen Textblock schrumpfen und das Optimierungsziel komplett verändern.

CoreDash Gerätetyp-Verteilung

Über CoreDash-Projekte hinweg liegt die typische Traffic-Aufteilung bei 65% Mobile und 35% Desktop. E-Commerce-Seiten tendieren stärker zu Mobile (70-75%), während B2B-SaaS-Produkte oft eine 50/50-Aufteilung oder sogar Desktop-Dominanz aufweisen.

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

Metrik-spezifische Analyse

Largest Contentful Paint (LCP)

Der mobile LCP ist fast immer schlechter als der Desktop-LCP. Die Hauptursache ist Load Delay: Mobile Browser entdecken das LCP-Bild später, weil das HTML länger braucht, um anzukommen (höherer TTFB) und der Preload Scanner auf einer langsameren CPU mit mehr Resource Contention konkurriert. Wenn Ihr Desktop-LCP unter 2,0s liegt, aber der mobile über 3,0s, ist das Problem selten die Bilddatei selbst. Es ist die Delivery-Pipeline.

Interaction to Next Paint (INP)

Hier trifft die Geräte-Lücke am härtesten. JavaScript Event Handler, die sich auf einem Desktop-i7 sofort anfühlen, können den Main Thread auf einem Snapdragon 665 für 300ms+ blockieren. Filtern Sie nach Mobile, sortieren Sie nach INP-Auswirkung, und Sie finden die genauen Interaktionen, die auf echten Telefonen nicht funktionieren. Ich sehe das ständig: Entwickler testen auf MacBook Pros und liefern Interaktionen aus, die auf den Geräten, die 65% ihrer Nutzer tatsächlich bei sich tragen, unbrauchbar sind.

Cumulative Layout Shift (CLS)

CLS-Unterschiede zwischen Gerätetypen lassen sich meist auf Responsive Design zurückführen. Werbeplätze, die auf dem Desktop Platz reservieren, können auf dem Mobilgerät zusammenklappen oder ihre Größe ändern. Font-Fallback-Metriken, die auf dem Desktop passen, verursachen auf kleineren Viewports sichtbare Verschiebungen. Web-Fonts werden auf mobilen und Desktop-Browsern unterschiedlich gerendert, und die physische Pixeldichte beeinflusst die Sub-Pixel-Rundung.

Debugging-Workflow

1. Beginnen Sie jede Untersuchung mit dem Gerätefilter: Bevor Sie sich eine andere Dimension ansehen, teilen Sie nach Gerätetyp auf. Wenn Ihr aggregierter LCP bei 2,5s liegt, finden Sie möglicherweise Desktop bei 1,8s und Mobile bei 3,1s. Das "Problem" ist ausschließlich mobil.
2. Vergleichen Sie Verteilungen, nicht nur p75: Prüfen Sie die gut/verbesserungswürdig/schlecht-Verteilung für jeden Gerätetyp. Ein Desktop mit 85% gut und ein Mobile mit 45% gut erzählt eine völlig andere Geschichte als der p75 allein.
3. Kombinieren Sie mit anderen Dimensionen: Sobald Sie den Gerätetyp isoliert haben, fügen Sie 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 gecacht werden.

Technische Faustregel

• Mobiler LCP unter 2,5s: Dies ist die Schwelle, die Google für "gut" verwendet. Wenn Ihr Desktop besteht, aber Mobile nicht, konzentrieren Sie sich auf die Reduzierung von Load Delay (fetchpriority, preload) und TTFB (Edge-Caching, CDN).
• Mobiler INP unter 200ms: Testen Sie jede interaktive Funktion auf einem echten Android-Mittelklassegerät. Chrome DevTools CPU-Drosselung (4x) nähert dies an, aber echte Gerätetests sind besser.
• Optimieren Sie niemals nur für Desktop: Wenn Ihr mobiler Traffic 50% übersteigt (und das tut er mit ziemlicher Sicherheit), ist die mobile Performance Ihr Suchranking-Signal. Google verwendet mobile CrUX-Daten für das Ranking.

Gerätetyp ist kein Nice-to-have-Filter. Es ist die erste Frage, die Sie stellen: "Ist das ein mobiles Problem oder ein Desktop-Problem?" Jede Optimierungsentscheidung ergibt sich aus dieser Antwort.