Velocità della pagina e Core Web Vitals
Nel SEO moderno, la velocità della pagina significa far sì che le pagine sembrino veloci: il contenuto principale appare rapidamente, il layout rimane stabile e le interazioni rispondono senza ritardi. Il nome pubblico usato da Google per le tre metriche sul campo che rilevano questa sensazione è : Largest Contentful Paint (), Interaction to Next Paint () e Cumulative Layout Shift ().
In tutta questa pagina, supponiamo che Fernwood debba far rientrare la propria pagina dei prezzi, le pagine di confronto e le principali guide nelle soglie "buone" su dispositivi mobili, da cui provengono la maggior parte dei nuovi visitatori e molti clic indirizzati dagli assistenti.
Questa tecnica non è intenzionalmente un manuale tecnico completo. web.dev contiene già le istruzioni approfondite. Quanto segue è il quadro decisionale: cosa significano le metriche, quanto contano, come stabilire le priorità con Silktide e dove indirizzare gli ingegneri per le correzioni.
Perché funziona (e quanto conta)
Sono interessati due tipi di pubblico:
- Visitatori. Un LCP lento e un CLS instabile causano abbandoni prima che siano visibili la risposta o la CTA. È un problema di conversione anche quando il posizionamento va bene.
- Ricerca. Google afferma che i Core Web Vitals vengono usati dai sistemi di ranking nell'ambito dell'esperienza sulla pagina e raccomanda valori buoni per il successo nella Ricerca (Understanding Core Web Vitals and Google search results; Understanding page experience). Google afferma inoltre che la Ricerca cerca comunque di mostrare i contenuti più pertinenti anche quando l'esperienza sulla pagina è inferiore agli standard: i Core Web Vitals sono quindi un segnale reale, non una leva magica per il ranking. Considerali un requisito di base e un criterio di spareggio tra pagine altrimenti simili, non un sostituto dei contenuti che forniscono prima la risposta o dell'autorevolezza.
Per l'AEO in particolare: una pagina veloce non fa sì che un assistente ti citi. Ma una pagina lenta, con layout che si sposta, perde comunque le persone inviate da tali citazioni; inoltre, il rendering pesante lato client che danneggia la velocità spesso danneggia anche i contenuti leggibili senza JavaScript.
Le tre metriche importanti
Le soglie seguenti sono gli obiettivi "buoni" di Google, valutati per utenti reali approssimativamente al 75° percentile (dati sul campo). Gli strumenti di laboratorio diagnosticano; i dati sul campo sono ciò che valuta la Ricerca.
| Metrica | Cosa misura | Buono |
|---|---|---|
| LCP | Quando appare il contenuto principale | ≤ 2,5 s |
| INP | Quanto rapidamente la pagina risponde a clic/tocchi | ≤ 200 ms |
| CLS | Quanto il layout salta durante il caricamento | ≤ 0,1 |
Dettagli e guide al debug: web.dev Vitals, Optimize LCP, Optimize INP, Optimize CLS.
Come affrontare il problema (ordine delle operazioni di Fernwood)
1. Scegli le pagine importanti
Non cercare di fare tutto insieme. Inizia da:
- Landing page ad alto traffico e homepage
- Pagine che generano entrate (prezzi, registrazione, confronti chiave)
- Guide pilastro e pagine di ricerca che vuoi vengano citate
Un archivio blog mediocre può aspettare. Una pagina dei prezzi lenta no.
2. Separa la diagnosi di laboratorio dalla realtà sul campo
- Laboratorio (test di velocità Silktide, Lighthouse, WebPageTest): ripetibile, utile per individuare le cause su un URL e un profilo dispositivo specifici.
- Campo (Chrome UX Report / report Core Web Vitals di Search Console, RUM come Analytics in Silktide, quando disponibile): ciò che hanno sperimentato i visitatori reali.
Possono non coincidere senza che nessuno dei due sia errato: dispositivi, paesi e stati della cache sono diversi. Correggi i problemi di laboratorio che corrispondono chiaramente a errori sul campo; non inseguire la perfezione in laboratorio per un URL che supera già le soglie sul campo.
La schermata Velocità di Silktide combina la diagnostica di laboratorio con le misurazioni dei visitatori reali dove Analytics è connesso. Il controllo Web Vitals riepiloga le prestazioni di laboratorio; Pagine a caricamento lento e Spostamenti del layout isolano LCP e CLS.
3. Correggi le cause, non i punteggi
Quando Silktide (o Lighthouse) segnala una causa, correggi quella causa:
| Causa comune | Metrica tipica | Silktide / passaggio successivo |
|---|---|---|
| Immagine hero enorme, server lento, CSS/JS che blocca il rendering | LCP | Pagine a caricamento lento, Precarica l'immagine LCP, controlli di ottimizzazione delle immagini |
| Immagini/pubblicità /incorporamenti senza spazio riservato; caratteri caricati tardi | CLS | Spostamenti del layout, Dimensioni esplicite delle immagini |
| Attività JavaScript lunghe al clic | INP / TBT | Riduci il tempo di esecuzione JavaScript, Elimina le risorse che bloccano il rendering |
| Troppi byte complessivi | Tutte | Esamina il peso in byte, formati di immagine moderni, caching |
Gli ingegneri dovrebbero usare le guide web.dev collegate sopra per i dettagli di implementazione: i modelli specifici per framework cambiano più rapidamente di quanto dovrebbe cambiare questa pagina.
4. Ripeti i test sugli stessi URL
Dopo una correzione, esegui di nuovo i test di laboratorio sullo stesso profilo dispositivo, quindi attendi che i dati sul campo si aggiornino (le finestre CrUX sono di più settimane). Valuta il successo in base allo stato sul campo degli URL importanti, non a uno screenshot di Lighthouse della sola homepage in una presentazione.
Limiti onesti
- I contenuti vincono comunque. Una pagina veloce ma vuota perde contro una risposta completa più lenta. Lavorare sulla velocità di pagine deboli è solo una rifinitura.
- Terze parti. Tag manager, widget di chat e strumenti A/B spesso dominano INP e LCP. Destina capitale politico alla loro rimozione o al rinvio del loro caricamento; minimizzare il tuo CSS non salverà una bomba sincrona di terze parti.
- SPA / rendering solo lato client. Se il sito marketing di Fernwood distribuisce un contenitore vuoto, potresti dover affrontare sia i Core Web Vitals sia la leggibilità per i crawler AI. Preferisci SSR/SSG per i contenuti pubblici (Contenuti leggibili senza JavaScript).
- Teatro dell'iperottimizzazione. Ridurre di 20 ms l'LCP di laboratorio su un URL già verde sul campo raramente è il miglior uso del tempo di un ingegnere, mentre alle pagine di confronto mancano ancora blocchi di prove.
Come aiuta Silktide
- Schermata Velocità - da dove iniziare nel prodotto
- Web Vitals - punteggio riepilogativo di laboratorio e tempi dei componenti
- Pagine a caricamento lento (LCP) e Spostamenti del layout (CLS)
- Controlli delle prestazioni di supporto (immagini, JS, caching, reindirizzamenti) collegati da tali articoli
- Panoramica dell'Esperienza utente: Esperienza utente
Correlati
- Contenuti leggibili senza JavaScript - spesso la stessa causa principale di un LCP scarso negli stack moderni
- / / /
- Web Vitals (web.dev)
- Core Web Vitals e Ricerca Google
- Comprendere l'esperienza sulla pagina nei risultati della Ricerca Google