1. Identifica le pagine con RTR eccessive.
Puoi ridurre al minimo le RTR grazie alla consapevolezza. Molte pagine avranno più di 100 RTR per pagina, quando in realtà dovrebbero averne meno di 50. Spesso sviluppatori o professionisti di SEO che esaminano tutte le richieste in una pagina scoprono che alcuni degli elementi richiesti mancano (404) e nessuno lo ha notato. Anche se mancano, il browser impiega tempo per richiedere e tornare a mani vuote, quindi queste pagine devono essere rimosse o corrette immediatamente.
Dovresti anche correggere le risorse che sono state spostate e che quindi danno una risposta 301 o 302. Queste risposte significano che il browser è andato in un posto, poi ha seguito un altro set di istruzioni per andare in un altro posto per ottenere la risorsa, ma ogni nuova posizione richiede più tempo. È come andare in un negozio di generi alimentari e sentirsi dire che non hanno ciò che ti serve, ma puoi chiederlo in un altro negozio lungo la strada. Ancora peggio, se c’è una catena di reindirizzamenti, è come andare al secondo negozio di generi alimentari per scoprire che anche loro hanno smesso di vendere l’articolo, e ora devi provare presso un terzo negozio.
2. Laddove possibile, combina i file.
Il prossimo passaggio per un sito web ottimizzato è quello di combinare i file (come JavaScript e CSS), laddove possibile. Ad esempio, se una pagina utilizza dieci fogli di stile (file CSS) che potrebbero essere tutti combinati in uno, è necessario farlo. Allo stesso modo, se utilizzi una serie di file Javascript che potrebbero essere combinati in uno, fallo. Prova a pensare alle cose come a livello di sito e specifiche per template. Dovresti avere un file Javascript a livello di sito per Javascript che si trova in ogni pagina del sito, e un file Javascript specifico per template per ogni template di pagina sul sito. Lo stesso può essere fatto con CSS. Assicurati di riferirti a questi file sempre con lo stesso nome e posizione, sarà anche utile averne la cache nel luogo giusto.
3. Ottimizza l’ordine di rendering.
Dopo aver eliminato e consolidato, diminuendo il numero totale di RTR, ciò che puoi fare dopo è modificare l’ordine in cui le cose sono richieste, per renderlo più veloce. Così come ci sono dei passaggi che devono essere completati in una ricetta prima di poter iniziarne altri, c’è un determinato ordine che un browser di dispositivo mobile seguirà e che deve essere rispettato durante la creazione di una pagina. Seguendo l’esempio della spesa, se la ricetta richiede qualcosa da marinare per due giorni, è importante ottenere prima gli articoli necessari per la marinatura, in modo da poterla iniziare mentre ottieni il resto degli ingredienti.
Traducendo questa analogia al mondo web, la marinatura è come un blocco del rendering, perché non si può proseguire col processo di cottura fino a quando la marinatura non è completata. Puoi prepararsi i passaggi successivi del processo di cottura solo acquistando gli ingredienti mentre il resto marina. Questo è come il rendering del percorso critico, in cui si assegna la priorità agli elementi fondamentali, come il tag di testa, il contenuto della pagina e il layout di base della pagina, e si ritardano gli elementi meno fondamentali, specialmente se ritarderanno il caricamento di elementi più importanti. Questo può migliorare drasticamente l’esperienza di caricamento per gli utenti e dare loro la certezza che il resto della pagina si caricherà rapidamente. Fornisce inoltre risorse per iniziare la valutazione, mentre avviene il processo di caricamento.
4. Crea una strategia di caricamento della pagina.
Poiché i motori di ricerca emulano gli utenti umani, sperimentano le pagine nello stesso modo in cui fa un utente. La cosa migliore che si può fare per ordinare le richieste di velocità è sapere cosa conta per l’esperienza utente e l’esperienza bot nei primi secondi in cui sono sulla pagina. Questa è generalmente l’informazione nel tag di testa e il testo e le immagini sulla pagina. Generalmente, gli utenti impiegano alcuni secondi per interagire con tutto ciò che è interattivo sul sito, quindi la maggior parte di Javascript non deve essere caricata all’inizio. Invece, le rappresentazioni visive di Javascript, come le caselle col segno “più” o gli espansori, possono essere caricate come placeholder prima che sia necessario Javascript. Javascript è particolarmente lento e ingombrante da caricare. Per garantire che il caricamento di Javascript non rallenti l’esperienza così tanto che sia utenti che bot debbano fissare una pagina vuota per molto tempo, è ideale caricare qualcosa che gli utenti possano guardare e poi caricare JavaScript in background, mentre gli utenti guardano la pagina.
Dopo JavaScript, video e immagini sono la cosa più lenta da caricare. I video e le immagini che sono in basso nella pagina non devono ostacolare l’esperienza in alto nella pagina, dove gli utenti e i bot in genere iniziano. Questo concetto di ritardare il caricamento di contenuti non visibili è chiamato “lazy loading”. Il lazy loading può essere eseguito in diversi modi (differito, asincrono e meta tag di lazy loading di Google).
Lo strumento migliore da utilizzare per poter caricare immagini con lazy loading è Google PageSpeed Insights. Per ottimizzare le immagini, puoi anche utilizzare il tag immagine di Google Lazy load, ma finora questo sarà rispettato solo nei browser Chrome per dispositivi mobili e desktop (sebbene questo potrebbe cambiare in futuro). Con entrambi i metodi, dovresti utilizzare l’URL Inspection Tool di Google Search Console per verificare che gli elementi caricati con lazy loading siano visibili nel rendering della pagina dello strumento e nell’HTML renderizzato.
5. Comprimi tutto ciò che puoi.
Dopo aver ridotto e assegnato la priorità alle RTR per ogni template di pagina, devi comprimere ciò che è possibile. La compressione aiuta ad aumentare la velocità delle pagine, risparmiando larghezza di banda. La compressione Gzip è un modo per comprimere i file e può essere impostata sulla maggior parte dei server, ma sono disponibili anche altre opzioni. Puoi anche eseguire la maggior parte del codice attraverso un processo di minificazione, che riduce le dimensioni del file di trasferimento finale. Tuttavia, è difficile comprimere le immagini attraverso questi metodi. Puoi utilizzare la pagina di Performance Review (Revisione delle prestazioni) su WebPageTest.org per trovare la Full Optimization Checklist (Completa lista di controllo per l’ottimizzazione), che mostra tutte le risorse nella pagina, se sono zippate e il loro livello di compressione.
Per la compressione delle immagini, invece di usare Gzip e ridurre al minimo le immagini, è importante che il designer le consegni allo sviluppatore nel formato più compresso possibile, riducendo i file immagine. Fondamentalmente, deve rendere la dimensione del file finale il più piccola possibile senza comprometterne l’aspetto. Le foto dovrebbero generalmente essere salvate come file JPG e icone e le illustrazioni dovrebbero essere salvate come file GIF. Per rendere belle le immagini di grandi dimensioni su computer a schermo intero, senza dare problemi ai piccoli schermi di dispositivi mobili, potresti usare il protocollo per immagini reattive o utilizzare un server di immagini come quello di Fastly, per inviare dinamicamente una versione in scala dell’immagine a schermi più piccoli.
6. Salva nella cache le pagine giuste al momento giusto.
Il prossimo passaggio è aiutare i browser e i bot a identificare cosa può essere riutilizzato e cosa deve essere recuperato ogni volta con il caching del browser, una funzionalità che può essere impostata in modi diversi, per esempio tramite CDN (content delivery network, rete di consegna dei contenuti). La maggior parte degli elementi di un sito, in particolare un sito che non cambia più di una volta alla settimana o che non condivide informazioni in tempo reale come notizie, previsioni meteorologiche o punteggi degli eventi sportivi, può essere salvata nella cache per un massimo di un anno. Caching significa che quando gli utenti visitano una pagina, i browser cercheranno localmente nella loro memoria per vedere se hanno già un file utile per creare la pagina. In questo modo si risparmiano le richieste di andata e ritorno e migliorano il tempo di caricamento. I bot del motore di ricerca visualizzano sempre una pagina come se non l’avessero mai vista prima, perciò non utilizzano il caching attivo, ma possono percepire quando il caching è in corso e possono usarlo per stimare il tempo di caricamento di una pagina.
La cosa importante da capire sul caching è che si basa sui nomi dei file e sulla loro posizione sul server. Quindi se utilizzi un file su molte pagine, come un logo, fai sempre riferimento allo stesso nome file e lo stesso URL, anche se esiste in più posizioni sul server. Può essere utilizzato a tuo vantaggio, perché significa che è sufficiente aggiornare il nome del file di un elemento e il suo riferimento nell’HTML per ottenere una nuova versione dell’elemento salvato nella cache. Quindi, per esempio, se riadatti il logo semplicemente modificando il nome del file da “logo” a “logov2”, la nuova versione verrà salvata nella cache e la vecchia versione verrà dimenticata. In questo modo, quando lasci qualcosa salvata nella cache per un anno, non vuol dire che non modificherai l’elemento per un anno, ma che, se lo fai, farai riferimento all’elemento aggiornato o nuovo con un nuovo nome di file.
Le impostazioni della cache possono essere un po’ complicate, quindi la cosa migliore da fare è pensare a loro come ad alimenti che possono scadere. Alcuni alimenti scadono più velocemente di altri, quindi è necessario far sapere al browser quali cose diventano vecchie e devono essere eliminate rapidamente, e quali possono rimanere sullo scaffale per un po’ di tempo in modo sicuro, senza sostituirle. Puoi usare uno strumento come WebPageTest.org per capire quali sono le opportunità. La cosa importante da capire qui è che non vi è alcun limite di scadenza, né alcun periodo massimo per lasciare l’elemento nella cache. Pertanto, il browser assumerà solo che debba essere recuperato ogni volta come se fosse nuovo: il chaching del browser non può avvenire se non si specificano questi dettagli.
Poiché le impostazioni della cache indicano a un browser quando un elemento è troppo vecchio per essere utilizzato, a volte viene indicato come “durata di caching” o “durata della validità”. Se qualche elemento supera la durata di caching o di validità, l’andata e ritorno al server deve essere completata per ottenere una nuova versione. Se gli elementi sono elencati come “scaduti”, significa che hanno superato la loro durata di validità e, sia per l’analogia con la spesa che per il browser, devono essere sostituiti la prossima volta che sono necessari.
Così come non è utile avere scaffali pieni di generi alimentari scaduti, non è utile avere una cache piena di contenuto web scaduto. Al contrario, è inefficiente scartare generi alimentari (file) che sono ancora perfettamente utilizzabili. Quando assegni le durate di caching ai file, è utile pensarci e considerare anche le conseguenze dell’essere generosi nella durata di caching. Se apporti una piccola modifica al tuo logo, non sarà la fine del mondo se il vecchio logo è ancora mostrato, in questo modo puoi mantenere la durata di caching a lungo, specialmente se intendi essere prudente nell’aggiornare i nomi dei file quando apporti modifiche. Con nomi di file diversi, non devi preoccuparti di mostrare il vecchio logo.
7. Crea Accelerated Mobile Pages (AMP, Pagine mobili accelerate).
Tutto questo può sembrare complicato, per questo Google ha creato una soluzione più semplice per l’ottimizzazione della velocità della pagina. Le Accelerated Mobile Pages, o AMP, sono un sottoinsieme di HTML che segue linee guida molto più rigorose su ciò che può essere incluso. L’obiettivo è quello di portare la maggior parte delle pagine a un tempo di caricamento di un secondo su dispositivi mobili. L’AMP consente a Google di prendere il controllo della maggior parte delle difficoltà, salvando nella cache e configurando il processo di caricamento e la maggior parte degli elementi descritti in precedenza, in modo da renderlo il più ottimizzato possibile.
In alcuni casi, le attività creano nuove pagine AMP e si collegano ad esse dalle pagine esistenti sul sito tramite il tag principale. Questo indica a Google di servire la pagina AMP quando un utente che richiede la pagina ha un dispositivo mobile o una connessione lenta. In altri casi, puoi sostituire le pagine esistenti (o le pagine mobili esistenti, se ci sono siti separati) con le pagine AMP. Queste si chiamano “AMP canoniche”. Google preferisce questo metodo, perché le pagine AMP sono estremamente facili per il crawling, il rendering, l’indicizzazione e la classificazione con Google. Tuttavia, le attività potrebbero non prediligerlo, perché i limiti e i requisiti di AMP possono rendere le pagine un po’ povere. L’AMP può anche complicare o limitare parte del tracciamento e del test che puoi fare sulle pagine da desktop, perciò questo è un altro motivo per cui alcuni lo evitano.
I siti che sono validi per le AMP seguono tutte le regole e le linee guida AMP e, di conseguenza, Google mostra un piccolo fulmine grigio accanto ad essi nei risultati su dispositivo mobile. È più probabile che Google li includa in caroselli speciali di risultati che tendono a essere classificati nella parte superiore di una pagina. Questo è fantastico, ma se essere conformi alle AMP causa troppi problemi per il tuo sito web, puoi utilizzare il codice AMP senza esserne conforme. Dovresti usare AMP HTML se puoi, senza preoccuparti di seguire tutte le regole. Continuerai a sfruttare la velocità di AMP HTML e AMP JavaScript: non male se consideri che è gratuito. Ricorda: la velocità ha un impatto diretto sul coinvolgimento e sulla conversione, ma probabilmente aiuta anche con la profondità di crawling e altri aspetti dell’efficienza di crawling.
I browser da dispositivi mobili funzionano in modo diverso dai browser desktop. Hanno anche processori più lenti e connessioni meno affidabili. Questi fattori dovrebbero spingerti a esaminare il tempo di caricamento delle pagine del tuo sito, considerando il peggiore scenario dal punto di vista dei dispositivi mobili, per capire dove ci sono reali opportunità di miglioramento.