Ciao, prima di tutto vorrei dire che non sono uno che insegue la SEO o si sforza di adattarsi alle richieste preferenze di Google su come dovrebbe apparire e funzionare il mio sito. Ma vale la pena sapere che Google mi ha appena inviato un’email riguardo alla necessità del mio sito di migliorare la loro nuova “metrica Core Web Vital” che presto inizierà a incidere molto sulle loro classifiche:
Ecco il report su Discourse Meta, che è un po’ peggio del mio sito per INP (372 ms contro 208 ms):
Dato che Discourse è fondamentalmente un’app web Javascript, immagino che non sarà facile migliorare quelle metriche. Ma d’altra parte, Google sembra basare la sua classifica sulla versione senza Javascript che i suoi crawler web stanno vedendo, nonostante affermi di emulare un telefono Moto G Power…
…quindi non credo o non mi interessa troppo di ciò che i loro algoritmi e le loro classifiche determinano. Ma vale la pena avvisare gli sviluppatori e gli amministratori di siti per esserne consapevoli.
Ciao @rahim123 - migliorare l’INP è una delle motivazioni per passare dall’animazione di navigazione della pagina di Discourse da uno “spinner” a pagina intera a uno slider. Abbiamo distribuito tale modifica solo su Meta la scorsa settimana, quindi è un po’ presto perché la modifica venga visualizzata nei dati del sondaggio sui Core Web Vitals di Google.
Ma stai certo che terremo d’occhio i dati e valuteremo ulteriori modifiche, se necessario.
Grazie mille per la risposta. Lieto di sapere che sei al corrente di questa situazione.
Ho utilizzato il tester URL live di Google https://pagespeed.web.dev, quindi non dovrebbe essere già incluso nel ranking? E poiché Google vede la versione senza Javascript, non sono sicuro di come tenga conto dello spinner rispetto allo slider? L’INP non ha a che fare con la navigazione da una pagina all’altra all’interno dello stesso sito web? In tal caso, non capisco davvero come valuti quella metrica per un singolo URL. Mi scuso per la mia ignoranza, sono tutt’altro che un esperto di queste minuzie relative all’architettura delle pagine e ai capricci più recenti di Google.
Sì, ‘pagespeed insights’ e il crawler di ricerca di Google recuperano la versione HTML di base di Discourse. Quindi, sfortunatamente, questi strumenti on-demand non sono molto utili per noi.
Per il ranking di ricerca, Google utilizza dati reali raccolti dagli utenti di Chrome su desktop e Android. Rendono tali dati disponibili pubblicamente su Overview of CrUX | Chrome UX Report | Chrome for Developers. Sfortunatamente, c’è un ritardo di 1-2 mesi tra la raccolta e la pubblicazione, motivo per cui dobbiamo aspettare un po’ prima di poter vedere l’impatto reale di questo nuovo cursore di caricamento.
Per vedere i dati di Google per il tuo sito (o per Meta), vai qui e inserisci il dominio: https://developer.chrome.com/docs/crux/dashboard/. Una volta caricato il report, c’è una scheda per INP sul lato sinistro. Se non ricordo male, Google si concentra sui dati ‘mobile’ per il ranking di ricerca, quindi dovrai utilizzare il filtro del dispositivo per approfondire.
L’obiettivo è ottenere almeno il 75% di ‘buono’, il che significa che il valore P75 INP che Google utilizza per il ranking di ricerca è inferiore a 200 ms.
Come punto dati, ho utilizzato esclusivamente il componente tema discourse-loading-slider da quando il mio sito è online. Sono ancora nella zona “necessita miglioramenti”
In particolare, sembra che le pagine a cui accedono principalmente account anonimi provenienti da Google abbiano le prestazioni peggiori. Potrebbe essere specifico del mio forum, ma ho pensato che valesse la pena condividerlo.
David, sembra un enorme miglioramento percepito, anche se sono affezionato al vecchio spinner Puoi ricordarmi qual è stato il cambiamento tecnico di alto livello nell’approccio che facilita quel miglioramento? È stato documentato da qualche parte?
Ember smonta tutto il DOM e pulisce i componenti dal vecchio percorso
Lo spinner viene visualizzato sullo schermo
Una volta risolta la richiesta di rete, viene visualizzato il nuovo percorso nel DOM
Con lo slider, saltiamo il passaggio 2. Lo slider viene visualizzato immediatamente, senza dover attendere il costoso processo di smontaggio.
Qui dovrei chiarire: la motivazione principale per cui abbiamo modificato l’impostazione predefinita è il miglioramento dell’UX. Anche il miglioramento della metrica INP è positivo, ma non è il motivo principale del cambiamento.
È molto importante notare che l’INP influenzerà il posizionamento del sito solo a marzo 2024, quindi i miglioramenti su cui stiamo lavorando oggi avranno tempo per essere perfezionati prima che inizi a influire su Google.
Per i dati del tuo dominio come meta.discourse.org c’è sempre un report recente in Google Search Console nascosto in ‘Esperienza’ –\u003e ‘Metriche principali del web’ –\u003e ‘Mobile (Apri report)’ e scorri fino a ‘Problema INP: più lungo di 200 ms (mobile)’
Modifica: Questo rientra maggiormente nella scala di bassa probabilità/alto impatto. INP tiene conto solo di p75.
L’INP potrebbe essere influenzato dalle procedure di post-?cooking? (= miglioramento delle funzionalità tramite JS al caricamento) del core di Matomo o dei plugin che eseguono ‘pesanti’ attività JS con un lungo ‘render blocking time’.
Soprattutto quando l’utente passa a un altro thread, ci sono circa 10-20 post “cucinati” contemporaneamente.
Qui è sempre bene suddividere i compiti per i singoli post in setTimeout() separati per consentire al browser di eseguire il rendering tra i singoli compiti e non attendere il completamento dell’intero processo.
Ad esempio, qualcosa del genere:
var initializeSliderSlickItem = function (item) {
/* esegui l'inizializzazione effettiva qui */
var $this = $(item);
[…];
};
$('.slider-slick').each(function () {
var item = this;
setTimeout(initializeSliderSlickItem, 0, item);
});
Modifica: Questo rientra nella scala di bassa probabilità/alto impatto. INP tiene conto solo di p75.
… e dopo inizia la cottura. Se l’utente fa clic su qualcosa mentre è in corso un’attività di cottura di Discourse, Google misura INP come tempo fino al prossimo paint. Il prossimo paint potrebbe apparire al più presto al termine dell’attività di cottura in corso.
“La vita di un’interazione. Si verifica un ritardo di input fino all’inizio dell’esecuzione dei gestori di eventi, che può essere causato da fattori quali lunghe attività sul thread principale [ad es. “cottura”]. Vengono quindi eseguiti i gestori di eventi dell’interazione e si verifica un ritardo prima che venga presentato il frame successivo.”
Google tiene conto del tempo di blocco del paint più lungo se ci sono più eventi di blocco “durante l’intero ciclo di vita della pagina”. Ciclo di vita come:
Il thread URL “A” si apre
Viene mostrato il puntatore
Cottura dei post nel thread “A”
Clic 1: l’utente fa clic sul link al thread “B”
Viene mostrato il puntatore
Caricamento del thread “B”
Cottura dei post nel thread “B”
Clic 2: l’utente fa clic sul link al thread “C” mentre il thread “B” è ancora in cottura
L’azione di cottura in corso sul thread “B” termina (-- conta nell’INP per il Clic 2)
“L’INP viene calcolato quando l’utente lascia la pagina, con il risultato di un singolo valore rappresentativo della reattività complessiva della pagina durante l’intero ciclo di vita della pagina.”
Fortunatamente, l’uso del p75 della metrica significa che nessuno deve davvero preoccuparsi di questo scenario che hai descritto, e chiaramente non è rappresentativo delle normali interazioni con Discourse.
Puoi ricordarmi qual è stato il cambiamento tecnico di alto livello nell’approccio che facilita quel miglioramento? È stato documentato da qualche parte?
