Accelerare LCP con il precaricamento tra siti

Un'introduzione alle tecnologie facilmente disponibili.

Kenji Baheux
Kenji Baheux
Michael Buettner
Michael Buettner
Devin Mullins
Devin Mullins

Perché la velocità di caricamento delle pagine è importante?

La maggior parte degli utenti identifica regolarmente i caricamenti lenti delle pagine come una delle principali fonti di frustrazione (il 54% in uno studio sugli utenti condotto da Google). Pertanto, non deve sorprendere che un caricamento più rapido delle pagine porti a risultati migliori per un'attività. In effetti, se i visitatori si infastidiscono ancora prima di interagire con un sito web, è molto improbabile che rimangano abbastanza a lungo da apprezzarne il valore. Infatti, un altro studio condotto da Google su 254 siti di e-commerce, finanza e viaggi ha dimostrato che i siti che si caricano in due secondi o meno hanno registrato tassi di conversione superiori del 15%.

Accelerare la visualizzazione di Largest Contentful Paint (LCP)

come si suol dire, non è possibile migliorare ciò che non si misura. Per quanto riguarda le esperienze utente sul web, riteniamo che i Segnali web essenziali costituiscano un solido insieme di metriche incentrate sull'utente e concepite per catturare gli aspetti fondamentali dell'esperienza utente. In particolare, la metrica Largest Contentful Paint (LCP) misura le prestazioni di caricamento delle pagine segnalando il tempo necessario per visualizzare il blocco di testo o di immagine più grande visualizzato dall'utente. Per offrire una buona esperienza utente, il valore LCP deve avvenire entro 2, 5 secondi dal primo avvio della pagina (ovvero la soglia di LCP buona).

Diamo un'occhiata a cosa contribuisce al valore LCP di una pagina standard.

Struttura a cascata in caricamento della pagina.
Una struttura a cascata tipica è necessaria per caricare una pagina web

Quando un utente visita una pagina, il browser richiede l'HTML al server. Il server risponde con il codice HTML, che offre al browser più suggerimenti sugli elementi da recuperare, tra cui CSS, JavaScript, caratteri e immagini. Quando queste risposte vengono restituite, il browser deve anche svolgere del lavoro per valutarle e, infine, disporre e colorare i componenti sulla pagina. Tuttavia, la maggior parte del tempo viene trascorsa in attesa che i pacchetti vengano trasferiti dal dispositivo al server e poi di nuovo al dispositivo. Infatti, i nostri dati (Chrome per Android; mediana) mostrano che circa il 40% della latenza visibile all'utente viene solitamente trascorso dal browser in attesa del primo byte di ritorno dal server.

La potenza del precaricamento

Se si potesse precaricare tutti questi file, cioè recuperarli prima che l'utente visiti la pagina, si otterrebbe un notevole aumento della velocità, lasciando solo alcune attività prima di visualizzare la pagina: valutazione, calcolo del layout e disegno.

Cascata essenziale.
Con tutte le risorse precaricate, la struttura a cascata è perfettamente ottimizzata.

Considerati i dati condivisi in precedenza, è possibile anche semplicemente precaricare la risorsa principale e ottenere comunque un caricamento pagina significativamente più veloce. Nello stesso caso, questo tipo di tecnica è facilmente disponibile con primitive come rel=prefetch. Tuttavia, gli scenari tra siti non sono così semplici.

Navigazioni tra siti

Anche se il precaricamento è attivo da un po' di tempo, occorre fare un'ulteriore considerazione quando si precaricano le pagine da un sito mentre l'utente si trova su un altro.

Supponiamo che un sito referrer debba indicare al browser di precaricare una pagina di un sito diverso. Ovviamente, quando l'utente fa clic sul link a questa pagina precaricata, godrà di un'esperienza utente migliore con un caricamento pagina molto più veloce. Tuttavia, che cosa succede se l'utente non fa mai clic su questo link? Non si aspettano che un sito web collegato sappia che potrebbe essere interessato a un argomento mentre cercava l'argomento sul sito referrer. Tuttavia, questo rappresenta un rischio sostanziale perché le richieste di precaricamento comportano l'indirizzo IP dell'utente e i cookie, se presenti, come qualsiasi altra richiesta regolare.

Soluzioni

Per consentire il precaricamento tra siti nel rispetto della privacy, negli ultimi tre anni abbiamo sviluppato due soluzioni: Private Prefetch Proxy e Signed Exchange (SXG). Abbiamo anche eseguito un esperimento su larga scala per confermare che il precaricamento multiorigine offra vantaggi significativi in termini di velocità. Concretamente, quando abbiamo esaminato i casi in cui Google è riuscita a precaricare in modo sicuro il codice HTML principale per la navigazione successiva dell'utente, abbiamo notato che la frazione di caricamenti di pagine con LCP "buono" è aumentata di 14 punti percentuali.

Considerazioni principali

Sebbene il proxy di precaricamento privato e la piattaforma Signed Exchange risolvano lo stesso caso d'uso, ciascuna tecnologia presenta un insieme diverso di compromessi. La scelta migliore dipende quindi dalle esigenze specifiche del tuo sito. Per aiutarti a avere un'idea dei compromessi, le seguenti sezioni trattano due considerazioni chiave per abilitare il precaricamento di più siti e scegliere tra le due tecnologie disponibili. Troverai ulteriori dettagli anche negli articoli di approfondimento su ciascuna tecnologia.

Visitatori abituali

Il precaricamento su più siti è facile da attivare per gli utenti che visitano il tuo sito per la prima volta. Per i visitatori abituali, dipende dal livello di personalizzazione del sito. Questo perché le richieste di precaricamento tra siti non possono includere cookie per motivi di privacy.

  • Per i nuovi visitatori, questa restrizione non presenta alcuna sfida, perché questi visitatori non hanno cookie iniziali. Di conseguenza, puoi attivare il precaricamento su più siti per questi utenti senza alcuna modifica al tuo sito.
  • Se vuoi attivare il precaricamento su più siti per i visitatori abituali e il tuo sito è personalizzato in base ai cookie, devi eseguire il caricamento lento di questi elementi personalizzati dopo che l'utente naviga. Questo funziona perché, durante la navigazione, la limitazione dei cookie non è più necessaria poiché l'utente ha esplicitamente scelto di visitare il tuo sito web. Quindi, al momento della navigazione, il tuo sito ha accesso ai suoi cookie come di consueto. Per indicazioni concrete, consulta queste best practice per il caricamento lento.
    • Se al momento codifichi la personalizzazione direttamente nel codice HTML, puoi continuare a farlo quando sono presenti i cookie e utilizzare il caricamento lento come strategia di riserva per le pagine precaricate.
    • Se il tuo sito non è personalizzato in base ai cookie o se la personalizzazione non è fondamentale, puoi scegliere di pubblicare gli stessi contenuti per i visitatori abituali, così come faresti per i nuovi visitatori.

Al momento, il proxy di precaricamento privato è abilitato solo per i nuovi visitatori (link senza cookie), con attività in corso per espandere la copertura ai visitatori abituali (link con cookie). D'altra parte, Signed Exchange supporta già il precaricamento su più siti sia per i nuovi visitatori che per quelli di ritorno (con gli approcci descritti sopra).

Pubblicazione di dati aggiuntivi da precaricamento

L'attivazione del precaricamento tra siti può comportare una pubblicazione di dati aggiuntiva. Infatti, se un referrer precarica la tua pagina, ma l'utente non fa clic sul link, per te c'è traffico aggiuntivo.

  • Per mitigare questo problema, si potrebbe richiedere che il referrer sia meno aggressivo con le sue richieste di precaricamento. Allo stesso modo, il referrer, o browser, può mitigare questo problema concentrandosi su risorse relativamente leggere, ma fondamentali (ad esempio, risorsa principale, CSS critico o sottorisorse JavaScript). Si tratta essenzialmente di un compromesso tra vantaggi in termini di velocità e traffico aggiuntivo.
  • In alternativa, si potrebbe compensare questo traffico attivando la memorizzazione nella cache aggiuntiva (per maggiori dettagli, consulta questa sezione su Signed Exchange). Lo svantaggio è che la memorizzazione nella cache di contenuti per troppo tempo può comportare la visualizzazione di informazioni meno recenti agli utenti. Si tratta essenzialmente di un compromesso tra pubblicazione di dati extra e aggiornamento dei contenuti.

Per prendere la decisione migliore in questo caso, chiediti in quale scala il tuo sito si trova tra il massimo aggiornamento e il numero minimo di richieste aggiuntive. La risposta a questa domanda dipende in definitiva dalle esigenze specifiche della tua attività e dei tuoi utenti.

Per iniziare

Queste tecnologie sono state integrate nella Ricerca Google in modo che i siti possano iniziare a migliorare immediatamente la metrica LCP. Ci auguriamo che questo stimoli altri referrer popolari a seguirlo e contribuisca a rendere il web molto più veloce su tutta la linea.

Sebbene entrambe queste tecnologie risolvano lo stesso caso d'uso, offrono compromessi diversi in merito alle considerazioni chiave illustrate in precedenza. Potresti anche decidere di iniziare con una tecnologia e passare all'altra in base alle tue esigenze o alla valutazione dei vantaggi. Consulta questi approfondimenti per scoprire qual è la tecnologia migliore per la tua situazione specifica: