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 il Monitoraggio Real Use (RUM) raccolta dati sulle operazioni, le informazioni vengono raccolte in modo continuo durante l'utilizzo sul campo e offrono un modo per eseguire iterazioni sulle misurazioni delle prestazioni di utilizzo 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 Google PageSpeed Insight 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 inizi il progetto con la Piastra come nella Tutorial per sviluppatori, otterrai un punteggio Lighthouse molto stabile su PageSpeed Insight sia per dispositivi mobili che per desktop all’indirizzo 100. Su ogni componente del punteggio del faro c'è un po' di buffer per il codice del progetto da consumare e rimanere ancora all'interno dei limiti di un perfetto 100 punteggio faro.

Verifica delle richieste di pull

Si scopre che è difficile migliorare il tuo punteggio Lighthouse una volta che è basso, ma non è difficile mantenerlo a 100 se esegue test continui.

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 GitHub dell’AEM non riuscirà automaticamente a eseguire la PR se il punteggio è inferiore 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.

Quindi, invece di utilizzare una configurazione specifica per il progetto per il test di Lighthouse, utilizziamo le configurazioni continuamente aggiornate viste come parte delle strategie mobile e desktop a cui si fa riferimento nelle versioni più recenti di Google API di Approfondimenti PageSpeed.

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 quanto più ci si avvicina a un punteggio del 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

In desideroso fase, tutto ciò che doveva essere caricato per il vero LCP da visualizzare è caricato. In un progetto, in genere sono costituiti dal markup, dagli stili CSS e dai file JavaScript.

In molti casi le LCP è contenuto in un blocco, spesso creato dal blocco automatico, in cui .js e .css devono essere caricati.

Il caricatore di blocchi rivela le sezioni progressivamente, il che significa che tutti i blocchi della prima sezione devono essere caricati per LCP per diventare visibili. Per questo motivo, potrebbe essere utile disporre di una sezione più piccola contenente il minimo necessario nella parte superiore di una pagina.

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

Caricamento da o connessione a una seconda origine prima del LCP si è verificato è fortemente sconsigliato in quanto si stabilisce una seconda connessione (TLS, DNS, ecc.) aggiunge un ritardo significativo al LCP.

Fase L: Lazy

In pigro , viene caricata la parte del payload che non influisce sul tempo di blocco totale (TBT) e infine il primo ritardo di ingresso (FID).

Ad esempio, puoi caricare blocchi (JavaScript e CSS) e tutte le immagini rimanenti in base al loro loading="lazy" e altre librerie JavaScript che non bloccano. La fase pigra è generalmente tutto ciò che accade nei vari blocks stai per creare per soddisfare le esigenze del progetto.

In questa fase sarebbe comunque consigliabile che la maggior parte del carico utile provenga dalla stessa origine e sia controllata dalla prima parte, in modo che possano essere apportate modifiche, se necessario, per evitare ripercussioni negative sulla TBT, TTI e FID.

Fase D: Ritardato

In ritardato fase, 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 tempo sufficiente per consentire il regolamento del resto dell’esperienza.

La fase ritardata viene di solito gestita in delayed.js che funge da catch-all iniziale per gli script che causano TBT. Idealmente, il TBT i problemi vengono rimossi dagli script in questione caricandoli al di fuori 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 ottenere con la tecnologia comunemente utilizzata, come i gestori di tag o la creazione di strumenti, per creare 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 per LCP, che è il 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 per web sono spesso un problema di larghezza di banda e vengono caricati da un’origine diversa tramite un servizio di font come https://fonts.adobe.com o https://fonts.google.com, è in gran parte impossibile caricare i font prima del LCP, che è il motivo per cui vengono in genere aggiunti al lazy-styles.css e vengono caricati dopo il LCP viene visualizzato.

Blocchi LCP

Esistono situazioni in cui l'effettivo LCP non è incluso nel markup trasmesso al client. Ciò si verifica in presenza di un’indirezione o di una ricerca (ad esempio, un servizio chiamato, un frammento caricato o una ricerca che deve essere eseguita in un .json) per LCP elemento.
In tali situazioni, è importante che il caricamento della pagina attenda con indovinazione LCP candidate (attualmente la prima immagine della pagina) fino a quando il primo blocco non apporta le modifiche necessarie al DOM.
Per identificare i blocchi da attendere prima del blocco per LCP , è possibile aggiungere i blocchi che contengono LCP elemento al LCP_BLOCKS array in scripts.js.

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.