Case study di alcune importanti modifiche introdotte da Wix per migliorare le prestazioni di caricamento dei siti web per milioni di siti, che ha aperto il percorso affinché ricevano buoni punteggi PageSpeed Insights e Core Web Vitals.
Secondo i dati di CrUX e HTTPArchive, la percentuale di siti Wix che raggiunge buoni punteggi del 75° percentile su tutte le metriche dei Segnali web essenziali, sfruttando gli standard di settore, i provider di servizi cloud e le funzionalità CDN, unita a un'importante riscrittura del runtime del nostro sito web, è più che triplicata su base annua.
Wix ha adottato una cultura orientata alle prestazioni e ulteriori miglioramenti continueranno a essere implementati agli utenti. Man mano che ci concentriamo sui KPI delle prestazioni, prevediamo di aumentare il numero di siti che superano le soglie dei Segnali web essenziali.
Panoramica
Il mondo delle prestazioni è molto complesso, con molte variabili e complessità. Da una ricerca è emerso che la velocità del sito ha un impatto diretto sui tassi di conversione e sulle entrate per le aziende. Negli ultimi anni, il settore ha posto maggiore enfasi sulla visibilità delle prestazioni e su come rendere il web più veloce. A partire da maggio 2021, gli indicatori dell'esperienza sulle pagine saranno inclusi nel ranking della Ricerca Google.
La sfida unica di Wix è supportare milioni di siti, alcuni dei quali sono stati costruiti molti anni fa e da allora non sono più stati aggiornati. 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à di miglioramenti significativi a tutti i livelli, ad esempio sfruttando le economie di scala.
Parlare in una lingua comune
Una delle difficoltà principali del rendimento è l'individuazione di una terminologia comune per discutere i diversi aspetti dell'esperienza utente, tenendo conto sia delle prestazioni tecniche che percepite. L'utilizzo di un linguaggio comune e ben definito all'interno dell'organizzazione ci ha permesso di discutere e classificare facilmente le diverse parti tecniche e i diversi compromessi, ha chiarito i nostri report sulle prestazioni e ci ha aiutato enormemente a capire quali aspetti dobbiamo concentrarci sul miglioramento per primi.
Abbiamo modificato tutte le nostre iniziative di monitoraggio e le discussioni interne in modo da includere metriche standard di settore come Segnali web, che includono:
Complessità del sito e punteggi delle prestazioni
È abbastanza facile creare un sito che si carica all'istante, purché tu renda tutto molto semplice utilizzando solo HTML e lo pubblichi tramite una rete CDN.
Tuttavia, la realtà è che i siti diventano sempre più complessi e sofisticati, funzionano più come applicazioni piuttosto che come documenti e supportano funzionalità come blog, soluzioni di e-commerce, codice personalizzato e così via.
Wix offre una grande serie di modelli, consentendo ai suoi utenti di creare facilmente un sito con molte funzionalità aziendali. Queste funzionalità aggiuntive spesso comportano alcuni costi di rendimento.
Il viaggio
All'inizio, c'era HTML
Ogni volta che viene caricata una pagina web, viene sempre avviata 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 l'esecuzione e il rendering del tuo sito. Questa è la parte più importante del caricamento della pagina, perché non succede nulla fino all'inizio della risposta (nota come TTFB - time to first byte).
Passato: rendering lato client (CSR)
Quando utilizzi sistemi su larga scala, devi sempre tenere presenti alcuni compromessi da considerare come prestazioni, affidabilità e costi. Fino a qualche anno fa, Wix utilizzava il rendering lato client (CSR), in cui gli effettivi contenuti HTML venivano generati tramite JavaScript sul lato client (ovvero nel browser), consentendoci di supportare siti su larga scala senza dover sostenere enormi costi operativi di backend.
Il CSR ci ha permesso di utilizzare un documento HTML comune, che era essenzialmente vuoto. È stato attivato il download del codice e dei dati richiesti, che sono stati poi utilizzati per generare l'HTML completo sul dispositivo client.
Oggi: rendering lato server (SSR)
Alcuni anni fa siamo passati al rendering lato server (SSR), in quanto era vantaggioso sia per la SEO che per le prestazioni, migliorando i tempi di visibilità iniziali delle pagine e garantendo una migliore indicizzazione per i motori di ricerca che non supportano completamente l'esecuzione di JavaScript.
Questo approccio ha migliorato l'esperienza di visibilità, in particolare sui dispositivi/connessioni più lenti, e ha aperto le porte a ulteriori ottimizzazioni delle prestazioni. Tuttavia, ciò significava anche che per ogni richiesta di pagina web veniva generata al momento una risposta HTML univoca, che è lontano dall'ottimizzazione, soprattutto per i siti con un elevato numero di visualizzazioni.
Introduzione della memorizzazione nella cache in più località
Il codice HTML per ogni sito era prevalentemente statico, ma erano alcune considerazioni:
- Cambia di frequente. 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.
- Aveva determinati dati e cookie specifici per il visitatore, il che significa che due persone che visitano lo stesso sito avrebbero visto un codice HTML leggermente diverso. Ad esempio, per supportare le funzionalità dei prodotti, come la memorizzazione degli articoli nel carrello o la chat che il visitatore ha iniziato con l'attività in precedenza e altro ancora.
- Non tutte le pagine possono essere memorizzate nella cache. Ad esempio, una pagina contenente codice utente personalizzato che visualizza l'ora attuale come parte del documento non è idonea per la memorizzazione nella cache.
Inizialmente, abbiamo adottato l'approccio relativamente sicuro che prevede la memorizzazione nella cache dell'HTML senza dati del visitatore, quindi abbiamo modificato al volo solo parti specifiche della risposta HTML per ogni visitatore, per ogni hit dalla cache.
Soluzione CDN interna
Per farlo, abbiamo implementato una soluzione interna che prevede l'utilizzo di Varnish HTTP Cache per il proxy e di memorizzazione nella cache, Kafka per i messaggi di invalidazione e un servizio basato su Scala/Netty che esegue il proxy per 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 consentito di eseguire il deployment di questi componenti sottili in molte più località geografiche e in più regioni di cloud provider distribuite in tutto il mondo. Nel 2019 abbiamo introdotto più di 15 nuove regioni e attivato gradualmente la memorizzazione nella cache per oltre il 90% delle visualizzazioni di pagina idonee per la memorizzazione nella cache. La pubblicazione di siti da posizioni aggiuntive ha ridotto la latenza di 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 alcune risposte dell'API di sola lettura utilizzando la stessa soluzione e invalidando la cache in caso di modifiche 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.
Ridurre le complessità
L'implementazione della memorizzazione nella cache ha migliorato in modo significativo le prestazioni, principalmente nelle fasi TTFB e FCP, e ha migliorato la nostra affidabilità pubblicando i contenuti da una località più vicina all'utente finale.
Tuttavia, la necessità di modificare il codice HTML per ogni risposta ha introdotto una complessità superflua che, se rimossa, offriva l'opportunità di ulteriori miglioramenti delle prestazioni.
Memorizzazione nella cache del browser (e preparazione per le CDN)
~ 13%
Le richieste HTML vengono inviate direttamente dalla cache del browser, consentendo di risparmiare molta larghezza di banda e ridurre i tempi di caricamento per le visualizzazioni ripetute
Il passaggio successivo è stato rimuovere effettivamente questi dati specifici del visitatore dal codice HTML interamente e recuperarli da un endpoint separato, chiamato dal cliente per questo scopo, dopo l'arrivo del codice HTML.
Abbiamo eseguito con attenzione la migrazione di questi dati e cookie in un nuovo endpoint, che viene chiamato a ogni caricamento pagina, ma restituisce un JSON sottile, necessario solo per il processo di idratazione, per raggiungere l'interattività a pagina intera.
Questo ci ha consentito di attivare la memorizzazione nella cache del codice HTML nel browser, il che significa che i browser ora salvano la risposta HTML per le visite ripetute e chiamano il server solo per verificare che i contenuti non siano cambiati. Per eseguire questa operazione, utilizza HTTP ETag, che è essenzialmente un identificatore assegnato a una versione specifica di una risorsa HTML. Se i contenuti sono sempre gli stessi, i nostri server inviano al client una risposta 304 Not Modified, senza un 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 memorizzato nella cache ovunque, in modo da poter utilizzare provider 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 attivata, i tempi di attesa si sono ridotti e altre parti importanti della connessione iniziale sono diventate più sostanziose. Il miglioramento dell'infrastruttura di networking e del monitoraggio ci ha permesso di migliorare i tempi di DNS, connessione e SSL.
HTTP/2 era abilitato per tutti i domini degli utenti, riducendo il numero di connessioni necessarie e l'overhead associato a ogni nuova connessione. Si è trattato di una modifica relativamente facile da implementare, sfruttando al contempo i vantaggi in termini di prestazioni e resilienza offerti da HTTP/2.
Compressione Brotli (vs. gzip)
21 - 25%
Riduzione delle dimensioni medie di trasferimento dei file
Tradizionalmente, tutti i nostri file sono stati compressi utilizzando la compressione gzip, che è l'opzione di compressione HTML più diffusa sul web. Questo protocollo di compressione è stato implementato quasi 30 anni fa.
La nuova compressione Brotli introduce miglioramenti della compressione senza quasi compromessi e sta diventando pian piano più popolare, come descritto nel capitolo Compressione dell'almanacco web annuale. È supportato da tutti i principali browser da un po' di tempo.
Abbiamo abilitato il supporto Brotli sui nostri proxy nginx a livello perimetrale, per tutti i client che lo supportano.
Il passaggio all'utilizzo della compressione Brotli ha ridotto le nostre dimensioni mediane di trasferimento dei file del 21%-25%, con conseguente riduzione dell'utilizzo della larghezza di banda e miglioramenti 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.
Recentemente, abbiamo integrato una soluzione del nostro provider DNS, per selezionare automaticamente la rete CDN con le migliori prestazioni in base alla rete e all'origine del client. In questo modo possiamo pubblicare i file statici dalla posizione migliore per ogni visitatore ed evitare problemi di disponibilità su una determinata rete CDN.
Disponibili a breve... Domini utente gestiti da CDN
L'ultimo tassello del puzzle consiste nel servire l'ultima parte, quella più importante, tramite una rete CDN: l'HTML dal dominio dell'utente.
Come descritto sopra, abbiamo creato la nostra soluzione interna per memorizzare nella cache e pubblicare i risultati HTML e API specifici del sito. Il mantenimento di questa soluzione in così tante nuove aree geografiche comporta anche i costi operativi e l'aggiunta di nuove località diventa un processo che dobbiamo gestire e ottimizzare continuamente.
Al momento stiamo integrando vari provider CDN per supportare l'intero sito Wix direttamente da località CDN per migliorare la distribuzione dei nostri server in tutto il mondo e, di conseguenza, migliorare ulteriormente i tempi di risposta. Questa è una sfida dovuta all'elevato numero di domini che gestiamo, che richiedono la terminazione SSL a livello perimetrale.
L'integrazione con le CDN permette ai siti web Wix più vicini che mai al cliente e offre ulteriori miglioramenti all'esperienza di caricamento, comprese tecnologie più recenti come HTTP/3, senza ulteriore impegno da parte nostra.
Informazioni sul monitoraggio delle prestazioni
Se gestisci un sito Wix, probabilmente ti starai chiedendo come questo si traduce in risultati di rendimento del tuo sito Wix e come possiamo confrontarci con quelli di altre piattaforme di siti web.
La maggior parte del lavoro fatto sopra è stata implementata nell'ultimo anno e alcune sono ancora in fase di implementazione.
Web Almanac di HTTPArchive ha recentemente pubblicato l'edizione 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 e le nostre metriche interne sul rendimento.
Ci impegniamo a migliorare continuamente i tempi di caricamento e a fornire ai nostri utenti una piattaforma in cui creare siti come immaginano, senza compromettere il rendimento.
DebugBear ha recentemente pubblicato un'interessante revisione sulle prestazioni dello strumento per la creazione di siti web, che esamina alcune delle aree citati sopra ed esamina il rendimento dei siti molto semplici creati su ogni piattaforma. Questo sito è stato realizzato quasi due anni fa e da allora non è stato modificato, ma la piattaforma è in continuo miglioramento e il rendimento del sito, di cui si può verificare consultando i dati dell'ultimo anno e mezzo.
Conclusione
Ci auguriamo che la nostra esperienza ti spinga ad adottare una cultura orientata al rendimento nella tua organizzazione e che i dettagli sopra riportati siano utili e applicabili alla tua piattaforma o al tuo sito.
Riepilogando:
- Scegli un insieme di metriche che puoi monitorare in modo coerente utilizzando strumenti approvati dal settore. Consigliamo i Segnali web essenziali.
- Sfrutta la memorizzazione nella cache e le reti CDN del browser.
- Esegui la migrazione a HTTP/2 (o HTTP/3 se possibile).
- Utilizza la compressione Brotli.
Ti ringraziamo per aver letto la nostra storia. Ti invitiamo a fare domande, condividere idee su Twitter e GitHub e a partecipare alle discussioni sulle prestazioni web sui tuoi canali preferiti.