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

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

Core Web Vitals sollten Teil eines objektiven Benchmarks für Website-Qualität sein. In der Praxis sind sie es nicht! Die Metriken sind eng mit den Geräten verknüpft, die Benutzer mitbringen. Wenn ein Unternehmen High-End-Produkte oder -Dienstleistungen verkauft, neigen seine Kunden dazu, schnelle Telefone, Desktops und zuverlässige Verbindungen zu besitzen. 
Vergleichen Sie das mit Unternehmen, die auf preisbewusste Käufer oder Schwellenmärkte abzielen. Ihr Publikum verlässt sich auf alternde Telefone, schwache Prozessoren oder schlechte Netzwerkbedingungen. 
Dieselben Website, die einen Test auf einem Flaggschiff-iPhone mit Leichtigkeit besteht, hat Schwierigkeiten, auf einem Mittelklasse-Android oder in Ländern mit geringer Bandbreitenkonnektivität akzeptabel zu laden. Dieser Artikel untersucht, wie man Core Web Vitals für Geräte der unteren Preisklasse optimiert.

Schritt 1: Generieren Sie einen Client Capability Score

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

Die folgende Funktion berechnet den Client Capability Score unter Verwendung von Hardware- und Netzwerkindikatoren, die stark mit realen RUM-Daten und Googles Core Web Vitals 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 und eine reibungslosere Interaktion zu bewältigen.

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 allen. Aber wenn jemand eine langsame Verbindung hat oder ein Gerät mit begrenztem Speicher verwendet, 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 kann sich das ohne viel Aufwand verdoppeln. Deshalb setzen wir die Bildoptimierung für die meisten Benutzer nicht ganz oben auf die Liste, aber wenn man mit Besuchern mit geringer Bandbreite oder eingeschränktem Speicher zu tun hat, wird sie schnell zur Priorität.

Aktivieren Sie http/3 mit QUIC und 0-RTT

• Schnellerer Verbindungsaufbau: QUIC fasst die Transport- und Verschlüsselungs-Handshakes zu einem zusammen. 0-RTT geht noch weiter: Wiederkehrende Besucher senden sofort Daten und umgehen Handshakes vollständig.
• Geringere Latenz für wiederkehrende Benutzer: 0-RTT lässt Clients Sitzungen wiederaufnehmen und Anforderungen ohne Pause senden. Hunderte von Millisekunden gespart – besonders wertvoll für entfernte oder mobile Benutzer.
• Resilient über große Entfernungen: HTTP/3 (über UDP) umgeht TCPs Head-of-Line-Blocking. QUIC handhabt Paketverlust und instabile Netzwerke eleganter – ideal für kontinentübergreifende oder wackelige mobile Verbindungen.

Komprimieren Sie Bilder aggressiver als es Ihrem Designer gefällt

Hochauflösende Bilder blockieren LCP (Largest Contentful Paint), insbesondere auf Geräten mit begrenzter GPU-Dekomprimierungsleistung. Anstatt der Ästhetik nachzugeben, zielen Sie auf kleinere, wahrnehmbar akzeptable Bilder ab. WebP und AVIF helfen, aber Lazy-Loading und das Bereitstellen responsiver Größen sind wichtiger.

Eine saubere Regel: Für Hero-Bilder auf Low-End-Geräten bleiben Sie unter 100KB. Wenn der Designer Einwände erhebt, sollte er dieselbe Website auf einem 100€ Android-Telefon testen, bevor er weiter argumentiert.

Reduzieren Sie CSS auf das absolut Notwendige

Wenn es um Styles geht, gibt es nur eine Regel: Aufräumen. 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 einen kleinen Satz von Utility-Klassen anstelle komplexer komponentenspezifischer Styles. Das hilft sowohl bei der CSSOM-Konstruktion des Browsers als auch bei der Wartbarkeit für Entwickler.

Für Inhalte "Above the Fold" fügen Sie nur das absolut Notwendige inline ein. Laden Sie den Rest lazy, aber halten Sie die Aufteilung minimal und klar. Vermeiden Sie Tools, die raten, was "kritisches CSS" ist, definieren Sie es manuell und chirurgisch.

Seien Sie direkt mit Skripten

• Kein Skript sollte das Rendern blockieren: Stellen Sie sicher, dass alle nicht essentiellen Skripte nicht blockierend sind. Verwenden Sie async- oder defer-Attribute in Ihren <script>-Tags. Wenn ein Skript für das anfängliche Laden der Seite oder die Benutzerinteraktion nicht wesentlich ist, darf es nicht synchron sein. Andernfalls werfen Sie kostbare Millisekunden weg.
•  Planen Sie nicht-kritische Skripte Skripte, die nicht im Voraus benötigt werden, sollten geplant werden. Aber laden Sie sie nicht willkürlich. Verwenden Sie die requestIdleCallback Funktionen, um Skripte auszuführen, wenn der Browser im Leerlauf ist. Dies ermöglicht es Ihnen, schwere Aufgaben auszulagern, ohne kritische Rendering-Pfade zu stören.
• Verwenden Sie den Client Capability Score, um selektiv Nice-to-have-Skripte zu laden:  Der Client Capability Score ist nicht nur eine Metrik, sondern ein Werkzeug zur Optimierung der Benutzererfahrung.  Auf Low-End-Geräten reduzieren Sie die Anzahl der geladenen Skripte und wählen leichtere Alternativen. Wenn der Benutzer begrenzten Speicher oder eine ältere CPU hat, verschwenden Sie keine Ressourcen durch das Laden ressourcenintensiver Skripte. Priorisieren Sie Leistung gegenüber Vanity-Features, die auf High-End-Geräten beeindrucken, aber auf Low-End-Geräten frustrieren könnten.

Verwenden Sie Systemschriftarten oder vermeiden Sie zumindest schwere benutzerdefinierte Schriftarten

Das Laden benutzerdefinierter Schriftarten fügt Latenz hinzu und stört das Layout. Auf Geräten mit begrenztem Speicher können sie auch unnötig den RAM-Druck erhöhen.

Systemschriftarten rendern schneller, respektieren Benutzereinstellungen und reduzieren Layoutverschiebungen. Wenn das Branding eine benutzerdefinierte Typografie vorschreibt, subsetten Sie aggressiv und laden Sie Schriftarten spät.

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

Schließlich simulieren synthetische Testtools (wie Lighthouse, WebPageTest usw.) Drosselung, ahmen aber nicht alle Eigenheiten von Low-End-Hardware nach: Thermik, Drosselung unter realer Last, Garbage-Collection-Pausen und Speicherengpässe.

Kaufen Sie ein billiges Android-Telefon und surfen Sie auf Ihrer Website. Wenn Sie das nicht regelmäßig tun können, verwenden Sie ein RUM-Tool wie Coredash und segmentieren Sie Daten nach Geräteklasse. Wenn Ihr P75 LCP auf dem iPhone 15 in Ordnung ist, aber auf dem Xiaomi Redmi 9 schrecklich, ist es an der Zeit, ehrlich darüber zu sein, für wen Sie optimieren.