Dimensione Core/Dash: Conteggio dei redirect

Dimensione: Navigazione: conteggio dei redirect (redir)

La dimensione redir conta i redirect HTTP prima di raggiungere la pagina finale. I valori sono 0, 1, 2 o 3+. Ogni redirect è un intero round trip di rete che avviene prima ancora che il tuo server inizi a generare l'HTML.

Su una connessione RTT da 100ms, un redirect aggiunge 100ms al TTFB. Su una connessione mobile da 200ms, questo valore raddoppia. Due redirect su mobile: 400ms di pura attesa prima che il browser riceva un singolo byte della tua pagina. Questa latenza è invisibile nei test di laboratorio che puntano direttamente all'URL finale, ma gli utenti reali che seguono link, preferiti o risultati di ricerca la subiscono a ogni visita.

I valori

0 redirect

Lo stato ideale. Il browser ha raggiunto l'URL finale alla prima richiesta. Tutta la navigazione interna dovrebbe produrre questo valore. Se i link del tuo sito, le sitemap e i tag canonical sono corretti, il traffico interno rimane a 0.

1 redirect

Comune per il traffico esterno: passaggi da HTTP a HTTPS, normalizzazione del www o URL di campagne marketing. Accettabile per i link in entrata che non controlli. Non accettabile per i tuoi link interni. Se CoreDash mostra 1 redirect sulle navigazioni interne, i tuoi link puntano a URL obsoleti o incoerenti.

2+ redirect

Catene di redirect. Un URL accorciato reindirizza a un dominio di tracciamento, che reindirizza al tuo endpoint HTTP, il quale reindirizza a HTTPS. Tre hop, tre round trip. Raggruppa per URL per trovare quali punti di ingresso creano queste catene, quindi elimina gli intermediari.

Da dove provengono i redirect

• Da HTTP a HTTPS: Link interni obsoleti che puntano ancora a http://. Aggiorna tutti i link, le sitemap e i tag canonical per usare direttamente https://.
• Normalizzazione del www: Incoerenza tra www e non-www. Imponi una sola versione a livello DNS e aggiorna tutti i riferimenti.
• Modifiche degli slug nel CMS: Vecchi percorsi che reindirizzano ai nuovi percorsi tramite 301. Va bene per i backlink esterni, ma aggiorna ogni link interno per puntare direttamente al nuovo slug.
• URL vanity per il marketing: Percorsi vanity come /spring-sale che reindirizzano a /products/seasonal. Ogni visitatore paga il costo della latenza a ogni clic.
• Accorciatori di URL in email e social: Link che passano attraverso Bitly, pixel di tracciamento o provider di servizi email prima di raggiungere il tuo dominio. Ciascun servizio aggiunge un round trip che non puoi controllare, ma puoi ridurre al minimo i tuoi redirect per mantenere basso il totale.

Flusso di lavoro per il debug

1. Filtra per redir ≥ 1: Controlla quale percentuale del tuo traffico totale incontra almeno un redirect. Qualsiasi valore superiore al 15% merita un'indagine.
2. Raggruppa per URL: Trova quali landing page sono le peggiori. Le pagine di marketing e i vecchi articoli del blog con slug modificati tendono a dominare.
3. Suddividi tra interno ed esterno: Filtra per navigation origin. Il traffico same-origin con redirect indica che i tuoi stessi link sono errati. I redirect cross-origin sono più difficili da correggere ma meno urgenti.
4. Correggi l'origine, non il redirect: Non ottimizzare il redirect in sé (risposta del server più veloce). Eliminalo aggiornando il link che lo ha causato.

Regole pratiche di sviluppo

• 0 redirect su tutta la navigazione interna. Nessun redirect dal tuo stesso sito è accettabile quando controlli il link di origine.
• Fai un controllo dopo ogni migrazione di URL. Quando modifichi gli slug o sposti le pagine, usa grep nel codebase e nel CMS per trovare i vecchi percorsi. I redirect sono una rete di sicurezza per i link esterni, non un sostituto dell'aggiornamento dei tuoi stessi riferimenti.
• Prevedi un budget di 150ms per ogni redirect su mobile. Se il tuo obiettivo di TTFB è di 800ms e gli utenti incontrano due redirect, hai già speso 300ms prima ancora che il tuo server inizi a fare alcunché.

I redirect sono la vittoria più facile da individuare e risolvere per il TTFB. Nessuna modifica al codice, nessuna sintonizzazione del server, nessuna ottimizzazione degli asset. Aggiorna semplicemente l'URL che punta alla destinazione errata.