Un caso di studio sulle modifiche implementate da GoDaddy per migliorare le prestazioni dei siti web di milioni di siti, aiutandoli a ottenere buoni punteggi di PageSpeed Insights e Core Web Vitals.
GoDaddy è la più grande piattaforma di servizi per imprenditori di tutto il mondo. La nostra missione è aiutare la nostra community mondiale di oltre 20 milioni di clienti ed imprenditori di tutto il mondo fornendo loro tutto l'aiuto e gli strumenti di cui hanno bisogno per crescere online.
Nel 2019 GoDaddy ha lanciato Websites + Marketing con l'impegno di fornire strumenti e servizi facili da usare che aiutano i proprietari di attività a raggiungere i loro obiettivi. Websites + Marketing integra la creazione di siti web con strumenti di marketing ed e-commerce e li abbina a indicazioni di livello superiore per aiutare i clienti a raggiungere il successo con le loro nuove iniziative.
Dal lancio di Siti web + marketing, il rendimento è stato una parte importante del prodotto e un aspetto su cui è stato monitorato e lavorato attivamente. In questo articolo esamineremo il percorso di GoDaddy dall'utilizzo dei test di prestazioni di laboratorio all'utilizzo di dati reali con Core Web Vitals e la serie di miglioramenti apportati al prodotto per ottenere un tasso di superamento molto elevato per i siti dei nostri clienti.
Monitoraggio del rendimento con Lighthouse
Ci siamo basati sui dati di Lighthouse per il monitoraggio del rendimento. Ogni volta che un sito web viene pubblicato sulla piattaforma, ne misuriamo il rendimento utilizzando il nostro strumento interno denominato "Lighthouse4u", che fornisce Google Lighthouse come servizio https://github.com/godaddy/lighthouse4u. Questo ci ha dato una buona indicazione sul rendimento generale dei siti in un'impostazione di laboratorio.
Poiché i milioni di siti che ospitiamo sulla nostra piattaforma offrono una vasta gamma di funzionalità e contenuti, era importante combinare i dati sul rendimento con i metadati di ciascun sito sottoposto a test (ad esempio il modello utilizzato, il tipo di widget visualizzati e così via). Questo ci ha permesso di trarre conclusioni sulle funzionalità del sito web con prestazioni inferiori, fornendo al contempo informazioni su dove cercare i miglioramenti.
Ad esempio, questo ci ha aiutato a identificare che la "finestra popup modale" aveva un impatto negativo sulla velocità della pagina: i siti con la funzionalità avevano un rendimento inferiore di 12 punti rispetto a quelli senza. Dopo aver apportato aggiornamenti al codice per posticipare il caricamento di JavaScript, abbiamo migliorato il nostro punteggio Lighthouse di 2 punti. Abbiamo potuto applicare queste informazioni ad altre funzionalità, come il "banner dei cookie" che viene visualizzato subito dopo il caricamento della pagina.
Oltre a esaminare i siti problematici in base alle funzionalità, abbiamo condotto un'analisi del nostro bundle JavaScript e abbiamo notato che gran parte delle sue dimensioni deriva da dipendenze esterne (immutable.js e draft.js). Abbiamo ridotto le dimensioni del bundle ristrutturando i consumatori in modo da caricare le dipendenze in modo lazy on demand. Ciò ha comportato un calo di oltre il 50% delle dimensioni del bundle JavaScript comune, che è passato da oltre 200 KB a circa 90 KB (minimizzato). Le dimensioni ridotte del bundle hanno consentito al browser di caricare asset esterni ed eseguire script critici all'inizio del ciclo di vita del caricamento iniziale del sito, con un miglioramento di Largest Contentful Paint (LCP) e First Input Delay (FID).
Grazie al nostro costante impegno, il punteggio Lighthouse medio dei siti dei clienti è passato da circa 40 punti a novembre 2020 a oltre 70 punti a maggio 2021. Tuttavia, non tutti i nostri tentativi sono andati a buon fine e a volte ci siamo stupiti quando i risultati non erano sempre coerenti tra ciò che è stato testato negli ambienti di test locali e i risultati ottenuti sul campo. I risultati del laboratorio erano stati molto utili, ma era arrivato il momento di concentrarsi sulle esperienze utente reali osservate sul campo.
Monitoraggio dei dati utente reali con Core Web Vitals
Dopo aver aggiunto la libreria web-vitals ai siti dei nostri clienti, siamo stati in grado di misurare i dati sui dispositivi reali di visitatori reali, in cui hardware, velocità di rete e interazione degli utenti (come scorrimento o clic) non sono una base di riferimento coerente come in un ambiente di laboratorio utilizzando Lighthouse. Si è trattato di un grande passo nella giusta direzione, poiché ora disponevamo di dati rappresentativi dell'esperienza dei visitatori del nostro sito web.
Concentrarsi sul nostro anello debole: Cumulative Layout Shift (CLS)
L'analisi dei nuovi dati ci ha fornito una nuova prospettiva su cosa dovevamo fare per migliorare la velocità del sito web. Grazie al lavoro svolto per migliorare il punteggio Lighthouse, il nostro LCP al 75° percentile era di 860 ms e il nostro FID alla stessa soglia era inferiore a 10 ms, quindi abbiamo registrato un tasso di superamento elevato per queste metriche sui siti dei nostri clienti: rispettivamente 78% e 98%. Tuttavia, i valori di variazione layout cumulativa (CLS) sembrano molto diversi da quelli a cui eravamo abituati con Lighthouse. Il nostro CLS al 75° percentile era pari a 0,17, sopra la soglia di 0,1 per il "superamento", pertanto il nostro tasso di superamento era solo del 47% su tutti i nostri siti.
Questa metrica ha ridotto il nostro tasso di successo complessivo al 40%, quindi abbiamo deciso di stabilire un obiettivo ambizioso per portarlo al di sopra del 60% entro la fine di agosto 2021. Per farlo, dobbiamo concentrarci sul CLS.
Nella vita reale, gli utenti interagiscono con la pagina e scorrono oltre i contenuti "above the fold", un aspetto che Core Web Vitals acquisisce meglio. A causa della variabilità del modo in cui gli utenti interagiscono con il sito durante il caricamento iniziale, il CLS era diverso dai dati di laboratorio e sul campo.
Il percorso per superare tutti i Core Web Vitals
Per migliorare il rendimento è necessario procedere per tentativi ed errori e ogni tentativo non funziona sempre come previsto. Tuttavia, ecco alcuni miglioramenti che ci hanno aiutato a raggiungere i nostri obiettivi.
La riserva di spazio per il caricamento delle immagini ha migliorato drasticamente il nostro punteggio CLS, in quanto impedisce lo spostamento dei contenuti sotto le immagini. Abbiamo utilizzato la proprietà CSS aspect-ratio per risolvere il problema sui browser che la supportano. Per quelli che non lo fanno, abbiamo caricato un'immagine segnaposto trasparente memorizzata nella cache e di dimensioni di pochi byte, che viene caricata quasi istantaneamente.
Questo comportamento generico delle immagini ci ha consentito di precalcolare l'altezza dell'immagine finale durante il rendering lato server, in base alla larghezza dell'area visibile e alle proporzioni dell'immagine. Il risultato è stato un markup HTML con spazio verticale opportunamente riservato per l'immagine finale. Il miglioramento è stato particolarmente evidente sui dispositivi mobili, poiché le immagini vengono visualizzate in tutta la larghezza dei viewport dei dispositivi mobili.
Alcuni componenti dei siti dei nostri clienti presentano contenuti dinamici (ad esempio un elenco di recensioni dei clienti esterni) e non è stato possibile convertirli in CSS puro per sfruttare i vantaggi in termini di prestazioni del rendering lato server. Si tratta di aree difficili in cui migliorare i cambiamenti di layout perché i contenuti (e quindi l'altezza) variano. In questi casi, abbiamo inserito il componente in un contenitore con un min-height applicato, predeterminato in base all'osservazione dell'altezza media di ciascuno dei componenti specifici. min-height viene rimosso al termine del rendering del componente dinamico interno. Sebbene non sia perfetta, questa soluzione ci ha permesso di ridurre notevolmente il cambiamento di layout.
Mentre ci concentravamo sui miglioramenti del CLS, abbiamo continuato a lavorare su LCP. Su molti siti web, le immagini sono il principale fattore che contribuisce al tempo di caricamento della pagina e per noi era un'area di miglioramento evidente. Abbiamo apportato miglioramenti al caricamento delle immagini in modo lazy utilizzando IntersectionObserver, ma ci siamo resi conto che le dimensioni delle immagini non erano impostate nel modo più ottimale per ogni breakpoint (dispositivo mobile, tablet, computer, computer di grandi dimensioni), quindi abbiamo aggiornato il nostro codice di generazione delle immagini per limitare e ridimensionare le immagini in base al breakpoint e poi ridimensionare di nuovo la risoluzione in base alla densità dei pixel. Ad esempio, le dimensioni di un'immagine di grandi dimensioni specifica sono state ridotte da 192 KB a 102 KB.
Per eseguire il rendering rapido dei siti web su dispositivi con connessioni di rete scadenti, abbiamo aggiunto del codice per ridurre dinamicamente la qualità delle immagini in base alla velocità di connessione. A questo scopo, utilizza la proprietà downlink restituita da navigator.connection. Applichiamo parametri di query basati su URL per ridurre la qualità delle immagini tramite la nostra API asset in base a queste condizioni di rete.
Alcune sezioni dei siti dei nostri clienti vengono caricate dinamicamente. Poiché sappiamo quali sezioni verranno visualizzate su un determinato sito quando viene pubblicato, abbiamo utilizzato l'suggerimento della risorsa rel=preconnect per inizializzare in anticipo la connessione e i handshake necessari. Utilizziamo inoltre i suggerimenti di risorse per caricare rapidamente caratteri e altre risorse importanti.
Quando creano i propri siti, i clienti aggiungono varie sezioni che potrebbero avere script in linea per consentire funzionalità diverse. La presenza di questi script in linea nella pagina HTML non è sempre ottimale per le prestazioni. Abbiamo deciso di esternalizzare questi script per consentire al browser di caricare e analizzare i contenuti degli script in modo asincrono. Gli script appena esternizzati potrebbero essere condivisi anche tra le pagine. Ciò ha consentito ulteriori miglioramenti delle prestazioni sotto forma di memorizzazione nella cache del browser e della CDN. Abbiamo mantenuto gli script critici in linea per consentire al browser di analizzarli ed eseguirli più rapidamente.
Risultati
Il nostro impegno incentrato sul CLS ha dato i suoi frutti: il tasso di superamento dei Core Web Vitals è passato da circa il 40% a quasi il 70%, un miglioramento del 75%.
Quando gli utenti tornano sulla nostra piattaforma per apportare aggiornamenti e ripubblicare i loro siti, ricevono gli ultimi miglioramenti delle prestazioni e, di conseguenza, il numero di siti che "superano Core Web Vitals" è in costante crescita, come mostrato nel grafico seguente:
Conclusioni
Individuare le aree di miglioramento del rendimento e monitorare correttamente i progressi dipende in gran parte dagli strumenti utilizzati per la misurazione. Sebbene Lighthouse fosse utile per misurare il rendimento della parte visibile della pagina in un "ambiente di laboratorio", non rilevava con precisione i problemi di rendimento che si verificavano solo a causa delle interazioni degli utenti (ad esempio lo scorrimento della pagina).
Il monitoraggio di Core Web Vitals reali con i metadati ci ha permesso di visualizzare, scegliere come target e misurare l'impatto dei nostri miglioramenti. Il percorso per migliorare i punteggi Core Web Vitals ha permesso al team di identificare e sostituire gli schemi non performanti rilevati nella base di codice. A volte, modifiche promettenti non hanno avuto l'impatto che ci aspettavamo, altre volte è successo il contrario. Il mondo non è perfetto, quindi devi continuare a provare.