Come ottimizzare per l'aggiornamento dell'esperienza di pagina a livello aziendale (caso di studio internazionale)
Pubblicato: 2021-06-23La SEO nella sua interezza è un argomento enorme, per non parlare dell'aspetto tecnico.
Negli ultimi due mesi, è stato difficile vagare nel campo della SEO tecnica senza toccare o sentire parlare di Google Page Experience Update e dei Core Web Vitals.
Potresti chiederti di cosa si tratta e in che modo ti influenzerà o forse hai dei dubbi su come lavorare con esso per ottimizzare il tuo sito web – e per buoni motivi!
L'obiettivo è fornirti gli input necessari in un formato di case study da utilizzare sul tuo sito Web (o su quello dei clienti) in questi ultimi giorni prima del "lancio".
Ma dobbiamo gattonare prima di camminare, quindi iniziamo con le basi.
Che cos'è CWV e perché risolverlo?
Core Web Vitals è un insieme di parametri specifici utilizzati da Google per valutare l'esperienza utente di un sito web.
L'intenzione è quella di utilizzare queste metriche per valutare il posizionamento di un sito Web in base al suo contenuto e garantire un'esperienza utente soddisfacente.
È proprio come un utente reale deciderebbe di lasciare un sito a caricamento lento o uno con un'interfaccia impegnativa, non importa quanto sia buono il contenuto.
Core Web Vitals è costituito da tre specifiche stime della velocità della pagina e valori di interazione dell'utente:
- La più grande vernice contenta
- Primo ritardo di ingresso
- Spostamento cumulativo del layout
I valori vengono valutati individualmente su desktop e dispositivi mobili per tenere conto dell'esperienza su diversi viewport e schede di rete.
LCP (Largest Contentful Paint) – Esperienza di caricamento
LCP esprime il tempo necessario prima che la maggior parte del contenuto di un sito Web sia disponibile (renderizzato) sullo schermo dell'utente.
Quando Core Web Vitals ritiene che l'ottimizzazione sia disponibile per questo parametro, spesso si basa sui file front-end (HTML, CSS, file di immagine).
Questo perché sono necessari troppi file per eseguire il rendering del sito nel browser dell'utente. Può anche essere che i file siano troppo grandi o siano dovuti alla capacità del server insufficiente per consegnarli in tempo.
Una soluzione suggerita può essere quella di garantire che questi file siano più piccoli, vengano inviati tramite un minor numero di richieste HTTP e ridimensionino il server in modo che corrisponda al traffico e alle dimensioni del sito web.
FID (First Input Delay) – Interattività
FID esprime il tempo necessario prima che un utente possa interagire con la pressione dei pulsanti del sito, i tocchi del touch screen, gli input della tastiera, ecc.
I problemi in questa categoria sono spesso causati dalla quantità di interazione e dal rendering DOM dinamico o basato su Javascript.
Il browser ha dato la priorità al caricamento di questi script e non ha accettato l'interazione dell'utente prima del caricamento. Più è difficile caricare ed eseguire questi script, più tempo ci vorrà prima di interagire con il sito web.
Il FID è teoricamente migliorato riducendo il tempo tra le pagine visualizzate fino a quando non consente l'interazione. In altre parole, è possibile dividere i file JavaScript in parti più piccole, se necessario.
In questo modo, puoi dare la priorità al caricamento degli elementi essenziali per utilizzare il sito Web (clic, tocchi, interazioni con lo slider, ecc.), lasciando animazioni, effetti e altre straordinarie funzionalità da caricare secondariamente.
In pratica, FID viene misurato come una metrica utente individuale: non misura il tempo prima che un utente possa interagire con esso, ma piuttosto il tempo prima che un utente interagisca con esso. È possibile ottenere un punteggio elevato su questa metrica se l'utente ottiene informazioni che il sito non è disponibile, ad esempio tramite animazioni di caricamento o segnaposto per set di dati di grandi dimensioni.
CLS (spostamento cumulativo del layout)
CLS indica se il sito Web inserisce nuovi pulsanti, testo o immagini dopo altri elementi di contenuto su un sito: se il sito carica elementi in modo asincrono, può modificare la struttura del layout originale e disturbare notevolmente l'esperienza dell'utente.
I file di immagine non ottimizzati spesso causano questo o possibili caratteri Web che non possono essere precaricati e vengono visualizzati dopo che il markup iniziale è a posto. I widget incorporati di terze parti possono anche causare uno spostamento nel layout.
La soluzione è spesso precaricare il contenuto. In questo modo, gli elementi in grado di spostare il layout saranno presenti prima che la pagina venga visualizzata per la prima volta.
In alternativa, puoi utilizzare contenitori chiusi a chiave per i tuoi contenuti. In questo modo, il posizionamento del contenuto iniziale non cambia man mano che alcuni elementi iniziano a comparire.
[Case Study] Aumenta il crawl budget su pagine strategiche
Leggi il caso di studioÈ ora di camminare
Ora che ci siamo occupati delle basi, è giunto il momento di metterlo in pratica, ed è esattamente quello che abbiamo fatto con un caso cliente.
Questo caso specifico è stato divertente perché presentava vari tipi di errore e quindi si concentra su diverse aree di ottimizzazione.
Ci sono molte aree di interesse e punti di azione da notare in tutta la custodia, quindi allaccia le cinture e goditi il viaggio.
Ti guiderò attraverso:
- Il caso
- Cosa abbiamo fatto sul caso
- Perché abbiamo fatto come abbiamo fatto
- Da asporto chiave
Il caso: Logpoint; affari internazionali di sicurezza informatica
Il sito, Logpoint.com, opera nel settore della sicurezza informatica ed è un marchio noto in tutto il mondo.
Essere una grande azienda internazionale significa che un bel po' di traffico scorre attraverso il sito web. Pertanto, è essenziale assicurarsi che i visitatori ottengano la migliore esperienza possibile, e quindi un caso ancora più avanzato per i Core Web Vitals.
L'esperienza utente è composta da molti fattori diversi, ma in particolare i Core Web Vitals sono importanti nella creazione e nella misurazione dell'esperienza nel suo insieme.
L'immagine sopra illustra la situazione prima di iniziare la nostra ottimizzazione di Core Web Vitals. Il punto di partenza per Logpoint non è stato male, rispetto a molte altre aziende più in vista, ma come mostra il grafico, c'è spazio per migliorare.
Questo potrebbe anche essere qualcosa a cui puoi relazionarti.
È fondamentale assicurarsi che ogni URL possibile rientri nella categoria di un "buon URL" perché si traduce nella migliore esperienza utente e perché Google sta rendendo Core Web Vitals un fattore di ranking a metà giugno 2021 con il loro aggiornamento: Pagina Google Esperienza.
Cosa abbiamo fatto sul caso
Durante la nostra ottimizzazione, l'intera situazione dei Core Web Vitals è cambiata molto. Quando abbiamo iniziato, i problemi principali erano problemi di LCP e CLS su entrambi i formati mobile e desktop e, naturalmente, la velocità della pagina.
Il mondo cambia e anche i siti Web, quindi se sei stato ottimizzato per CWV sei mesi fa, ora potrebbe sembrare diverso.
Console di ricerca di Google (vitali web principali)
La prima cosa che abbiamo fatto è stata approfondire i diversi tipi di errore e capire quali URL erano interessati. Come forse già saprai, Google Search Console e la loro scheda Core Web Vitals hanno una panoramica del formato mobile e desktop.
Facendo un passo avanti nei rapporti dei formati, appare una panoramica dei tipi di errore, dove è possibile andare ancora oltre in un errore specifico.
Dalla panoramica è possibile fare un ultimo passo in più, ed è da qui che è iniziato il nostro lavoro.
Ogni URL interessato dal tipo di errore viene visualizzato in questo passaggio specifico, rendendo possibile l'avvio della nostra analisi.
Approfondimenti sulla velocità della pagina
Sapendo quali URL erano interessati, il nostro passaggio successivo è stato quello di analizzarli per individuare gli elementi che causavano gli errori. È qui che entra in gioco PageSpeed Insights. Analizzando gli URL, abbiamo compreso il punteggio di salute di PageSpeed, ma siamo anche stati in grado di esaminare gli elementi che contribuiscono agli errori.
Chrome DevTool – Analisi delle prestazioni
Per essere chiari sui tipi di errore e sugli elementi che li causano, abbiamo utilizzato l'analisi delle prestazioni trovata in DevTool. Confrontando questo strumento con PageSpeed Insights e i rapporti Core Web Vitals, ci siamo assicurati di ottenere una visione più completa delle informazioni fornite dai diversi mezzi e del modo in cui si relazionano tra loro.
Ogni strumento da solo fornisce una prospettiva unica nei dettagli, che a sua volta crea l'insieme più ampio.
Una volta completata la profilazione, nella sezione Esperienza sono apparse alcune caselle rosse. Questi indicavano un caricamento di elementi, che in qualche modo cambiava il layout spostandosi o spingendo gli elementi adiacenti in giro.
Facendo clic su un elemento viene visualizzata una serie di informazioni utili:
- Punto
Questo valore indica quanti punti occupa questo particolare elemento o evento di caricamento nel calcolo del punteggio CLS accumulato. elementi adiacenti intorno. - Punteggio cumulativo
Questo valore indica il totale di tutti i punti evento CLS per determinare quanto sia grave la situazione accumulata per la pagina specificata. Per soddisfare gli standard di Google, il punteggio CLS accumulato non può superare 0,1 punti. Si raccomanda che il punteggio sia ancora più basso, poiché CLS è un valore calcolato individualmente e potrebbe essere valutato peggio dal crawler di Google rispetto a quando calcola il punteggio su il proprio computer. - Ha avuto input recenti
Questo valore indica se l'elemento è stato interagito fino a quando non si è verificato lo spostamento del layout. Per una pagina HTML statica, raramente è un valore di cui preoccuparsi. Principalmente, dice se un input dell'utente ha causato o meno lo spostamento del layout. - Spostato da / Spostato in
Questo valore rivela dove si trovava inizialmente l'elemento e dove si trovava la sua nuova posizione dopo lo spostamento. Non è raro che il componente ne abbia spostati diversi da/spostato a valori se è stato spostato più volte. Passando il mouse sopra i valori viene visualizzata una struttura sullo schermo di dove si trovava l'elemento prima e dopo che si è verificato il cambio di layout. - Nodo correlato
Questo valore fa riferimento al nodo DOM nel flusso di documenti, che è stato spostato. A seconda di dove si trova l'errore, questo darà un buon puntatore nella direzione di quale elemento ha causato lo spostamento o è stato influenzato da un elemento adiacente che poi, a sua volta, ha causato lo spostamento.
La causa degli errori
Il motivo principale degli errori LCP era dovuto all'immagine di un eroe che appariva su ogni pagina del sito web.
Naturalmente, ci sono molti modi per ottimizzare un'immagine di eroe come questa comprimendo e ridimensionando, che sarebbe stata una delle cose da fare se Logpoint avesse voluto mantenere il loro design e layout. Tuttavia, non era così, quindi abbiamo rimosso l'immagine dell'eroe che si occupava della maggior parte degli errori LCP.
Un'altra causa degli errori LCP era la struttura del codice. Logpoint utilizza un generatore di pagine, che si traduce nell'impostazione dei limiti del costruttore su come strutturare sia il design che il codice.
In alcuni punti del sito Web, l'intero layout presentava dei difetti, come p tag nidificati all'interno di h1 che causavano la trasformazione degli elementi di testo in Largeest Contentful Paint. Per risolvere questo problema, abbiamo spazzato il sito Web per semplificare e ottimizzare la struttura del codice.
Come accennato, anche il CLS faceva parte del problema, ed era principalmente innescato da due elementi, che di fatto si influenzavano a vicenda.
I due elementi
Prima di tutto, Logpoint ha incorporato Youtube sul proprio sito Web e, per aiutare con il tempo di caricamento, ha implementato una miniatura. Il problema era che sia la miniatura che il video venivano caricati contemporaneamente, dopodiché il video veniva rimosso dal codice JavaScript. Ciò ha causato cambiamenti significativi nel layout del sito web.
Il secondo elemento che ha influenzato CLS è stato il CookieBot implementato sul sito web. Come previsto, CookieBot ha concesso le autorizzazioni relative ai video, quindi non potevano essere visualizzati fino a quando non fosse stato fornito il consenso.
È qui che i due elementi interagiscono tra loro. Il codice JavaScript per la rimozione del video è stato creato su misura dallo sviluppatore ed è stato programmato per interagire con il consenso di CookieBot.
Per risolvere il problema, abbiamo modificato lo script ritardando il caricamento dell'elemento video e il caricamento dello script stesso.
È essenziale ricordare che Logpoint è un grande sito Web con molti componenti che interagiscono tutti tra loro in modi diversi. Ciò, combinato con il tema e il generatore di pagine, rende il sito Web complesso e limita anche alcune delle opzioni di ottimizzazione.
PageSpeed è stato influenzato
Questo, ovviamente, ha influito sul PageSpeed, quindi, mentre ci siamo concentrati sui Core Web Vitals, abbiamo anche lavorato per ottimizzarlo. Per fare ciò, abbiamo installato i plugin: WP Engine per ottenere un hosting veloce, WP Rocket per ottenere un'ottima memorizzazione nella cache e ottimizzazione di HTML, CSS e JS e, infine, CloudFlare , per ottenere un ottimo provider DNS.
Le variazioni della lingua hanno creato nuovi errori di Core Web Vitals...
Durante l'ottimizzazione, Logpoint ha subito modifiche significative al proprio sito Web, pubblicando molte nuove pagine in diverse lingue, con nuovi elementi e layout che hanno portato alla comparsa di nuovi errori Core Web Vital: ora è necessario correggere un nuovo tipo di errore CLS.
Ancora una volta, abbiamo attraversato il nostro processo di analisi. In questo caso particolare, i cambiamenti di layout sono stati causati da un plug-in di chat di terze parti. Molto spesso, questo errore viene corretto aggiungendo e modificando le regole CSS, ma poiché il chatbot è stato implementato da una terza parte non siamo stati in grado di aggiungere in modo efficace CSS personalizzato.
Pertanto, il nostro obiettivo era sia pubblicare una richiesta di aggiornamento con gli sviluppatori del plug-in, poiché l'aggiunta stava comportando un pedaggio visibile su un sito altrimenti molto performante, sia, in alternativa, trovare un plug-in di chat con una migliore priorità di caricamento.
Perché abbiamo fatto quello che abbiamo fatto
Il fatto che i Core Web Vitals stiano diventando un fattore di ranking è un cambiamento fondamentale nel modo in cui funzionano i ranking dei motori di ricerca. Un sito Web mal progettato che non si concentra sull'esperienza dell'utente semplicemente non lo taglierà più.
L'obiettivo di Google è aiutare i proprietari di siti Web a creare siti incentrati sull'esperienza dell'utente e, includendo i Core Web Vitals come fattori di ranking, fanno esattamente questo.
Google non è noto per giocare con le carte aperte o per farci sapere in anticipo i loro aggiornamenti, ma con i loro Core Web Vitals e Page Experience Update siamo stati effettivamente informati all'inizio del processo.
Questo ovviamente ci ha dato il tempo di padroneggiare la conoscenza di Core Web Vitals, ma ha anche significato che molti elementi e idee non sono stati ancora decisi e modificati durante il periodo dall'introduzione fino ad ora.
Ciò includeva i risultati di avere un punteggio Core Web Vitals perfetto: solo buoni URL.
All'inizio, non era chiaro in che modo il fattore di ranking di Core Web Vitals avrebbe influenzato gli URL. Questo è stato un argomento per un po' di tempo, ma questo giugno ne sapremo tutti di più sull'impatto di sicuro.
"Le pagine che ricevono un punteggio di "buono" su Core Web Vitals stanno raggiungendo un livello di esperienza utente ambizioso e potrebbero ottenere una spinta nella componente di esperienza della pagina del ranking".
– Documentazione di Google
Nella stessa questione, non è nemmeno chiaro se un rapporto Core Web Vitals che non padroneggia tutti i tipi di errore sarebbe influenzato negativamente o se ha ancora qualche effetto positivo.
"Se hai pagine che non misurano "buone" su almeno una delle metriche di Core Web Vitals o non superano i criteri di esperienza delle altre pagine, ti consigliamo di concentrarti sui miglioramenti di tali dimensioni nel tempo. Sebbene tutti i componenti dell'esperienza della pagina siano importanti, daremo la priorità alle pagine con le migliori informazioni in generale, anche se alcuni aspetti dell'esperienza della pagina sono scadenti".
– Documentazione di Google
Inoltre, l'idea di un badge Core Web Vitals è sul tavolo da disegno, proprio come lo conosciamo dal badge AMP. Anche questo deve ancora essere definitivamente deciso.
"La linea guida generale è che vorremmo utilizzare questi criteri anche per mostrare un badge nei risultati di ricerca, e penso che siano stati effettuati alcuni esperimenti in merito. E per questo, dobbiamo davvero sapere che tutti i fattori sono conformi. Quindi, se non è su HTTPS, in sostanza, anche se il resto è OK, non sarebbe sufficiente".
– John Mueller, Webmaster Trends Analyst, Google
Quindi, anche se ci sono state molte incertezze, una cosa è certa! Core Web Vitals è qui per restare e diventerà una parte importante della battaglia per il traffico organico, ed è per questo che abbiamo fatto uno sforzo in più per correggere gli errori di Core Web Vitals su Logpoint.
Da asporto chiave
Alla fine della strada, è giusto guardare indietro a dove abbiamo iniziato e, si spera, questo caso ti ha fornito le conoscenze e gli strumenti per iniziare a camminare da solo.
Core Web Vitals è qualcosa che prevedo sarà il futuro della SEO. Ci siamo spinti sempre più a fare affidamento sul traffico organico per influenzare la crescita e Core Web Vitals non è altro che un rapporto per perfezionare l'esperienza dell'utente.
Quando diamo potere all'utente e diamo loro un prodotto degno del loro tempo, allora, ovviamente, vorranno interagire con esso.
Logpoint, essendo la star dello spettacolo, ha subito una trasformazione grazie alle intuizioni di Core Web Vitals, consentendoci di affrontare problemi di LCP e CLS, nonché integrazioni di terze parti e struttura del codice disordinata generale.
Aderendo alle migliori pratiche e allo stesso tempo disegnando prospettive alle intuizioni fornite da Core Web Vitals, siamo stati in grado di capovolgere gli aspetti tecnici del sito in modo tale che si ergesse al di sopra della massa: spetta a Google decidere .
Un consiglio conclusivo
Un mio consiglio amichevole prima di concludere è di concentrarti sull'ottimizzazione dei tuoi Core Web Vitals – non solo per il fattore di ranking ma anche perché ha un enorme impatto sui visitatori del tuo sito web – e non è questo che SEO è tutto di?
Non solo aumenterà il tempo sul sito, ma ridurrà anche la frequenza di rimbalzo e, si spera, si tradurrà in quantità maggiori sia di classifiche che di conversioni.
Scritto in collaborazione con Andre Vestergaard, Technical SEO Specialist di Bonzer.