Fast jede Entscheidung über das Tempo einer Website fällt auf einem Gerät, das kein Kunde besitzt. Das Team arbeitet an einem schnellen Rechner mit kurzem Weg zum Server, die Abnahme läuft auf demselben Rechner, und der Bericht sieht ordentlich aus. Im Feld entsteht ein anderes Bild: Über alle Websites hinweg bestehen mobil 48 Prozent (Web Almanac 2025) die Core Web Vitals, auf dem Desktop sind es 56 Prozent (Web Almanac 2025). Acht Prozentpunkte Abstand klingen überschaubar, verteilen sich aber sehr ungleich auf die drei Kennzahlen – bei der Interaktivität wird daraus ein Graben. Dieser Beitrag ordnet ein, warum das Testgerät die falsche Messlatte ist, welches Referenzgerät das 75. Perzentil tatsächlich trifft, was die eingebaute Drosselung leistet und was sie nicht leisten kann, und wie aus beidem ein Budget wird, an dem sich die Arbeit ausrichten lässt. Wo die Zeit auf schwacher Hardware bleibt, zeigt eine technische Performance-Analyse, die Feld- und Labordaten nebeneinanderlegt.
Das Wichtigste in Kürze
- Das Entwicklergerät ist als Messlatte ungeeignet, weil eine Labormessung bauartbedingt ein einzelnes Gerät an einem einzelnen Netz an einem einzelnen Ort abbildet (web.dev). In Deutschland kommen dagegen 50,89 Prozent (Statcounter Global Stats) der Seitenaufrufe vom Telefon.
- Der Geräteabstand ist bei der Interaktivität am größten: 97 Prozent (Web Almanac 2025) der Seiten haben auf dem Desktop gutes INP, auf dem Telefon 77 Prozent (Web Almanac 2025) – 20 Prozentpunkte (Web Almanac 2025) Abstand.
- Das Referenzgerät ist ein Mittelklassetelefon, kein Flaggschiff: Einstiegsgeräte rechnen einkernig rund neunmal (Performance Inequality Gap) langsamer als ein aktuelles Spitzentelefon, Mittelklassegeräte mehr als 3,5-mal (Performance Inequality Gap) langsamer.
- Die Drosselung der Standardmessung ist ein fester Faktor, kein Gerätemodell: Der Multiplikator liegt bei 4x (Lighthouse) und wirkt relativ zur Leistung des Messrechners (Chrome for Developers) – dieselbe Konfiguration ergibt auf zwei Rechnern zwei verschiedene Zielgeräte.
- Die Feldstatistik kennt nur drei Geräteklassen (Chrome for Developers) aus der Browserkennung, und die Signale im Browser sind bewusst grob: Der gemeldete Arbeitsspeicher wird auf die nächste Zweierpotenz gerundet (MDN Web Docs).
- Daraus folgt ein hartes Budget: 1,2 MiB (Performance Inequality Gap) kritischer Pfad beim Drei-Sekunden-Ziel, davon 0,62 MiB (Performance Inequality Gap) JavaScript. Die mediane mobile Startseite liefert 632 KB (Web Almanac 2025) JavaScript aus.
Warum das Entwicklergerät die falsche Messlatte ist
Eine Labormessung ist ihrer Bauart nach ein einziger Punkt aus einer Verteilung. Die Chrome-Dokumentation beschreibt das ohne Umschweife: Ein Labortest besteht aus einem einzelnen Gerät, verbunden mit einem einzelnen Netz, ausgeführt von einem einzelnen geografischen Ort (web.dev). Das ist kein Mangel, sondern der Zweck – nur so bleiben zwei Läufe überhaupt vergleichbar. Zum Problem wird es erst, wenn dieser eine Punkt für die ganze Verteilung genommen wird und die Auswahl des Punktes niemand begründet. In Deutschland entfallen 50,89 Prozent (Statcounter Global Stats) der Seitenaufrufe auf das Telefon und 47,38 Prozent (Statcounter Global Stats) auf den Desktop; das Zielgerät ist im Zweifel also kein Rechner mit Netzteil. Wie sich Labor- und Feldwerte sinnvoll nebeneinanderlegen lassen, ohne dass am Ende zwei Wahrheiten im Raum stehen, ordnet der Beitrag zu Felddaten und Laborwerten im Vergleich ein.
Wie weit die Geräteklassen auseinanderliegen, zeigt am deutlichsten die Zeit, in der der Hauptthread blockiert ist. Im Labor des HTTP Archive, das mobil ein einheitlich emuliertes Gerät verwendet, liegt die mediane Blockadezeit bei 1.916 Millisekunden (Web Almanac 2025) gegenüber 92 Millisekunden (Web Almanac 2025) auf dem Desktop. Das ist bei identischer Seite mehr als das Zwanzigfache. Am oberen Rand der Verteilung wird der Abstand noch deutlicher: 7.555 Millisekunden (Web Almanac 2025) mobil gegen 802 Millisekunden (Web Almanac 2025) auf dem Desktop im 90. Perzentil. Dieselbe Menge JavaScript, dieselben Abhängigkeiten, dieselbe Reihenfolge – nur eine andere Recheneinheit darunter. Wer diese Blockade in kleinere Abschnitte zerlegen will, findet das Handwerkszeug im Beitrag zum Aufteilen langer Aufgaben.
Ein Messwert ist ein Punkt, keine Verteilung
Was die Felddaten über den Geräteabstand sagen
Der Abstand zwischen Telefon und Desktop zeigt in den drei Core Web Vitals nicht in dieselbe Richtung, und das ist der erste Befund, der die Diskussion versachlicht. Beim Ladeverhalten liegt der Desktop vorn: 74 Prozent (Web Almanac 2025) gute LCP-Werte gegen 62 Prozent (Web Almanac 2025) mobil. Bei der Layoutstabilität dreht sich das Bild, hier erreichen 81 Prozent (Web Almanac 2025) der mobilen und 72 Prozent (Web Almanac 2025) der Desktop-Seiten einen guten CLS-Wert – schmale Ansichten mit wenigen Spalten verrutschen schlicht seltener. Wer die Ursachen für springende Layouts sucht, findet sie im Beitrag zum Vermeiden von Layoutsprüngen. Die Geräteklasse ist also kein pauschaler Malus, sondern wirkt dort, wo Rechenzeit gebraucht wird.
Genau deshalb ist die Interaktivität die Kennzahl, an der sich schwache Hardware am schärfsten zeigt. Auf dem Desktop haben 97 Prozent (Web Almanac 2025) der Websites ein gutes INP, auf dem Telefon 77 Prozent (Web Almanac 2025). Der Abstand von 20 Prozentpunkten (Web Almanac 2025) ist der größte der drei Kennzahlen und schließt sich nur langsam. INP misst die Zeit von der Eingabe bis zum nächsten Bildaufbau, und diese Zeit setzt sich aus Skriptausführung, Stilberechnung und Layout zusammen – alles Arbeit, die auf der CPU des Besuchers anfällt und nicht auf dem Server. Welche Eingriffe dort tatsächlich wirken, beschreibt der Beitrag zum Verbessern von Interaction to Next Paint.
| Kennzahl | Desktop | Telefon | Woran das liegt |
|---|---|---|---|
| Gute Core Web Vitals insgesamt | 56 % | 48 % | Summe aus Netz und Rechenleistung |
| Guter LCP | 74 % | 62 % | schmaleres Netz, langsamere Dekodierung |
| Schlechter LCP | 7 % | 13 % | der ungünstige Rand wächst mobil doppelt so stark |
| Gutes INP | 97 % | 77 % | Skriptarbeit hängt an der Einkernleistung |
| Guter CLS | 72 % | 81 % | schmale Ansichten verrutschen seltener |
Noch aufschlussreicher wird es, wenn man die mobilen Zahlen nach Seitentyp und Bekanntheit aufteilt. Mobile Startseiten erreichen 80 Prozent (Web Almanac 2025) gutes INP, Unterseiten dagegen nur 69 Prozent (Web Almanac 2025) – also gerade die Seiten mit Filtern, Sortierungen, Formularen und Warenkorb. Und bei den tausend meistbesuchten Websites fällt der Wert auf 63 Prozent (Web Almanac 2025), weil dort am meisten Code ausgeführt wird. Bekanntheit und Budget schützen also nicht vor dem Geräteabstand, sie vergrößern ihn eher. Für die Messplanung heißt das: Nicht die Startseite auf dem schnellen Gerät ist der Prüfstein, sondern die Interaktionsseite auf dem langsamen. Wie eine solche Priorisierung aussieht, zeigt der Beitrag zum Lesen und Priorisieren eines Lighthouse-Berichts.
Das Referenzgerät ist nicht das schnellste im Team
Wenn Skriptarbeit der Engpass ist, dann ist die Einkernleistung des Zielgeräts die Kennzahl, an der alles hängt. Die Auswertung der weltweiten Geräteverteilung formuliert das als harte Obergrenze: Das Tempo JavaScript-getriebener Erfahrungen hängt stark an der Einkernleistung, und damit setzt das Gerät im 75. Perzentil eine feste Grenze für die Menge an JavaScript, auf die sich eine Website stützen darf (Performance Inequality Gap). Die Spanne dahinter ist beträchtlich: Einstiegsgeräte rechnen einkernig rund neunmal (Performance Inequality Gap) langsamer als ein aktuelles Spitzentelefon, Geräte der Mittelklasse mehr als 3,5-mal (Performance Inequality Gap) langsamer. Wer auf einem Flaggschiff misst, misst also nicht ein bisschen zu gut, sondern eine Größenordnung daneben.
Ein typisches Gerät, kein Ausreißer
Das empfohlene Referenzgerät ist ein Mittelklasse-Android aus dem Jahr 2023. Es kostete beim Marktstart 250 USD (Performance Inequality Gap) und lag damit unter dem weltweiten Durchschnittsverkaufspreis von 353 USD (Performance Inequality Gap). Der Punkt ist nicht Sparsamkeit, sondern Repräsentativität: Ein Viertel aller Geräte und Netze liegt unterhalb dieser Marke.
Der Bestand altert langsamer als das Testlager
Telefone bleiben länger im Einsatz. Die jährliche Austauschrate wird auf 23,7 Prozent (TechInsights) geschätzt, und Geräte im 75. Perzentil sind demnach fast drei Jahre alt. Ein Testgerät, das jedes Jahr ersetzt wird, entfernt sich also mit jedem Jahr weiter vom Bestand der Besucher.
Die Netzschere geht weiter auf
Der Abstand zwischen dem 25. und dem 75. Perzentil der Anbindung wuchs von 15 auf 21 Mbit/s (Performance Inequality Gap), ein Zuwachs von 40 Prozent (Performance Inequality Gap). Das untere Viertel legte im selben Zeitraum nur um 28 Prozent (Performance Inequality Gap) zu. Wer auf der eigenen Leitung misst, misst den falschen Rand.
Zum Referenzgerät gehört ein Referenznetz, sonst bleibt die Hälfte der Verzögerung unsichtbar. Für 2026 wird das 75. Perzentil der Anbindung mit 9 Mbit/s (Performance Inequality Gap) im Download, 3 Mbit/s (Performance Inequality Gap) im Upload und 100 Millisekunden (Performance Inequality Gap) Umlaufzeit angegeben, abgeleitet aus weltweiten Netzmessdaten ohne Bevölkerungsgewichtung. Diese Zahlen sind unbequem, weil sie im Widerspruch zum Alltagsgefühl im Büro stehen. Sie erklären aber, warum dieselbe Seite in der Auswertung des Feldes anders dasteht als im Bericht der letzten Abnahme. Wer beides zusammenbringen will, braucht ein festes Messprofil und keine Tagesform – eine Herangehensweise, die der Beitrag zum Verankern von Performance-Zielen in Ausschreibung und Abnahme für Verträge durchdekliniert.
Der Kern in einem Satz
Drosselung ist ein Faktor, kein Gerätemodell
Die naheliegende Antwort auf schwache Hardware ist die eingebaute Drosselung, und sie ist ein guter erster Schritt – solange man weiß, was sie tut. Das Standardprofil der verbreiteten Mobilmessung drosselt das Netz auf 150 Millisekunden (Lighthouse) Latenz, 1,6 Mbit/s (Lighthouse) im Download und 750 kbit/s (Lighthouse) im Upload, ohne Paketverlust. Die Rechenleistung wird mit einem konstanten Faktor von 4x (Lighthouse) gebremst, der einen typischen Lauf aus dem Bereich starker Desktop-Rechner ungefähr in den Bereich der mobilen Mittelklasse verschiebt. Das ist eine Näherung mit klarer Absicht, und sie ist ausdrücklich als solche dokumentiert.
Der Haken steckt im Wort konstant. Die Drosselung wirkt relativ zur Leistung des Rechners, auf dem gemessen wird: Der Faktor 2x macht die CPU doppelt so langsam wie ihre gewöhnliche Leistung, und die Architektur mobiler Geräte lässt sich damit nicht wirklich nachbilden (Chrome for Developers). Zwei Rechner mit demselben Faktor ergeben also zwei verschiedene Zielgeräte. Wie groß die Spanne ist, zeigt der Rechenleistungsindex derselben Dokumentation: Starke Desktop-Rechner liegen bei 1500 bis 2000 (Lighthouse) Punkten, Mittelklassetelefone bei 125 bis 800 (Lighthouse). Für dieselbe Nachrichtenseite bedeutet das 2 bis 4 Sekunden (Lighthouse) Skriptausführung oben und 20 bis 40 Sekunden (Lighthouse) am unteren Rand.
{
"//": "Zwei Profile nebeneinander -- Standard und Referenznetz.",
"//": "Der CPU-Faktor wird je Messrechner kalibriert, nicht kopiert.",
"standard": {
"rttMs": 150,
"throughputKbps": 1638,
"uploadThroughputKbps": 750,
"cpuSlowdownMultiplier": 4
},
"referenznetz_p75": {
"rttMs": 100,
"throughputKbps": 9000,
"uploadThroughputKbps": 3000,
"cpuSlowdownMultiplier": null,
"hinweis": "Faktor aus dem Benchmark des Laufrechners bestimmen"
}
}Was die Drosselung nicht abbildet
Was die Feldstatistik über Geräte wirklich weiß
Wer die Geräteklasse aus den Felddaten ablesen will, stößt schnell an eine Grenze. Die öffentliche Feldstatistik unterscheidet drei Geräteklassen (Chrome for Developers) – Telefon, Tablet und Desktop – und leitet sie aus der Browserkennung ab (Chrome for Developers). Über die Rechenleistung sagt das nichts: Ein Spitzentelefon und ein fünf Jahre altes Einstiegsgerät landen im selben Topf. Immerhin ist die Bewertungslogik selbst geräteklassenbewusst: Die Schwelle für gutes INP liegt bei 200 Millisekunden (web.dev), gemessen am 75. Perzentil (web.dev) der Seitenaufrufe und ausdrücklich getrennt nach mobilen und Desktop-Geräten. Genau diese Trennung ist der Grund, warum ein Mittelwert über alle Geräte selten eine brauchbare Grundlage ist.
Im Browser selbst stehen zwei Signale bereit, und beide sind mit Bedacht ungenau. Der gemeldete Arbeitsspeicher ist absichtlich unscharf, um Wiedererkennung zu erschweren: Der tatsächliche Wert wird auf die nächste Zweierpotenz gerundet und anschließend durch 1024 geteilt (MDN Web Docs). Die Kernzahl trägt eine ähnliche Einschränkung – der Browser darf eine niedrigere Zahl logischer Kerne melden, um besser abzubilden, wie viele Arbeiter gleichzeitig laufen können, und der Wert taugt darum nicht als absolutes Maß (MDN Web Docs). Als Signal für eine grobe Klassenbildung in der eigenen Feldmessung reichen beide trotzdem, solange man sie als Eimer behandelt und nicht als Messwert.
// Grobe Klassenbildung fuer die eigene Feldmessung.
// Beide Signale sind absichtlich unscharf -- deshalb Eimer, keine Zahlen.
function geraeteklasse() {
const kerne = navigator.hardwareConcurrency || 0; // darf niedriger sein
const speicher = navigator.deviceMemory || 0; // auf 2er-Potenz gerundet
if (!kerne && !speicher) return 'unbekannt'; // nicht raten
if (speicher && speicher <= 2) return 'schwach';
if (kerne && kerne <= 4 && speicher <= 4) return 'schwach';
if (kerne <= 6 || speicher <= 4) return 'mittel';
return 'stark';
}
// Klasse an jede Messung haengen, sonst mittelt der Bericht sie weg.
new PerformanceObserver((liste) => {
for (const eintrag of liste.getEntries()) {
navigator.sendBeacon('/messwerte/', JSON.stringify({
metrik: 'inp',
wert: Math.round(eintrag.duration),
klasse: geraeteklasse(),
seitentyp: document.body.dataset.seitentyp
}));
}
}).observe({ type: 'event', durationThreshold: 40, buffered: true });Vom Referenzgerät zum belastbaren Budget
Referenzgerät und Referenznetz sind erst dann nützlich, wenn eine Zahl daraus wird, gegen die sich ein Entwurf prüfen lässt. Rechnet man beides in ein Budget um, bleiben für ein Drei-Sekunden-Ziel auf dem kritischen Pfad 1,2 MiB (Performance Inequality Gap) übrig, davon 0,62 MiB (Performance Inequality Gap) JavaScript, wenn die Seite zur Hälfte aus Skript besteht. Dem steht die Wirklichkeit gegenüber: Mobile JavaScript-Auslieferungen erreichen 680 KiB (Performance Inequality Gap) im Median und 1,3 MiB (Performance Inequality Gap) im 75. Perzentil. Die mediane mobile Startseite liefert 632 KB (Web Almanac 2025) JavaScript aus – nach Bildern der zweitgrößte Posten und der einzige, der auf schwacher Hardware zusätzlich Rechenzeit kostet. Wie sich daraus konkrete Schranken je Seitentyp ableiten lassen, beschreibt der Beitrag zu JavaScript und Performance-Budgets.
- Zielgerät benennen und aufschreiben: eine Geräteklasse, ein Netzprofil, ein Perzentil. Ohne diese drei Angaben ist jede spätere Diskussion über Messwerte eine Diskussion über Ausstattung.
- Ein echtes Gerät der Zielklasse beschaffen und im Schrank behalten. Es ersetzt die gedrosselte Messung nicht, aber es deckt auf, was ein konstanter Faktor nicht abbildet.
- Den Drosselungsfaktor je Messrechner kalibrieren statt kopieren – der Faktor wirkt relativ zur vorhandenen Rechenleistung (Chrome for Developers) und wandert mit jeder neuen Maschine im Bauprozess.
- Die eigene Feldmessung um eine grobe Geräteklasse ergänzen und Kennzahlen je Klasse getrennt auswerten. Ein Mittelwert über alle Geräte verdeckt genau den Rand, um den es geht.
- Nicht die Startseite als Prüfstein nehmen, sondern die Interaktionsseite: Unterseiten liegen mobil bei 69 Prozent (Web Almanac 2025) gutem INP gegenüber 80 Prozent (Web Almanac 2025) bei Startseiten.
- Das Budget als Schranke in den Bauprozess legen und jede Abweichung sichtbar machen, statt sie in der nächsten Abnahme zu entdecken. Wie eine risikoarme Erprobung neuer Varianten dabei aussieht, zeigt der Beitrag zu A/B-Tests ohne Flimmern.
Dass Gewicht und Bestehensquote zusammenhängen, lässt sich im Feld direkt ablesen: Von den mobilen Startseiten unter einem Megabyte bestehen 57 Prozent (Web Almanac 2025) die Core Web Vitals, ab fünf Megabyte sind es noch 30 Prozent (Web Almanac 2025). Die Quote fällt mit jeder Gewichtsklasse, und mobil liegt sie in jeder einzelnen Klasse unter dem Desktop-Wert. Das ist der eigentliche Grund, warum ein Budget mehr bewirkt als eine Liste von Einzeloptimierungen: Es begrenzt die Ursache, statt Symptome nachträglich zu behandeln. Wer die Auslieferung zusätzlich an das Netz des Besuchers anpassen will, findet die Bausteine im Beitrag zum adaptiven Laden auf langsamen Verbindungen.
Die unbequeme Frage in jedem Performance-Gespräch ist nicht, wie schnell die Seite auf dem Rechner des Teams lädt. Sie lautet: Auf welchem Gerät soll sie noch gut sein – und wer hat entschieden, dass es dieses ist?
Zielgerät statt Testgerät ist damit weniger eine technische als eine organisatorische Festlegung. Die Technik dahinter ist überschaubar: ein benanntes Gerät, ein benanntes Netz, ein kalibrierter Faktor, eine Klasseneinteilung in der eigenen Feldmessung und ein Budget, das aus beidem folgt. Schwierig ist der Beschluss, sich an dieser Latte messen zu lassen, obwohl das eigene Gerät bessere Werte liefert. Wer ihn fasst, bekommt dafür Zahlen, die im Feld halten, was sie im Bericht versprechen. Welche Kennzahlen dabei zählen und wie sie zusammenspielen, ordnet unsere Seite zu den Core Web Vitals ein; wo bei Ihrer Website die Rechenzeit auf schwacher Hardware bleibt, klärt eine Analyse mit Feld- und Labordaten gemeinsam mit unserer Frontend-Optimierung.
Quellen und Studien
Verwandte Artikel
fetchLater: Messdaten senden, ohne Tempo zu kosten
Abschiedsereignisse liefern den letzten Messwert mobil häufig nicht aus. Wie fetchLater() das löst, welches Kontingent gilt und wie der Rückfallweg aussieht.
Soft Navigations: Core Web Vitals in SPAs messen
Single-Page-Apps melden nur den ersten Load an CrUX. Wie die Soft-Navigations-API ab Chrome 151 Route-Wechsel misst und LCP, INP und CLS je Route trennt.
Style-Recalculation: wenn CSS erst im Browser bremst
Warum Stilberechnung zur Laufzeit Zeit kostet, wie Selector Stats und Long Animation Frames den Anteil sichtbar machen und welche Eingriffe den Umfang senken.