INP ha sostituito FID più di un anno fa e la maggior parte dei team di sviluppo non ha ancora un metodo collaudato per gestirlo. Ecco cosa consigliamo su ogni progetto che realizziamo.
Si parte dal budget. Trattiamo 2,0 s di LCP, 0,05 di CLS e 200 ms di INP come soglie vincolanti. Se una pagina non rispetta anche una sola di queste nei test di laboratorio, la pull request non viene unita. Non è un obiettivo ideale: è un controllo automatico nella CI.
Per l’LCP la leva più grande è l’immagine principale della pagina. Usate AVIF, indicate dimensioni esplicite, marcatela come priority e servitela da una CDN con una cache configurata bene. Se l’elemento principale è solo testo, renderizzatelo lato server e avete finito.
Per il CLS, fissate le dimensioni di ogni immagine, video e contenuto incorporato. Riservate lo spazio per gli annunci e per i moduli caricati in differita. Non caricate web font che si scambiano a metà rendering, a meno di aver dimensionato il font di riserva perché combaci.
Per l’INP il lavoro riguarda meno la velocità assoluta e più i task lunghi che bloccano il thread principale. Analizzate il bundle. Suddividete il codice dei componenti pesanti. Rimandate il caricamento delle librerie di animazione finché non servono. Se potete, spostate in un worker la logica che richiede molto parsing.
Misurate su dispositivi reali. I numeri di laboratorio e quelli raccolti sul campo raccontano storie diverse: la fonte di verità dovrebbe essere il Chrome User Experience Report, non l’ultimo Lighthouse lanciato sul vostro computer.
Scritto dal team di brainiac/studio. Pubblichiamo lavoro originale degli ingegneri, dei designer e dei marketer che fanno il lavoro, mai affidato a un’agenzia di contenuti.