Wymiar CoreDash: Liczba przekierowań

Zmierz, na ile przekierowań HTTP trafiają użytkownicy przed dotarciem do Twojej strony i jaki jest ich bezpośredni wpływ na TTFB.

Darmowy okres próbny

Trusted by market leaders · Client results

workivaadevintaharvardnestlefotocasanina caredpg mediavpnaleteiasaturncompareerasmusmchappyhorizonloopearplugsebayperionmarktplaatswhowhatwearmonarchkpnsnvmy work featured on web.dev

Wymiar: Nawigacja: Liczba przekierowań (redir)

Wymiar redir zlicza przekierowania HTTP przed dotarciem do docelowej strony. Wartości to 0, 1, 2 lub 3+. Każde przekierowanie to pełny cykl sieciowy (round trip), który ma miejsce, zanim Twój serwer w ogóle zacznie generować HTML.

Przy połączeniu z RTT rzędu 100ms, jedno przekierowanie dodaje 100ms do TTFB. Przy 200ms na połączeniu mobilnym, ta wartość się podwaja. Dwa przekierowania na urządzeniu mobilnym: 400ms czystego czekania, zanim przeglądarka otrzyma choćby jeden bajt Twojej strony. To opóźnienie jest niewidoczne w testach laboratoryjnych, które uderzają bezpośrednio w końcowy URL, ale prawdziwi użytkownicy klikający w linki, zakładki lub wyniki wyszukiwania odczuwają je przy każdej wizycie.

coredash redirect count

Wartości

0 przekierowań

Stan docelowy. Przeglądarka trafiła na ostateczny URL przy pierwszym żądaniu. Cała wewnętrzna nawigacja powinna generować tę wartość. Jeśli linki na Twojej własnej stronie, mapy witryn i tagi kanoniczne są poprawne, ruch wewnętrzny pozostaje na poziomie 0.

1 przekierowanie

Częste zjawisko dla ruchu zewnętrznego: wymuszanie HTTPS zamiast HTTP, normalizacja www czy adresy URL kampanii marketingowych. Akceptowalne dla linków przychodzących, nad którymi nie masz kontroli. Niedopuszczalne dla Twoich własnych linków wewnętrznych. Jeśli CoreDash pokazuje 1 przekierowanie dla nawigacji wewnętrznej, Twoje linki prowadzą do starych lub niespójnych adresów URL.

2+ przekierowania

Łańcuchy przekierowań. Skrócony adres URL przekierowuje do domeny śledzącej, która przekierowuje do Twojego punktu końcowego HTTP, który następnie przekierowuje na HTTPS. Trzy skoki, trzy pełne cykle sieciowe. Pogrupuj według URL, aby sprawdzić, które punkty wejścia tworzą te łańcuchy, a następnie wyeliminuj pośredników.

Skąd biorą się przekierowania

  • Z HTTP na HTTPS: Przestarzałe linki wewnętrzne wciąż prowadzące do http://. Zaktualizuj wszystkie linki, mapy witryn i tagi kanoniczne, aby korzystały bezpośrednio z https://.
  • Normalizacja www: Niespójność między wersją z www i bez www. Wymuś jedną wersję na poziomie DNS i zaktualizuj wszystkie odniesienia.
  • Zmiany slugów w CMS: Stare ścieżki przekierowujące na nowe ścieżki za pomocą 301. Akceptowalne dla zewnętrznych linków zwrotnych, ale musisz zaktualizować każdy link wewnętrzny, by wskazywał bezpośrednio na nowy slug.
  • Marketingowe przyjazne linki (vanity URLs): Skrócone, przyjazne ścieżki, jak /spring-sale, przekierowujące na /products/seasonal. Każdy odwiedzający płaci kosztem opóźnienia przy każdym kliknięciu.
  • Skracacze linków w e-mailach i social media: Linki przechodzące przez Bitly, piksele śledzące lub dostawców usług e-mail przed dotarciem do Twojej domeny. Każda z tych usług dodaje cykl sieciowy, nad którym nie masz kontroli, ale możesz zminimalizować swoje własne przekierowania, aby utrzymać łączną liczbę na niskim poziomie.

Proces debugowania

  1. Filtruj dla redir ≥ 1: Zobacz, jaki procent całego Twojego ruchu trafia na co najmniej jedno przekierowanie. Wszystko powyżej 15% jest warte zbadania.
  2. Grupuj według URL: Znajdź, które strony docelowe są największymi winowajcami. Zazwyczaj dominują tu strony marketingowe i stare wpisy na blogu ze zmienionymi slugami.
  3. Podziel na wewnętrzne i zewnętrzne: Filtruj po pochodzeniu nawigacji. Ruch z tego samego źródła (same origin) z przekierowaniami oznacza, że Twoje własne linki są błędne. Przekierowania z innych źródeł (cross origin) są trudniejsze do naprawienia, ale mniej pilne.
  4. Napraw źródło, nie przekierowanie: Nie optymalizuj samego przekierowania (szybsza odpowiedź serwera). Wyeliminuj je, aktualizując link, który je spowodował.

Praktyczne zasady inżynierskie

  • 0 przekierowań dla całej nawigacji wewnętrznej. Żadne przekierowanie z Twojej własnej strony nie jest akceptowalne, gdy masz kontrolę nad linkiem źródłowym.
  • Audyt po każdej migracji URL. Kiedy zmieniasz slugi lub przenosisz strony, przeszukaj bazę kodu i CMS w poszukiwaniu starych ścieżek. Przekierowania to siatka bezpieczeństwa dla zewnętrznych linków, a nie substytut aktualizacji Twoich własnych odnośników.
  • Załóż budżet 150ms na każde przekierowanie na urządzeniach mobilnych. Jeśli Twoim celem dla TTFB jest 800ms, a użytkownicy trafiają na dwa przekierowania, straciłeś już 300ms, zanim Twój serwer wykonał jakąkolwiek pracę.

Przekierowania to najłatwiejszy do znalezienia i naprawienia element poprawiający TTFB. Żadnych zmian w kodzie, żadnego dostrajania serwerów, żadnej optymalizacji zasobów. Po prostu zaktualizuj adres URL, który wskazuje na niewłaściwe miejsce.