Optymalizuj Core Web Vitals dla urządzeń niskiej klasy

Optymalizuj Core Web Vitals dla urządzeń niskiej klasy

Core Web Vitals powinny być częścią obiektywnego benchmarku jakości witryny. W praktyce tak nie jest! Metryki są ściśle powiązane z urządzeniami, z których korzystają użytkownicy. Jeśli firma sprzedaje wysokiej klasy produkty lub usługi, jej klienci mają tendencję do posiadania szybkich telefonów, komputerów stacjonarnych i niezawodnych połączeń. 
Porównaj to z firmami, które celują w klientów dbających o koszty lub rynki wschodzące. Ich odbiorcy polegają na przestarzałych telefonach, słabych procesorach lub złych warunkach sieciowych. 
Ta sama witryna, która bez problemu przechodzi test na flagowym iPhone, ma trudności z załadowaniem się w akceptowalny sposób na średniej klasy Androidzie lub w krajach o niskiej przepustowości połączenia. Ten artykuł analizuje, jak optymalizować Core Web Vitals dla urządzeń niższej klasy.

Krok 1: Wygeneruj wynik możliwości klienta

Aby ocenić, czy odwiedzający korzysta z urządzenia wysokiej czy niskiej klasy, można obliczyć wynik możliwości klienta bezpośrednio w przeglądarce. Ten wynik waha się od 0 (ekstremalnie ograniczony) do 100 (sprzęt najwyższej klasy). W praktyce każde urządzenie z wynikiem poniżej 40 powinno być sklasyfikowane jako słabe.

Poniższa funkcja oblicza wynik możliwości klienta przy użyciu wskaźników sprzętowych i sieciowych, które silnie korelują z rzeczywistymi danymi RUM i Core Web Vitals Google. Wyższy wynik wskazuje, że urządzenie jest bardziej zdolne do zapewnienia szybkiej wydajności strony przy mniejszych ograniczeniach zasobów i może obsłużyć płynniejszą interakcję.

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();

Wskazówka Core Web Vitals: Te optymalizacje pomagają wszystkim. Ale jeśli ktoś korzysta z wolnego połączenia lub używa urządzenia o ograniczonej pamięci, mają one znacznie większe znaczenie. Wady pominięcia ich ujawniają się szybciej.
Weźmy pobieranie obrazów. Przy normalnym połączeniu zwykle stanowią one około 10% czasu Largest Contentful Paint. Przy wolnym może się to podwoić bez większego wysiłku. Dlatego nie umieszczamy optymalizacji obrazów na szczycie listy dla większości użytkowników, ale w przypadku odwiedzających z niską przepustowością lub ograniczoną pamięcią szybko staje się to priorytetem.

Włącz http/3 z QUIC i 0-RTT

• Szybsza konfiguracja połączenia: QUIC łączy uściski dłoni transportu i szyfrowania w jedno. 0-RTT idzie dalej: powracający odwiedzający wysyłają dane natychmiast, omijając uściski dłoni całkowicie.
• Niższe opóźnienie dla powracających użytkowników: 0-RTT pozwala klientom wznowić sesje i wysłać żądania bez pauzy. Setki milisekund zaoszczędzone — szczególnie cenne dla odległych lub mobilnych użytkowników.
• Odporny na duże odległości:HTTP/3 (przez UDP) omija blokowanie head-of-line TCP. QUIC radzi sobie z utratą pakietów i niestabilnymi sieciami bardziej gracefully — idealny dla połączeń międzykontynentalnych lub chwiejnych mobilnych.

Kompresuj obrazy bardziej agresywnie, niż lubi twój projektant

Obrazy wysokiej rozdzielczości opóźniają LCP (Largest Contentful Paint), szczególnie na urządzeniach o ograniczonej mocy dekompresji GPU. Zamiast poddawać się estetyce, dąż do mniejszych, percepcyjnie akceptowalnych obrazów. WebP i AVIF pomagają, ale lazy-loading i serwowanie responsywnych rozmiarów mają większe znaczenie.

Czysta zasada: dla obrazów głównych na urządzeniach niskiej klasy, pozostań poniżej 100KB. Jeśli projektant protestuje, powinien przetestować tę samą stronę na telefonie Android za 100€ przed dalszą dyskusją.

Ogranicz CSS do tego, co jest absolutnie niezbędne

Jeśli chodzi o style, jest tylko jedna zasada: posprzątaj. Usuń nieużywane selektory, zmniejsz specyficzność i połącz nadmiarowe reguły.

Skup się na przewidywalnych, spójnych układach z minimalnymi nadpisaniami. Użyj małego zestawu klas narzędziowych zamiast złożonych stylów specyficznych dla komponentów. To pomaga zarówno w konstrukcji CSSOM przeglądarki, jak i w łatwości utrzymania przez deweloperów.

Dla treści powyżej fałdy, inline tylko to, co jest absolutnie niezbędne. Lazy-loaduj resztę, ale utrzymuj podział minimalny i jasny. Unikaj narzędzi, które zgadują, co to jest "krytyczny CSS", zdefiniuj go ręcznie i chirurgicznie.

Bądź bezpośredni ze skryptami

• Żaden skrypt nie powinien blokować renderowania: Upewnij się, że wszystkie nieistotne skrypty są nieblokujące. Użyj atrybutów async lub defer w tagach <script>. Jeśli skrypt nie jest niezbędny do początkowego ładowania strony lub interakcji użytkownika, nie może być synchroniczny. W przeciwnym razie po prostu marnujesz cenne milisekundy.
•  Zaplanuj niekrytyczne skrypty Skrypty, które nie są wymagane od razu, powinny być zaplanowane. Ale nie ładuj ich chaotycznie. Użyj funkcji requestIdleCallback, aby uruchamiać skrypty, gdy przeglądarka jest bezczynna. Pozwala to na odciążenie ciężkich zadań bez zakłócania krytycznych ścieżek renderowania.
• Użyj wyniku możliwości klienta, aby selektywnie ładować skrypty nice-to-have:  Wynik możliwości klienta nie jest tylko metryką, ale narzędziem do optymalizacji doświadczenia użytkownika.  Na urządzeniach niskiej klasy zmniejsz liczbę ładowanych skryptów i wybierz lżejsze alternatywy. Jeśli użytkownik ma ograniczoną pamięć lub starszy procesor, nie marnuj zasobów na ładowanie skryptów wymagających dużo zasobów. Priorytetyzuj wydajność nad próżnymi funkcjami, które mogą robić wrażenie na urządzeniach wysokiej klasy, ale frustrują na urządzeniach niskiej klasy.

Używaj czcionek systemowych lub przynajmniej unikaj ciężkich niestandardowych czcionek

Ładowanie niestandardowych czcionek dodaje opóźnienie i powoduje przeskakiwanie układu. Na urządzeniach o ograniczonej pamięci mogą również niepotrzebnie zwiększyć ciśnienie RAM.

Czcionki systemowe renderują się szybciej, respektują ustawienia użytkownika i zmniejszają przesunięcie układu. Jeśli branding wymaga niestandardowej typografii, agresywnie podziel na podzbiory i ładuj czcionki późno.

Monitoruj za pomocą rzeczywistego sprzętu, a nie tylko testów syntetycznych

Wreszcie, narzędzia do testowania syntetycznego (takie jak Lighthouse, WebPageTest itp.) symulują throttling, ale nie naśladują wszystkich dziwactw sprzętu niskiej klasy: termiki, throttling pod rzeczywistym obciążeniem, pauzy w odśmiecaniu pamięci i wąskie gardła pamięci masowej.

Kup tani telefon Android i przeglądaj swoją stronę. Jeśli nie możesz znieść robienia tego regularnie, użyj narzędzia RUM, takiego jak Coredash, i segmentuj dane według klasy urządzenia. Jeśli twój P75 LCP jest w porządku na iPhone 15, ale okropny na Xiaomi Redmi 9, nadszedł czas, aby być szczerym co do tego, dla kogo optymalizujesz.