Sperimentazione con la misurazione delle navigazioni soft

Barry Pollard

Michal Mocny

Pubblicato: 1° febbraio 2023, ultimo aggiornamento: 30 marzo 2026

Dal suo lancio, l'iniziativa Core Web Vitals ha cercato di misurare l'esperienza utente effettiva di un sito web, anziché i dettagli tecnici alla base della creazione o del caricamento di un sito web. Le tre metriche Core Web Vitals sono state create come metriche incentrate sull'utente, un'evoluzione rispetto alle metriche tecniche esistenti come DOMContentLoaded o load, che misuravano tempi spesso non correlati alla percezione delle prestazioni della pagina da parte degli utenti. Per questo motivo, la tecnologia utilizzata per creare il sito non dovrebbe influire sul punteggio, a condizione che il sito funzioni bene.

La realtà è sempre un po' più complicata dell'ideale e la popolare architettura applicazione a pagina singola non è mai stata completamente supportata dalle metriche Core Web Vitals. Anziché caricare pagine web distinte e individuali mentre l'utente naviga nel sito, queste applicazioni web utilizzano le cosiddette "navigazioni soft", in cui il contenuto della pagina viene modificato da JavaScript. In queste applicazioni, l'illusione di un'architettura di pagina web convenzionale viene mantenuta modificando l'URL e inserendo gli URL precedenti nella cronologia del browser per consentire ai pulsanti Indietro e Avanti di funzionare come previsto dall'utente.

Molti framework JavaScript utilizzano questo modello, ma ognuno in modo diverso. Poiché questo comportamento non rientra in ciò che il browser considera tradizionalmente una "pagina", la misurazione è sempre stata difficile: dove deve essere tracciata la linea di demarcazione tra un'interazione nella pagina corrente e una pagina nuova?

Il team di Chrome sta valutando questa sfida da un po' di tempo e sta cercando di standardizzare una definizione di "navigazione soft" e di come i Core Web Vitals possono essere misurati per questo, in modo simile a come vengono misurati i siti web implementati nell'architettura convenzionale multi-pagina (MPA).

Abbiamo apportato diversi miglioramenti all'API in base al feedback degli sviluppatori per l'ultima prova dell'origine e ora chiediamo agli sviluppatori di provare l'ultima iterazione e fornire feedback sull'approccio prima del lancio. Siamo abbastanza sicuri di dove sia arrivata l'API nel corso di queste iterazioni e puntiamo a lanciarla entro la fine dell'anno, in base al feedback su questa ultima prova dell'origine.

Che cos'è una navigazione soft?

Abbiamo elaborato la seguente definizione di navigazione soft:

• La navigazione viene avviata da un'azione utente.
• La navigazione comporta una modifica visibile dell'URL per l'utente.
• L'interazione genera un rendering visibile.

Per alcuni siti, queste euristiche possono portare a falsi positivi (che gli utenti non considererebbero realmente una "navigazione ") o falsi negativi (in cui l'utente considera una "navigazione" nonostante non soddisfi questi criteri). Accettiamo feedback sulle euristiche nel repository delle specifiche di navigazione soft.

Supporto di DevTools per le navigazioni soft

Abbiamo aggiunto il supporto per le navigazioni soft al riquadro Prestazioni di DevTools nella visualizzazione Traccia:

Puoi visualizzare i marcatori per la navigazione soft e LCP, entrambi contrassegnati con un * per distinguerli dalle normali voci di navigazione hard. Questa funzionalità è abilitata per impostazione predefinita ed è separata dalle modifiche all'API Performance di cui parleremo di seguito. È un modo rapido per verificare se l'esperimento di navigazione soft funziona correttamente per il tuo sito.

Per ora, nella visualizzazione della traccia vengono visualizzati solo i timestamp di navigazione soft e LCP. Altre metriche (ad esempio LCP) e il supporto nella visualizzazione Metriche live verranno aggiunti in un secondo momento.

In che modo Chrome implementa le navigazioni soft per gli sviluppatori web?

Una volta attivata l'euristica di navigazione soft (maggiori dettagli nella sezione successiva), Chrome cambierà il modo in cui vengono registrate alcune metriche sul rendimento:

• Un evento soft-navigation PerformanceTiming verrà emesso dopo ogni navigazione temporanea rilevata.
• Questa voce soft-navigation includerà un navigationId, il nuovo URL nell'attributo name e un interactionId dell'interazione iniziale.
• Una o più voci interaction-contentful-paint verranno emesse dopo le interazioni che causano un rendering significativo dei contenuti. Può essere utilizzato per misurare la metrica Largest Contentful Paint (LCP) per le navigazioni soft quando l'interazione genera una navigazione soft.
• L'attributo navigationId viene aggiunto a ciascuna delle tempistiche del rendimento (first-paint, first-contentful-paint, largest-contentful-paint, interaction-contentful-paint, first-input-delay, event e layout-shift). Corrisponde alla voce di navigazione in cui è stato emesso l'evento. Tieni presente che quando queste voci si estendono alle navigazioni soft, possono contenere il navigationId precedente o successivo a seconda di quando è stata emessa la voce. Scopri di più nella sezione Generare report sulle metriche in base all'URL appropriato.
• soft-navigation includerà una voce largestInteractionContentfulPaint, che a sua volta includerà la voce interaction-contentful-paint più grande emessa nell'ambito della navigazione. Questo valore può essere utilizzato come LCP iniziale per la navigazione e può essere aggiornato man mano che vengono osservate altre voci interaction-contentful-paint per l'interazione.
• Potenzialmente, alcune voci interaction-contentful-paint potrebbero essere state registrate prima della navigazione soft (se l'aggiornamento dell'URL non avviene prima di questi rendering). In questi casi, la voce largestInteractionContentfulPaint più grande evita la necessità di bufferizzare e rivedere le voci precedenti. Tieni presente che largestInteractionContentfulPaint è una copia esatta della voce interaction-contentful-paint più grande, quindi questa voce avrà utilizzato il precedente navigationId, poiché è stato in quel momento che è stata eseguita la pittura, ma queste pitture devono essere misurate in base al nuovo navigationId.
• La voce soft-navigation includerà anche paintTime e presentationTime come FCP per quella navigazione.
• Tieni presente che verranno emesse anche voci interaction-contentful-paint dopo ulteriori interazioni, ma LCP per un URL deve essere limitato alle voci interaction-contentful-paint che corrispondono alle navigazioni temporanee interactionId per escluderle.

Queste modifiche consentiranno di misurare i Core Web Vitals e alcune delle metriche diagnostiche associate per ogni navigazione della pagina, anche se è necessario considerare alcune sfumature.

Quali sono le implicazioni dell'attivazione delle navigazioni soft in Chrome?

Di seguito sono riportate alcune delle modifiche che i proprietari dei siti devono prendere in considerazione dopo aver attivato questa funzionalità:

• Il monitoraggio delle voci soft-navigation consente di "suddividere" le voci di rendimento in ogni "navigazione".
• Le metriche CLS e INP possono già essere suddivise a tua discrezione, anziché essere misurate per tutta la durata del ciclo di vita della pagina, ma l'API Soft Navigation fornisce una misurazione standardizzata di quando ciò si verifica, indipendentemente dalla tecnologia sottostante utilizzata.
• La voce largest-contentful-paint viene finalizzata in un'interazione (necessaria per avviare una navigazione soft), quindi può essere utilizzata solo per misurare l'LCP della navigazione "hard" iniziale. Ciò significa che questo valore non cambierà quando vengono misurate le navigazioni soft, in modo che LCP per il caricamento della pagina iniziale e della navigazione hard possa essere misurato come sempre.
• La nuova voce interaction-contentful-paint emessa dalle interazioni può essere utilizzata per misurare LCP per le navigazioni soft, ma ci sono alcune considerazioni su come utilizzare questa voce che tratteremo in questo articolo.
• Tieni presente che non tutti gli utenti supportano questa API di navigazione soft, in particolare per le versioni precedenti di Chrome e per chi utilizza altri browser. Tieni presente che alcuni utenti potrebbero non segnalare le metriche basate sulla navigazione soft, anche se segnalano le metriche Core Web Vitals.
• In quanto nuova funzionalità sperimentale non attivata per impostazione predefinita, i siti devono testarla per verificare la presenza di effetti collaterali indesiderati.

Verifica con il tuo provider RUM se supporta la misurazione dei Core Web Vitals tramite la navigazione soft. Molti prevedono di testare questo nuovo standard e terranno conto delle considerazioni precedenti. Nel frattempo, alcuni fornitori consentono anche misurazioni limitate delle metriche sul rendimento in base alle proprie euristiche.

Per saperne di più su come misurare le metriche per le navigazioni temporanee, consulta la sezione Misurazione di Core Web Vitals per navigazione temporanea.

Come faccio ad attivare le navigazioni soft in Chrome?

Le navigazioni soft non sono attivate per impostazione predefinita in Chrome, ma sono disponibili per la sperimentazione attivando esplicitamente questa funzionalità.

Per gli sviluppatori, questa opzione può essere attivata impostando il flag su chrome://flags/#soft-navigation-heuristics. In alternativa, può essere attivato utilizzando gli argomenti della riga di comando --enable-features=SoftNavigationHeuristics all'avvio di Chrome. L'attivazione del flag chrome://flags/#enable-experimental-web-platform-features attiva anche le navigazioni soft.

Per un sito web che vuole attivare questa funzionalità per tutti i suoi visitatori per vedere l'impatto, a partire da Chrome 147 verrà eseguita una prova dell'origine che può essere attivata registrandosi alla prova e includendo un elemento meta con il token di prova dell'origine nell'intestazione HTML o HTTP. Per ulteriori informazioni, consulta il post Guida introduttiva alle prove di origine.

I proprietari dei siti possono scegliere di includere la prova dell'origine nelle loro pagine per tutti gli utenti o solo per un sottoinsieme. Tieni presente la sezione Implicazioni precedente in merito a come questa modifica influisce sulla modalità di generazione dei report sulle metriche, soprattutto se attivi questa prova dell'origine per una percentuale elevata di utenti. Tieni presente che CrUX continuerà a generare report sulle metriche nel modo esistente, indipendentemente da questa impostazione di navigazione soft, pertanto non è interessato da queste implicazioni. È inoltre importante notare che le prove dell'origine sono limitate all'attivazione di funzionalità sperimentali su un massimo dello 0,5% di tutti i caricamenti di pagine Chrome come mediana su 14 giorni, ma questo dovrebbe essere un problema solo per i siti molto grandi.

Supporto dell'API Soft Navigations per il rilevamento delle funzionalità

Puoi utilizzare il seguente codice per verificare se l'API è supportata:

if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
  // Monitor Soft Navigations
}

Tieni presente che supportedEntryTypes viene bloccato al primo utilizzo, quindi se il supporto della navigazione soft viene aggiunto dinamicamente da un token di prova dell'origine inserito nella pagina, potrebbe restituire il valore originale, prima dell'attivazione della funzionalità.

In questo caso, mentre le navigazioni soft non sono ancora supportate per impostazione predefinita e si trovano in questo stato di transizione, è possibile utilizzare la seguente alternativa:

if ('SoftNavigationEntry' in window) {
  // Monitor Soft Navigations
}

Come posso misurare le navigazioni soft?

Una volta attivato l'esperimento di navigazione soft, le metriche verranno generate utilizzando l'API PerformanceObserver, come per le altre metriche. Tuttavia, per queste metriche è necessario tenere conto di alcune considerazioni aggiuntive.

Report sulle navigazioni soft

Puoi utilizzare un PerformanceObserver per osservare le navigazioni soft. Di seguito è riportato un esempio di snippet di codice che registra le voci di navigazione soft nella console, incluse le navigazioni soft precedenti in questa pagina utilizzando l'opzione buffered:

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

Può essere utilizzato per finalizzare le metriche della pagina per l'intera durata della navigazione precedente.

Generare report sulle metriche in base all'URL appropriato

Quando viene visualizzata una navigazione soft, i Core Web Vitals della pagina precedente devono essere finalizzati e poi segnalati per l'URL precedente. Il nuovo monitoraggio deve essere avviato per il nuovo URL.

L'attributo name della voce soft-navigation appropriata conterrà il nuovo URL per cui generare le metriche, mentre navigationId sarà il riferimento univoco per questa navigazione (poiché lo stesso URL potrebbe essere visitato più volte durante la durata di una singola applicazione a pagina singola). Puoi cercarlo con l'API PerformanceEntry:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const pageUrl = navEntry?.name;

Segnala l'URL corretto per interaction-contentful-paint

Per calcolare LCP dalle voci interaction-contentful-paint sono necessarie considerazioni aggiuntive, poiché non tutte le voci interaction-contentful-paint devono essere mappate utilizzando navigationId e segnalate come LCP per quell'URL:

• Il primo problema è che le voci interaction-contentful-paint potrebbero essere emesse prima che si verifichi la navigazione temporanea se si verifica un paint prima dell'aggiornamento dell'URL. In questi casi, il navigationId sarà per il vecchio URL. Se l'URL viene aggiornato per primo, il rendering completerà la navigazione temporanea e in questo caso verrà emessa prima la voce soft-navigation e la voce interaction-contentful-paint avrà il nuovo URL.
• Il secondo problema è che a partire dal giorno interaction-contentful-paint, le voci continueranno a essere emesse per le interazioni più recenti, poiché l'ambito di questa metrica sul rendimento si estende oltre il solo LCP per le navigazioni soft. Vogliamo prendere in considerazione solo i paint per il caricamento della navigazione soft per LCP e non quelli per le interazioni successive.

Pertanto, per mappare le voci interaction-contentful-paint a soft-navigation-entries e ottenere l'URL corretto, è necessario utilizzare interactionId anziché navigationId. In questo modo verranno gestite tutte le voci con navigationId precedenti e verranno filtrate tutte le voci interaction-contentful-paint che non devono essere prese in considerazione per LCP.

Inoltre, devi prendere in considerazione l'elaborazione della voce largestInteractionContentfulPaint delle voci soft-navigation, per gestire più facilmente le voci interaction-contentful-paint che si verificano prima dell'emissione di soft-navigation entries.

Ottenere il startTime delle navigazioni soft

Tutti i tempi di rendimento, inclusi quelli per le navigazioni soft, e le voci utilizzate per calcolare le metriche di Core Web Vitals vengono riportati come tempo dalla navigazione nelle pagine "hard" iniziale. Pertanto, il tempo di inizio della navigazione soft deve essere sottratto dai tempi delle metriche di caricamento della navigazione soft (ad esempio LCP), per segnalarli in relazione a questo tempo di navigazione soft.

L'ora di inizio della navigazione può essere ottenuta in modo simile mappando la voce soft-navigation appropriata e utilizzando il relativo startTime.

Il startTime è il momento dell'interazione iniziale (ad esempio, un clic su un pulsante) che ha avviato la navigazione soft. Questo è leggermente diverso dalle "navigazioni hard", in cui l'"ora di inizio" è il momento in cui la nuova pagina viene "confermata" al browser e dopo l'esecuzione di parte del codice del gestore di eventi. Anche i tempi di inizio della navigazione soft includono il codice del gestore di eventi, poiché la misurazione viene effettuata a partire dal tempo di inizio dell'interazione.

Misurare i Core Web Vitals per navigazione soft

Per misurare i Core Web Vitals, ascolta le voci soft-navigation e reimposta le metriche alla ricezione. FCP può essere emesso in base a presentationTime e LCP può essere inizializzato su largestInteractionContentfulPaint. INP e CLS devono essere inizializzati su 0 come per il caricamento pagina.

LCP, INP e CLS possono quindi essere misurati e monitorati come di consueto (con l'eccezione dell'utilizzo di interaction-contentful-paint per LCP che fornisce le corrispondenze interactionId). interactionId e navigationId possono essere utilizzati per assegnare un nome alle voci di un URL, come descritto in precedenza.

I tempi verranno comunque restituiti rispetto all'ora di inizio della navigazione "hard" originale. Quindi, per calcolare LCP per una navigazione soft, ad esempio, dovrai prendere la sincronizzazione interaction-contentful-paint e sottrarre l'ora di inizio della navigazione soft appropriata, come descritto in precedenza, per ottenere una sincronizzazione relativa alla navigazione soft.

Alcune metriche sono state tradizionalmente misurate durante il ciclo di vita della pagina: LCP, ad esempio, può cambiare fino a quando non si verifica un'interazione. CLS e INP possono essere aggiornati fino a quando non si esce dalla pagina, indipendentemente dalle interazioni. Pertanto, le metriche della navigazione precedente devono essere finalizzate a ogni nuova navigazione soft. Ciò significa che le metriche di navigazione "hard" iniziali potrebbero essere finalizzate prima del solito quando si misurano i Core Web Vitals con le navigazioni soft.

Allo stesso modo, quando inizi a misurare le metriche per la nuova navigazione soft di queste metriche di lunga durata, le metriche dovranno essere "reimpostate" o "reinizializzate" e trattate come nuove metriche, senza memoria dei valori impostati per le "pagine" precedenti. ovvero la comprensione di quale sia la pittura, l'interazione con il successivo paint o lo spostamento del layout "più grande" viene reimpostata per consentire una nuova misurazione da zero.

Come devono essere trattati i contenuti che rimangono invariati tra le navigazioni?

LCP per le navigazioni soft (calcolato da interaction-contentful-paint) misurerà solo i nuovi paint e solo quelli associati all'interazione che ha causato la navigazione. Ciò può comportare un LCP diverso, ad esempio, da un caricamento completo di quella navigazione soft a un caricamento soft.

Ad esempio, prendi una pagina che include un'immagine del banner di grandi dimensioni che è l'elemento LCP, ma il testo sottostante cambia a ogni navigazione temporanea. Il caricamento iniziale della pagina contrassegnerà l'immagine del banner come elemento LCP e baserà la tempistica LCP su questo elemento. Per le navigazioni soft successive, il testo sottostante sarà l'elemento più grande visualizzato dopo la navigazione soft e sarà il nuovo elemento LCP. Tuttavia, se la pagina viene caricata con un link diretto all'URL di navigazione soft, l'immagine del banner sarà un nuovo paint e pertanto potrà essere considerata come elemento LCP.

Allo stesso modo, un'animazione potrebbe aggiornare continuamente una parte della pagina, indipendentemente da qualsiasi navigazione soft. Eventuali nuovi paint dovuti all'animazione dello sfondo non verranno presi in considerazione per LCP per la nuova navigazione soft. Tuttavia, potrebbero essere presi in considerazione per LCP se la pagina è stata ricaricata da questo URL.

Come mostrano questi esempi, l'elemento LCP per la navigazione soft può essere segnalato in modo diverso a seconda di come viene caricata la pagina, proprio come il caricamento di una pagina con un link di ancoraggio più in basso nella pagina può comportare un elemento LCP diverso per le navigazioni hard.

Come misurare il TTFB?

Il Time to First Byte (TTFB) per un caricamento della pagina convenzionale rappresenta il tempo in cui vengono restituiti i primi byte della richiesta originale.

Per una navigazione soft, questa è una domanda più difficile. Dobbiamo misurare la prima richiesta effettuata per la nuova pagina? Cosa succede se tutti i contenuti sono già presenti nell'app e non ci sono richieste aggiuntive? Che cosa succede se la richiesta viene effettuata in anticipo con un prefetch? Cosa succede se una richiesta non correlata alla navigazione soft dal punto di vista dell'utente (ad esempio, è una richiesta di analisi)?

Un metodo più semplice consiste nel segnalare un TTFB pari a 0 per le navigazioni soft, in modo simile a quanto consigliato per i ripristini della cache back-forward. Questo è il metodo utilizzato dalla libreria web-vitals per le navigazioni soft e quello che consigliamo per questa metrica al momento.

Devi misurare i Core Web Vitals con entrambe le metodologie?

Durante questo esperimento, ti consigliamo di continuare a misurare i tuoi Core Web Vitals nel modo attuale, in base alle navigazioni di pagina "hard", poiché la nuova implementazione potrebbe presentare problemi o modifiche prima di essere rilasciata definitivamente. In questo modo, i dati corrisponderanno a quelli misurati da CrUX per il momento (ne parleremo meglio più avanti).

Oltre a queste, devono essere misurate anche le navigazioni soft per consentirti di vedere come potrebbero essere misurate in futuro e per darti l'opportunità di fornire feedback al team di Chrome su come funziona questa implementazione nella pratica. In questo modo, tu e il team di Chrome potrete definire l'API in futuro.

Per LCP, ciò significa considerare solo le voci largest-contentful-paint per il metodo attuale e le voci largest-contentful-paint e interaction-contentful-paint per il nuovo metodo.

Per CLS e INP, ciò significa misurare queste metriche durante l'intero ciclo di vita della pagina, come avviene per il metodo attuale, e suddividere separatamente la sequenza temporale in base alle navigazioni temporanee per misurare valori CLS e INP separati per la nuova.

Utilizza la libreria web-vitals per misurare i Core Web Vitals per le navigazioni soft

Il modo più semplice per tenere conto di tutte le sfumature è utilizzare la libreria JavaScript web-vitals, che offre il supporto sperimentale per le navigazioni soft in un soft-navs branch separato (disponibile anche su npm e unpkg). Questa operazione può essere misurata nel seguente modo (sostituendo doTraditionalProcessing e doSoftNavProcessing in base alle esigenze):

import {
  onTTFB,
  onFCP,
  onLCP,
  onCLS,
  onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';

function doTraditionalProcessing(callback) {
  ...
}

function doSoftNavProcessing(callback) {
  ...
}

onTTFB(doTraditionalProcessing);
onFCP(doTraditionalProcessing);
onLCP(doTraditionalProcessing);
onCLS(doTraditionalProcessing);
onINP(doTraditionalProcessing);

onTTFB(doSoftNavProcessing, {reportSoftNavs: true});
onFCP(doSoftNavProcessing, {reportSoftNavs: true});
onLCP(doSoftNavProcessing, {reportSoftNavs: true});
onCLS(doSoftNavProcessing, {reportSoftNavs: true});
onINP(doSoftNavProcessing, {reportSoftNavs: true});

La libreria web-vitals garantisce inoltre che le metriche vengano riportate in base all'URL corretto come indicato in precedenza, in quanto includono sia navigationId sia navigationURL nelle voci fornite al callback.

La libreria web-vitals riporta le seguenti metriche per le navigazioni temporanee:

Queste modifiche faranno parte delle misurazioni di Core Web Vitals?

Vogliamo valutare le euristiche e verificare se riflettono in modo più accurato l'esperienza utente prima di decidere se integrarle nell'iniziativa Core Web Vitals. L'obiettivo finale è fornire un mezzo per misurare meglio il rendimento in base alle esperienze degli utenti reali. Pertanto, se questo esperimento avrà esito positivo, l'obiettivo è includere queste metriche nelle misurazioni dei Core Web Vitals esposte da tutti gli strumenti.

Apprezziamo il feedback degli sviluppatori web sull'esperimento, sull'euristica utilizzata e se ritieni che rifletta in modo più accurato l'esperienza. Il repository GitHub di Soft Navigation è il posto migliore per fornire questo feedback, anche se i singoli bug relativi all'implementazione di Chrome devono essere segnalati nel tracker dei problemi di Chrome.

Come verranno registrate le navigazioni soft in CrUX?

Inoltre, se l'esperimento avrà esito positivo, è ancora da determinare in che modo verranno segnalate le navigazioni soft in CrUX. Non è detto che vengano trattati allo stesso modo delle navigazioni "hard" attuali.

In alcune pagine web, le navigazioni soft sono quasi identiche ai caricamenti di pagine complete per quanto riguarda l'utente e l'utilizzo della tecnologia applicazione a pagina singola è solo un dettaglio di implementazione. In altri casi, potrebbero essere più simili a un caricamento parziale di contenuti aggiuntivi.

Pertanto, potremmo decidere di segnalare queste navigazioni soft separatamente in CrUX o magari ponderarle quando calcoliamo i Core Web Vitals per una determinata pagina o gruppo di pagine. Man mano che l'euristica si evolve, potremmo anche essere in grado di escludere completamente la navigazione soft con caricamento parziale.

Il team si sta concentrando sull'implementazione euristica e tecnica, che ci consentirà di valutare la riuscita di questo esperimento, pertanto non è stata presa alcuna decisione in merito.

Feedback

Stiamo raccogliendo attivamente feedback su questo esperimento nei seguenti luoghi:

• Il feedback sull'API deve essere segnalato come problema su GitHub.
• I bug nell'implementazione di Chromium devono essere segnalati nel tracker dei problemi di Chrome, se non si tratta ancora di uno dei problemi noti.
• Il feedback generale sui Core Web Vitals può essere condiviso all'indirizzo web-vitals-feedback@googlegroups.com.

In caso di dubbi, non preoccuparti troppo. Preferiamo ricevere il feedback in entrambi i casi e saremo felici di eseguire il triage dei problemi in entrambi i casi e reindirizzare i problemi alla posizione corretta.

Log delle modifiche

Poiché questa API è in fase sperimentale, sono in corso diverse modifiche, più che con le API stabili. Per ulteriori dettagli, consulta il log delle modifiche dell'euristica di navigazione soft.

Conclusione

L'esperimento sulle navigazioni soft è un approccio entusiasmante all'evoluzione dell'iniziativa Core Web Vitals per misurare un pattern comune sul web moderno che manca nelle nostre metriche. Anche se questo esperimento è ancora nelle sue fasi iniziali e c'è ancora molto da fare, rendere disponibili i progressi compiuti finora alla più ampia community web per sperimentare è un passo importante. La raccolta dei feedback di questo esperimento è un'altra parte fondamentale dell'esperimento, pertanto incoraggiamo vivamente le persone interessate a questo sviluppo a utilizzare questa opportunità per contribuire a plasmare l'API in modo che sia rappresentativa di ciò che speriamo di poter misurare con questo strumento.

Ringraziamenti

Immagine in miniatura di Jordan Madrid su Unsplash

Questo lavoro è la continuazione di un progetto iniziato da Yoav Weiss quando lavorava in Google. Ringraziamo Yoav per il suo impegno in questa API.