Core Web Vitals für Low-End-Geräte optimieren

Core Web Vitals für Low-End-Geräte optimieren

Core Web Vitals sollten Teil eines objektiven Benchmarks für die Qualität einer Website sein. In der Praxis sind sie das nicht! Die Metriken sind eng an die Geräte gekoppelt, die die Nutzer mitbringen. Wenn ein Unternehmen High-End-Produkte oder -Dienstleistungen verkauft, besitzen seine Kunden in der Regel schnelle Smartphones, Desktops und zuverlässige Verbindungen.
Vergleichen Sie das mit Unternehmen, die preisbewusste Käufer oder aufstrebende Märkte ansprechen. Deren Zielgruppen sind auf alternde Smartphones, schwache Prozessoren oder schlechte Netzwerkbedingungen angewiesen.
Dieselbe Website, die einen Test auf einem Flaggschiff-iPhone mühelos besteht, hat Mühe, auf einem Mittelklasse-Android-Gerät oder in Ländern mit geringer Bandbreite akzeptabel zu laden.

Zuletzt überprüft von Arjen Karel im März 2026

Die Zahlen sprechen für sich

Laut dem 2025 Web Almanac bestehen nur 48 % der mobilen Origins die Core Web Vitals, verglichen mit 56 % auf dem Desktop. Die größte Lücke besteht bei INP: 97 % der Desktop-Origins bestehen, aber nur 77 % auf Mobilgeräten. Diese Lücke von 20 Prozentpunkten wird fast ausschließlich durch langsamere CPUs auf Android-Geräten verursacht.

Die mediane mobile Total Blocking Time beträgt 1.916 Millisekunden. Auf dem Desktop? 92 Millisekunden. Das ist ein Verhältnis von 20:1. Wenn Ihre Skripte auf Ihrem MacBook problemlos laufen, tun sie das auf einem Budget-Smartphone absolut nicht.

Laut Alex Russells Forschung sind etwa 30 % der im Umlauf befindlichen Geräte Low-End (4 Kerne oder weniger, 4 GB RAM oder weniger). Diese Geräte haben eine Single-Core-Leistung, die bis zu 9-mal langsamer ist als ein aktuelles iPhone. In den Real User Monitoring-Daten von CoreDash sehen wir, dass für Low-End-Geräte optimierte Websites die Core Web Vitals bei 62 % der mobilen Seitenaufrufe bestehen, verglichen mit nur 41 % bei Websites, die nur auf High-End-Hardware testen.

Schritt 1: Generieren Sie einen Client Capability Score

Um zu beurteilen, ob ein Besucher ein High-End- oder Low-End-Gerät verwendet, kann direkt im Browser ein Client Capability Score berechnet werden. Dieser Wert reicht von 0 (extrem eingeschränkt) bis 100 (Top-Tier-Hardware). In der Praxis sollte jedes Gerät mit einem Wert unter 40 als schlecht eingestuft werden.

Die folgende Funktion berechnet den Client Capability Score anhand von Hardware- und Netzwerk-Indikatoren, die stark mit echten RUM- und Googles Core Web Vitals-Daten korrelieren. Ein höherer Score zeigt an, dass das Gerät besser in der Lage ist, eine schnelle Seitenleistung mit weniger Ressourcenbeschränkungen zu liefern.

function getClientCapabilityScore() {
  const mem = navigator.deviceMemory || 4;
  let cpu = navigator.hardwareConcurrency || 4;
  cpu = Math.min(cpu, 8);

  let net = 4;
  if (navigator.connection) {
    const { effectiveType, rtt = 300 } = navigator.connection;
    const map = { 'slow-2g': 1, '2g': 2, '3g': 3, '4g': 4, '5g': 5 };
    net = map[effectiveType] || 4;
    if (rtt > 500) net = Math.max(net - 3, 1);
    else if (rtt > 300) net = Math.max(net - 2, 1);
    else if (rtt < 150) net = Math.min(net + 1, 5);
  }

  const score = mem + cpu * 0.5 + net * 2;
  return Math.min(100, Math.round(score * 5));
}

getClientCapabilityScore();

Core Web Vitals Tipp: Diese Optimierungen helfen jedem. Aber wenn jemand über eine langsame Verbindung verfügt oder ein Gerät mit begrenztem Speicher nutzt, sind sie viel wichtiger. Die Nachteile, sie zu überspringen, zeigen sich schneller.
Nehmen Sie Bild-Downloads. Bei einer normalen Verbindung machen sie normalerweise etwa 10 % der Largest Contentful Paint-Zeit aus. Bei einer langsamen Verbindung kann sich das ohne großen Aufwand verdoppeln. Deshalb setzen wir die Bildoptimierung für die meisten Benutzer nicht ganz oben auf die Liste, aber wenn es um Besucher mit geringer Bandbreite oder begrenztem Speicher geht, wird sie schnell zur Priorität.

Aktivieren Sie HTTP/3 mit QUIC und 0-RTT

Besucher, die weit von Ihren Servern entfernt sind oder auf langsamen Netzwerken festsitzen, haben hohe Round-Trip-Zeiten (RTT). HTTP/3 verbessert zusammen mit QUIC und 0-RTT direkt Ihre anfängliche Verbindungsgeschwindigkeit. Dies ist eine wichtige Optimierung für alle Besucher, aber besonders kritisch für Besucher mit geringer Bandbreite. Laut Cloudflare Radar wickelt HTTP/3 mittlerweile 21 % des weltweiten Web-Traffics ab. Wenn Sie Cloudflare nutzen, können Sie HTTP/3 im Cloudflare-Dashboard aktivieren.

• Schnellerer Verbindungsaufbau: QUIC fasst die Transport- und Verschlüsselungs-Handshakes zu einem zusammen. 0-RTT geht noch weiter: Wiederkehrende Besucher senden Daten sofort und überspringen Handshakes komplett.
• Geringere Latenz für wiederkehrende Nutzer: 0-RTT ermöglicht es Clients, Sitzungen fortzusetzen und Anfragen ohne Pause zu senden. Hunderte von Millisekunden werden gespart, was besonders für weit entfernte oder mobile Nutzer wertvoll ist.
• Belastbar über große Entfernungen: HTTP/3 (über UDP) umgeht das Head-of-Line-Blocking von TCP. QUIC geht eleganter mit Paketverlusten und instabilen Netzwerken um. Das macht bei kontinentübergreifenden oder wackeligen mobilen Verbindungen einen echten Unterschied.

Komprimieren Sie Bilder aggressiver, als es Ihrem Designer lieb ist

Hochauflösende Bilder verzögern LCP, insbesondere auf Geräten mit begrenzter GPU-Dekomprimierungsleistung. Der 2025 Web Almanac zeigt, dass die mediane mobile Startseite 911 KB an Bildern lädt. Das sind 42 % des gesamten Seitengewichts. Auf einem Budget-Gerät mit einem P75-Downlink von 9 Mbit/s konkurrieren diese Bilder direkt mit Ihren kritischen Ressourcen.

Anstatt der Ästhetik nachzugeben, sollten Sie kleinere, visuell noch akzeptable Bilder anstreben. WebP und AVIF helfen, aber Lazy-Loading und die Bereitstellung von responsiven Größen sind wichtiger.

Eine saubere Regel: Bleiben Sie bei Hero-Bildern auf Low-End-Geräten unter 100 KB. Wenn der Designer widerspricht, sollte er dieselbe Website auf einem 100-€-Android-Smartphone testen, bevor er weiter diskutiert.

Reduzieren Sie CSS auf das absolut Notwendige

Wenn es um Styles geht, gibt es nur eine Regel: Ausmisten. Entfernen Sie ungenutzte Selektoren, reduzieren Sie die Spezifität und fassen Sie redundante Regeln zusammen.

Konzentrieren Sie sich auf vorhersehbare, konsistente Layouts mit minimalen Überschreibungen. Verwenden Sie eine kleine Auswahl an Utility-Klassen anstelle von komplexen, komponentenspezifischen Styles. Das hilft sowohl der CSSOM-Konstruktion des Browsers als auch der Wartbarkeit für Entwickler.

Inlinen Sie für Above-the-Fold-Inhalte nur das, was absolut notwendig ist. Laden Sie den Rest per Lazy-Loading, aber halten Sie die Aufteilung minimal und klar. Sie können den Critical CSS Generator als Ausgangspunkt verwenden, aber definieren Sie Ihr Critical CSS für das beste Ergebnis manuell und chirurgisch präzise.

Seien Sie radikal bei Skripten

Mit einer medianen mobilen TBT von 1.916 ms (laut dem 2025 Web Almanac im Jahresvergleich um 58 % gestiegen) ist JavaScript das mit Abstand größte Problem auf Low-End-Geräten. Die P75-Netzwerkgeschwindigkeit für Budget-Geräte beträgt etwa 9 Mbit/s im Download bei 100 ms RTT. Jedes Kilobyte JavaScript, das Sie ausliefern, wird auf einer CPU geparst und ausgeführt, die 9-mal langsamer ist als das Smartphone, auf dem Sie testen.

• Kein Skript sollte das Rendering blockieren: Stellen Sie sicher, dass alle nicht essenziellen Skripte nicht-blockierend sind. Verwenden Sie async- oder defer-Attribute in Ihren <script>-Tags. Wenn ein Skript nicht für das initiale Laden der Seite oder die Benutzerinteraktion essenziell ist, darf es nicht synchron sein. Für einen vollständigen Überblick über Defer-Techniken siehe 16 Methoden zur Verzögerung von JavaScript.
• Planen Sie nicht-kritische Skripte: Skripte, die nicht sofort benötigt werden, sollten eingeplant werden. Verwenden Sie requestIdleCallback, um Skripte auszuführen, wenn der Browser im Leerlauf ist. Dadurch können Sie schwere Aufgaben auslagern, ohne kritische Rendering-Pfade zu stören.
• Nutzen Sie den Client Capability Score zum selektiven Laden von Skripten: Verwenden Sie den Score, um zu entscheiden, was geladen werden soll. Reduzieren Sie auf Low-End-Geräten die Anzahl der Skripte und wählen Sie leichtere Alternativen. Wenn der Nutzer über begrenzten Speicher oder eine ältere CPU verfügt, verschwenden Sie keine Ressourcen mit dem Laden schwerer Skripte. Priorisieren Sie die Performance gegenüber rein optischen Features, die vielleicht auf High-End-Geräten beeindrucken, aber auf Low-End-Geräten frustrieren.

Verwenden Sie Systemschriftarten oder vermeiden Sie zumindest schwere benutzerdefinierte Schriftarten

Das Laden benutzerdefinierter Schriftarten erhöht die Latenz und stört das Layout. Auf Geräten mit begrenztem Speicher können sie zudem unnötig den RAM-Druck erhöhen. Laut dem 2025 Web Almanac laden 88 % der Websites mindestens einen Webfont, aber nur 12 % laden diese per Preload vor. Die beste Option für die Performance, font-display: optional, wird von nur 0,4 % der Websites genutzt.

Systemschriftarten rendern schneller, respektieren die Nutzereinstellungen und reduzieren Layout Shift. Wenn das Branding eine benutzerdefinierte Typografie vorschreibt, nutzen Sie aggressives Subsetting und laden Sie Schriftarten spät. Ziehen Sie in Betracht, Ihre Schriftarten selbst zu hosten, damit Sie die Auslieferung kontrollieren können.

Überwachen Sie mit echter Hardware, nicht nur mit synthetischen Tests

Synthetische Test-Tools (wie Lighthouse, WebPageTest usw.) simulieren Drosselung, bilden aber nicht alle Eigenheiten von Low-End-Hardware ab: Temperaturentwicklung, Drosselung unter realer Last, Garbage-Collection-Pausen und Speicherengpässe. Beachten Sie, dass PageSpeed Insights seine CPU-Drosselung im Dezember 2024 von 4x auf 1,2x geändert hat, was Labor-Scores noch weniger repräsentativ für die tatsächliche Leistung von Budget-Geräten macht.

Kaufen Sie ein günstiges Android-Smartphone und surfen Sie auf Ihrer Website. Wenn Sie sich nicht überwinden können, das regelmäßig zu tun, verwenden Sie ein RUM-Tool wie CoreDash und segmentieren Sie die Daten nach Geräteklasse. Wenn Ihr P75-LCP auf dem iPhone 15 gut, auf dem Xiaomi Redmi 9 aber schrecklich ist, wird es Zeit, ehrlich zu sein, für wen Sie optimieren.