La sezione Servizi in background di Chrome DevTools è una raccolta di strumenti per le API JavaScript che consente al tuo sito web di inviare e ricevere aggiornamenti anche quando un utente non ha aperto il sito. Un servizio in background è funzionalmente simile a un processo in background.
La sezione Servizi in background ti consente di eseguire il debug dei seguenti servizi in background:
- Recupero in background
- Sincronizzazione in background
- Notifiche
- Caricamenti speculativi
- Messaggi push
Chrome DevTools può registrare eventi di recupero, sincronizzazione e notifica per tre giorni, anche quando DevTools non è aperto. In questo modo, puoi assicurarti che gli eventi vengano inviati e ricevuti come previsto.
Oltre agli eventi dei servizi in background, DevTools può:
- Mostrare i report che Chrome ha già inviato o sta per inviare utilizzando l'API Reporting.
- Consente di eseguire il debug e testare la cache back-forward con un solo clic.
Recupero in background
L'API Background Fetch consente a un service worker di scaricare in modo affidabile risorse di grandi dimensioni, come film o podcast, come servizio in background. Per registrare gli eventi di recupero in background per tre giorni, anche quando DevTools non è aperto:
- Apri DevTools, ad esempio in questa pagina dimostrativa.
Vai ad Applicazione > Servizi in background > Recupero in background e fai clic su
Registra.
Nella pagina di demo, fai clic su Memorizza gli asset localmente. Questo attiva alcune attività di recupero in background. DevTools registra gli eventi nella tabella.
Fai clic su un evento per visualizzarne i dettagli nello spazio sotto la tabella.
Puoi chiudere DevTools e lasciare in esecuzione la registrazione per un massimo di tre giorni. Per interrompere la registrazione, fai clic su
Interrompi.
Sincronizzazione in background
L'API Background Sync consente a un service worker offline di inviare dati a un server dopo aver ristabilito una connessione a internet affidabile. Per registrare gli eventi di sincronizzazione in background per tre giorni, anche quando DevTools non è aperto:
- Apri DevTools, ad esempio in questa pagina dimostrativa.
Vai ad Applicazione > Servizi in background > Sincronizzazione in background e fai clic su
Registra.
Nella pagina di demo, fai clic su Registra sincronizzazione in background per registrare il rispettivo service worker e fai clic su Consenti quando richiesto.
La registrazione del service worker è un'attività di sincronizzazione in background. DevTools registra gli eventi nella tabella.
Fai clic su un evento per visualizzarne i dettagli nello spazio sotto la tabella.
Puoi chiudere DevTools e lasciare in esecuzione la registrazione per un massimo di tre giorni. Per interrompere la registrazione, fai clic su
Interrompi.
(Sperimentale) Mitigazioni del monitoraggio del rimbalzo
L'esperimento Mitigazioni del monitoraggio dei tassi di abbandono in Chrome ti consente di identificare ed eliminare lo stato dei siti che sembrano eseguire il monitoraggio tra siti utilizzando la tecnica di monitoraggio dei tassi di abbandono. Puoi forzare manualmente le mitigazioni del monitoraggio e visualizzare un elenco dei siti di cui sono stati eliminati gli stati.
Per forzare le mitigazioni del monitoraggio:
- Blocca i cookie di terze parti in Chrome. Vai a
> Impostazioni >
Privacy e sicurezza > Cookie e altri dati dei siti >
Blocca cookie di terze parti e attiva l'opzione.
- In
chrome://flags
, imposta l'esperimento Mitigazioni del monitoraggio del rimbalzo su Attivato con eliminazione. - Apri DevTools, ad esempio nella pagina demo, e vai a Application (Applicazione) > Background services (Servizi in background) > Bounce tracking mitigations (Mitigazioni del monitoraggio dei giri a vuoto).
- Nella pagina di dimostrazione, fai clic su un link di abbandono e attendi 10 secondi affinché Chrome registri l'abbandono. La scheda Problemi ti avvisa dell'imminente eliminazione dello stato.
- Fai clic su Esegui forzatamente per eliminare immediatamente lo stato.
Notifiche
Dopo che un service worker ha ricevuto un messaggio push da un server, il service worker utilizza l'API Notifications per mostrare i dati a un utente. Per registrare le notifiche per tre giorni, anche quando DevTools non è aperto:
- Apri DevTools, ad esempio in questa pagina dimostrativa.
Vai ad App > Servizi in background > Notifiche e fai clic su
Registra.
Nella pagina di demo, fai clic su Pianifica notifica e Consenti quando richiesto.
Attendi la visualizzazione della notifica. DevTools registra gli eventi di notifica nella tabella.
Fai clic su un evento per visualizzarne i dettagli nello spazio sotto la tabella.
Puoi chiudere DevTools e lasciare in esecuzione la registrazione per un massimo di tre giorni. Per interrompere la registrazione, fai clic su
Interrompi.
Caricamenti speculativi
I caricamenti speculativi consentono un caricamento quasi istantaneo della pagina in base alle regole di speculazione che definisci. In questo modo, il tuo sito web può eseguire il pre-caricamento e il pre-rendering della maggior parte delle pagine visitate.
Il pre-caricamento recupera una risorsa in anticipo, mentre il pre-rendering fa un passo avanti e esegue il rendering dell'intera pagina in un processo di rendering in background nascosto.
Puoi eseguire il debug dei carichi speculativi nella sezione Applicazione > Servizi in background > Caricamenti speculativi. La sezione contiene tre visualizzazioni:
- Caricamenti speculativi. Contiene lo stato speculativo della pagina corrente, l'URL corrente, le pagine che la pagina corrente tenta di caricare in modo speculativo e i relativi stati.
- Regole. Contiene i set di regole nella pagina corrente nel riquadro Elementi e lo stato generale delle speculazioni.
- Spieghi. Contiene una tabella con informazioni sui tentativi di caricamento speculativi e sui relativi stati. Se un tentativo non è riuscito, puoi fare clic su di esso nella tabella per visualizzare informazioni dettagliate e il motivo dell'errore.
Prova a eseguire il debug dei caricamenti speculativi in questa pagina dimostrativa:
Apri DevTools nella pagina e vai ad Applicazione > Servizi in background > Carichi speculativi. Se non vedi caricamenti speculativi avviati dalla pagina, ricaricala.
La pagina iniziale della demo esegue il prerendering di due pagine e non riesce a eseguirlo per una. Fai clic su Visualizza tutte le speculazioni.
In Stime, seleziona la stima con lo stato Errore per visualizzare il Motivo dell'errore, la sezione con informazioni dettagliate in basso.
In questo caso, il prerendering non è riuscito perché sul sito web non è presente una pagina
/next3.html
.Apri la sezione Regole e fai clic su Stato per visualizzare l'insieme di regole in basso. Se fai clic sul link Set di regole, si apre il riquadro Elementi e viene mostrato dove è definita la regola di speculazione.
Per una procedura dettagliata, vedi Eseguire il debug delle regole di speculazione.
Messaggi push
Per mostrare una notifica push a un utente, un service worker deve prima utilizzare l'API PushMessage per ricevere i dati da un server. Quando il service worker è pronto per visualizzare la notifica, utilizza l'API Notifications. Per registrare i messaggi push per tre giorni, anche quando DevTools non è aperto:
- Apri DevTools, ad esempio in questa pagina dimostrativa.
Vai a App > Servizi in background > Messaggistica push e fai clic su
Registra.
Nella pagina di demo, attiva/disattiva l'opzione Attiva notifiche push, fai clic su Consenti quando richiesto, digita un messaggio e invialo. DevTools registra gli eventi di notifica push nella tabella.
Fai clic su un evento per visualizzarne i dettagli nello spazio sotto la tabella.
Puoi chiudere DevTools e lasciare in esecuzione la registrazione per un massimo di tre giorni. Per interrompere la registrazione, fai clic su
Interrompi.
API di reporting
Alcuni errori si verificano solo in produzione. Non li vedi mai localmente o durante lo sviluppo perché utenti, reti e dispositivi reali cambiano le carte in tavola.
Ad esempio, supponiamo che il tuo nuovo sito si basi su software di terze parti che utilizza document.write()
per caricare script critici. Nuovi utenti di tutto il mondo aprono il tuo sito, ma potrebbero avere connessioni più lente rispetto a quelle utilizzate per il test. A tua insaputa, il tuo sito inizia a non funzionare per loro perché Chrome interviene contro document.write()
su reti lente. In alternativa, ti consigliamo di tenere d'occhio le API ritirate o in procinto di essere ritirate che potrebbero essere utilizzate nel tuo codebase.
L'API Reporting è progettata per aiutarti a monitorare le chiamate API ritirate, le violazioni della sicurezza della tua pagina e altro ancora. Puoi configurare i report come descritto in Monitorare l'applicazione web con l'API Reporting.
Per visualizzare i report generati da una pagina:
- Vai a
chrome://flags/#enable-experimental-web-platform-features
, imposta Funzionalità sperimentali della piattaforma web su Abilitato e riavvia Chrome. Apri DevTools e vai ad Application (Applicazione) > Background services (Servizi in background) > Reporting API (API Reporting). Ad esempio, puoi consultare i report in questa pagina demo.
La scheda API di reporting è suddivisa in tre parti:
- La tabella Report con le seguenti informazioni su ogni report:
- URL che ha causato la generazione del report
- Tipo di violazione
- Stato del report
- Endpoint Destinazione
- Timestamp Generato
- Testo del report
- La sezione di anteprima del Testo del report. Per visualizzare l'anteprima del corpo di un report, fai clic su un report nella tabella dei report.
- La sezione Endpoint con una panoramica di tutti gli endpoint configurati nell'intestazione
Reporting-Endpoints
.
Stato del report
La colonna Stato indica se Chrome ha inviato il report correttamente, sta per inviarlo o se l'invio non è riuscito.
Stato | Descrizione |
---|---|
Success |
Il browser ha inviato il report e l'endpoint ha risposto con un codice di esito positivo (200 o un altro codice di risposta di esito positivo 2xx ). |
Pending |
Il browser sta tentando di inviare il report. |
Queued |
Il report è stato generato e il browser non sta ancora tentando di inviarlo. Un report viene visualizzato come Queued in uno dei seguenti due casi:
|
MarkedForRemoval |
Dopo aver riprovato per un po' di tempo (Queued ), il browser ha smesso di provare a inviare il report e lo rimuoverà a breve dall'elenco dei report da inviare. |
I report vengono rimossi dopo un po' di tempo, indipendentemente dal fatto che siano stati inviati correttamente o meno.