Prestazioni web, mantenimento del punteggio Lighthouse pari a 100.

La qualità dell’esperienza di siti web è fondamentale per raggiungere gli obiettivi aziendali del proprio sito web e la soddisfazione di chi lo visita.

Adobe Experience Manager (AEM) è ottimizzato per fornire esperienze eccellenti e prestazioni web ottimali. Con la raccolta dati delle operazioni di Real Use Monitoring (RUM), le informazioni vengono raccolte in modo continuo dall'uso del campo e offrono un modo per eseguire iterazioni sulle misurazioni delle prestazioni di uso reale senza dover attendere che i dati CRuX mostrino gli effetti delle modifiche al codice e alla distribuzione. È comune che i dati sul campo raccolti in RUM si discostino dai risultati di laboratorio, in quanto la rete, la geolocalizzazione e la potenza di elaborazione per i dispositivi reali sono molto più diverse rispetto alle condizioni simulate in un laboratorio.

Il servizio di approfondimento Google PageSpeed si è dimostrato un ottimo strumento di misurazione di laboratorio. Può essere utilizzato per evitare il lento deterioramento delle prestazioni e del punteggio dell’esperienza del sito web.

Se si avvia il progetto con Boilerplate come nell'esercitazione per sviluppatori 🔗, si otterrà un punteggio Lighthouse molto stabile su PageSpeed Insight sia per dispositivi mobili che per desktop alle 100. Su ogni componente del punteggio del faro è presente un po' di buffer per il codice del progetto da consumare e comunque entro i limiti di un punteggio perfetto del faro 100.

Verifica delle richieste di pull

Si è scoperto che è difficile migliorare il punteggio di Lighthouse una volta che è basso, ma non è difficile mantenerlo a 100 se si esegue continuamente il test.

Quando apri una richiesta di pull (PR) su un progetto, gli URL di test nella descrizione del progetto vengono utilizzati per eseguire il servizio Insights PageSpeed su. Il bot AEM GitHub avrà automaticamente un esito negativo del tuo PR se il punteggio è inferiore a 100 con un po' di buffer per tenere conto di una certa volatilità dei risultati.

I risultati sono per il punteggio del faro mobile, in quanto tendono a essere più difficili da raggiungere del desktop.

Perché Google PageSpeed Insights?

Molti team e singoli utenti utilizzano le proprie configurazioni per misurare i punteggi di Lighthouse. Diversi team hanno sviluppato i propri cablaggi preassemblati di test e utilizzano i propri strumenti di test con configurazioni che sono state configurate nell’ambito delle loro pratiche di monitoraggio continuo e reporting delle prestazioni.

Le prestazioni di un sito web influiscono sulle sue classificazioni nei risultati di ricerca, che si riflettono nei Core Web Vitals nel rapporto crUX. Google è in grado di gestire in modo ottimale le combinazioni medie rilevanti di informazioni sui dispositivi (ad esempio le dimensioni dello schermo) e le prestazioni di rete di tali dispositivi. Ma alla fine, SEO è l'arbitro finale di ciò che è buono contro cattivo prestazioni web. Poiché la configurazione specifica è una destinazione mobile, le procedure prestazionali devono essere allineate alle attuali caratteristiche medie dei dispositivi e della rete a livello globale.

Invece di utilizzare una configurazione specifica per il progetto per il test di Lighthouse, utilizziamo le configurazioni continuamente aggiornate visualizzate come parte delle strategie mobili e desktop a cui si fa riferimento nelle versioni più recenti dell'API PageSpeed Insights di Google.

Anche se alcuni sviluppatori ritengono di poter raccogliere informazioni aggiuntive da altri modi di misurare i punteggi di Lighthouse, per poter avere una conversazione sulle prestazioni significativa e comparabile tra i progetti, deve essere disponibile un modo per misurare le prestazioni in modo universale. Il servizio PageSpeed Insight predefinito è il test di laboratorio più autorevole e accettato quando si tratta di misurare le prestazioni.

Tuttavia è importante ricordare che i consigli che ottieni da PageSpeed Insights non portano necessariamente a risultati migliori, soprattutto se ti avvicini a un punteggio di faro di 100.

I core Web Vitals (CWV) raccolti dalla raccolta dati RUM integrata svolgono un ruolo importante nella convalida dei risultati. Per modifiche minori, tuttavia, la varianza dei risultati e la mancanza di punti di dati (traffico) sufficienti in un breve periodo di tempo rendono impraticabile ottenere risultati statisticamente rilevanti nella maggior parte dei casi.

Caricamento trifase (E-L-D)

La suddivisione del payload presente in una pagina web in tre fasi rende relativamente semplice ottenere un punteggio chiaro in un faro e quindi impostare una linea di base per una migliore esperienza del cliente.

L’approccio di caricamento in tre fasi divide il payload e l’esecuzione della pagina in tre fasi

Fase E: Eager

Prima di tutto, è importante notare che il corpo deve essere nascosto (con display:none) per assicurarsi che non inizi il download di immagini e per evitare il CLS iniziale.

Nella fase eager, la prima azione consiste nel "decorare" DOM: la sequenza di caricamento apporta alcune modifiche, principalmente aggiunge classi CSS a icone, pulsanti, blocchi e sezioni e crea blocchi automatici. Per ulteriori dettagli sul markup risultante, vedere la pagina Markup, sezioni, blocchi e blocco automatico.

Il corpo può quindi essere già visualizzato, considerando che le sezioni non sono ancora caricate e rimangono nascoste.

Quindi, la prima sezione completa viene caricata con una priorità assegnata alla prima immagine di questa sezione, la "LCP candidata". In teoria, meno blocchi sono presenti nella prima sezione, più veloce è il caricamento di LCP.

Una volta caricati il candidato LCP e tutti i blocchi della sezione, è possibile visualizzare la prima sezione e caricare i font in modo asincrono.

Termina la fase eager.

LCP

In generale, LCP è l'immagine "protagonista" visualizzata nella parte superiore di una pagina. È fondamentale assicurarsi che questa immagine sia caricata e visualizzata il prima possibile nella sequenza di caricamento (vedi la fase Ansioso).

È necessario caricare tutto ciò che è necessario caricare per visualizzare LCP vero. In un progetto, in genere sono costituiti dal markup, dagli stili CSS e dai file JavaScript.

In molti casi l'elemento LCP è contenuto in un blocco, dove è necessario caricare anche il blocco .js e .css.

È buona norma mantenere il payload aggregato prima che LCP venga visualizzato sotto i 100 kb, il che in genere si traduce in un evento LCP più rapido di 1560 ms (LCP punteggio a 100 in PSI). Soprattutto nei dispositivi mobili, la rete tende ad essere limitata dalla larghezza di banda, pertanto la modifica della sequenza di caricamento prima di LCP ha un impatto minimo o nullo.

Il caricamento o la connessione a una seconda origine prima che si verificasse LCP è fortemente sconsigliato in quanto l'impostazione di una seconda connessione (TLS, DNS, ecc.) aggiunge un ritardo significativo a LCP.

In alcune situazioni l'elemento LCP effettivo non è incluso nel markup trasmesso al client. Ciò si verifica quando si verifica un'indirezione o una ricerca (ad esempio un servizio chiamato, un frammento caricato o una ricerca che deve essere eseguita in un .json) per l'elemento LCP.
In queste situazioni, è importante che il caricamento della pagina attenda con l'indovinare il candidato LCP (attualmente la prima immagine nella pagina) fino a quando il primo blocco non avrà apportato le modifiche necessarie al DOM.

Ci sono altre situazioni in cui il contenuto contiene 2 immagini protagonista, una per desktop e una per dispositivi mobili. Come sopra, è importante assicurarsi che l'immagine corretta sia considerata come il candidato LCP e che il blocco "hero" possa essere regolato per rimuovere l'immagine non necessaria da DOM (rimuovere l'immagine desktop su dispositivi mobili o viceversa) per non caricare un'immagine che consuma larghezza di banda o anche peggio, caricare prima l'immagine non necessaria come candidato LCP.

Infine, LCP può essere diverso da un'immagine, un video, un testo lungo. Per tutti questi casi, è necessaria una profonda comprensione della sequenza di caricamento e del modo in cui viene calcolato il candidato LCP per effettuare le ottimizzazioni corrette.

Fase L: Lazy

Nella fase lazy, viene caricata la porzione del payload che non influisce sul tempo di blocco totale (TBT) e, in ultima analisi, sul primo ritardo di input (FID).

Ad esempio, puoi caricare le sezioni successive e i relativi blocchi (JavaScript e CSS), nonché tutte le immagini rimanenti in base al loro attributo loading="lazy" e altre librerie JavaScript che non bloccano. La fase lenta è generalmente tutto ciò che accade nei vari blocks che si sta per creare per soddisfare le esigenze del progetto.

In questa fase è comunque consigliabile che la maggior parte del payload provenga dalla stessa origine ed sia controllata dalla prima parte, in modo che sia possibile apportare modifiche se necessario per evitare un impatto negativo su TBT, TTI e FID.

Fase D: Ritardato

Nella fase delay, vengono caricate le parti del payload che non hanno un impatto immediato sull'esperienza e/o che non sono controllate dal progetto e provengono da terze parti. Pensa a strumenti di marketing, gestione del consenso, analisi estese, moduli di chat/interazione, ecc. che vengono spesso distribuiti tramite soluzioni di gestione tag.

È importante comprendere che, per ridurre al minimo l’impatto sull’esperienza complessiva del cliente, l’inizio di questa fase deve essere notevolmente posticipato. La fase ritardata deve essere di almeno tre secondi dopo l'evento LCP in modo da lasciare un tempo sufficiente per consentire la liquidazione del resto dell'esperienza.

La fase ritardata viene in genere gestita in delayed.js, che funge da catch-all iniziale per gli script che causano TBT. È consigliabile rimuovere i problemi TBT dagli script in questione caricandoli all'esterno del thread principale (in un Web worker) o semplicemente rimuovendo il tempo di blocco effettivo dal codice. Una volta risolti i problemi, queste librerie possono essere facilmente aggiunte alla fase lazy e caricate prima.

Idealmente non c’è tempo di blocco negli script, che a volte è difficile da raggiungere come tecnologia comunemente utilizzata come i gestori di tag o la creazione di strumenti crea file JavaScript di grandi dimensioni che si bloccano mentre il browser li analizza. Dal punto di vista delle prestazioni, è consigliabile rimuovere tali tecniche, assicurarsi che i singoli script non vengano bloccati e caricarli singolarmente come file separati di dimensioni inferiori.

Intestazione e piè di pagina

L'intestazione e in particolare il piè di pagina della pagina non si trovano nel percorso critico di LCP, motivo per cui vengono caricati in modo asincrono nei rispettivi blocchi. In genere, le risorse che non condividono lo stesso ciclo di vita (ovvero che vengono aggiornate con l’authoring delle modifiche in momenti diversi) devono essere conservate in documenti separati per rendere la catena di caching tra le origini e il browser più semplice e più efficace. Mantenendo tali risorse separate si aumentano i rapporti di hit della cache e si riducono l’invalidamento e la complessità della gestione della cache.

Font

Poiché i font Web sono spesso un problema di larghezza di banda e vengono caricati da un'origine diversa tramite un servizio font come https://fonts.adobe.com o https://fonts.google.com, è praticamente impossibile caricare i font prima di LCP, questo è il motivo per cui vengono caricati subito dopo.

Per impostazione predefinita, AEM Boilerplate implementa la tecnica font fallback per evitare che CLS venga caricato. Sarebbe controproducente precaricare i font (tramite Early hints, h2-push o markup) e influenzare in gran parte le prestazioni.

Bonus: La velocità è verde

Costruire siti web veloci, piccoli e veloci da riprodurre non è solo una buona idea per offrire esperienze eccezionali che si convertono meglio, è anche un buon modo per ridurre le emissioni di carbonio.

Origini comuni dei problemi di prestazioni

Nel tempo, abbiamo raccolto una raccolta di anti-pattern che influiscono negativamente sulle prestazioni e che devono essere evitati per essere conformi alle best practice descritte in questo documento.

I primi suggerimenti / h2-push / pre-connessione fanno parte del budget di rete

Istintivamente, avrebbe senso dire al browser di scaricare il più possibile e il prima possibile, anche prima che inizi l’elaborazione del markup. Ma ricorda che l’obiettivo finale è di avere una pagina stabile da mostrare al visitatore il più rapidamente possibile. LCP timing è un proxy valido per questo.

Come regola empirica, per ottenere un LCP a 100 su Mobile con PageSpeed Insight i vincoli di rete sono impostati in modo che ci possa essere solo un singolo host con un payload di rete che non è superiore a 100 kb, in quanto la configurazione è in gran parte vincolata dalla larghezza di banda. Gli hint iniziali, il push h2 e la preconnessione utilizzano tale larghezza di banda, scaricando risorse non necessarie per LCP e quindi influendo negativamente sulle prestazioni, e devono essere rimossi.

Reindirizzamenti per la risoluzione dei percorsi

Se un visitatore richiede www.domain.com e viene reindirizzato a www.domain.com/en e poi a www.domain.com/en/home,, riceve una penalità per ogni reindirizzamento, ovvero le prestazioni sono influenzate negativamente. Questo è visibile soprattutto nei core web vitals misurati tramite RUM o CrUX, in quanto i risultati di laboratorio in PageSpeed Insights escludono per impostazione predefinita il sovraccarico di reindirizzamento dai test di laboratorio.

Iniezione di script client CDN

Il markup, ma anche le origini di .aem.page e .aem.live, sono ottimizzate per le prestazioni e prestiamo estrema attenzione a qualsiasi parte del payload, nonché alla sequenza di caricamento delle risorse.

Alcuni fornitori e configurazioni CDN inseriscono script che occupano molta larghezza di banda e creano tempi di blocco, prima di LCP con impatti negativi sulle prestazioni. Questi script devono essere disabilitati o caricati in modo appropriato nella sequenza di caricamento dopo LCP.

Il confronto tra un'origine .aem.live del report PageSpeed Insight e il sito corrispondente gestito da una rete CDN di clienti (ad esempio, un sito di produzione) mostrerà l'impatto negativo prodotto da una rete CDN al di fuori del controllo di AEM.

TTFB CDN e impatto sull’implementazione del protocollo

A seconda del fornitore CDN, esistono differenze nelle implementazioni dei protocolli e nelle caratteristiche di prestazioni per la distribuzione pura del payload HTTP. Anche strumenti aggiuntivi come WAF e altre infrastrutture di rete a monte di AEM possono influire negativamente sulle prestazioni.
Il confronto tra un'origine .aem.live del report PageSpeed Insight e il sito corrispondente gestito da una rete CDN di clienti (ad esempio, un sito di produzione) mostrerà l'impatto negativo prodotto da una rete CDN al di fuori del controllo di AEM.