È certamente possibile apportare questa modifica (tutti gli utenti anonimi vedono la vista HTML), ma avrebbe un forte impatto sull’usabilità per gli utenti anonimi. Sì, vedrebbero i contenuti più velocemente, ma un’enorme quantità di funzionalità che funzionano per gli anonimi smetterebbe di funzionare, e il sito non “sembrerebbe giusto” per gli utenti anonimi.
Potremmo eventualmente trasformare questa opzione in una configurazione del sito, in modo da poterla sperimentare, ma funzionalità come il “caricamento infinito” smetterebbero di funzionare per gli anonimi: ci sono costi molto elevati in gioco. Dovremmo inoltre investire almeno alcune risorse di ingegneria per creare un percorso /login che possa essere aggirato, in modo che le persone possano effettivamente registrarsi o accedere.
Sarebbe forse possibile servire una vista HTML come PRIMA pagina visualizzata dagli utenti anonimi in arrivo, per poi attivare tutte le funzionalità se continuano a navigare? Sembra una buona soluzione (non so però se sia accettabile per i motori di ricerca).
Sembra davvero poco ideale. Esiste un modo per servire la versione statica e poi ‘arricchirla’ con le parti dinamiche? Probabilmente si tratterebbe di una revisione architetturale significativa, quindi forse non è fattibile. In sostanza, stiamo riscontrando 49.000 errori LCP sul nostro sito a partire da maggio, e il traffico di ricerca è crollato nello stesso periodo. Il nostro punteggio LCP attuale media 5,3 secondi. Sto cercando idee su come ridurre questo numero.
Forse aggiungendo o rimuovendo alcuni plugin? Aumentando o riducendo il numero di categorie? Spostando gli asset statici su una CDN? Lo scorso inverno abbiamo provato a configurare Cloudflare senza successo, ma potremmo riprovare. Non conosco molto bene l’architettura di Discourse, quindi cerco indicazioni utili.
È esattamente quello che abbiamo riscontrato: stiamo sperimentando la rimozione di ogni plugin e persino degli annunci (ora i nostri siti non hanno più pubblicità, immagini ottimizzate, ecc.) e siamo riusciti a ridurre l’LCP, ma appena fino alla zona gialla. Ora non è più un errore, ma più un avviso che comunque influisce sul nostro sito. Abbiamo notato un leggero aumento da allora, ma abbiamo bisogno di più tempo per confermarlo…
A dirla tutta, sono molto tentato di iniziare a creare un clone open-source di Discourse basato su Nuxt+Vue.js o un wrapper sopra di esso; sembra l’unica scelta ragionevole al momento!
Sì, non c’è modo di ridurre quel caricamento iniziale senza un notevole sforzo ingegneristico, perché stai scaricando l’intera applicazione Discourse.
A peggiorare le cose, le prestazioni di JavaScript su Android sono generalmente inferiori rispetto agli iPhone… e a quanto pare Google conteggia solo i dispositivi Android nelle loro metriche mobili “del mondo reale”. Su Meta, gli account iOS rappresentano circa il 40% del traffico mobile.
Tutto ciò che posso dire qui è che siamo consapevoli della lentezza di FCP e LCP e abbiamo piani a lungo termine per migliorarli.
Nello specifico, @eviltrout ci sta aggiornando a Ember CLI. Una volta completato, potremo iniziare a considerare e possibilmente sperimentare il code splitting e altre tecniche.
Non ci sono scorciatoie facili: utilizziamo una CDN, siamo molto accurati nel modo in cui carichiamo le risorse e abbiamo dedicato innumerevoli ore all’ottimizzazione, ma fondamentalmente usiamo JavaScript per renderizzare le nostre pagine, e il caricamento, l’analisi e l’esecuzione del JavaScript richiedono tempo al primo avvio.
Scusate se riporto alla luce un argomento così vecchio, ma ora ho ulteriori dati dopo aver condotto alcuni test negli ultimi mesi…
Ecco i due siti web su cui ho lavorato: il primo è stato migrato da Discourse (EmberJs) a un sito front-end personalizzato basato su Vue con Nuxt.
Il secondo è invece Discourse, privato di pubblicità, font personalizzati e di qualsiasi altra cosa eliminabile per renderlo il più leggero possibile (questo ha permesso di ridurre gli errori LCP dal livello “Errore” a “Avviso”).
1. Forum Discourse (rimossi font personalizzati, annunci, plugin, ecc.)
Come potete vedere, a maggio, dopo l’aggiornamento, abbiamo perso il 50% delle posizioni per le parole chiave. A ottobre abbiamo iniziato le modifiche, che ci hanno dato un piccolo picco per breve tempo, ma poi tutto è tornato a scendere! È come se ci fosse una sorta di resistenza (in altre parole, una penalità da parte di Google).
Come si vede nell’immagine sopra, le modifiche apportate (rimozione di tutto il superfluo) hanno permesso di spostare gli URL dalla categoria “URL scadenti” a “URL che necessitano di miglioramento”, ma nemmeno questo ha aiutato!
2. Front-end personalizzato Vue/Nuxt con backend Discourse
Su questo sito, come notato oltre un mese fa, le prestazioni sono tornate a crescere fino a raggiungere i massimi precedenti al 4 maggio.
Conclusione:
SÌ, A GOOGLE IMPORTA DELL’LCP!
Spero che il team di Discourse prenda ora la cosa più seriamente in considerazione; forse vale la pena allontanarsi da Ember. Ho dovuto farlo io stesso su un progetto di grandi dimensioni: sì, la migrazione è stata molto costosa, ma ne è valsa davvero la pena.
Anch’io concordo sul fatto che l’LCP sia una penalità correlata. Seguo questo thread da molto tempo. Non c’è ancora una raccomandazione concreta su questo argomento.
Grazie per il riscontro! Penso che questo sia ancora valido:
L’aggiornamento a ember CLI è ancora in corso e sta facendo progressi, ma se stai aspettando che ci allontaniamo completamente da ember, potresti voler considerare un’altra piattaforma e magari ricontrollare la situazione riguardo a LCP tra un anno.
Non sono sicuro che valga la pena per Discourse aggiornare a Ember CLI, ma chissà: abbiamo avuto la stessa esperienza in un altro progetto e abbiamo dovuto abbandonarlo completamente. L’aggiornamento a Ember CLI richiede quasi lo stesso impegno dell’aggiornamento a Vue o ad altre tecnologie.
In ogni caso, la mia ricerca aveva solo lo scopo di evidenziare il problema e arrivare a una conclusione, dato che nei primi tempi quasi tutti smentivano il fatto che LCP abbia a che fare con il ranking.
Siamo probabilmente al 90% di completamento, che comunque era già nella nostra roadmap a lungo termine, poiché offre un’enorme comodità per gli sviluppatori e ci mantiene aggiornati su Ember. @eviltrout può fornire dettagli specifici, dato che è a capo di questo sforzo.
Sì, ma questo non significa che ogni sito passerà ora al rendering HTML statico per dominare il web con i suoi superpoteri magici di SEO e caricamento rapido delle pagine. Si scopre che l’contenuto effettivo della pagina è anche piuttosto importante per il ranking
Puoi consultare la storia di Google AMP per vedere come questo tipo di enfasi esagerata su un solo metrico possa portare a un bel po’ di traumi e lavori ingegneristici fuorvianti.
Bene, è esattamente ciò che sto cercando di smentire nel mio post. Google ha già così tanto contenuto di qualità decente che, se dovessero decidere in base alla soddisfazione dell’utente, credo che LCP sia il minimo su cui baserebbero il loro giudizio. Dopotutto, Google ha avvertito al riguardo alcuni mesi prima dell’aggiornamento.
Per essere onesti, ho avuto così tanta esperienza con Ember CLI ed è tutto sommato pessimo come prima. Inoltre, non sono sicuro che lo sforzo di aggiornamento ne valga la pena. Ma vedremo come andrà, speriamo che @eviltrout abbia qualche informazione su eventuali miglioramenti di velocità osservati.
Sfortunatamente, dalle mie ricerche sopra riportate! Google in realtà si concentra molto sull’esperienza utente e su LCP. Abbiamo provato ogni altra cosa. E, come puoi vedere dal secondo sito web, non abbiamo fatto assolutamente nulla se non eliminare l’errore LCP, e questo ci ha rimesso sulla strada per recuperare tutti i nostri ranking (anzi, al momento abbiamo già ottenuto questo risultato).
Abbiamo iniziato a utilizzare Ember CLI nella nostra startup, e uno dei motivi è stato che l’abbiamo visto impiegato in Discourse (ci ha attirato l’attenzione). L’abbiamo testato: era semplice da iniziare e facile da usare, ma era estremamente gonfio (a parte altre ragioni).
Ember CLI ha introdotto un aggiornamento recente che richiederebbe la riscrittura di qualsiasi app scritta nelle versioni precedenti alla 3; è stato proprio allora che abbiamo deciso di eliminarlo completamente.
Sì, Ember CLI supporta il lazy loading, ma non è affatto efficiente (almeno durante i test che abbiamo eseguito). Inoltre, la maggior parte delle librerie disponibili per Ember CLI era o obsoleta o così piena di bug che abbiamo dovuto scrivere noi stessi la maggior parte delle funzionalità, oppure clonare vecchi repository e mantenerli personalmente.
Ember CLI, con o senza, presenta comunque tempi di rendering scadenti (il che non aiuterebbe affatto il problema LCP di cui stiamo discutendo).
Oltre a ciò, il modo in cui funziona Ember rende facile ritrovarsi con un’app gonfia.
Vorrei ancora avere le vecchie analisi che facevamo prima di decidere di cambiare rotta. Abbiamo appena terminato la migrazione da Ember a Vue un paio di mesi fa e non potrei essere più felice delle prestazioni delle nostre app e della velocità di sviluppo.
PS. Non ho avuto l’opportunità di controllare il repository di Discourse, ma passare a Ember CLI potrebbe creare ulteriori problemi, dato che dovresti aggiornare nuovamente a Ember Octane (che non è nemmeno stabile) e che utilizza una sintassi completamente diversa… Insomma, per dirla tutta, è un disastro. Non sono sicuro che gli argomenti usati in passato per scegliere Ember siano ancora validi al momento, @Jeff.
Cosa significa “prendere sul serio”? Distruggere l’intero ecosistema e ricominciare da capo?
Discourse è un progetto in crescita; siamo pienamente consapevoli di questo problema e stiamo valutando soluzioni di mitigazione come Fastboot, una suddivisione del codice più aggressiva e così via. Tutto ciò è in attesa del nostro aggiornamento di Ember CLI.
Sono curioso di vedere questa interfaccia front-end alternativa. Puoi inviarmi un link in privato? Fondamentalmente, creare una versione solo HTML non personalizzabile è banale: forniamo già una visualizzazione solo HTML; puoi vedere che l’LCP su samsaffron.com è molto buono, si tratta semplicemente di un plugin di Discourse che rende HTML.
In generale, concordo con te riguardo all’LCP e alla SEO di Google, e apprezzo molto la tua analisi e le tue intuizioni.
Potresti spiegarmi perché, se Google utilizza l’LCP nella misura che stai sostenendo, due argomenti che ho scritto sul nostro forum Discourse, che ha un LCP molto scarso secondo Google, si posizionano rispettivamente al primo e al secondo posto su 3.580.000 voci?
Mi sembra che, se il problema LCP con la SPA di Discourse fosse così grave come sostieni, e non sto assolutamente essendo polemico, ma solo curioso basandomi sulla tua competenza: come è possibile che un sito lento come il nostro, che non utilizza alcuna CDN e ha un LCP molto scarso, riesca a occupare le prime due posizioni per argomenti pubblicati solo 11 e 13 giorni fa, dove questi due argomenti sono al primo e al secondo posto su quasi 3,5 milioni di altri post?
Sono sinceramente curioso di sapere come, se l’LCP di Google è così influente come stai presentando, il nostro sito con prestazioni LCP molto scarse possa ottenere risultati SERP così eccellenti.
Secondo il tuo esempio, la risposta sembra abbastanza ovvia: hai cercato termini piuttosto specifici dove non c’è realmente concorrenza con un LCP migliore. Essere i “migliori” è facile quando sei l’unico. Come indicato nei post precedenti, il contenuto rimane il fattore più importante, ma quando c’è molto contenuto disponibile per la tua ricerca, gli altri fattori stanno diventando importanti. Potresti persino dimostrare il suo punto piuttosto che il contrario.
So che questo è già stato menzionato sopra, ma non potrebbe essere generata una versione veloce e statica solo HTML del forum e utilizzata per i motori di ricerca? (impedendo loro di esplorare il forum effettivo dove gli utenti registrati navigano e pubblicano).
Dici che esiste un plugin per generare una visualizzazione statica? È disponibile per tutti da usare?
Sembra che si tratti ancora di una “supposizione” e non di un fatto accertato, non è corretto?
Secondo Google e altri, l’LCP non è ancora un fattore utilizzato per il posizionamento e non verrà impiegato come segnale di ranking fino a maggio 2021, giusto?
Mi sembra un po’ eccessivo spingere il team di Discourse a apportare modifiche sostanziali al proprio ecosistema basandosi su analisi e grafici provenienti da un numero molto ristretto di persone che affermano che l’LCP stia già influenzando la SEO, quando Google dichiara che questo segnale non è ancora attivo.
Il segnale LCP è attivo o no?
Google afferma che l’LCP non viene ancora utilizzato come segnale per la SEO.
Solo per farvelo sapere, non sono affatto un fan di EmberJS e concordo sul fatto che l’LCP sia importante. Sto semplicemente cercando fatti basati su prove ed evidenze concrete.
Il mio unico “punto” è che, leggendo questa discussione, sembra che molte persone stiano spingendo con forza il team meta di Discourse a effettuare cambiamenti strutturali importanti basandosi su qualcosa che, secondo Google e altri esperti di SEO, non è ancora utilizzato come segnale per la SEO.
Voi state dicendo che Google non è onesto con il pubblico?
Per vostra informazione, è altamente improbabile che Google, una società quotata in borsa, inganni il pubblico. Questo esporrebbe Google a un enorme potenziale rischio finanziario.
Va bene. Io stesso non so molto su LCP. Lo ammetto. Mi basavo solo su ciò che viene detto in questo argomento e hai ragione, non so se sia affatto accurato (tranne le prove presentate qui). Quindi, per favore, leggi il mio post “come se la questione LCP fosse corretta”.
La tua conclusione (che, a mio avviso, è che Google non utilizzi il LCP per determinare il posizionamento nei risultati di ricerca) potrebbe anche essere corretta, ma non arrivi a tale conclusione seguendo la strada che hai intrapreso.
Si tratta di un termine di ricerca così specifico che Google ha proposto correzioni per errori di ortografia. Non c’è molto da scegliere.
Sarebbe necessario effettuare molte ricerche per trarre conclusioni. Se cerco “+discourse +gon”, il tuo sito non appare affatto e il primo risultato è The Discourse Encouragement Fund
Inoltre, penso che Google personalizzi i risultati di ricerca. Il sito che visiti più frequentemente è apparso in cima per te, ma potrebbe non esserlo per altri. Per me, il primo risultato è Plugin - Discourse Meta. Di solito uso DuckDuckGo, quindi forse questo risultato non è affatto personalizzato.
Niente di tutto ciò dice o dimostra qualcosa riguardo al LCP. È stato un argomento interessante e non vedo l’ora che continui. Personalmente, sono soddisfatto della velocità di Discourse.
