 Perfetto, visto che ho solo dieci minuti di disposizione cercherò di fare uno spizio quanto più performante e comprensibile possibile. Di cosa vi parlerò oggi? Vi parlerò di INP, del nuovo Core Web Vital di Google, che entrerà in vigore da marzo 2024. Quanti di voi conoscono i Core Web Vital per al fatto di mano? N'hanno sentito parlare? Ok, bene, ma non benissimo, ok. Allora, che cos'è INP? INP, che per esteso è Interaction to Next Paint, è un nuovo Core Web Vital, e quindi la domanda è cos'è un Core Web Vital che andrà a sostituire FID, e qui adesso vi racconto che cos'è FID. Allora, anzi tutto, che cos'è un Core Web Vital? Un Core Web Vital è uno dei parametri che è definito da Google come un parametro che serve per misurare l'esperienza dell'utente. Questi parametri sono delle metriche, quindi sono di numeri, sono qualcosa di misurabile dal browser, e Google ha deciso di elerserne 3 a Core, quindi sono più importanti di altri parametri che Google utilizza per misurare l'esperienza degli utenti sulla pagina. INP sostituirà FID, perché FID, First Input Delay, è un parametro che misura il ritardo della prima interazione che ha l'utente con la pagina. Ho sottolineato prima perché il FID, a differenza di INP, si limita a questa, mentre INP misura tutte le interazioni che vengono sulla pagina, in particolare misura la latenza più grande, quindi il ritardo maggiore che avviene tra tutte le interazioni che ha l'utente con la pagina. Questo perché è perché l'utente normalmente non si limita a fare un solo click, un solo tap o a premere il tasto solo una volta, ma ne fa di più. Quindi questo parametro misura tutte le interazioni che avvengono sulla pagina stessa. Quando si parla di pagina è anche importante considerare che non è solo la pagina in sé ma anche i frame, quindi i video ad esempio o i widget di chat. Quindi anche l'interazione che avviene all'interno di questi elementi ha un impatto sull'INP, quindi occhio a cosa tirate dentro nel sito perché quello può impattare negativamente su INP. INP misura il tempo massimo che trascorre tra l'interazione che ha l'utente con il sito e il feedback visivo che ottiene, ovvero l'utente clicca poi conto 1, 2, 3, cambia qualcosa di video, quindi viene terminato, viene misurato l'INP. Quindi finché l'utente clicca in tradizio con la pagina e non succede niente a schermo, l'INP continua a correre ed aumentare di valore. Ovviamente più tempo passa e più non succede niente sulla pagina, più l'utente avrà un'esperienza utente pessima. Perché è importante l'INP per tre motivi principali che poi sono alla fine riconducibili a uno che è l'esperienza dell'utente ma andando per ordine è importante per l'asseo perché essendo l'INP, uno dei core web vital e facendo in modo che siccome Google premia da un boost nell'algoritmo se un sito super a tutti i 3 core web vital, quindi non solo l'INP, bisogna avere un sito ottimizzato ma anche se non esistesse Google che ci premia con questo fantomatico boost che non è dato sapere se solo grazie a questo arriveremo primi su Google. Spoiler no, non è così. È comunque importante per l'esperienza dell'utente perché se l'utente ha una pessima esperienza, clicca non succede niente, l'utente può anche decidere di abbandonare la pagina, si rompe, si stufa, va da un'altra parte, va a comprare sul sito del vostro competitor e quindi pessima esperienza utente, pessimo tasso di conversione, quindi anche un sito con un'esperienza pessima ovviamente ne risentirà dal punto di vista delle conversioni. Quanto tempo può trascorrere Massimo per considerare l'esperienza utente buona? 200 millisecondi è veramente poco, quindi cosa bisogna fare affinché gli Np sia inferiore di 200 millisecondi lo vediamo tra un attimo. Finisco la parte di spiegazione teorica segnalando tre cose importanti su gli Np, ovvero la prima è che viene calcolata quando l'utente esce dalla pagina, quindi se un utente sta sulla pagina anche due minuti, quando faremo i nostri test noi dovremmo simulare tutto il comportamento dell'utente e compiere le stesse interazioni per avere un risultato attendibile. I Np può anche non esistere per riprimiate pagine, ovvero non interaction, non parti, perché se l'utente non interagisce dove l'interazione è il click, il tap o la pressione di un tasto, ad esempio fa solo lo scroll sulla pagina, senza interagire in alcun altro modo, poi la pagina avrà I Np non disponibile. In più non è possibile misurarlo in laboratorio, quindi non è possibile usare Lighthouse o Google Page Speed Insight per simularlo, per misurarlo con uno strumento o da riga di comando per intenderci. Quello che si può fare però è approssimarlo oppure tenere come metrica alternativa il TBT, il Total Blocking Time, per cui andando a migliorare gli aspetti che impattano sul Total Blocking Time, allo stesso modo è anche impossibile migliorare l'I Np, perché? Perché si basano sulla stessa cosa, diciamo che migliorando il JavaScript per un attimo ci ottiene un miglioramento di tutte le metriche che adesso ho collegato, tra cui Total Blocking Time e anche I Np. Quindi come ottimizzare per I Np? Prima di tutto bisogna capiamo cosa significa ottimizzare all'attopratico, ottimizzare significa modificare il codice, il sorgente della pagina, o HTML e JavaScript di cui composta la pagina, in modo da fornire un feedback visivo all'utente il più velocemente possibile. La chiave di tutto l'intervento è questo, fare in modo che quando passi meno tempo possibile da quando l'utente interagisce lura col sito a quando succede qualcosa a video. Andando più nello specifico poi possiamo dire che il main thread deve passare nello stato di inattività il prima possibile. E cos'è il main thread? Il main thread è il processo principale che vive all'interno browser e che gestice l'interazione dell'utente con la pagina, l'aggiornamento della grafica della pagina e anche l'elaborazione e l'interpretazione del codice JavaScript e vada a sé che il main thread può fare una sola cosa alla volta, un po' come gli uomini, che è un inside zocchi che si fa fare una sola cosa alla volta e il main thread non fa eccezione. Quindi cosa bisogna fare? Bisogna fare in modo di non caricare il JavaScript che non serve perché se il browser carica del JavaScript e questo non viene eseguito, viene comunque passato, viene comunque interpretato. Questa interpretazione ha un impatto sul, cioè tiene bloccato il main thread, quindi se il JavaScript non mi serve l'autologo. Del JavaScript che mi resta in pagina, sia che sia bloccante o vero che si trovi nella sezione add del sito o che sia non bloccante, quindi si trova nel body, lo devo comunque ridurre al minimo perché il JavaScript ogni volta che si attiva ha comunque bisogno del main thread per intervenire e il main thread o esegua il JavaScript o disegna le cose a video. Inoltre bisogna anche stare attenti a non modificare il DOM, quindi la struttura della pagina con il JavaScript o farlo in maniera centellinata perché più DOM modifico, più l'operazione di repaint, di ridisegno della pagina è grande e più tempo impiega il JavaScript anche per effettuare l'operazione. In più bisogna stare attenti a non scrivere e cambiare lo stile della pagina, quindi non impostare il CSS tramite JavaScript e fare questa operazione di lettura e scrittura contemporanea perché questo rende il processo sincrono e rendendo il processo sincrono lo rende bloccante, quindi il main thread è occupato lì e non può aggiornare la pagina. Quindi quello che possiamo ricapitolare tutta questa storia del main thread è che scrivili codice JavaScript in modo che sia il più eseguibile, il più velocemente possibile e che aggiorni lo schermo nel modo più veloce possibile, in modo che il frame successivo che viene disegnato avvenga in meno di 200 mili secondi. Quindi il consiglio finale è toglieri i page builder che così vi risolvete tutti i problemi legati a INP e FID. Io ho finito, vi ringrazio per non c'è spazio per le domande, me le potete fare dopo durante il talk, durante la pausa pranzo. Qui lascio i miei contatti nel frattempo che facciamo il cambio mic.