Olá, antes de mais nada, gostaria de dizer que não sou de correr atrás de SEO ou de me esforçar para atender às exigências preferências do Google sobre como meu próprio site deve parecer e funcionar. Mas vale a pena saber que o Google acabou de me enviar um e-mail sobre a necessidade de meu site melhorar em sua nova “métrica Core Web Vital”, que em breve começará a influenciar muito seus rankings:
Aqui está o relatório sobre o Discourse Meta, que é um pouco pior do que meu próprio site para INP (372ms vs 208ms):
Dado que o Discourse é basicamente um aplicativo web Javascript, imagino que não será fácil melhorar essas métricas. Mas, por outro lado, o Google parece estar baseando seu ranking na versão sem Javascript que seus rastreadores web estão vendo, apesar de alegar estar emulando um telefone Moto G Power…
…então eu realmente não acredito ou me importo muito com o que seus algoritmos e rankings determinam. Mas vale a pena um aviso para que os desenvolvedores e administradores de sites estejam cientes.
Olá @rahim123 - melhorar o INP é uma das motivações para mudar a animação de navegação de página do Discourse de um ‘spinner’ de página inteira para um slider. Nós só implementamos essa mudança no Meta na semana passada, então é um pouco cedo para a mudança aparecer nos dados da pesquisa de web vitals do Google.
Mas fique tranquilo, estamos de olho nos dados e veremos em fazer mais ajustes, se necessário.
Muito obrigado pela resposta. Fico feliz em saber que você está cuidando disso.
Eu usei o testador de URL ao vivo do Google https://pagespeed.web.dev, então isso já não deveria estar incluído na classificação? E como o Google está vendo a versão sem Javascript, não tenho certeza de como ele leva em consideração o spinner versus o slider? O INP não tem a ver com a navegação de uma página para outra dentro do mesmo site? Nesse caso, não entendo realmente como ele mede essa métrica para um único URL. Desculpe minha ignorância, estou longe de ser um especialista nessas minúcias relacionadas à arquitetura de páginas e aos últimos caprichos do Google.
Sim, o ‘pagespeed insights’ e o crawler de busca do Google buscam a versão básica em HTML do Discourse. Então, infelizmente, essas ferramentas sob demanda não são muito úteis para nós.
Para a classificação de busca, o Google usa dados do mundo real coletados de usuários do Chrome em desktop e Android. Eles disponibilizam esses dados publicamente em Overview of CrUX | Chrome UX Report | Chrome for Developers. Infelizmente, há um atraso de 1 a 2 meses entre a coleta e a publicação, e é por isso que precisamos esperar um pouco antes de podermos ver o impacto real deste novo controle deslizante de carregamento.
Para ver os dados do Google em seu próprio site (ou no Meta), vá aqui e insira o domínio: https://developer.chrome.com/docs/crux/dashboard/. Depois de carregar o relatório, há uma aba para INP no lado esquerdo. Se bem me lembro, o Google foca nos dados ‘mobile’ para a classificação de busca, então você precisará usar o filtro de dispositivo para investigar isso.
O objetivo é obter pelo menos 75% de ‘bom’ - isso significará que o valor P75 do INP que o Google usa para a classificação de busca é inferior a 200ms.
Como um ponto de dados, tenho usado exclusivamente o componente de tema discourse-loading-slider desde que meu site entrou no ar. Ainda estou na zona de “precisa de melhorias”
Particularmente, parece que as páginas acessadas principalmente por contas anônimas vindas do Google têm o pior desempenho. Pode ser específico do meu fórum, mas pensei que valia a pena compartilhar.
David, parece uma enorme melhoria percebida, embora eu goste do antigo spinner Você pode me lembrar qual foi a mudança técnica de alto nível na abordagem que facilita essa melhoria? Isso foi documentado em algum lugar?
O Ember desmonta todo o DOM e limpa os componentes da rota antiga
O spinner é renderizado na tela
Assim que a solicitação de rede é resolvida, renderiza a nova rota no DOM
Com o slider, pulamos a etapa 2. O slider é renderizado imediatamente, sem precisar esperar pelo dispendioso processo de desmontagem.
Eu deveria esclarecer aqui: a principal motivação para mudarmos o padrão é a melhoria da UX. A melhoria da métrica INP também é boa, mas não é a razão principal da mudança.
É muito importante observar que o INP só afetará o ranking do site em março de 2024, portanto, as melhorias nas quais estamos trabalhando hoje têm tempo para serem iteradas antes que comecem a afetar o Google.
Para os dados do seu próprio domínio, como meta.discourse.org, sempre há um relatório recente no Google Search Console, oculto em ‘Experiência’ –\u003e ‘Core Web Vitals’ –\u003e ‘Móvel (Abrir relatório)’ e role para baixo até ‘Problema de INP: mais longo que 200ms (móvel)’
Editar: Isso está mais na escala de baixa probabilidade/alto impacto. O INP leva em consideração apenas o p75.
O INP pode ser influenciado pelos procedimentos de pós-processamento (?cooking?) (= aprimoramento de recursos via JS ao carregar) do núcleo do Matomo ou de plugins que realizam algumas tarefas ‘pesadas’ de JS com um longo ‘tempo de bloqueio de renderização’.
Especialmente quando o usuário muda para outro tópico, há cerca de 10-20 posts sendo “processados” de uma vez.
Aqui, é sempre bom dividir as tarefas para posts individuais em setTimeouts() separados para permitir que o navegador faça a pintura entre as tarefas individuais e não espere que todo o processo termine.
Por exemplo, algo como isto:
var initializeSliderSlickItem = function (item) {
/* faça a inicialização real aqui */
var $this = $(item);
[…];
};
$('.slider-slick').each(function () {
var item = this;
setTimeout(initializeSliderSlickItem, 0, item);
});
Editar: Isso está mais na escala de baixa probabilidade/alto impacto. O INP leva em conta apenas o p75.
… e depois começa o cozimento. Se o usuário então clicar em algo enquanto uma tarefa de cozimento do Discourse está em execução, o Google mede o INP como o tempo até a próxima pintura. A próxima pintura pode aparecer mais cedo no final da tarefa de cozimento em execução.
“A vida de uma interação. Um atraso de entrada ocorre até que os manipuladores de eventos comecem a ser executados, o que pode ser causado por fatores como tarefas longas no thread principal [por exemplo, "cozimento"]. Os manipuladores de eventos da interação são então executados, e um atraso ocorre antes que o próximo quadro seja apresentado.”
O Google leva em consideração o tempo de bloqueio da pintura mais longo se houver vários eventos de bloqueio “ao longo de todo o ciclo de vida da página”. Ciclo de vida como:
Thread “A” do URL abre
O spinner é exibido
Cozimento de posts no thread “A”
Clique 1: o usuário clica no link para o thread “B”
O spinner é exibido
Carregamento do thread “B”
Cozimento de posts no thread “B”
Clique 2: o usuário clica no link para o thread “C” enquanto o thread “B” ainda está cozinhando
A ação de cozimento em execução no thread “B” termina (-- conta para o INP do Clique 2 --)
“O INP é calculado quando o usuário sai da página, resultando em um único valor que é representativo da responsividade geral da página ao longo de todo o ciclo de vida da página.”
Ainda bem que usar o p75 da métrica significa que ninguém precisa se preocupar com esse cenário que você pintou, e claramente não é representativo das interações normais com o Discourse.
Você pode me lembrar qual foi a mudança técnica de alto nível na abordagem que facilita essa melhoria? Isso foi documentado em algum lugar?
