Un case study delle modifiche che GoDaddy ha implementato per migliorare le prestazioni del sito web di milioni di siti, aiutandoli a ottenere buoni punteggi PageSpeed Insights e Core Web Vitals.
GoDaddy è la più grande piattaforma di servizi al mondo per imprenditori di tutto il mondo. La nostra missione è aiutare la nostra community mondiale di oltre 20 milioni di clienti e imprenditori in tutto il mondo, fornendo loro tutto l'aiuto e gli strumenti di cui hanno bisogno per crescere online.
Nel 2019 GoDaddy ha lanciato Website + Marketing con l'impegno di fornire strumenti e servizi facili da usare e aiutare i proprietari di attività a raggiungere i loro obiettivi. Website + Marketing integra la creazione di siti web con strumenti di marketing ed e-commerce e li abbina alle migliori linee guida per aiutare i clienti a raggiungere il successo con le loro nuove imprese.
Fin dal lancio di Website + Marketing, il rendimento è stato una parte importante del prodotto che è stata monitorata e lavorata attivamente. In questo articolo esamineremo il percorso di GoDaddy dall'utilizzo dei test sulle prestazioni di laboratorio all'utilizzo di dati reali con Core Web Vitals e la serie di miglioramenti apportati al prodotto per ottenere una percentuale di superamento molto elevata per i siti dei nostri clienti.
Monitorare il rendimento con Lighthouse
Per il monitoraggio del rendimento abbiamo fatto affidamento sui dati di Lighthouse. Ogni volta che un sito web viene pubblicato sulla piattaforma, ne misuriamo le prestazioni utilizzando il nostro strumento interno denominato "Lighthouse4u", che fornisce come servizio Google Lighthouse https://github.com/godaddy/lighthouse4u. Questo ci ha fornito una buona indicazione delle prestazioni generali dei siti in un laboratorio.
Poiché i milioni di siti ospitati sulla nostra piattaforma hanno un'ampia gamma di funzionalità e contenuti, era importante combinare i dati sul rendimento con i metadati relativi a ogni sito testato (come il modello utilizzato, il tipo di widget visualizzati e così via). Questo ci ha permesso di trarre conclusioni sulle funzionalità del sito web che hanno registrato un rendimento inferiore, fornendo al contempo informazioni su dove cercare miglioramenti.
Ad esempio, questo ci ha aiutato a identificare che la "finestra modale popup" aveva un impatto negativo sulla velocità delle pagine; i siti con questa funzione avevano registrato un rendimento inferiore di 12 punti rispetto a quello precedente. Dopo aver aggiornato il codice per rinviare il caricamento di JavaScript, abbiamo migliorato il punteggio Lighthouse di 2 punti. Abbiamo potuto applicare queste conoscenze ad altre funzionalità come il "banner dei cookie" che viene visualizzato subito dopo il caricamento della pagina.
Oltre all'analisi dei siti problematici in base alle funzionalità, abbiamo condotto un'analisi del nostro bundle JavaScript e abbiamo visto che gran parte delle sue dimensioni proveniva da dipendenze esterne (imutable.js e sketch.js). Abbiamo ridotto le dimensioni del bundle riorganizzando i consumatori in dipendenze di caricamento lento on demand. Ciò ha comportato un calo di oltre il 50% delle dimensioni comuni dei bundle JavaScript, che sono passate da oltre 200 kB a circa 90 kB (minimizzati). Le dimensioni ridotte dei bundle hanno permesso al browser di caricare asset esterni ed eseguire script critici nelle prime fasi del ciclo di vita del caricamento del sito, con conseguente aumento delle metriche Largest Contentful Paint (LCP) e First Input Delay (FID).
Grazie al nostro continuo impegno, il punteggio medio di Lighthouse del sito dei clienti è passato da circa 40 punti a novembre 2020 a oltre 70 punti a maggio 2021. Tuttavia, non tutti i nostri tentativi hanno funzionato e a volte siamo rimasti sorpresi quando i risultati non erano sempre coerenti tra ciò che è stato testato in ambienti di test locali e i risultati che abbiamo ottenuto sul campo. I risultati del lab sono stati davvero utili, ma era giunto il momento di concentrarsi sulle esperienze utente reali osservate sul campo.
Monitorare i dati degli utenti 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 effettivi di visitatori reali, nei casi in cui hardware, velocità della rete e interazione degli utenti (ad esempio, scorrimento o clic) non abbiano una base di riferimento coerente, come in un ambiente di laboratorio usando Lighthouse. Si è trattato di un grande passo nella giusta direzione, poiché ora avevamo dati rappresentativi dell'esperienza dei visitatori del nostro sito web.
Concentrazione sull'anello più debole: Cumulative Layout Shift (CLS)
L'analisi dei nuovi dati ci ha offerto una nuova prospettiva sulle misure da adottare per migliorare la velocità del sito web. A causa del lavoro svolto per migliorare il punteggio di Lighthouse, la nostra LCP del 75° percentile era di 860 ms e il nostro FID alla stessa soglia era inferiore a 10 ms, quindi abbiamo goduto di un tasso di superamento elevato per queste metriche sui siti dei nostri clienti: rispettivamente 78% e 98%. Tuttavia, i valori relativi alla Cumulative Layout Shift (CLS) sembrano molto diversi da quelli a cui eravamo abituati con Lighthouse. Il nostro CLS al 75° percentile era di 0,17, al di sopra della soglia di 0,1 per "superare", e la nostra percentuale di superamento era quindi solo del 47% su tutti i nostri siti.
Quella metrica ha ridotto il nostro tasso di superamento complessivo al 40%, quindi abbiamo deciso di fissare un obiettivo ambizioso per portare questo numero oltre il 60% entro la fine di agosto 2021. Per farlo, dovremmo concentrarci sul CLS.
Nella vita reale, gli utenti interagiscono con la pagina e scorrono i contenuti "above the fold". Questa funzionalità viene acquisita meglio da Segnali web essenziali. A causa della variabilità del modo in cui gli utenti interagiscono con il sito durante il caricamento iniziale, la metrica CLS differisce dai dati di prova controllati e reali.
Il percorso per superare tutti i Segnali web essenziali
Il miglioramento delle prestazioni richiede prove ed errori e non sempre ogni tentativo funziona come previsto. Tuttavia, di seguito sono riportati alcuni miglioramenti che ci hanno aiutato a raggiungere i nostri obiettivi.
Riservare spazio per il caricamento delle immagini ha migliorato drasticamente il nostro punteggio CLS, in quanto impedisce lo spostamento dei contenuti sotto le immagini. Per risolvere questo problema abbiamo utilizzato la proprietà CSS aspect-ratio sui browser che la supportano. Per quelli che non lo avessero, abbiamo caricato un'immagine segnaposto trasparente che è stata memorizzata nella cache e ha una dimensione di pochi byte, in modo da caricarsi quasi istantaneamente.
Questo comportamento generico dell'immagine ci ha permesso di precalcolare l'altezza finale dell'immagine durante il rendering lato server, in base alla larghezza dell'area visibile e alle proporzioni dell'immagine. Di conseguenza, il markup HTML con spazio verticale è stato opportunamente riservato per l'immagine finale. Il miglioramento è stato particolarmente osservabile sui dispositivi mobili, poiché le immagini vengono visualizzate nell'intera gamma di aree visibili dei dispositivi mobili.
Alcuni componenti dei siti dei nostri clienti presentano contenuti dinamici (ad es. un elenco di recensioni di clienti esterni) e non è stato possibile convertirli in CSS puri per sfruttare i vantaggi in termini di prestazioni del rendering lato server. Si tratta di aree difficili da migliorare le variazioni del layout perché i contenuti (quindi l'altezza) variano. In questi casi, abbiamo inserito il componente in un container 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 consentito di ridurre notevolmente la variazione del layout.
Mentre ci siamo concentrati sui miglioramenti della metrica CLS, abbiamo continuato a lavorare sulla metrica LCP. Su molti siti web, le immagini sono il principale responsabile della metrica LCP e per noi è stata un'area di miglioramento evidente. Avevamo apportato miglioramenti alle immagini con caricamento lento utilizzando IntersectionObserver, ma ci siamo resi conto che le dimensioni delle immagini non erano impostate nel modo ottimale per ogni punto di interruzione (dispositivo mobile, tablet, computer, desktop di grandi dimensioni), quindi abbiamo aggiornato il nostro codice di generazione delle immagini per bloccare e ridimensionare le immagini per punto di interruzione, quindi abbiamo ridimensionato la risoluzione in base alla densità dei pixel. Ad esempio, ciò ha ridotto le dimensioni di un'immagine di grandi dimensioni specifica da 192 kB a 102 kB.
Per eseguire rapidamente il rendering dei siti web su dispositivi con connessioni di rete deboli, abbiamo aggiunto un codice che consente di ridurre dinamicamente la qualità delle immagini in base alla velocità di connessione. Questa operazione può essere eseguita utilizzando la proprietà downlink restituita da navigator.connection. Applichiamo parametri di query basati su URL per ridurre la qualità delle immagini tramite la nostra API per gli 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 al momento della pubblicazione, abbiamo usato il suggerimento della risorsa rel=preconnect per inizializzare in anticipo la connessione e gli handshake necessari. Usiamo anche suggerimenti relativi alle risorse per caricare rapidamente caratteri e altre risorse importanti.
Quando creano i loro siti, i clienti aggiungono varie sezioni che potrebbero avere script incorporati per consentire funzionalità diverse. Avere questi script incorporati in tutta la 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. I nuovi script esternalizzati potrebbero anche essere condivisi tra le pagine. Ciò ha consentito ulteriori miglioramenti delle prestazioni sotto forma di memorizzazione nella cache del browser e CDN. Abbiamo mantenuto in linea gli script critici per consentire al browser di analizzarli ed eseguirli più velocemente.
Risultati
Concentrando il nostro impegno sul CLS ha dato i suoi frutti, la percentuale di superamento dei Segnali web essenziali è passata da circa il 40% a quasi il 70%, ovvero un miglioramento del 75%.
Quando gli utenti tornano sulla nostra piattaforma per apportare aggiornamenti e ripubblicare i propri siti, ottengono gli ultimi miglioramenti delle prestazioni e, di conseguenza, il numero di siti che "superano i Segnali web essenziali" è in costante crescita, come mostrato nel grafico seguente:
Conclusioni
L'individuazione delle aree per migliorare il rendimento e il corretto monitoraggio dei progressi dipendono in gran parte dagli strumenti utilizzati per la misurazione. Sebbene Lighthouse fosse utile per misurare le prestazioni above the fold in un ambiente "lab", non è stato in grado di acquisire accuratamente i problemi di prestazioni che si verificavano solo nelle interazioni degli utenti (ad esempio lo scorrimento della pagina).
Tracciare i Segnali web essenziali del mondo reale con i metadati ci ha permesso di visualizzare, indirizzare e misurare l'impatto dei nostri miglioramenti. Il percorso volto a migliorare i punteggi di Segnali web essenziali ha permesso al team di identificare e sostituire i pattern non ottimali rilevati nel nostro codebase. A volte le modifiche promettenti non hanno avuto l'impatto che ci aspettavamo, altre volte è successo il contrario. Là fuori non è un mondo immacolato, quindi devi continuare a provare.