Stavo esaminando i nostri risultati di ricerca su Google più tardi oggi e anche noi abbiamo notato un calo significativo del traffico dalle pagine di ricerca alla nostra istanza Discourse (discourse.julialang.org) dopo il 4 maggio (circa il 30%). Non me ne sono accorto fino ad ora, perché Discourse rappresenta solo circa la metà delle nostre visualizzazioni di pagina e il resto del sito ha registrato un aumento del traffico grazie a questo aggiornamento, quindi l’effetto complessivo è stato leggermente negativo. Tuttavia, diventa molto evidente quando si separano i dati di Discourse da quelli non-Discourse sullo stesso dominio. Il traffico sta lentamente risalendo, ma allo stesso tasso di crescita del resto del sito. C’è qualcosa che si può fare riguardo al problema LCP? Sembra un buon candidato per ciò che viene penalizzato da Google (e vedo anche decine di migliaia di segnalazioni LCP nella nostra Search Console). Le metriche di Google riportano un LCP mobile di circa 3 secondi per molte delle nostre pagine Discourse, il che sembra piuttosto alto. Questo sembra essere un problema universale di Discourse. Ad esempio, se eseguo un rapporto su questo stesso thread, ottengo 3,3 secondi per l’LCP. Purtroppo non sono uno sviluppatore web, quindi non ho suggerimenti concreti, ma spero che qualcuno che ne sappia di più possa proporre qualcosa. Sarebbe davvero bello recuperare quel 30% di traffico 
.
Ecco il nostro grafico delle impressioni di ricerca con livellamento settimanale, suddiviso tra Discourse e il resto del dominio (che presumibilmente avrebbe lo stesso punteggio di fiducia a livello di dominio). L’aggiornamento di maggio è piuttosto evidente. Ironia della sorte, nella stessa settimana abbiamo registrato un picco di traffico non correlato per il resto del sito, ma direi che il comportamento complessivo mostra un calo evidente delle impressioni per Discourse e impressioni per il resto del sito sostanzialmente stabili (ignorando il picco di traffico non correlato).
È esattamente di quello che mi lamentavo da mesi, ma gli amministratori non lo prendono sul serio @Keno
Abbiamo anche iniziato a sperimentare con Vuejs per servire parte del nostro contenuto tramite Nuxt, al fine di migliorare le prestazioni di pre-rendering di Discourse. Possiamo vedere che, l’aggiornamento è stato pubblicato meno di un mese fa e negli ultimi 2-3 giorni le nostre impressioni sono raddoppiate, tornando esattamente ai livelli precedenti all’aggiornamento di maggio.
Non so se sia una coincidenza o meno, ma forse ha a che fare con LCP. Continuerò a monitorare per un paio di settimane prima di trarre conclusioni.
Dopo aver letto questo post del blog, il consiglio è… suuuuper generico. Si può riassumere essenzialmente in “abbiate contenuti di qualità”. Non sono nemmeno sicuro di cosa potremmo cambiare specificamente in Discourse basandoci su questo post del blog? 
Non sono sicuro che si tratti solo della qualità dei contenuti; potrebbe seriamente essere correlato all’elevato tempo LCP, che presumibilmente potrebbe essere risolto su Ember. Ma non ne sono davvero certo, sto ancora sperimentando altre soluzioni per vedere…
Penso che tu ti stia concentrando un po’ troppo su una singola metrica. Ti stai concentrando su di essa più di quanto faccia Google.
Hanno pubblicato informazioni sull’LCP il 28 maggio e hanno dichiarato “Forniremo un preavviso di 6 mesi prima di implementare queste modifiche”. Tale preavviso non è stato ancora fornito oggi.
Come ho già detto, non ho prove, né mi sto concentrando su di esse. Sto ancora sperimentando altre cose e, vedendo un picco di impressioni tornare ai livelli iniziali da ieri, terrò d’occhio la situazione per vedere come evolverà nelle prossime settimane.
Sì, non so se LCP sia affatto responsabile, ma è l’unico elemento che spicca nella Search Console, che per noi segnala circa 20.000 errori per pagine con un LCP elevato. Indipendentemente da qualsiasi impatto SEO, migliorare i tempi di LCP sembra un obiettivo valido. Certo, resta il dubbio di quanto le metriche di Google riflettano realmente la situazione, ma se lo fanno, allora 5 secondi di tempo di caricamento iniziale sono parecchi e sicuramente c’è modo di fare meglio. In particolare per il caso d’uso di utenti non autenticati che arrivano direttamente da Google, servire pagine pre-renderizzate tramite CDN potrebbe essere molto utile.
Sta indicando l’LCP, ma penso che il problema sia l’FCP… nota i tempi identici
Il primo caricamento su Discourse è più lento rispetto ai caricamenti successivi perché stai caricando l’applicazione e non solo quella prima pagina, quindi penso che sia una situazione molto più facile a dirsi che a farsi quella di ridurre il tempo di caricamento iniziale per raggiungere il livello “buono” di Google (< 1s per FCP) su mobile.
Penso che voi siate troppo concentrati sui fattori “tecnici” e concreti. Quello che Google non vi dice è che in realtà misurano anche le prestazioni “percepite” dei siti web.
Discourse ha forse il potenziale per migliorare le prestazioni percepite, e dovrebbe farlo.
https://thepathforward.io/web-performance-how-to-affect-perceived-performance/
Esistono molti modi per farlo, ad esempio il prerendering degli scheletri prima che l’app completa sia caricata.
In pratica, qualsiasi elemento che appare prima che l’app sia completamente caricata aiuta a migliorare le prestazioni percepite. Anche semplicemente renderizzare l’intestazione (senza contenuti, solo con il colore corretto) e lo sfondo con l’indicatore di caricamento della pagina prima che l’app completa sia disponibile, aiuterebbe nella visualizzazione iniziale della pagina. Qualsiasi cosa costruita a stadi, in modo che l’utente sappia… che qualcosa sta accadendo, anche su dispositivi lenti.
Ad esempio, per Meta qualcosa del genere potrebbe/dovrebbe essere renderizzato istantaneamente (potrebbe essere fatto con un semplice CSS critico) prima che l’app completa sia disponibile al browser:
Ci sono centinaia di articoli su come migliorare le prestazioni percepite delle singole app web. Forse qualcosa da valutare per il @team?
Una pagina di “caricamento” può essere realizzata in un componente del tema, se lo desideri. Potresti provare a implementarla e farci sapere se fa la differenza per il tuo sito?
Non credo che il risultato desiderato sia possibile con un semplice componente del tema. Per questo, è necessario avere un blocco CSS inline critico nell’intestazione, posizionato prima di qualsiasi altro script e tag meta CSS. Inoltre, il tag viene renderizzato solo dopo che l’applicazione completa è stata caricata. Non vedo come un componente del tema possa essere utilizzato per raggiungere gli obiettivi desiderati, ad esempio avere un blocco CSS critico nell’intestazione e almeno alcuni
C’è questa soluzione, che aggiunge un loader leggermente prima…
Hai una fonte sull’impatto percepito delle prestazioni sul posizionamento nei risultati di ricerca, o ti riferisci a FCP/LCP? FCP e LCP sono metriche specifiche con requisiti tecnici, nonostante siano concetti basati sulla percezione. Nota inoltre che FCP non fa parte dei “Core Web Vitals” di Google (mentre LCP sì).
Alcuni dettagli in più da https://web.dev/lcp/:
Come specificato attualmente nella API Largest Contentful Paint, i tipi di elementi considerati per il Largest Contentful Paint sono:
- Elementi
<img>- Elementi
<image>all’interno di un elemento<svg>- Elementi
<video>(viene utilizzata l’immagine poster)- Un elemento con un’immagine di sfondo caricata tramite la funzione
url()(a differenza di un gradiente CSS)- Elementi a livello di blocco contenenti nodi di testo o altri elementi figli a livello di riga.
Se una pagina rimuove un elemento dal DOM, quell’elemento non verrà più considerato. Allo stesso modo, se la risorsa immagine associata a un elemento cambia (ad esempio modificando
img.srctramite JavaScript), quell’elemento smetterà di essere considerato fino al caricamento della nuova immagine.
Questi requisiti rendono la cosa un po’ difficile; forse un elemento di caricamento con un’immagine o un testo di grandi dimensioni potrebbe funzionare se, invece di rimuoverlo dal DOM, lo nascondi in qualche altro modo? Lo spinner sopra menzionato usa lo z-index per nascondersi, quindi forse potrebbe funzionare… ma lo spinner stesso non è sufficiente perché non è un’immagine né un testo (è CSS).
Concordo sul fatto che una sorta di loader sarebbe utile per gli utenti con connessioni lente, ma ci sono ostacoli specifici da superare per Google (e non sappiamo se risolverebbe il problema sollevato dall’OP).
Richiederebbe una riscrittura di Discourse dal basso verso l’alto, quindi non trattenere il fiato per questo.
Ho esaminato questo componente, ma non credo faccia una grande differenza, dato che viene caricato troppo tardi, ovvero quando la maggior parte dell’app è già avviata. Google non rivela esattamente cosa prende in considerazione e così via. Oltre ai contenuti, l’esperienza utente (UX) soggettiva è sicuramente qualcosa che misurano, anche se indirettamente, ad esempio attraverso il rimbalzo verso il loro motore di ricerca. Un caricamento percepito come lungo comporta un tasso di rimbalzo più elevato sul primo risultato. Inoltre, anche se ciò non è del tutto rilevante per la SEO secondo quanto dichiara ufficialmente Google, rimane comunque rilevante dal punto di vista dell’UX e del traffico. Perché un utente abbandonerà se le prestazioni percepite al primo caricamento della pagina non sono sufficienti.
Lo capisco perfettamente. E devo ammettere che non ho ancora una piena comprensione del processo di rendering dell’app.
Davvero, se vuoi vincere su questa metrica, vai su un sito statico pregenerato, tipo tutta la faccenda di Google Amp.
Perché perderai sempre contro i siti che hanno pagine statiche.
Stai parlando con me? Nooo, sono super felice con Discourse 
E una buona UX non riguarda solo il primo caricamento della pagina; forse perdi qualcosa al primo caricamento, ma una volta che l’app è caricata, gli utenti rimangono sicuramente più a lungo e tornano più spesso rispetto a pagine statiche noiose. E sono sicuro che Google ne tenga conto in qualche modo.
Inoltre, da quando siamo passati a Discourse, nessun utente si è lamentato della velocità. E il nostro traffico di ricerca è in aumento rispetto alla nostra pagina Drupal super ottimizzata con tempi di caricamento istantanei della prima pagina grazie alla cache HTML completa tramite Fastly e CSS critico.
@codinghorror Ragazzi, ho fatto alcuni test con due domini che possiedo,
Entrambi sono stati colpiti dall’aggiornamento del 4 maggio:
Caso di studio 1: Concentrarsi esclusivamente sulla qualità dei contenuti (come molti hanno suggerito sopra)
Nel primo caso mi sono concentrato sul migliorare i contenuti, le parole chiave, rimuovere eventuali link dannosi, creare collegamenti interni, aggiungere nuovi contenuti di valore con molto potenziale… eccetera, eccetera.
Come potete vedere sopra, tutto lo sforzo è andato sprecato: anche se i nuovi articoli sono stati indicizzati correttamente, i contenuti scadenti sono stati rimossi e gli articoli più vecchi sono stati migliorati, si nota a malapena un qualsiasi miglioramento. È come se Google indicizzasse il sito abbastanza bene da ricevere un po’ di traffico, ma non abbastanza da generarne di significativo!
Caso di studio 2: Passaggio a Vue+Nuxt (miglioramento leggermente della struttura + LCP e velocità di rendering)
Nel secondo sito ho semplicemente spostato alcune pagine nella nostra app personalizzata Vue+Nuxt, che serve lo stesso contenuto con cambiamenti minimi o nulli nella struttura tramite API. Non sono stati compiuti altri sforzi di miglioramento (anche se in questo caso, spostare effettivamente la community da community.something.com e servire i contenuti sul sito principale avrebbe danneggiato più che beneficiare, cosa che è accaduta per un breve periodo).
Non sono sicuro di cosa si possa concludere da quanto sopra, continuerò a fare test e vedrò. Certamente quel picco improvviso è interessante. A proposito, ho controllato prima e dopo maggio e dopo quel recente picco, e ho notato in tutti questi casi che molti articoli hanno perso le impressioni e improvvisamente quasi gli stessi articoli hanno riguadagnato lo stesso numero di impressioni. Quindi non sono stati colpiti solo uno o due articoli/pagine, ma qualcosa che ha portato Google a penalizzare l’intero sito, lasciando poi la penalità sull’intero sito indipendentemente dagli sforzi fatti per migliorare la qualità dei contenuti.
Spero che quanto sopra abbia senso. Sentitevi liberi di farmi sapere se avete domande,
Saluti!
Se non erro, Discourse cerca di fornire una versione statica delle sue pagine ai crawler, giusto? Sarebbe possibile fornire questa versione statica a tutti gli utenti non autenticati? Queste penalità LCP suggeriscono che Google sta visualizzando la versione non statica del nostro forum.
Stiamo indagando su questo problema a intervalli per mesi, anche ingaggiando consulenti esterni, e tutto sembra ricondurre al fatto che il nostro forum sia pesantemente penalizzato da Google per violazioni LCP dopo l’aggiornamento del 4 maggio.