Lento per errore vs lento per progettazione

Lento per errore vs lento per progettazione.

Quando mi assumi per correggere o parlare dei Core Web Vitals, ad un certo punto mi sentirai parlare di lento per errore vs lento per progettazione.  Penso che sia una distinzione critica da fare e in questo articolo spiegherò come questo ti aiuterà a migliorare i Core Web Vitals.

Lento per errore

Amo gli anti-pattern lento per errore. Hai fatto qualcosa che ha rallentato la pagina. Hai fatto un errore. Non sapevi che cè un modo molto più veloce di farlo. Nessun problema, posso correggere gli errori. 

Quindi categorizzare questi errori ha senso. Mi darà un elenco di miglioramenti facili da correggere e ad alto impatto che posso inviare al tuo team di sviluppo (o correggere io stesso). Di solito cè poca discussione necessaria. Migliorare questi anti-pattern ha semplicemente senso da tutte le direzioni. Una volta corretti, i Core Web Vitals miglioreranno.

Ecco alcuni esempi di anti-pattern in cui mi imbatto quotidianamente. Quando spiego cosa e perché di solito ricevo oh, non sapevo che questo avrebbe rallentato la pagina.

1. Immagini non lazy

Lanti-pattern più comune sono le immagini non lazy. Le immagini che non vengono caricate in lazy loading verranno messe in coda per il download durante le prime fasi del caricamento della pagina. Questo utilizzerà risorse di rete e CPU. Non ha senso assegnare risorse preziose a immagini che non sono nemmeno visibili, giusto? 

2. Font di terze parti

3. Script di terze parti

4. Immagini di sfondo

5. Fogli di stile di grandi dimensioni

Lento per progettazione

Lento per progettazione è la parte di cui dovresti preoccuparti. Hai fatto scelte strutturali che hanno rallentato la pagina.  Di solito coinvolgono scelte di design UX o codice JavaScript che modifica la parte visibile della pagina a tal punto che non ci sono buone soluzioni alternative.

Il problema con lento per progettazione è che non è immediatamente risolvibile apportando piccole modifiche. Richiede più pianificazione e la riscrittura di alcune funzionalità principali del sito. 

La prima cosa che devo fare è capire lintenzione: Perché lhai fatto? Quali erano le considerazioni e cosa intendevi esattamente ottenere? E poi entro quei parametri trovare unalternativa migliore!

Ecco alcuni esempi degli errori lento per progettazione più comuni.

1. Slider

Gli slider di solito funzionano così: quando la pagina viene renderizzata, un JavaScript inietterà lo slider nella pagina. Senza questo JavaScript la pagina apparirà completamente diversa.  Questo causerà un Largest Contentful Paint più lungo, probabilmente un Layout Shift e molto probabilmente problemi con il First Input Delay.

Non cè una soluzione rapida. Differire il JavaScriptmigliorerà le metriche di paint ma ritarderà lo slider e causerà un layout shift. Rendere lo script dello slider critico risolverà il Layout Shift ma rallenterà le metriche di paint.

La soluzione è migliorare progressivamente la pagina. Prima assicurati che lo slider venga renderizzato senza JavaScript e poi migliora la pagina e trasforma limmagine dello slidergià presente in uno slider completo. 

La cosa divertente è: 9 volte su 10 quando spiego questo, il proprietario del sitosuggerisce immediatamente di rimuovere loslider. Ecco perché èimportante chiedere informazioni sulle intenzioni e le considerazioni di questi slider. Di solito erano semplicemente lì.

2. Zoom del prodotto

Lo zoom del prodotto funziona così: sul tuo tipico webshop passa il mouse sopra unimmagine del prodotto e puoi ingrandire una parte del prodotto.  Gli zoom del prodotto di solito hanno lo stesso problema degli slider.  Un pezzo di codice JavaScript prenderà le tue immagini, le nasconderà e le riscriverà nella pagina come immagini zoomabili. Questo causerà un Largest Contentful Paint più lungo, probabilmente un Layout Shift e molto probabilmente problemi con il First Input Delay.

La differenza con lo slider è che nessun proprietario di prodotto dirà mai: "oh, rimuovi semplicemente questa funzionalità". È importante e aumenta la conversione.

La soluzione è la stessa della correzione dello slider. Lo script di zoom non dovrebbe nascondere le immagini originali ma estendere la funzionalità dellimmagine del prodotto. Sfortunatamente la funzionalità di zoom di solito non èfacilmenterisolvibile e richiederà un po di lavoro per ottenerla correttamente.

3. jQuery inline / dipendenze JavaScript inline

jQuery inline è un problema che è iniziato come lento per errore ma è peggiorato nel tempo. Circa il 50% dei siti che esamino soffre di questo problema. Poiché gli script inline dipendono da uno script precedente (di solito jQuery) non puoi più differire jQuery. Questo ritarderà tutte le metriche di paint.

La correzione è semplice: sposta semplicemente questi script in uno script esterno. Ora puoi differire sia jQuery che lo script personalizzato. 

Allora perché ho inserito questo nella categoria lento per progettazione? Quando chiedo informazioni sullintenzione e la considerazione di solito ricevo oh, non lo so. E questo è il vero problema. Cè una mancanza di conoscenza su come funziona JavaScript.  Posso essere abbastanza certo che questo errore si ripeterà in futuro. Ciò significa che la soluzione non è la stessa della correzione. Dovrò educare il team di sviluppo sulle dipendenze e la tempistica di JavaScript.

4. Immagini grandi (hero)

Un altro problema lento per progettazione sono le immagini grandi. Alcuni siti hanno semplicemente bisogno di stupire il pubblico con molte immagini a dimensione intera. Immagina di vendere poster. Probabilmente vorresti servire immagini grandi e di alta qualità ai tuoi visitatori. Queste immagini, non importa quanto le ottimizzi, impiegheranno sempre più tempo a scaricarsi rispetto alle immagini più piccole. 

A questo punto (supponendo che le immagini siano tutte ottimizzate) lunica cosa che posso fare è vedere se cè un margine di manovra. Abbiamo davvero bisogno di immagini 4k o sarebbe sufficiente anche il full-hd?

5. Mappe interattive

Un altro problema in cui mi imbatto frequentemente sono le mappe interattive. Quando una pagina ha una mappa interattiva, lintera intenzione di questa pagina è far interagire il visitatore con la mappa. Ovviamente ci vorrà del tempo per caricare quella mappa. 

Non cè modo di aggirare questo. Dovremo accettare un po di lentezza. Ma ci sono cose che possiamo fare. Possiamo assicurarci che le mappe vengano caricate con la massima priorità. Di solito queste pagine non sono ottimizzate per lesecuzione precoce di JavaScript. In questo caso quella era la scelta sbagliata. Abbiamo bisogno che lo script venga scaricato ed eseguito il prima possibile!

6. API lente

Conclusione

Può essere utile distinguere tra lento per errore e lento per progettazione quando si tratta di Core Web Vitals. Lento per errore è solitamente facilmente risolvibile mentre lento per progettazione richiede un approccio multidimensionale più approfondito.