Un case study di alcune importanti modifiche introdotte in Wix per migliorare le prestazioni di caricamento dei siti web per milioni di siti, aprendo la strada per ricevere buoni punteggi di PageSpeed Insights e Core Web Vitals.
Grazie all'utilizzo di standard di settore, cloud provider e funzionalità CDN, insieme a una riscrittura completa del runtime del nostro sito web, la percentuale di siti Wix che raggiungono buoni punteggi del 75° percentile per tutte le metriche Core Web Vitals è più che triplicata anno dopo anno, secondo i dati di CrUX e HTTPArchive.
Wix ha adottato una cultura incentrata sul rendimento e continuerà a implementare ulteriori miglioramenti per gli utenti. Poiché ci concentriamo sui KPI sul rendimento, prevediamo che il numero di siti che superano le soglie di Core Web Vitals aumenterà.
Panoramica
Il mondo del rendimento è meravigliosamente complesso, con molte variabili e complessità. La ricerca mostra che la velocità del sito ha un impatto diretto sui tassi di conversione e sulle entrate delle attività. Negli ultimi anni, il settore ha posto maggiore enfasi sul rendimento, sulla visibilità e sul miglioramento della velocità del web. A partire da maggio 2021, i segnali relativi all'esperienza sulle pagine saranno inclusi nel ranking della Ricerca Google.
La sfida unica di Wix è supportare milioni di siti, alcuni dei quali sono stati creati molti anni fa e non sono stati aggiornati da allora. Disponiamo di vari strumenti e articoli per aiutare i nostri utenti a capire cosa possono fare per analizzare e migliorare il rendimento dei loro siti.
Wix è un ambiente gestito e non tutto è nelle mani dell'utente. La condivisione di infrastrutture comuni presenta molte sfide per tutti questi siti, ma offre anche opportunità per miglioramenti significativi a livello generale, ad esempio sfruttando le economie di scala.
Parlare una lingua comune
Una delle principali difficoltà relative al rendimento è trovare una terminologia comune per discutere di diversi aspetti dell'esperienza utente, tenendo conto sia del rendimento tecnico che di quello percepito. L'utilizzo di un linguaggio comune ben definito all'interno dell'organizzazione ci ha permesso di discutere e classificare facilmente le diverse parti tecniche e i compromessi, di chiarire i nostri report sul rendimento e di capire in che modo migliorare innanzitutto gli aspetti più importanti.
Abbiamo modificato tutte le nostre discussioni interne e di monitoraggio in modo da includere le metriche standard del settore come Web Vitals, che includono:
Punteggi di complessità e rendimento del sito
È abbastanza facile creare un sito che si carica immediatamente, a condizione che lo semplifichi molto utilizzando solo HTML e lo pubblichi tramite una CDN.
Tuttavia, la realtà è che i siti diventano sempre più complessi e sofisticati, funzionano più come applicazioni che come documenti e supportano funzionalità come blog, soluzioni di e-commerce, codice personalizzato e così via.
Wix offre un'ampia varietà di modelli, che consentono agli utenti di creare facilmente un sito con molte funzionalità aziendali. Queste funzionalità aggiuntive spesso comportano alcuni costi in termini di rendimento.
Il viaggio
All'inizio c'era HTML
Ogni volta che viene caricata una pagina web, inizia sempre con una richiesta iniziale a un URL per recuperare il documento HTML. Questa risposta HTML attiva tutte le richieste del client aggiuntive e la logica del browser per eseguire e visualizzare il tuo sito. Questa è la parte più importante del caricamento della pagina, perché non accade nulla fino all'inizio della risposta (noto come TTFB, tempo di risposta del primo byte).
Il passato: il rendering lato client (CSR)
Quando utilizzi sistemi su larga scala, devi sempre fare dei compromessi, ad esempio in termini di prestazioni, affidabilità e costi. Fino a qualche anno fa, Wix utilizzava il rendering lato client (CSR), in cui i contenuti HTML effettivi venivano generati tramite JavaScript lato client (ovvero nel browser), il che ci consentiva di supportare un numero elevato di siti senza costi operativi di backend elevati.
La CSR ci ha permesso di utilizzare un documento HTML comune, essenzialmente vuoto. Tutto ciò che ha fatto è stato attivare il download del codice e dei dati richiesti, che sono stati poi utilizzati per generare il codice HTML completo sul dispositivo client.
Oggi: rendering lato server (SSR)
Alcuni anni fa abbiamo eseguito la transizione al rendering lato server (SSR), poiché era utile sia per la SEO sia per le prestazioni, migliorando i tempi di visibilità iniziali della pagina e garantendo un'indicizzazione migliore per i motori di ricerca che non supportano completamente l'esecuzione di JavaScript.
Questo approccio ha migliorato l'esperienza di visibilità, in particolare su dispositivi/connessioni più lenti, e ha aperto la strada a ulteriori ottimizzazioni del rendimento. Tuttavia, significava anche che per ogni richiesta di pagina web veniva generata dinamicamente una risposta HTML univoca, il che è lontano dall'ottimizzazione, soprattutto per i siti con un numero elevato di visualizzazioni.
Introduzione della memorizzazione nella cache in più posizioni
Il codice HTML di ogni sito era per lo più statico, ma presentava alcune limitazioni:
- Cambiano spesso. Ogni volta che un utente modifica il proprio sito o apporta modifiche ai dati del sito, ad esempio all'inventario del negozio del sito web.
- Conteneva determinati dati e cookie specifici per i visitatori, il che significa che due persone che visitavano lo stesso sito vedevano HTML leggermente diverso. Ad esempio, per supportare le funzionalità dei prodotti, come ricordare gli articoli che un visitatore ha inserito nel carrello, la chat che ha avviato con l'attività in precedenza e altro ancora.
- Non tutte le pagine sono memorizzabili nella cache. Ad esempio, una pagina con codice utente personalizzato, che mostra l'ora corrente all'interno del documento, non è idonea per la memorizzazione nella cache.
Inizialmente, abbiamo adottato l'approccio relativamente sicuro di memorizzare nella cache il codice HTML senza i dati dei visitatori, per poi modificare al volo solo parti specifiche della risposta HTML per ogni visitatore e per ogni hit della cache.
Soluzione CDN interna
Per farlo, abbiamo implementato una soluzione interna: abbiamo utilizzato Varnish HTTP Cache per il proxy e la memorizzazione nella cache, Kafka per i messaggi di invalidazione e un servizio basato su Scala/Netty che esegue il proxy di queste risposte HTML, ma modifica il codice HTML e aggiunge dati e cookie specifici del visitatore alla risposta memorizzata nella cache.
Questa soluzione ci ha permesso di eseguire il deployment di questi componenti slim in molte più località geografiche e in più regioni di fornitori di cloud, distribuite in tutto il mondo. Nel 2019 abbiamo introdotto oltre 15 nuove regioni e gradualmente abbiamo attivato la memorizzazione nella cache per oltre il 90% delle visualizzazioni di pagina idonee. La pubblicazione dei siti da località aggiuntive ha ridotto la latenza della rete tra i client e i server che pubblicano la risposta HTML, avvicinando i contenuti ai visitatori del sito web.
Abbiamo anche iniziato a memorizzare nella cache determinate risposte dell'API di sola lettura utilizzando la stessa soluzione e invalidando la cache in caso di qualsiasi modifica ai contenuti del sito. Ad esempio, l'elenco dei post del blog sul sito viene memorizzato nella cache e invalidato quando un post viene pubblicato/modificato.
Riduzione delle complessità
L'implementazione della memorizzazione nella cache ha migliorato notevolmente le prestazioni, soprattutto nelle fasi di TTFB e FCP, e ha migliorato la nostra affidabilità pubblicando i contenuti da una posizione più vicina all'utente finale.
Tuttavia, la necessità di modificare il codice HTML per ogni risposta ha introdotto una complessità non necessaria che, se rimossa, offriva un'opportunità per ulteriori miglioramenti delle prestazioni.
Memorizzazione nella cache del browser (e preparazione per le CDN)
Circa il 13%
Richieste HTML pubblicate direttamente dalla cache del browser, che consentono di risparmiare molta larghezza di banda e ridurre i tempi di caricamento per le visualizzazioni ripetute
Il passaggio successivo è stato rimuovere completamente questi dati specifici del visitatore dal codice HTML e recuperarli da un endpoint separato, chiamato dal client a questo scopo, dopo l'arrivo del codice HTML.
Abbiamo eseguito con attenzione la migrazione di questi dati e cookie a un nuovo endpoint, che viene chiamato a ogni caricamento di pagina, ma restituisce un JSON snello, necessario solo per la procedura di idratazione, per raggiungere l'interattività a livello di pagina completa.
Ciò ci ha permesso di attivare la memorizzazione nella cache del codice HTML da parte del browser, il che significa che ora i browser salvano la risposta HTML per le visite ripetute e chiamano il server solo per verificare che i contenuti non siano stati modificati. Questo viene fatto utilizzando l'ETag HTTP, che è essenzialmente un identificatore assegnato a una versione specifica di una risorsa HTML. Se i contenuti rimangono invariati, i nostri server inviano al client una risposta 304 Not modifed senza corpo.
Inoltre, questa modifica significa che il nostro codice HTML non è più specifico per i visitatori e non contiene cookie. In altre parole, può essere memorizzata nella cache praticamente ovunque, aprendo la strada all'utilizzo di fornitori CDN con una presenza geografica molto migliore in centinaia di località in tutto il mondo.
DNS, SSL e HTTP/2
Con la memorizzazione nella cache abilitata, i tempi di attesa sono stati ridotti e altre parti importanti della connessione iniziale sono diventate più sostanziali. Il miglioramento della nostra infrastruttura di rete e del monitoraggio ci ha permesso di migliorare i tempi di DNS, connessione e SSL.
HTTP/2 è stato attivato per tutti i domini utente, riducendo sia la quantità di connessioni richieste sia l'overhead associato a ogni nuova connessione. Si è trattato di una modifica relativamente semplice da implementare, che ha consentito di usufruire dei vantaggi in termini di prestazioni e resilienza offerti da HTTP/2.
Compressione Brotli (rispetto a gzip)
21 - 25%
Riduzione delle dimensioni medie dei trasferimenti di file
Tradizionalmente, tutti i nostri file venivano compressi utilizzando la compressione GZIP, che è l'opzione di compressione HTML più diffusa sul web. Questo protocollo di compressione è stato inizialmente implementato quasi 30 anni fa.
La più recente compressione Brotli introduce miglioramenti alla compressione con quasi nessun compromesso e sta lentamente diventando più popolare, come descritto nel capitolo Compressione dell'Almanaco web annuale. È supportato da tutti i principali browser da un po' di tempo.
Abbiamo attivato il supporto di Brotli sui nostri proxy nginx nelle reti perimetrali per tutti i client che lo supportano.
Il passaggio all'utilizzo della compressione Brotli ha ridotto le dimensioni medie dei trasferimenti di file dal 21% al 25%, con una conseguente riduzione dell'utilizzo della larghezza di banda e un miglioramento dei tempi di caricamento.
Reti CDN (Content Delivery Network)
Selezione CDN dinamica
In Wix abbiamo sempre utilizzato le CDN per pubblicare tutto il codice JavaScript e le immagini sui siti web degli utenti.
Di recente abbiamo integrato una soluzione del nostro provider DNS per selezionare automaticamente la CDN con il rendimento migliore in base alla rete e all'origine del cliente. In questo modo, possiamo pubblicare i file statici dalla posizione migliore per ogni visitatore ed evitare problemi di disponibilità su una determinata CDN.
Disponibile a breve… domini utente pubblicati da CDN
L'ultimo pezzo del puzzle è la pubblicazione dell'ultima parte, la più importante, tramite una CDN: il codice HTML del dominio dell'utente.
Come descritto sopra, abbiamo creato una nostra soluzione interna per memorizzare nella cache e pubblicare i risultati HTML e API specifici del sito. La gestione di questa soluzione in così tante nuove regioni ha anche dei costi operativi e l'aggiunta di nuove località diventa un processo che dobbiamo gestire e ottimizzare continuamente.
Al momento stiamo integrando vari fornitori di CDN per supportare la pubblicazione dell'intero sito Wix direttamente dalle sedi CDN al fine di migliorare la distribuzione dei nostri server in tutto il mondo e, di conseguenza, migliorare ulteriormente i tempi di risposta. Si tratta di un compito difficile a causa della grande quantità di domini che gestiamo, che richiedono la terminazione SSL all'edge.
L'integrazione con le CDN avvicina i siti web Wix ai clienti come mai prima d'ora e offre ulteriori miglioramenti all'esperienza di caricamento, tra cui tecnologie più recenti come HTTP/3, senza alcun intervento da parte nostra.
Qualche parola sul monitoraggio delle prestazioni
Se gestisci un sito Wix, probabilmente ti stai chiedendo come si traducono questi dati nei risultati sul rendimento del tuo sito Wix e come ci confrontiamo con altre piattaforme di siti web.
La maggior parte del lavoro svolto sopra è stata implementata nell'ultimo anno e parte è ancora in fase di implementazione.
Di recente, The Web Almanac di HTTPArchive ha pubblicato la versione 2020, che include un eccellente capitolo sull'esperienza utente del CMS. Tieni presente che molti dei numeri descritti in questo articolo risalgono alla metà del 2020.
Non vediamo l'ora di vedere il report aggiornato nel 2021 e monitoriamo attivamente i report CrUX per i nostri siti, nonché le nostre metriche sul rendimento interno.
Ci impegniamo a migliorare continuamente i tempi di caricamento e a fornire ai nostri utenti una piattaforma su cui possono creare siti come li immaginano, senza compromettere il rendimento.
Di recente DebugBear ha pubblicato un report molto interessante sul rendimento dei siti web, che tocca alcune delle aree sopra menzionate ed esamina il rendimento di siti molto semplici creati su ogni piattaforma. Questo sito è stato creato quasi due anni fa e non è stato modificato da allora, ma la piattaforma è in continuo miglioramento, così come il rendimento del sito, come si può vedere visualizzando i suoi dati nell'ultimo anno e mezzo.
Conclusione
Ci auguriamo che la nostra esperienza ti incoraggi ad adottare una cultura orientata al rendimento nella tua organizzazione e che i dettagli riportati sopra ti siano utili e applicabili alla tua piattaforma o al tuo sito.
In sintesi:
- Scegli un insieme di metriche che puoi monitorare in modo coerente utilizzando strumenti approvati dal settore. Consigliamo Core Web Vitals.
- Utilizza la memorizzazione nella cache del browser e le CDN.
- Esegui la migrazione a HTTP/2 (o HTTP/3, se possibile).
- Utilizza la compressione Brotli.
Grazie per aver letto la nostra storia. Ti invitiamo a porre domande, condividere idee su Twitter e GitHub e partecipare alla conversazione sulla performance web sui tuoi canali preferiti.