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 pobiera tę wartość z Network Information API przeglądarki i grupuje wizyty w poziomy przepustowości. Każdy wiersz w tabeli CoreDash reprezentuje konkretny przedział prędkości, dzięki czemu można porównać wyniki Core Web Vitals dla użytkowników szybkiego łącza szerokopasmowego, połączeń o umiarkowanej prędkości oraz wolnych lub mobilnych połączeń obok siebie.

Przepustowość jest jedną z dwóch cech sieci, które kształtują wydajność ładowania strony. Drugą jest opóźnienie (latency), które kontroluje czas podróży w obie strony do serwera (round-trip time). Wymiar dl w CoreDash izoluje zmienną przepustowości, dzięki czemu można odpowiedzieć na konkretne pytanie: czy Twoje wyniki Core Web Vitals pogarszają się 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 internetowy. Na połączeniu 100 Mbps obraz hero o rozmiarze 400 KB dociera w około 32 milisekundy czasu transferu. Na połączeniu 5 Mbps ten sam obraz potrzebuje ponad 640 milisekund samego czasu transferu, nie licząc opóźnień ani narzutu związanego z przetwarzaniem. Sama ta różnica może zepchnąć pozytywny wynik LCP do zakresu "wymaga poprawy".

Time to First Byte jest mniej wrażliwy na przepustowość. TTFB jest zdominowane przez czas przetwarzania po stronie serwera i opóźnienie podróży w obie strony (latency), a nie przez ilość przesyłanych bajtów. Powolna odpowiedź serwera jest powolna na każdej prędkości połączenia. Jeśli TTFB jest słabe we wszystkich poziomach przepustowości w CoreDash, wskazuje to na problemy z serwerem lub CDN, a nie na problem z przepustowością po stronie klienta.

Interaction to Next Paint jest prawie całkowicie ograniczone przez CPU. INP mierzy czas między interakcją użytkownika a kolejną aktualizacją wizualną. Ciężkie wykonywanie JavaScript, długie zadania i blokowanie głównego wątku (main thread) powodują słabe wyniki INP. Powolne połączenie może opóźnić początkowe pobieranie paczek JavaScript, co może pośrednio pogorszyć INP, jeśli skrypty są nadal analizowane (parsing), gdy użytkownik po raz pierwszy wchodzi w interakcję ze stroną. Jednak po załadowaniu skryptów wydajność INP zależy od mocy obliczeniowej urządzenia, a nie od sieci.

W praktyce problemy z przepustowością wyraźnie ujawniają się w LCP Load Time, czyli podczęści LCP mierzącej, ile czasu przeglądarka spędziła na pobieraniu zasobu LCP po jego odkryciu. CoreDash raportuje LCP Load Time oddzielnie, co ułatwia potwierdzenie, czy wolni użytkownicy czekają na sieć, czy na coś innego.

Interpretacja danych

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

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

Około 35% ruchu w CoreDash wpada do tego poziomu. Obejmuje to połączenia światłowodowe, szerokopasmową telewizję kablową i użytkowników mobilnych 5G w dobrych warunkach sygnału. Średnie prędkości pobierania 5G w 2025 roku oscylują wokół 184 Mbps, a średnie dla stacjonarnego szerokopasmowego internetu w USA osiągnęły 214 Mbps. Użytkownicy w tym poziomie rzadko doświadczają opóźnień LCP wynikających z sieci na dobrze zoptymalizowanych stronach. Jeśli wyniki LCP są tu słabe, problemem jest czas odpowiedzi serwera, zasoby blokujące renderowanie lub opóźnienie odkrycia elementu LCP, a nie przepustowość.

Średnia prędkość: 10 do 50 Mbps

Około 40% ruchu w CoreDash mieści się w tym zakresie. Ten poziom obejmuje starsze połączenia kablowe, 4G LTE w przeciętnych warunkach sygnału (typowe rzeczywiste prędkości 4G wynoszą od 10 do 50 Mbps) oraz niektórych użytkowników stacjonarnego dostępu bezprzewodowego. Obraz hero o rozmiarze 300 KB potrzebuje od 48 do 240 milisekund czasu transferu przy tych prędkościach. Strony z niezoptymalizowanymi obrazami lub wieloma zasobami blokującymi renderowanie zaczną przekraczać progi LCP w tym poziomie. To właśnie na tym poziomie wybór formatu obrazu (WebP, AVIF) i agresywne wstępne ładowanie (preloading) z fetchpriority="high" robią mierzalną różnicę.

Wolne i mobilne: Poniżej 10 Mbps

Około 25% ruchu w CoreDash pochodzi z połączeń poniżej 10 Mbps. Obejmuje to użytkowników mobilnych 3G, wiejskie połączenia stacjonarne oraz użytkowników 4G w słabych warunkach sygnału lub przy przeciążonej sieci. Przy 5 Mbps obraz o rozmiarze 400 KB potrzebuje ponad 640 milisekund czasu transferu. Niepowodzenia LCP w tym poziomie są niemal pewne, chyba że obraz LCP został agresywnie skompresowany, serwowany z węzła brzegowego CDN blisko użytkownika i poprawnie wstępnie załadowany. Jeśli Twoja firma obsługuje użytkowników w regionach z historycznie wolniejszą infrastrukturą, sprawdź wymiar Country w CoreDash obok dl, aby potwierdzić, czy ruch o niskiej prędkości koncentruje się geograficznie.

Proces debugowania

1. Odfiltruj poziom poniżej 10 Mbps w CoreDash i sprawdź LCP Load Time. Jeśli LCP Load Time jest głównym czynnikiem wpływającym na negatywny wynik LCP, zasób LCP jest zbyt duży dla wolnych połączeń. Mocniej skompresuj obraz, przejdź na format AVIF i upewnij się, że zasób jest serwowany z CDN z węzłem brzegowym blisko dotkniętych użytkowników.
2. Porównaj z wymiarem Country. Jeśli użytkownicy o niskiej prędkości koncentrują się w określonych krajach, sprawdź, czy Twój CDN ma dobry zasięg w tych regionach. Użytkownik z połączeniem 15 Mbps obsługiwany przez węzeł brzegowy CDN oddalony o 200 ms będzie miał znacznie gorsze doświadczenia niż użytkownik z tą samą prędkością obsługiwany przez węzeł oddalony o 10 ms.
3. Sprawdź wyniki INP i TTFB we wszystkich poziomach. Jeśli INP pogarsza się przy niskich poziomach przepustowości, ale nie przy wysokich, duże paczki JavaScript nadal pobierają się w momencie pierwszej interakcji użytkownika. Podziel JavaScript, odsuń w czasie skrypty niekrytyczne i rozważ oddanie kontroli do głównego wątku (yielding to the main thread) podczas inicjalizacji, aby zmniejszyć ekspozycję INP podczas fazy analizy (parse phase).

Inżynierska zasada kciuka

• Celuj w rozmiar pliku obrazu LCP poniżej 100 KB (AVIF lub WebP), aby utrzymać LCP Load Time poniżej 200 ms nawet na połączeniach 5 Mbps.
• Całkowita waga strony dla zasobów powyżej linii zanurzenia (above-the-fold) powinna wynosić poniżej 500 KB, aby zapewnić rozsądne LCP na połączeniach 10 Mbps w granicach 2,5 sekundy.
• Używaj fetchpriority="high" dla obrazu LCP i ładuj go wstępnie (preload) w sekcji <head> dokumentu, aby przeglądarka nie marnowała przepustowości na mniej ważne zasoby w pierwszej kolejności.
• Serwuj wszystkie statyczne zasoby z CDN. Liczby przepustowości w CoreDash mierzą połączenie klienta, a nie serwera. Szybkie połączenie klienta nie pomoże, jeśli serwer jest odległy geograficznie i dodaje 300 ms opóźnienia, zanim dotrze pierwszy bajt.
• Jeśli ponad 15% Twojego ruchu znajduje się w poziomie poniżej 10 Mbps i LCP dla tych użytkowników kończy się niepowodzeniem, traktuj optymalizację obrazów i zasięg CDN jako priorytety P1 przed zajęciem się czymkolwiek innym.