Wymiar CoreDash: Prędkość sieci

Wymiar: Prędkość sieci (dl)

Wymiar dl raportuje efektywną przepustowość pobierania połączenia każdego użytkownika w momencie wizyty na stronie, mierzoną w megabitach na sekundę (Mbps). CoreDash zbiera tę wartość z interfejsu Network Information API przeglądarki i grupuje wizyty w poziomy przepustowości. Każdy wiersz w tabeli CoreDash reprezentuje określony przedział prędkości, dzięki czemu możesz zestawić ze sobą wyniki Core Web Vitals dla użytkowników szybkiego łącza szerokopasmowego, połączeń o umiarkowanej prędkości oraz wolnych połączeń mobilnych.

Przepustowość to jedna z dwóch charakterystyk sieci, które kształtują wydajność ładowania strony. Drugą jest opóźnienie (latency), które kontroluje czas podróży pakietu do serwera i z powrotem. Wymiar dl w CoreDash izoluje zmienną przepustowości, co pozwala odpowiedzieć na konkretne pytanie: czy Twoje wyniki Core Web Vitals ulegają pogorszeniu wraz ze spadkiem prędkości połączenia i o ile?

Dlaczego prędkość sieci ma znaczenie dla Core Web Vitals

Przepustowość pobierania ma bezpośredni i mierzalny wpływ na Largest Contentful Paint. LCP jest prawie zawsze wyzwalane przez obraz hero, duży obraz tła lub ciężki font webowy. Na łączu 100 Mbps, pobranie obrazu hero o wadze 400 KB zajmuje około 32 milisekund samego czasu transferu. Na łączu 5 Mbps ten sam obraz wymaga ponad 640 milisekund samego transferu, i to przed uwzględnieniem opóźnień lub narzutu na przetwarzanie. Już sama ta różnica może zepchnąć pozytywny wynik LCP do zakresu "wymaga poprawy".

Wskaźnik Time to First Byte jest mniej podatny na przepustowość. TTFB jest zdominowane przez czas przetwarzania po stronie serwera i opóźnienie w sieci na trasie w obie strony, a nie przez ilość przesyłanych bajtów. Powolna odpowiedź serwera jest powolna niezależnie od prędkości połączenia. Jeśli TTFB w CoreDash wypada słabo na wszystkich poziomach przepustowości, wskazuje to na problemy z serwerem lub CDN, a nie na problem z przepustowością po stronie klienta.

Interaction to Next Paint zależy prawie w całości od procesora (CPU). INP mierzy czas między interakcją użytkownika a kolejną wizualną aktualizacją. Ciężkie wykonywanie JavaScript, długie zadania i blokowanie głównego wątku (main thread) są głównymi przyczynami słabych wyników INP. Wolne połączenie może opóźnić początkowe pobieranie paczek JavaScript, co może pośrednio pogorszyć INP, jeśli skrypty są wciąż przetwarzane (parsowane) w momencie pierwszej interakcji użytkownika ze stroną. Ale po załadowaniu skryptów wydajność INP jest uzależniona od mocy obliczeniowej urządzenia, a nie od sieci.

W praktyce problemy z przepustowością wyraźnie uwidaczniają się w czasie ładowania LCP (LCP Load Time) – tej części LCP, która mierzy, ile czasu przeglądarka poświęciła na pobieranie zasobu LCP po jego odkryciu. CoreDash raportuje czas ładowania LCP oddzielnie, co pozwala na proste potwierdzenie, czy wolniejsi użytkownicy czekają na sieć, czy na coś innego.

Interpretacja danych

Ruch CoreDash na typowych stronach dzieli się na trzy poziomy przepustowości. Zrozumienie, co reprezentuje każdy poziom, pomaga w priorytetyzacji poprawek.

Szybkie łącze szerokopasmowe: 50 Mbps i więcej

Do tego przedziału należy około 35% ruchu w CoreDash. Obejmuje on połączenia światłowodowe, szerokopasmowe łącza kablowe oraz użytkowników sieci mobilnych 5G przy dobrych warunkach sygnału. Średnia prędkość pobierania 5G w 2025 roku wynosi około 184 Mbps, a średnia dla stałych łączy szerokopasmowych w USA osiągnęła 214 Mbps. Użytkownicy na tym poziomie rzadko doświadczają opóźnień LCP spowodowanych siecią na dobrze zoptymalizowanych stronach. Jeśli wyniki LCP w tej grupie są słabe, problemem jest czas odpowiedzi serwera, zasoby blokujące renderowanie (render-blocking resources) lub opóźnienie w wykryciu elementu LCP, a nie przepustowość.

Umiarkowana prędkość: od 10 do 50 Mbps

Około 40% ruchu CoreDash mieści się w tym przedziale. Obejmuje to starsze łącza kablowe, połączenia 4G LTE w przeciętnych warunkach sygnału (typowe realne prędkości 4G wynoszą od 10 do 50 Mbps) i niektórych użytkowników stacjonarnych sieci bezprzewodowych. Przy tych prędkościach pobranie obrazu hero o wadze 300 KB zajmuje od 48 do 240 milisekund czasu transferu. Strony z niezoptymalizowanymi obrazami lub wieloma zasobami blokującymi renderowanie zaczną na tym poziomie osiągać gorsze wyniki na progach LCP. To właśnie ten poziom, na którym wybór formatu obrazu (WebP, AVIF) i agresywne wczytywanie wstępne (preloading) za pomocą fetchpriority="high" robią mierzalną różnicę.

Wolne i mobilne: poniżej 10 Mbps

Około 25% ruchu CoreDash pochodzi z połączeń poniżej 10 Mbps. Zalicza się do nich użytkowników mobilnych 3G, stałe łącza wiejskie oraz użytkowników 4G przy słabym sygnale lub przeciążonych warunkach sieciowych. Przy 5 Mbps pobranie obrazu o rozmiarze 400 KB wymaga ponad 640 milisekund czasu transferu. Niespełnienie wymagań LCP na tym poziomie jest prawie pewne, chyba że obraz LCP został poddany agresywnej kompresji, jest serwowany przez brzegowy węzeł CDN znajdujący się blisko użytkownika i jest poprawnie wczytywany wstępnie. Jeśli Twoja firma obsługuje użytkowników w regionach o historycznie wolniejszej infrastrukturze, sprawdź wymiar Country (Kraj) w CoreDash wraz z dl, aby upewnić się, czy ruch o niskiej prędkości koncentruje się geograficznie.

Proces debugowania (Workflow)

1. Filtruj do poziomu poniżej 10 Mbps w CoreDash i sprawdź czas ładowania LCP (LCP Load Time). Jeśli czas ładowania LCP jest głównym powodem słabego wyniku LCP, oznacza to, że zasób LCP jest zbyt duży dla wolnych połączeń. Poddaj obraz silniejszej kompresji, przełącz się na format AVIF i upewnij się, że zasób jest dostarczany z CDN mającego węzeł brzegowy w pobliżu docelowych użytkowników.
2. Porównaj krzyżowo z wymiarem Kraj (Country). Jeśli wolni użytkownicy skupiają się w określonych krajach, sprawdź, czy Twój CDN ma tam dobry zasięg. Użytkownik na łączu 15 Mbps obsługiwany przez węzeł brzegowy CDN oddalony o 200 ms będzie miał znacznie gorsze wrażenia (UX) niż użytkownik przy tej samej prędkości obsługiwany przez węzeł oddalony o 10 ms.
3. Sprawdź wyniki INP i TTFB na różnych poziomach. Jeśli INP pogarsza się przy niskich prędkościach połączenia, ale nie przy wysokich, duże paczki JavaScript są nadal w trakcie pobierania, gdy użytkownicy podejmują pierwszą interakcję. Podziel kod JavaScript, opóźnij niekrytyczne skrypty i rozważ yielding do głównego wątku w trakcie inicjalizacji, aby ograniczyć ryzyko pogorszenia INP podczas fazy parsowania.

Inżynieryjna zasada praktyczna

• Celuj w rozmiar pliku obrazu LCP poniżej 100 KB (AVIF lub WebP), aby utrzymać LCP Load Time poniżej 200 ms, nawet przy połączeniach 5 Mbps.
• Całkowita waga strony dla zasobów widocznych od razu (above-the-fold) powinna pozostawać poniżej 500 KB, aby zapewnić rozsądne LCP przy połączeniach 10 Mbps w granicach 2,5-sekundowego progu.
• Zastosuj fetchpriority="high" dla obrazu LCP i wstępnie go załaduj w sekcji <head> dokumentu, aby przeglądarka nie marnowała przepustowości w pierwszej kolejności na zasoby o niższym priorytecie.
• Serwuj wszystkie zasoby statyczne z CDN. Wyniki przepustowości w CoreDash mierzą połączenie klienta, a nie serwera. Szybkie połączenie u klienta nie pomoże, jeśli serwer jest geograficznie odległy i dodaje 300 ms opóźnienia do momentu, zanim nadejdzie pierwszy bajt.
• Jeśli ponad 15% Twojego ruchu mieści się na poziomie poniżej 10 Mbps, a LCP nie spełnia norm dla tych użytkowników, potraktuj optymalizację obrazów oraz zasięg CDN jako priorytet (P1) zanim zaczniesz poprawiać cokolwiek innego.