Data di pubblicazione: 14 ottobre 2025
Interaction to Next Paint (INP) è una metrica di Core Web Vitals fondamentale per misurare la reattività. In Fotocasa, Google Search Console ha evidenziato un numero significativo di pagine che sono passate a "Da migliorare" e "Scarso" quando INP ha sostituito First Input Delay (FID) nel 2024. Questo case study descrive gli strumenti e le strategie utilizzati per diagnosticare e risolvere questi problemi, migliorando in modo significativo l'INP.
Dove ha iniziato il team di Fotocasa
Prima del passaggio da FID a INP, quasi tutte le pagine su computer e dispositivi mobili rientravano nella soglia "Buono", il che significa che tutti i Segnali web essenziali in quel momento (LCP, CLS e FID) avevano un buon rendimento. Tuttavia, dopo il passaggio a INP, quasi tutte le pagine sono passate a "Richiede miglioramenti" e alcune persino a "Scarso", poiché i valori INP superavano costantemente i 200 millisecondi per la maggior parte delle interazioni degli utenti.
Questa modifica ha fatto capire al team di Fotocasa che stava trascurando un aspetto cruciale dell'esperienza utente. Mentre FID misurava solo il ritardo della prima interazione, INP valuta la reattività di tutte le interazioni, tenendo conto dei ritardi di elaborazione e presentazione dell'input. Questa misurazione più ampia è un proxy molto migliore per l'interattività effettiva (come dichiarato da Google) e ha evidenziato le opportunità mancanti.
Anche se Google Search Console fornisce dati sul rendimento sul campo, non fornisce approfondimenti in tempo reale. I suoi dati vengono aggregati in un periodo di 28 giorni, il che rende difficile individuare esattamente quali interazioni causavano problemi in quel momento.
Era necessario un modo per monitorare INP in tempo reale per identificare le interazioni più lente e più utilizzate dagli utenti e riprodurle in modo affidabile negli ambienti di sviluppo del team. Altrettanto importante è stato comprendere l'impatto delle modifiche apportate, non solo quali correzioni hanno aiutato, ma anche quali modifiche hanno inavvertitamente peggiorato le cose.
Per questi motivi, è stato utilizzato un insieme di strumenti per diagnosticare e risolvere i problemi. Le più importanti erano:
- Google Chrome DevTools, in particolare la scheda Rendimento.
- Un sistema RUM (Real User Monitoring) personalizzato creato dal team di Fotocasa in Datadog utilizzando la libreria web-vitals.
- Strumenti per sviluppatori React.
Strumenti per diagnosticare il problema
Per diagnosticare ed eseguire il debug dei problemi di prestazioni INP, sono stati utilizzati i seguenti strumenti.
Google Chrome DevTools
Un ottimo modo per rilevare e riprodurre i problemi relativi a Core Web Vitals in un'applicazione web è utilizzare la scheda Rendimento in Google Chrome DevTools. La scheda Prestazioni misura automaticamente le metriche Core Web Vitals, fornendo un feedback immediato sulle metriche di caricamento, interattività e spostamento del layout. È in linea con il modo in cui queste metriche vengono riportate in altri strumenti Google.
Per identificare e risolvere i problemi INP, il team di Fotocasa ha iniziato limitando la CPU per simulare le prestazioni dei dispositivi di fascia bassa e media. In questo modo, il team di Fotocasa ha potuto osservare il comportamento della pagina in condizioni più restrittive. La sessione è stata quindi registrata utilizzando il profiler e le tracce sono state analizzate attentamente, concentrandosi sull'interazione dell'utente per individuare i problemi di prestazioni.
Quando identifichi i colli di bottiglia, è particolarmente utile esaminare le sottoparti dell'INP e le attività che il browser esegue in ciascuna di esse. Ad esempio, nell'immagine seguente si può notare che l'INP è piuttosto elevato a causa di due ricalcoli dello stile causati da modifiche allo stile nel corpo del documento.
Fotocasa ha configurato un sistema per monitorare l'INP e altre metriche Core Web Vitals, garantendo che eventuali problemi di prestazioni vengano identificati e risolti rapidamente. Quando una metrica supera una soglia specifica (in base agli intervalli definiti da Google), l'attribuzione viene registrata in modo che il problema possa essere analizzato e risolto.
Per questo sistema, è stata utilizzata la libreria web-vitals per acquisire queste metriche da utenti reali in modo da corrispondere accuratamente al modo in cui vengono misurate da Chrome e segnalate ad altri strumenti Google (come il Report sull'esperienza utente di Chrome, Page Speed Insights, il report sulla velocità di Search Console e altri).
Per una visione completa e un monitoraggio centralizzato, Fotocasa ha utilizzato Datadog per raccogliere e visualizzare i dati, consentendo al team di prendere decisioni informate e basate sui dati. Le metriche personalizzate consentono di mantenere l'efficienza dei costi e di monitorare meglio quasi tutti gli utenti sul sito web Fotocasa.
Questo sistema consente al team di Fotocase di monitorare rapidamente se le modifiche influiscono sulle metriche o se si verificano alterazioni impreviste, compromettendole potenzialmente. La metrica INP può quindi essere suddivisa in parti come ritardo di input, durata dell'elaborazione e ritardo di presentazione per individuare con precisione quale parte dell'interazione è principalmente responsabile dei lunghi tempi di interazione.
Dopo aver rilevato anomalie, come quella illustrata nelle figure 7 e 8, Fotocasa ha risposto prontamente e ha utilizzato OpenSearch, un altro strumento che ha contribuito a individuare dove potrebbe verificarsi l'alterazione. I dati forniti dalla libreria web-vitals hanno contribuito a identificare il target (l'elemento DOM potenzialmente responsabile di un valore elevato della metrica) e aiutano il team a concentrarsi maggiormente sulla risoluzione del problema.
Inoltre, è possibile definire vari filtri, come tipo di pagina, dispositivo o stato di caricamento, per semplificare gli scenari e ottenere una comprensione più accurata dell'impatto dell'INP.
Strumenti per sviluppatori React
React Developer Tools sono stati utilizzati per migliorare le funzionalità di debug di Fotocasa, che fornisce una potente funzionalità che consente di evidenziare visivamente i componenti di cui è stato eseguito nuovamente il rendering.
Questa funzionalità può essere attivata accedendo alla scheda Profiler. Da qui, fai clic sull'icona a forma di ingranaggio sul lato destro della barra in alto, vai alla scheda Generale e seleziona la casella di controllo Evidenzia gli aggiornamenti durante il rendering dei componenti. Se questa opzione è attiva, i componenti vengono evidenziati quando vengono sottoposti a rendering, fornendo una rappresentazione visiva dinamica.
Scoprire la causa di un nuovo rendering
Una volta identificato un componente che è stato sottoposto a rendering di nuovo, la domanda successiva è "perché è successo?". React DevTools risponde a questa domanda con un suggerimento utile nella visualizzazione del grafico a fiamma.
Per accedere a queste informazioni, registra una sessione del profiler. Analizzando l'output del profiler, troverai informazioni utili:
- Nell'angolo in alto a destra viene visualizzato il numero di commit di React.
- Il grafico a fiamma rappresenta visivamente l'albero dei componenti, con il grigio che indica i componenti che non sono stati sottoposti a rendering. Ogni barra rappresenta un momento in cui l'albero dei componenti React è cambiato e in cui è stata eseguita una modifica corrispondente nel DOM.
- Se passi il mouse sopra ogni componente nel grafico a fiamma, il motivo del rendering viene visualizzato nel sottotitolo Perché è stato eseguito il rendering?.
I motivi per cui viene eseguito nuovamente il rendering di un componente possono includere:
- Questa è la prima volta che il componente è stato sottoposto a rendering
- Contesto modificato
- Hook modificati
- Elementi di scena modificati
- Regione è cambiato
- Il componente padre sottoposto a rendering
Determinare il tempo di rendering
I colori nel grafico a fiamma trasmettono informazioni significative. Colori come varie tonalità di blu indicano che un componente ha richiesto un tempo di rendering relativamente breve rispetto ad altri componenti. Al contrario, colori come l'arancione e il rosso indicano che un componente ha richiesto più tempo di rendering.
Come il team di Fotocasa ha risolto il problema
Rimuovere i rendering non necessari
I rendering vengono eseguiti ogni volta che React deve aggiornare l'interfaccia utente con nuovi dati. Di solito deriva da un'azione dell'utente, da una risposta API o da altri eventi importanti che richiedono un aggiornamento dell'interfaccia utente. Poiché ogni rendering esegue JavaScript, un numero eccessivo di rendering contemporaneamente, soprattutto in un albero dei componenti di grandi dimensioni, può bloccare il thread principale e causare problemi di prestazioni.
Esistono due tipi di rendering:
- Rendering necessari: quando un componente deve essere aggiornato perché possiede o utilizza dati aggiornati.
- Rendering non necessari: quando un componente viene aggiornato senza modifiche significative, spesso a causa di una gestione dello stato inefficiente o di una gestione impropria delle proprietà.
In genere, alcuni rendering non necessari non sono un problema, in quanto React è abbastanza veloce da non essere notato dagli utenti. Tuttavia, se si verificano troppo spesso o in un albero di componenti pesante, possono compromettere l'esperienza utente e influire negativamente sull'INP della pagina.
È il caso del team di Fotocasa. Si sono resi conto che il sito web aveva molti rendering non necessari. Questi si sono verificati in due scenari principali:
- Durante il caricamento della pagina: aumento del numero di attività lunghe sul thread principale e ritardo della prima interazione, con conseguente impatto negativo sull'INP della pagina.
- Durante le interazioni utente: aumento del tempo di elaborazione della maggior parte delle interazioni, il che ha danneggiato anche l'INP.
Molti rendering non necessari sono stati ottimizzati sul sito web di Fotocasa. Una delle maggiori ottimizzazioni realizzate è stata apportata alla pagina di ricerca. Sono stati eseguiti tre rendering non necessari durante il caricamento della pagina. Una volta rimossi, sono stati osservati i seguenti risultati:
- Numero inferiore di attività lunghe (vedi la figura che segue)
- Total Blocking Time inferiore (confronta le figure 14 e 15)
Colocation statale
Il posizionamento errato dello stato di React può rallentare un'applicazione e rendere l'interfaccia utente non reattiva. Quando lo stato di un componente cambia, i relativi componenti secondari vengono nuovamente sottoposti a rendering per impostazione predefinita, a meno che non venga utilizzata una via di fuga (ad esempio, memo).
Come spiegato nella sezione precedente, i nuovi rendering non sono intrinsecamente negativi, ma il rendering dell'intera pagina a causa di un aggiornamento di stato specifico può comportare interazioni più lente, poiché gli aggiornamenti del DOM si verificano dopo il rendering.
Ad esempio, nella pagina di ricerca è presente una finestra di dialogo che mostra tutti i filtri quando viene fatto clic su un pulsante.
Lo stato che controlla lo stato di apertura della finestra di dialogo in questo caso è stato inserito nella pagina di ricerca. Quando questo stato è cambiato, l'intera pagina è stata sottoposta a rendering, causando un INP scadente, in particolare sui dispositivi più lenti, come si è visto quando è stato utilizzato il throttling della CPU in DevTools:
La modifica dello stato il più vicino possibile al componente che attiva la modifica risolve il problema. In questo caso specifico, lo stato può essere inserito nel componente pulsante dei filtri, in modo che quando lo stato cambia, venga eseguito il rendering solo del pulsante.
Rimuovere gli stati non necessari
Gli stati non devono contenere informazioni ridondanti o duplicate. In caso contrario, potrebbero verificarsi rendering non necessari e problemi.
Ad esempio, nella barra dei filtri di Fotocasa, è presente un testo che indica il numero di filtri applicati a una determinata ricerca:
Il numero di filtri applicati viene calcolato in base allo stato dell'applicazione. Tuttavia, questo non solo ha comportato un rendering non necessario dell'intero componente, ma in alcuni casi ha anche causato uno spostamento del layout, poiché questo componente viene sottoposto a rendering lato server:
const [filtersCount, setFiltersCount] = useState(DEFAULT_COUNTER)
useEffect(() => {
const counter = filters
? Object.keys(filters)
?.reduce(reducerCounter, [])
?.filter((param) => searchParams?.[param]).length
: DEFAULT_COUNTER
setFiltersCount(counter)
}, [searchParams]);
Per risolvere il problema, il valore è stato derivato dall'oggetto dei filtri utilizzando una variabile anziché lo stato:
const counter = filters
? Object.keys(filters)
?.reduce(reducerCounter, [])
?.filter((param) => searchParams?.[param]).length
: DEFAULT_COUNTER;
Ridurre i rendering costosi
Quando si verifica un'interazione in un'applicazione React, in genere viene attivato un cambio di stato. Come spiegato in precedenza, quando lo stato di un componente cambia, il componente viene sottoposto a rendering insieme a tutti i relativi elementi secondari.
Se una di queste funzioni di rendering dei componenti è lenta, influirà negativamente sull'INP della pagina, poiché probabilmente verrà generata un'attività lunga e l'aggiornamento del DOM richiederà più tempo.
Il team di Fotocasa ha cercato di ridurre al minimo i calcoli che richiedono molto tempo all'interno della funzione di rendering dei componenti. Chrome DevTools e React Developer Tools sono stati molto utili per rilevare le operazioni di rendering lente.
Ritardare l'esecuzione del codice
Oltre a ottimizzare la funzione di rendering dei componenti, sono state ottimizzate altre funzioni per ridurre al minimo le attività lunghe. Tuttavia, alcune attività non sono state ottimizzate perché dipendevano da codice di terze parti.
Un esempio è l'analisi. In questo caso, è stato deciso di ritardare l'esecuzione del codice di analisi e dare la priorità agli aggiornamenti del DOM quando si verificavano interazioni degli utenti. Per raggiungere questo obiettivo, il team di Fotocasa ha utilizzato una libreria chiamata idlefy, che ha anche garantito che il codice di analisi venisse eseguito anche se il browser veniva chiuso subito dopo.
Cultura del rendimento
Il lavoro sulle prestazioni non è un'attività una tantum, ma qualcosa da considerare per ogni funzionalità rilasciata in produzione. Tutti i membri del team devono essere allineati, altrimenti le regressioni nei Segnali web essenziali sono quasi inevitabili.
Per tenere tutto sotto controllo, il team di Fotocasa ha condiviso attivamente le conoscenze all'interno del team e ha stabilito un framework chiaro per identificare i problemi di rendimento in base ai dati RUM di Datadog di Fotocasa, incluso come riprodurli. Gli avvisi per i Core Web Vitals, in particolare per l'INP, sono stati configurati nel sistema RUM in modo da inviare una notifica direttamente al team di Fotocasa su Slack. Questo approccio ha mantenuto le prestazioni al primo posto e ha contribuito a individuare i problemi prima che si trasformassero in regressioni.
Risultati
Il miglioramento dell'INP su Fotocasa ha richiesto una combinazione di ottimizzazioni tecniche e cambiamenti culturali. Eliminando i rendering non necessari, ottimizzando il posizionamento dello stato, riducendo i rendering costosi e posticipando il codice non critico, il team di Fotocasa è riuscito a spostare tutte le pagine desktop da "Richiede miglioramenti" a "Buono" e a migliorare significativamente le pagine mobile, eseguendo l'upgrade di quasi tutte le pagine "Scarso" e "Richiede miglioramenti" a "Buono".
Queste modifiche hanno migliorato l'esperienza utente complessiva di Fotocasa e, insieme ad altre iniziative, hanno determinato un aumento del 27% degli annunci di contatti e lead telefonici, rafforzando direttamente le metriche aziendali chiave dell'azienda.
Il monitoraggio in tempo reale con Datadog ha consentito al team di Fotocasa di convalidare i miglioramenti dell'INP, rilevare rapidamente le anomalie e prevenire le regressioni. Oltre a questi risultati, Fotocasa è riuscita a integrare le prestazioni web nella propria cultura di sviluppo, garantendo che INP e Segnali web essenziali rimangano una priorità in ogni release.