Landing page principali
Monitora le pagine che presentano prodotto, servizio o campagna, perché una prima esperienza lenta può influire su scoperta e conversione.
Monitora i Core Web Vitals delle pagine importanti
Segui LCP, CLS e gli indicatori di caricamento di pagine pubbliche selezionate del dominio del progetto. Esamina cinque metriche per URL e un riepilogo separato della homepage con Speed Index; valuta una correzione mirata con un risultato successivo. Sono test controllati, non dati sul campo di utenti reali.
Controlli Core Web Vitals
LCP
Trova gli URL selezionati in cui il contenuto principale appare tardi.
CLS
Esamina gli spostamenti imprevisti del layout negli URL selezionati.
Misurazioni di laboratorio giornaliere
Annota i valori attuali e verifica un risultato di laboratorio successivo dopo una correzione mirata.
Monitora Largest Contentful Paint
Largest Contentful Paint misura quando l’immagine, il blocco di testo o il video idoneo più grande diventa visibile nell’area della prova. Usa il valore LCP di ogni URL monitorato per scegliere la pagina il cui caricamento richiede un’indagine più approfondita.
- Screpy mostra LCP in secondi: fino a 2,5 s è buono; oltre 2,5 s e fino a 4 s richiede miglioramenti; oltre 4 s è scarso.
- Un FCP rapido seguito da un LCP lento indica che parte del contenuto è apparsa prima dell’elemento principale. Indaga consegna e rendering di quell’elemento, senza presumere che l’intera pagina fosse vuota.
- Conferma l’immagine, il font o il ritardo di rendering con un’analisi delle prestazioni del tuo sviluppatore. Il numero da solo non identifica l’elemento e non prescrive la correzione.
example.comLaboratorio
LCP2,1 s
Misura Cumulative Layout Shift
Una pagina può caricarsi rapidamente e spostare comunque un pulsante o un paragrafo in modo inatteso. Cumulative Layout Shift fornisce a ogni URL monitorato un punteggio di stabilità in laboratorio, per analizzare i movimenti separatamente dalla velocità di caricamento.
- CLS non ha un’unità di tempo: fino a 0,1 è buono in Screpy; oltre 0,1 e fino a 0,25 richiede miglioramenti; oltre 0,25 è scarso.
- Controlla lo spazio riservato a immagini, annunci e contenuti incorporati, oltre ai cambiamenti dei font. Sono possibili cause; il punteggio Screpy non identifica l’elemento spostato.
- Un CLS basso nel test di caricamento non esclude spostamenti successivi durante la visita. Verifica l’interazione effettiva e i dati sul campo se il problema compare dopo il caricamento.
CLS
0,04Controlla Total Blocking Time
Total Blocking Time aiuta a riconoscere il lavoro del thread principale che può ritardare la risposta agli input durante il caricamento. Leggi TBT insieme a LCP e FCP: mostrare subito contenuto non significa necessariamente che la pagina risponda rapidamente.
- TBT è mostrato in millisecondi: fino a 200 ms è buono; oltre 200 ms e fino a 600 ms richiede miglioramenti; oltre 600 ms è scarso.
- Il tempo di blocco somma le porzioni delle attività lunghe che superano 50 ms nell’intervallo misurato. Non è il tempo totale di esecuzione di JavaScript.
- Se TBT è alto, analizza attività lunghe e script inutili con gli strumenti per sviluppatori prima di cambiare il codice. Il valore nel pannello non attribuisce il ritardo a uno script specifico.
- TBT non è INP. INP misura interazioni e può essere testato in laboratorio eseguendole; questa funzionalità Screpy non riporta una misurazione INP.
example.comLaboratorio
TBT180 ms
Confronta FCP e TTFB
First Contentful Paint indica il primo contenuto visibile; Time to First Byte indica l’inizio della risposta. Leggerli per lo stesso URL aiuta a distinguere un ritardo iniziale della risposta dal tempo necessario per mostrare contenuto sullo schermo.
- FCP è mostrato in secondi: fino a 1,8 s è buono; oltre 1,8 s e fino a 3 s richiede miglioramenti; oltre 3 s è scarso.
- TTFB è mostrato in millisecondi: fino a 800 ms è buono; oltre 800 ms e fino a 1.800 ms richiede miglioramenti; oltre 1.800 ms è scarso. Connessione, reindirizzamenti e risposta possono influenzarlo.
- Se TTFB è basso ma FCP è lento, indaga cosa ritarda la prima visualizzazione. Se la risposta è lenta, esamina prima la consegna; nessun valore isolato dimostra una causa nel backend o nel rendering.
Laboratorio2100 ms
TTFB450 ms
FCP1100 ms
LCP2100 ms
TBT95 ms
Monitora pagine web importanti
Segui un insieme gestibile di pagine pubbliche del progetto, invece di considerare un singolo risultato della homepage come quello dell’intero sito. Usa la quota del progetto prevista dal piano per le pagine dove caricamento e stabilità sono più importanti.
- La homepage viene aggiunta alla creazione del progetto. Puoi aggiungere altri URL pubblici del dominio del progetto o dei suoi sottodomini quando il piano consente il monitoraggio.
- Scegli pagine rappresentative di prodotti, categorie, articoli e ingressi di conversione. Un problema di modello ricorrente può giustificare altre analisi, ma il test di un URL non misura tutte le pagine di quel modello.
- L’inserimento normalizza protocollo e host, aggiunge HTTPS quando manca e rimuove i frammenti. Percorsi e parametri di query restano significativi; un URL normalizzato duplicato viene rifiutato.
- La pagina aggiunta attende la prima verifica programmata prima di comparire nella tabella. L’aggiunta dell’URL non avvia una prova immediata.
- Conferma la rimozione per interrompere il monitoraggio e liberare spazio nella quota. Viene rimosso il record monitorato, non la pagina dal sito o da Google.
example.comLaboratorio
/1,4 s/shop/linen2,8 s/guides/seo1,9 sEsamina le prestazioni della homepage
Il riepilogo sopra la tabella usa la homepage verificata del progetto. Riunisce le misurazioni di laboratorio attuali, incluso Speed Index; la tabella sottostante mantiene le cinque metriche visualizzate associate a ogni URL monitorato.
- Leggi FCP, LCP, CLS, TTFB, TBT e Speed Index nel riepilogo della homepage. Sono valori di quella pagina, non la media delle pagine monitorate.
- Speed Index descrive quanto rapidamente il contenuto visibile si forma durante il caricamento. Screpy mostra secondi: fino a 3,4 s è buono; oltre 3,4 s e fino a 5,8 s richiede miglioramenti; oltre 5,8 s è scarso.
- Ogni barra rappresenta la misurazione attuale. Non è una cronologia salvata, una percentuale di visitatori o il 75° percentile dei dati sul campo di Google.
- Se manca un risultato verificato della homepage, il riepilogo non è disponibile. Non viene sostituito con il risultato di un altro URL monitorato.
example.comLaboratorio
LCP2,1 s
TBT180 ms
CLS0,04
Segui le verifiche giornaliere di laboratorio
Le pagine attive idonee possono ricevere un’altra verifica programmata dopo un giorno. Esamina il risultato attuale dopo una modifica mirata, considerando il piano e la disponibilità della verifica invece di aspettarti una prova a un’ora esatta garantita.
- Ordina i risultati per URL o stato CWV per organizzare la revisione. FCP, LCP, CLS, TTFB e TBT restano visibili per ogni URL testato.
- Il badge CWV usa la peggiore classificazione disponibile di LCP, CLS e TBT. PASS significa che questi valori disponibili sono buoni; FAIL comprende risultati da migliorare e scarsi.
- Controlla i valori mancanti anche se la riga indica PASS. Una metrica assente non conta come misurazione sana; il badge non certifica la valutazione Google basata su LCP, INP e CLS sul campo.
- Nessun dato indica che il verdetto di laboratorio non è disponibile. Un valore mancante non è zero e una verifica fallita non dimostra che la pagina sia sana.
- Annota i valori attuali prima di pubblicare una correzione, poi confrontali con un risultato successivo dello stesso URL. La tabella mostra risultati attuali, non una cronologia salvata del prima e dopo.
Giornaliero09:00
123456789101112131415161718192021
Leggi i dati con SEO MCP
Porta il riepilogo di laboratorio salvato della homepage in una conversazione IA o in un’integrazione REST. Chiedi una spiegazione delle misurazioni disponibili e un’indagine mirata, distinguendo le prove da una correzione proposta.
- Autenticati e seleziona un progetto accessibile. L’accesso REST richiede anche che Core Web Vitals sia disponibile nel piano del progetto.
- La risposta include l’URL della homepage, l’ora salvata della verifica e i valori disponibili di FCP, LCP, CLS, TTFB, TBT e Speed Index. Sono dati della homepage, non l’elenco di tutte le pagine monitorate.
- Senza una homepage verificata non viene restituito il riepilogo; le singole misurazioni assenti restano indisponibili. Chiedi all’assistente di indicare le lacune prima di trarre conclusioni.
- Lo strumento MCP Core Web Vitals legge dati salvati. Non avvia nuove prove, aggiunge pagine, identifica l’elemento responsabile o trasforma TBT in INP.
GET
/projectsJSON{
"data": [
{ "domain": "example.com" }
]
}Parla di Core Web Vitals. Con SEO MCP.
Leggi il riepilogo di laboratorio salvato della homepage del progetto tramite SEO MCP. Spiega le metriche disponibili con URL e ora della verifica, poi scegli cosa indagare senza presumere un rapporto di tutte le pagine o un nuovo test.
- Screpy: Ciao! Vediamo Core Web Vitals per example.com. Cosa vuoi sapere?
- Tu: Spiega i risultati di laboratorio salvati della homepage di example.com e indica ciò che resta sconosciuto.
- Screpy: In questo esempio della homepage, LCP è 3,2 s e richiede miglioramenti; CLS è 0,04 ed è buono. Controlla URL e ora salvati prima di usare i valori. Questi due numeri non mostrano tutte le metriche, non misurano INP e non identificano l’elemento responsabile. Posso suggerire un’indagine, non eseguire un nuovo test. Valori di esempio della homepage in laboratorio: LCP: 3,2 s. CLS: 0,04.
- Tu: Trasformalo in un breve piano d’azione.
- Screpy: Terrò separati i risultati dalle raccomandazioni. Esamina le prove, scegli una modifica e controlla poi i risultati. I prossimi passi: Esamina: Controlla fonte e data di ogni risultato.. Decidi: Scegli la prima modifica.. Verifica: Confronta i risultati dopo la modifica..
- Tu: Puoi spiegare le prove con parole semplici?
- Screpy: Sì. Chiedi di un risultato supportato e spiegherò cosa mostra, da dove proviene e quali incertezze restano. I dati mancanti restano indisponibili; le raccomandazioni non sono correzioni automatiche.
Trasforma un URL lento in una correzione delle prestazioni verificabile.
Mantieni stabili URL e metodo di misurazione, usa la metrica più debole per restringere l’indagine e valida una modifica con un controllo successivo.
-
Scegli un URL pubblico rappresentativo
Scegli URL pubblici del dominio del progetto o dei suoi sottodomini. Inizia dalla homepage, da un ingresso di conversione e da un URL rappresentativo di un modello importante, entro la quota del progetto.
-
Lascia che il controllo programmato stabilisca una baseline
Gli URL attivi idonei ricevono controlli programmati ricorrenti. Dopo il primo tentativo, esamina i valori disponibili di FCP, LCP, CLS, TTFB e TBT dell’URL testato; il riepilogo separato della homepage include anche Speed Index.
-
Segui la metrica debole fino a un’ipotesi mirata
Usa la metrica debole per scegliere un’indagine: LCP per il contenuto principale, CLS per movimenti inattesi, TBT per lavoro bloccante, FCP e TTFB per la fase iniziale. Speed Index della homepage aggiunge contesto visivo, senza dimostrare una causa.
-
Cambia una causa e misura di nuovo
Annota i valori prima di una modifica mirata, mantieni stabile l’URL e confronta un risultato programmato successivo. Il pannello mostra misure attuali: conserva separatamente la base precedente e analizza cambiamenti ripetuti, senza considerare prova una sola oscillazione.
Monitora le pagine dove una regressione avrebbe il maggiore impatto.
Un piccolo insieme di URL rappresentativi è più facile da analizzare di una dashboard piena di pagine di basso valore. Inizia dai percorsi critici e dai modelli riutilizzabili.
Modelli di pagina condivisi
Scegli un URL rappresentativo di prodotto, categoria, articolo o documentazione per individuare problemi che possono ripetersi nello stesso modello.
Percorsi di conversione
Mantieni visibili pagine di prezzo, registrazione, lead e ingresso al checkout quando script, embed, esperimenti o tag di terze parti cambiano le prestazioni.
Pagine sensibili alle release
Monitora URL interessati da redesign, cambi di framework, nuovi media, aggiornamenti del tag manager o modifiche di distribuzione prima di estendere il modello.
Interpreta i risultati di laboratorio senza sopravvalutarli.
Screpy rende utilizzabili i controlli ricorrenti delle prestazioni. Questi limiti mantengono il risultato accurato quando la domanda riguarda dati sul campo, causa o impatto sul ranking.
Dati di laboratorio, non dati sul campo
Screpy esegue test controllati delle pagine. Il risultato non rappresenta il dataset degli utenti reali riportato da Chrome UX Report o Google Search Console.
TBT non è INP
TBT descrive il lavoro bloccante nel periodo di caricamento misurato. INP richiede misure di interazioni e può essere testato in laboratorio eseguendole; questa funzione Screpy non riporta INP e non sostituisce prove sulla reattività degli utenti reali.
Un verdetto non è una causa principale
Una metrica scarsa indica dove indagare. Conferma elemento, richiesta, script, modello o comportamento del server prima di decidere cosa cambiare.
Le prestazioni non garantiscono il ranking
Una buona esperienza della pagina aiuta utenti e ricerca, ma non sostituisce contenuti pertinenti, scansione, indicizzazione, link o altri segnali.
Usa il flusso delle prestazioni adatto alla domanda.
Monitora URL selezionati per risultati ricorrenti di laboratorio, esegui un audit del sito per modelli tecnici ripetuti o leggi la metodologia prima di confrontare i dati sul campo.
Monitora URL pubblici selezionati del progetto con controlli ricorrenti: cinque metriche nella tabella e sei nel riepilogo separato della homepage.
Scansiona il sito per trovare link, immagini e problemi di pagina intorno a un URL o modello interessato. Usa i risultati come contesto tecnico, non come una traccia delle prestazioni.
Comprendi ambito, tempi e limiti dei dati di laboratorio Screpy prima di confrontarli con report di utenti reali.
Documentazione di Screpy
Impara a interpretare i controlli delle prestazioni di laboratorio
Usa la guida per selezionare URL, leggere metriche di laboratorio e distinguerle dai dati sul campo. Conserva separatamente una base iniziale prima di confrontare un miglioramento mirato con un risultato successivo.
Risposte alle domande sul monitoraggio Core Web Vitals.
Comprendi dati di laboratorio e sul campo, LCP, CLS, TBT, metriche di velocità, controlli giornalieri, scelta degli URL, verdetti e limiti delle affermazioni sull’esperienza della pagina.
Perché Screpy mostra TBT invece di INP?
Questa funzione misura il caricamento e fornisce TBT come diagnostica del blocco; non misura le interazioni richieste per INP. INP può essere testato in laboratorio eseguendo interazioni, ma TBT non è INP e non descrive ogni interazione dopo il caricamento.
Quali metriche sono i Core Web Vitals ufficiali?
Google definisce attualmente Largest Contentful Paint, Interaction to Next Paint e Cumulative Layout Shift come Core Web Vitals. Screpy misura LCP e CLS in laboratorio e riporta TBT come diagnostico insieme a FCP, TTFB e Speed Index. Non presenta TBT come INP.
Migliorare i Core Web Vitals garantisce ranking più alti?
No. Google raccomanda buoni Core Web Vitals per utenti e ricerca, ma l’esperienza della pagina è solo una parte dei segnali. Contenuti pertinenti possono posizionarsi anche con un’esperienza più debole e una pagina veloce non garantisce il ranking.
Con quale frequenza vengono controllati gli URL monitorati?
Gli URL attivi idonei possono ricevere un nuovo controllo programmato dopo un giorno. Piano del progetto e disponibilità del controllo influenzano il completamento: non è garantito un risultato alla stessa ora ogni giorno. Un nuovo URL compare nella tabella dopo il primo tentativo di controllo.
Quali pagine devo monitorare per prime?
Inizia da homepage, pagine pubbliche importanti, ingressi di conversione e un URL rappresentativo per ogni modello rilevante. Gli URL aggiunti devono appartenere al dominio del progetto o ai sottodomini e rientrare nella quota. Un campione di modello non testa tutte le sue pagine.
Cosa misura il monitoraggio Core Web Vitals di Screpy?
La tabella degli URL Screpy mostra FCP, LCP, CLS, TTFB e TBT in laboratorio. Il riepilogo della homepage verificata aggiunge Speed Index. La tabella usa PASS/FAIL; le risposte autenticate API e MCP espongono anche URL della homepage e ora salvata del controllo. Non sono misure di utenti reali.
I dati Core Web Vitals di Screpy si basano su utenti reali?
No. Screpy riporta misurazioni controllate per l’URL verificato. I dati sul campo di Chrome UX Report o Google Search Console riflettono visite reali in un periodo mobile e possono differire per dispositivi, reti, area geografica e comportamento.
Un PASS di Screpy significa che l’URL supera i Core Web Vitals di Google?
No. Il verdetto della tabella usa la peggiore classificazione disponibile di LCP, CLS e TBT in laboratorio e può avere valori mancanti. Google valuta dati reali degli utenti, incluso INP, con regole proprie di copertura e percentili. Esamina le metriche disponibili e il relativo rapporto sul campo prima di concludere.