Migliora efficacemente le prestazioni del tuo sito web (mobile)!

La nostra azienda è stata invitata da Google a partecipare alla Page Speed ​​Race di quest’anno del Nord Europa. L’obiettivo di questa gara era quello di ottenere il massimo miglioramento assoluto del Lighthouse Performance Score del tuo sito web entro due mesi.

Avere esperienze sul Web mobile rapide e coinvolgenti è fondamentale per la tua esperienza utente e per la tua attività. Le aspettative degli utenti sui dispositivi mobili crescono costantemente ed è fondamentale stare al passo con questa richiesta di velocità.

Le pagine che facevano parte di questa gara e che dovevamo migliorare erano la home page, la panoramica delle categorie e la pagina dei dettagli del prodotto. Dove nel nostro caso la pagina del prodotto aveva bisogno dell’amore e della cura più teneri.

Eliminare le richieste
Il primo passo che abbiamo intrapreso è stato dare un’occhiata alle richieste che le nostre pagine stanno facendo, cosa che può essere facilmente eseguita in Chrome DevTools (o con siti come WebPageTest) . Abbiamo scoperto abbastanza facilmente che stavamo caricando troppe risorse e talvolta persino non necessarie. Ad esempio, perché dovresti caricare un’immagine per un dispositivo mobile se dovrebbe essere visualizzata solo sul desktop giusto? È un controllo rapido e con esso puoi risparmiare molti kilobyte.

Un’altra cosa che abbiamo scoperto è che l’ordine di caricamento degli asset non era corretto e non stava avvantaggiando il nostro percorso di rendering critico. Dopo aver guardato un corso gratuito di Google abbiamo scoperto le seguenti cose:

Caricamento lento delle immagini
Osservando le richieste abbiamo notato che avevamo già scaricato la maggior parte delle immagini, quindi il passaggio successivo più logico per noi è stato implementare il caricamento lento.

Abbiamo già utilizzato Intersection Observer sulle nostre pagine per l’invio di tagging a GTM, quindi potremmo facilmente estendere questa funzionalità per caricare in modo lento le immagini. Per questo abbiamo utilizzato il pacchetto react-intersection-observer, che rende la vita un po ‘più semplice ma puoi anche implementarlo tu stesso, ovviamente.

Dopo averlo abilitato sulla nostra pagina del prodotto, abbiamo immediatamente notato un forte calo delle dimensioni dell’immagine sulla pagina, dove abbiamo iniziato a 1,21 MB e finito con 122 KB!

Ottimizzazione del pacchetto javascript
JavaScript è di gran lunga il più pesante da caricare per il browser poiché blocca il rendering e mantiene occupato il thread principale, quindi ogni kilobyte che puoi eliminare dal tuo pacchetto è un vantaggio immediato per le tue prestazioni.

Usiamo webpack-bundle-analyzer per ispezionare i nostri bundle. Questo è uno strumento molto utile che puoi utilizzare per ottimizzare il tuo pacchetto lato client poiché puoi vedere molto facilmente quali pacchetti sono (troppo) grandi o quali pacchetti non dovrebbero appartenere al pacchetto.

I soliti sospetti da eliminare sono per lo più librerie come Lodash o jQuery, dovresti metterti alla prova se ne hai bisogno. Alla fine di questo esercizio abbiamo quasi risparmiato 100 KB.

Ottimizzazione del CSS
Nella nostra azienda utilizziamo ITCSS, ma la pagina del prodotto non è stata ancora convertita per utilizzarlo, quindi questa è stata una buona opportunità per riscrivere, ripulire il CSS duplicato e usa le classi CSS già esistenti che alla fine hanno risparmiato 13 KB in più.

Dato che CSS blocca il rendering, abbiamo deciso di incorporare gli stili per base, intestazione e piè di pagina, il che ha migliorato notevolmente il First Contentful Paint. I passaggi successivi che stiamo intraprendendo sono l’integrazione del resto degli stili di pagina critici e la creazione di fogli di stile diversi per dispositivo.

Memorizzazione nella cache delle risposte alle chiamate del servizio lato server
Le nostre pagine effettuano chiamate diverse a microservizi diversi, alcune personalizzate, altre mostrano dati in tempo reale. Questi servizi non possiamo memorizzare nella cache, ma abbiamo anche risposte di servizio che possiamo memorizzare nella cache, alcune per un minuto e altre molto più a lungo.

Abbiamo implementato la cache del nodo e per ogni chiamata controlliamo se abbiamo una risposta in cache, altrimenti andremo a prendere il servizio. Alcuni servizi memorizzeranno anche la loro risposta, ma memorizzarla nella cache anche sul client salverà la chiamata e la potenziale latenza.

Ovviamente devi scoprire quale sarebbe la durata migliore della memorizzazione nella cache se entrambe le parti eseguissero la memorizzazione nella cache. Ad esempio, se entrambi i lati memorizzano nella cache per 30 minuti, potrebbero essere necessari fino a 60 minuti prima che il contenuto del sito web cambi.

Aggiornamento a babel 7 e rimozione del transpiling lato server
Questo è un miglioramento un po ‘tecnico sotto il cofano. Avevamo una configurazione Webpack generica che trasportava il nostro codice lato server nello stesso modo in cui abbiamo eseguito il codice lato client, ma non ce n’è bisogno. Perché il codice lato server dovrebbe essere trasferito per funzionare anche in IE 11? Giusto, non dovrebbe.

L’unica cosa che volevamo trasferire è la funzionalità di import / export perché nel nostro caso riscrivere tutto in require () richiederebbe molto tempo. Regola pratica, se non hai bisogno di importazioni, vai sempre con require sul server. Quindi non c’è più motivo per trasferire il tuo codice.

Insieme all’aggiornamento da babel 6 a 7, abbiamo ridotto molti kilobyte che il server non deve più elaborare! Abbiamo anche avuto un caso in cui il bundle è stato ridotto da 400 kB a 200 kB!

The White Zebra sale
Dopo una gara di quasi due mesi e con tutti i miglioramenti che abbiamo apportato, siamo arrivati ​​secondi con un miglioramento del nostro punteggio complessivo Lighthouse Performance Score da 71 a 78.

Per questo risultato, abbiamo ricevuto alcune parole molto gentili da Google:

Ottimo lavoro per arrivare alla fine della gara di velocità con un aumento di velocità impressionante! E ‘stata una chiamata molto vicina per il 1 ° posto e abbiamo apprezzato molto il tuo entusiasmo per tutta la gara. Sappi che questo è ancora un risultato enorme tra le 85 squadre del Nord Europa: congratulazioni!

Non far cadere la palla, implementa i budget per le prestazioni
Con la gara finita ciò non significa che non dovremmo più concentrarci su velocità e prestazioni, al contrario dovrebbe essere in cima alla mente. Ecco perché abbiamo aggiunto i budget per il rendimento al rendimento di Lighthouse, all’indice di velocità e alle dimensioni dei contenuti.

Se stai mirando al meglio, il tuo pacchetto javascript dovrebbe essere inferiore a 150 KB, il punteggio delle prestazioni di Lighthouse dovrebbe essere superiore a 90 e per le metriche incentrate sull’utente, Google ha alcune linee guida piuttosto valide. Se vuoi spingerlo al limite, è il momento di iniziare a esaminare le app web progressive (PWA).

Grazie per aver dedicato del tempo alla lettura di questa storia! Se ti è piaciuto leggere questa storia, applaudimi facendo clic sul 👏🏻 di seguito in modo che altre persone lo vedano qui su Medium.

Lavoro presso Wehkamp.nl, una delle più grandi società di e-commerce di 🇳🇱
Abbiamo un blog tecnologico, dai un’occhiata e iscriviti se vuoi leggere altre storie come questa. Oppure guarda le nostre offerte di lavoro se stai cercando un ottimo lavoro!