Spis treści
Czym są Early Hints 103 i jak przyspieszają LCP
Early Hints 103 to wczesna odpowiedź serwera, która pozwala przeglądarce zacząć pobieranie kluczowych zasobów zanim backend wygeneruje stronę. Zamiast bezczynnie czekać na HTML, klient już w pierwszych milisekundach pobiera CSS, czcionki lub obraz LCP – dlatego metryka Largest Contentful Paint zwykle się poprawia.
Mechanizm działa prosto – serwer lub CDN wysyła status 103 wraz z nagłówkami Link, a pełna odpowiedź 200 pojawia się chwilę później. Przeglądarka traktuje te wskazówki jak polecenia preload lub preconnect, więc skraca czas do renderu. Największy zysk widać tam, gdzie TTFB bywa dłuższy – aplikacje dynamiczne, sklepy i strony z wieloma integracjami.
Jak włączyć Early Hints – Cloudflare i inne środowiska
Najprościej uruchomić Early Hints na CDN – to on wyśle 103 zanim origin skończy generować HTML. W Cloudflare funkcja jest dostępna na poziomie domeny – włącz ją w sekcji optymalizacji wydajności i zostaw tryb domyślny, który automatycznie buduje 103 z nagłówków Link oraz z analizy HTML. To dobry start bez zmian w aplikacji.
Jeśli chcesz kontrolować wskazówki, dodawaj Link po stronie originu – CDN skopiuje je do 103. Możesz też tworzyć reguły na ścieżki – dla /, /product/* czy /blog/* przygotuj różne zestawy zasobów, które mają być pobierane najwcześniej.
W środowiskach bez CDN masz dwie ścieżki. Pierwsza – native support w serwerze lub frameworku. Nowoczesne platformy potrafią wysłać 103 z poziomu aplikacji – w Node możesz emitować Early Hints przed właściwą odpowiedzią, a podobne wsparcie pojawia się w wybranych frameworkach. Druga – reverse proxy przed aplikacją. Serwery pośrednie mogą generować 103 na podstawie reguł lub wstrzykiwanych nagłówków Link.
Pamiętaj o protokole – Early Hints najlepiej działają na HTTP/2 i HTTP/3. Jeśli ruch wpada przez HTTP/1.1, część klientów 103 zignoruje, a część nie zyska wystarczająco na równoległości. W praktyce i tak warto je włączyć – nowoczesne przeglądarki obsługują mechanizm, a brak wsparcia po stronie klienta po prostu niczego nie psuje.
Co preloadować, żeby nie przepalić budżetu
Zasada jest prosta – preloaduj tylko to, co realnie przyspiesza pierwsze renderowanie. Zbyt długa lista w 103 spowoduje kontencję i odwrotny efekt. Zacznij od trzech kategorii:
1) Krytyczny CSS
– Główna kaskada, bez której nie ma layoutu.
– Użyj as=style i upewnij się, że nazwa pliku jest stabilna – w przeciwnym razie przeglądarka nie skorzysta z cache.
– Jeśli dzielisz CSS na moduły, preloaduj tylko pakiet krytyczny – resztę ładuj później.
2) Czcionki użyte w above the fold
– Pliki w formatach WOFF2 – są mniejsze i szybciej się dekodują.
– Zawsze dodaj as=font i crossorigin – inaczej przeglądarka może pobrać font dwa razy.
– Unikaj preloading wielu wariantów – zwykle wystarczy regular i bold dla pierwszego widoku.
3) Obraz LCP
– Preload ma największy sens, gdy LCP to hero image lub główny baner.
– Dodaj as=image i parametry odpowiadające faktycznemu rozmiarowi – zminimalizujesz ryzyko pobrania niepotrzebnie dużych plików.
– Jeśli masz warianty responsywne, upewnij się, że przeglądarka wybierze właściwy zasób – wskazuj dokładnie ten, który jest najczęściej renderowany na danym szablonie.
Uzupełniająco rozważ preconnect do kluczowych domen – np. CDN obrazów lub hosta czcionek. To skraca TLS handshake i DNS, ale nie nadużywaj tej techniki – każdy preconnect zużywa gniazda i może pogorszyć kolejkę żądań.
Czego nie preloadować – skryptów analitycznych, widżetów społecznościowych i zasobów, które nie biorą udziału w pierwszym malowaniu. Jeśli musisz preloadować JS, rób to ostrożnie i tylko dla krytycznych, małych plików inicjalizujących.
Weryfikacja zysku – metryki, narzędzia i kontrola jakości
1) Zbierz bazę przed wdrożeniem
– Minimum 7 dni danych z ruchu produkcyjnego – LCP w percentylu 75, TTFB, CLS i FID/INP.
– Podziel wyniki na typ połączenia i urządzenia – mobilne vs desktop.
– Zanotuj, które szablony stron i URL-e generują najwięcej odsłon – tam skupisz optymalizację.
2) Włącz Early Hints na ograniczonym zakresie
– Najpierw / i szablony o największym ruchu.
– Preloaduj tylko krytyczne zasoby – 2–4 wpisy Link to zwykle bezpieczny poziom.
– Monitoruj błędy – czy nie pojawia się podwójne pobieranie fontów, czy nie rośnie Total Blocking Time przez kolizję z innymi optymalizacjami.
3) Porównaj przed i po
– Porównanie tydzień do tygodnia na tej samej puli URL-i.
– Oczekiwany efekt – spadek LCP o 50–200 ms na dobrze dobranych zasobach, więcej przy długim TTFB.
– Jeśli zysku nie ma – ogranicz listę preloadów, usuń preconnect, przetestuj różne rozmiary obrazu LCP lub zaktualizuj priorytety ładowania.
Jak sprawdzić, że 103 naprawdę wychodzi do użytkownika?
– DevTools – w zakładce Network zobaczysz wczesną odpowiedź 103 dla dokumentu oraz rozpoczęte pobieranie zasobów przed 200.
– cURL – nagłówki 103 są widoczne przy zapytaniach z włączonym HTTP/2.
– Logi i RUM – zanotuj odsetek żądań z Early Hints oraz korelację z LCP. Jeśli masz możliwość, wysyłaj w RUM flagę „EH hit” i porównuj mediany.
Ważne zasady jakości
– Nie dubluj preloadów – jeśli zasób jest już inlinowany lub wymuszony w HTML, usuń zbędne wpisy.
– Dodawaj crossorigin do fontów i zasobów z innych domen – inaczej przeglądarka może utworzyć dwa wpisy w cache.
– Aktualizuj listę przy zmianach bundla – hash w nazwie pliku wymaga dostosowania nagłówków Link.
– Nie preloaduj zasobów warunkowych – jeśli obraz LCP różni się na wielu typach stron, rozdziel reguły w zależności od szablonu.
Najczęstsze pułapki i jak ich uniknąć
Za długi zestaw hintów – ogranicz do najważniejszego CSS, jednego fontu i obrazu LCP. Dodatkowe zasoby dołóż dopiero, gdy zobaczysz brak regresji w LCP.
Konflikt z optymalizacjami – niektóre narzędzia łączą pliki i zmieniają kolejność ładowania. Ustal priorytety – najpierw weryfikuj Early Hints, potem dopasuj minifikację i lazy loading.
Cache po stronie CDN – 103 powinien być generowany dla każdej odpowiedzi dokumentu – nie buforuj dynamicznych nagłówków Link w sposób, który pomija warianty dla różnych szablonów.
Brak efektu na wolnych łączach – jeśli głównym wąskim gardłem jest przepustowość, postaw na kompresję obrazów i rozmiary plików – Early Hints skracają „bezczynność”, ale nie zastąpią optymalizacji payloadu.
Podsumowując
Early Hints 103 to szybkie zwycięstwo – przeglądarka zaczyna pracę, zanim backend skończy, a LCP spada bez zmian w widoku. Włącz funkcję na krawędzi, preloaduj tylko CSS krytyczny, wybrane fonty i obraz LCP, a zysk weryfikuj w danych polowych. Trzymaj listę Link krótką, dodawaj crossorigin do fontów i mierz wpływ per szablon – tak wykorzystasz potencjał 103 bez ryzyka regresji.
