Tempi di caricamento su pianificazione
Sei tempi vengono registrati ad ogni esecuzione: Largest Contentful Paint, First Contentful Paint, Cumulative Layout Shift, Time to First Byte, Speed Index e Total Blocking Time.
Monitoraggio della velocità delle pagine
Rilevare le regressioni di performance
Rilevare le regressioni di performance
prima che vadano in produzione.
Audit Lighthouse pianificati, eseguiti tramite la Google PageSpeed Insights API, che monitorano nel tempo i punteggi Lighthouse e i tempi di caricamento, così un deploy lento non raggiunge mai gli utenti in silenzio.
Free tier included
No credit card
2-minute setup
Controlli di performance che funzionano come un utente reale.
Ogni audit è un'esecuzione Lighthouse completa sulla tua URL live, quindi misura rendering, esecuzione degli script e layout shift invece di un semplice ping al server. Inviamo la URL alla Google PageSpeed Insights API e archiviamo ciò che torna, quindi il browser che esegue il rendering è quello di Google e non il nostro. Ogni risultato viene conservato, così puoi tracciare qualsiasi punteggio o tempo attraverso i rilasci.
Gli audit vengono eseguiti ogni 6 ore sulla URL esatta che ci indichi, quindi puoi puntarne uno sul checkout o sui risultati di ricerca e non solo sulla homepage. Non seguono l'intervallo del controllo HTTP.
Audit desktop
Gli audit vengono eseguiti sul profilo desktop, il valore predefinito di Google PageSpeed Insights. Oggi non eseguiamo un audit mobile separato, e preferiamo dirlo piuttosto che lasciarti supporre che una regressione mobile verrebbe rilevata.
Grafici di tendenza tra i rilasci
Ogni punteggio e ogni tempo grezzo viene archiviato con il momento della misurazione, così puoi tracciare i cambiamenti nel corso di giorni, settimane o tra deployment specifici.
Quattro categorie Lighthouse
Performance, Accessibilità, SEO e Best Practice vengono valutate ad ogni esecuzione, così una modifica che aiuta la velocità e danneggia l'accessibilità non passa inosservata.
Una soglia sul punteggio di performance
Il monitor fallisce quando il punteggio Lighthouse di performance scende sotto 0,5, e un alert si attiva. Oggi quella soglia è fissa: non esistono budget per metrica né un modo per cambiare il numero, e questa pagina lo dirà finché non ci saranno.
Alert per regressione su tutti i canali
Instradare gli alert di calo del punteggio verso Slack, Teams, email o qualsiasi webhook così l'ingegnere che ha effettuato il deploy ne viene informato immediatamente.
Risultati accurati come in produzione
Rendering reale, non
Rendering reale, non
curl con un cronometro.
Gli strumenti di velocità che si basano su misurazioni solo HTTP perdono l'esecuzione di JS, le risorse che bloccano il rendering e i layout shift che definiscono l'esperienza utente reale. Ogni audit è un'esecuzione Lighthouse completa tramite la Google PageSpeed Insights API, quindi il rendering avviene in un browser reale, anche se è quello di Google e non il nostro.
- Rendering completo del browser inclusa l'esecuzione JS e i cicli di paint
- Audit su qualsiasi URL: link diretto al checkout o alla ricerca, non solo alla homepage
- Eseguito secondo la pianificazione del monitor a cui è collegato
acme.com / checkout HealthyLIVE
LCP2.1s
CLS0.02
PERF SCORE91
LCP2100ms
FCP1050ms
TTFB420ms
TBT210ms
Speed Index1640ms
Operativo in pochi minuti
Un interruttore sul monitor
Un interruttore sul monitor
che hai già.
Il page speed non è un monitor separato da configurare. Attivalo su un monitor HTTP esistente e l'audit viene eseguito insieme al controllo, sulla stessa pianificazione, e l'alert raggiunge chi è in reperibilità attraverso i canali che quel monitor già usa.
- Un flag sul monitor, nessuna seconda cosa da configurare
- Gli alert passano dai tuoi gruppi di notifica esistenti
- Ogni esecuzione viene archiviata, così la regressione ha un prima e un dopo
add a speed audit$ curl -X POST https://api.siteqwality.com/http/job \
-H "Authorization: Bearer $SQ_TOKEN" \
-d '{"uri":"https://acme.com/checkout","method":"GET","timeout_ms":10000,
"run_interval_seconds":300,"monitor_page_speed":true}'
$ curl https://api.siteqwality.com/http/job/$JOB_ID/page_speed
✓ performance_score, lcp_ms, fcp_ms, cls, ttfb_ms, speed_index_ms
-H "Authorization: Bearer $SQ_TOKEN" \
-d '{"uri":"https://acme.com/checkout","method":"GET","timeout_ms":10000,
"run_interval_seconds":300,"monitor_page_speed":true}'
$ curl https://api.siteqwality.com/http/job/$JOB_ID/page_speed
✓ performance_score, lcp_ms, fcp_ms, cls, ttfb_ms, speed_index_ms
10
punteggi e tempi archiviati ad ogni esecuzione
4
categorie Lighthouse valutate: performance, accessibilità, SEO, best practice
$0
piano gratuito, inizia senza carta di credito
0.5
l'unica soglia fissa, sul punteggio performance di Lighthouse: sotto di essa il monitor risulta fallito
FAQ
Site Qwality esegue audit su pianificazione, archivia ogni risultato, ne traccia le tendenze nel tempo e invia alert quando i punteggi regrediscono. Un'esecuzione singola di Lighthouse dice dove ci si trova oggi, mentre gli audit pianificati informano nel momento in cui qualcosa cambia.
Ad ogni esecuzione vengono archiviati dieci valori: i quattro punteggi di categoria Lighthouse (Performance, Accessibilità, SEO, Best Practice) e sei tempi (Largest Contentful Paint, First Contentful Paint, Cumulative Layout Shift, Time to First Byte, Speed Index e Total Blocking Time). E per essere espliciti su cosa non c'è, perché viene spesso dato per scontato: nessun Interaction to Next Paint, nessun Time to Interactive, nessun waterfall delle risorse, nessuno screenshot, nessun peso totale della pagina e nessun conteggio delle richieste.
No. Gli audit vengono eseguiti sul profilo desktop, il valore predefinito dell'API che chiamiamo. Un audit mobile sarebbe una seconda esecuzione con una strategia diversa e oggi non la effettuiamo.
Non per il page speed. L'audit invia la tua URL alla Google PageSpeed Insights API, che recupera la pagina come visitatore anonimo, quindi una pagina dietro un login non può essere valutata in questo modo. Per i percorsi autenticati la funzione giusta sono i nostri browser check.
Oggi no. Esiste una sola soglia, sul punteggio Lighthouse di performance, ed è fissa a 0,5. Scendere sotto quel valore segna il monitor come fallito e attiva un alert. Le soglie di warn e fail per metrica non esistono, e né la dashboard né l'API possono cambiare il numero.
Secondo la pianificazione che imposti per il monitor a cui l'audit è collegato. Tieni presente che ogni esecuzione chiama un'API di Google, quindi un intervallo molto stretto raramente conviene per un audit di page speed come invece conviene per un controllo di uptime.
Related features
Inizia gratis. Nessuna carta di credito.
Uptime, cron, synthetic, log, RUM, incidenti e pagine di stato. Piano gratuito su ogni prodotto.