Estava apenas analisando nossos resultados no Google Search mais cedo hoje e nós também notamos uma queda significativa no tráfego vindo dos resultados de busca para nossa instância do Discourse (discourse.julialang.org) após 4 de maio (cerca de 30%). Não percebi isso até agora, porque o Discourse representa apenas cerca de metade das nossas visualizações de página, e o restante do nosso site teve um aumento de tráfego com essa atualização, então o efeito geral foi apenas levemente negativo no saldo. No entanto, fica muito claro ao separar o Discourse do não-Discourse no mesmo domínio. Está subindo lentamente de volta, mas na mesma taxa de crescimento do restante do site. Há algo que possa ser feito sobre o problema de LCP? Isso parece ser um bom candidato para o que está sendo penalizado pelo Google (e eu também vejo dezenas de milhares de reclamações de LCP no nosso Search Console). As métricas do Google estão relatando cerca de 3 segundos de LCP em dispositivos móveis para muitas das nossas páginas do Discourse, o que parece bastante alto. Isso parece ser um problema universal do Discourse. Por exemplo, se eu gerar um relatório nesta própria thread, obtenho 3,3 s para o LCP. Infelizmente, não sou desenvolvedor web, então não tenho sugestões concretas, mas espero que alguém que saiba mais sobre isso possa sugerir algo. Seria muito bom recuperar esses 30% de tráfego 
.
Aqui está nosso gráfico de impressões de busca com suavização semanal, dividido entre o Discourse e o restante do domínio (que, presumo, teria a mesma classificação de confiança em todo o domínio). A atualização de maio é bastante perceptível. Ironicamente, tivemos um pico de tráfego não relacionado na mesma semana para o restante do site, mas diria que o comportamento geral é uma queda perceptível nas impressões do Discourse e impressões majoritariamente estáveis (ignorando o pico de tráfego não relacionado) para o restante do site.
Isso é exatamente o que tenho reclamado há meses, mas os administradores não estão levando a sério @Keno
Começamos a experimentar o Vue.js também para servir parte do nosso conteúdo através do Nuxt, a fim de melhorar o desempenho de pré-renderização do Discourse. E podemos ver isso: a atualização foi publicada há menos de um mês e, nos últimos 2 a 3 dias, nossas impressões dobraram, voltando exatamente ao que eram antes da atualização de maio.
Não sei se é uma coincidência ou não, mas talvez tenha algo a ver com o LCP. Vou continuar monitorando por mais algumas semanas antes de tirar qualquer conclusão.
Depois de ler este post do blog, isso é… um conselho super genérico. Basicamente, pode ser resumido como “tenha conteúdo de qualidade”. Nem tenho certeza do que poderíamos mudar especificamente no Discourse com base neste post do blog? 
Não tenho certeza se é apenas sobre a qualidade do conteúdo; isso poderia estar seriamente relacionado ao alto tempo de LCP, que, suponho, pode ser corrigido no Ember. Mas, na verdade, não tenho certeza ainda; estou experimentando outras soluções para ver…
Acho que você está focando um pouco demais em uma única métrica. Você está focando mais nela do que o próprio Google.
Eles publicaram sobre o LCP em 28 de maio e disseram “Forneceremos um aviso de 6 meses antes de implementar essas mudanças.”. Esse aviso nem mesmo foi dado hoje.
Bem, como eu disse, não tenho provas, nem estou focando nisso. Ainda estou experimentando outras coisas e, ao ver um pico de impressões voltando ao nível de antes, começando ontem, vou ficar de olho para ver como as coisas evoluem nas próximas semanas.
É, não tenho ideia se o LCP é realmente o culpado, mas é o que mais salta aos olhos no Search Console, que para nós sinaliza cerca de 20 mil erros em páginas com LCP elevado. Independentemente de qualquer impacto no SEO, melhorar o tempo de LCP parece um objetivo válido. Claro, há a questão de saber o quanto as métricas do Google realmente refletem a realidade, mas, se refletem, então um tempo de carregamento inicial de 5 segundos é bastante e certamente há como fazer melhor. Especialmente para o caso de uso de usuários deslogados que vêm diretamente do Google, servir páginas pré-renderizadas via CDN parece ser bastante útil.
Está apontando o LCP, mas acho que o problema seria o FCP… observe os tempos idênticos
O primeiro carregamento no Discourse é mais lento que os carregamentos subsequentes porque você está carregando o aplicativo e não apenas aquela primeira página. Portanto, acho que é uma situação muito mais fácil de dizer do que fazer reduzir o tempo de carregamento inicial para atingir o nível “bom” do Google (< 1s para FCP) no mobile.
Acho que vocês se concentram demais nos fatores técnicos “duros”. O que o Google não vai te dizer é que eles também medem o desempenho “percebido” dos sites.
O Discourse tem potencial para melhorar o desempenho percebido, e deveria.
https://thepathforward.io/web-performance-how-to-affect-perceived-performance/
Existem muitas maneiras de fazer isso, por exemplo, pré-renderização de esqueletos antes que o aplicativo completo seja carregado.
Basicamente, qualquer coisa que apareça antes do aplicativo estar totalmente carregado ajuda a melhorar o desempenho percebido. Até mesmo renderizar apenas o cabeçalho (sem conteúdo, apenas a cor correta) e o fundo com o spinner de carregamento da página antes que o aplicativo completo esteja disponível ajudaria na visualização inicial da página. Qualquer coisa que seja construída em etapas, para que o usuário saiba… que algo está acontecendo, mesmo em um dispositivo lento.
Por exemplo, para o Meta, algo assim poderia/deveria ser renderizado instantaneamente (pode ser feito com um CSS crítico simples) antes que o aplicativo completo esteja disponível no navegador:
Existem centenas de artigos sobre como melhorar o desempenho percebido de aplicativos web únicos. Talvez seja algo para a @equipe investigar?
Uma página de “carregando” pode ser implementada em um componente de tema, se desejar. Que tal experimentar e nos informar se isso faz alguma diferença no seu site?
Acho que o resultado desejado não é possível com um componente de tema simples. Para isso, preciso ter um bloco crítico de CSS inline no cabeçalho, que seja colocado antes de qualquer outro script e meta tags CSS. Além disso, o <body> só é renderizado depois que o aplicativo completo é carregado. Não vejo como um componente de tema possa ser usado para alcançar os resultados desejados, como ter um bloco de CSS crítico no cabeçalho e, pelo menos, alguns <div> renderizados no corpo antes que o aplicativo seja totalmente carregado.
Existe uma solução que adiciona o loader ligeiramente mais cedo…
Você tem alguma fonte sobre o impacto percebido no desempenho que afeta o ranqueamento de busca, ou você está se referindo a FCP/LCP? FCP e LCP são métricas específicas com requisitos técnicos, apesar de serem conceitos baseados na percepção. Além disso, note que o FCP não faz parte dos “Core Web Vitals” do Google (mas o LCP sim).
Mais detalhes em https://web.dev/lcp/:
Conforme especificado atualmente na API Largest Contentful Paint, os tipos de elementos considerados para o Largest Contentful Paint são:
- Elementos
<img>- Elementos
<image>dentro de um elemento<svg>- Elementos
<video>(a imagem poster é utilizada)- Um elemento com imagem de fundo carregada via a função
url()(em oposição a um gradiente CSS)- Elementos de bloco contendo nós de texto ou outros elementos filhos de nível de linha.
Se uma página remove um elemento do DOM, esse elemento não será mais considerado. Da mesma forma, se o recurso de imagem associado a um elemento mudar (por exemplo, alterando
img.srcvia JavaScript), esse elemento deixará de ser considerado até que a nova imagem seja carregada.
Esses requisitos tornam um pouco difícil a implementação; talvez um elemento de carregamento com uma imagem ou texto grande possa funcionar se, em vez de removê-lo do DOM, você o ocultar de outra forma? O spinner acima usa z-index para se ocultar, então talvez isso funcione… mas o próprio spinner não é suficiente porque não é uma imagem ou texto (é CSS).
Concordo que algum tipo de loader seria bom para usuários em conexões lentas, mas existem requisitos específicos a serem atendidos para o Google (e não sabemos se isso resolveria o problema levantado pelo autor da postagem original).
Isso exigiria uma reescrita de baixo para cima do Discourse, então eu não prenderia a respiração por isso.
Olhei para este componente, mas não acho que faça muita diferença, pois ele carrega muito tarde, ou seja, quando a maior parte do aplicativo já está inicializada. O Google não divulga exatamente o que leva em consideração e outras coisas. Além do conteúdo, a UX subjetiva certamente é algo que eles medem, mesmo que indiretamente, como o retorno ao mecanismo de busca deles. Carregamento longo (percebido) = maior taxa de rejeição na primeira visita. Além disso, mesmo que isso não seja 100% relevante para SEO, de acordo com o que o Google afirma oficialmente, ainda é relevante do ponto de vista da UX e do tráfego. Porque um usuário vai abandonar se o desempenho percebido na primeira carga da página não for bom o suficiente.
Eu entendo perfeitamente isso. E tenho que admitir que ainda não compreendo totalmente o processo de renderização do aplicativo.
Realmente, se você quer vencer nessa métrica, vá para um site estático pré-gerado, como todo o projeto Google Amp.
Porque você sempre perderá para sites que possuem páginas estáticas.
Está falando comigo? Não, estou super feliz com o Discourse 
E uma boa UX não se resume apenas ao carregamento inicial da página. Talvez você perca um pouco no primeiro carregamento, mas, uma vez que o aplicativo está carregado, os usuários certamente permanecem por mais tempo e retornam com mais frequência, em comparação com páginas estáticas chatas. E tenho certeza de que o Google também leva isso em consideração de alguma forma.
Além disso, desde que mudamos para o Discourse, nenhum usuário reclamou da velocidade. E nosso tráfego de busca está aumentando, em comparação com nossa página Drupal super otimizada, que tinha tempo de carregamento da primeira página na velocidade da luz, graças ao cache HTML completo via Fastly e ao CSS crítico.
@codinghorror Pessoal, fiz alguns testes com dois domínios que tenho,
Ambos foram afetados pela atualização de 4 de maio:
Estudo de caso 1: Foco total na qualidade do conteúdo (como muitos acima sugeriam)
No primeiro, concentrei-me em melhorar o conteúdo, palavras-chave, remover links ruins, fazer interligação, adicionar novo conteúdo de qualidade com muito potencial… etc… etc.
Como vocês podem ver acima, todo o esforço foi desperdiçado. Mesmo que os novos artigos tenham sido indexados bem, o conteúdo raso tenha sido removido e os artigos antigos tenham sido melhorados, mal se vê qualquer melhoria. É como se o Google estivesse indexando o site de forma boa o suficiente para receber um pouco de tráfego, mas não tanto!
Estudo de caso 2: Migração para Vue+Nuxt (melhorando um pouco a estrutura + LCP e velocidade de renderização)
No segundo site, apenas movi algumas páginas para nosso próprio aplicativo Vue+Nuxt personalizado, que serve o mesmo conteúdo com mudanças mínimas ou nenhuma na estrutura, via API. Não houve outros esforços de melhoria (embora, neste caso, mover a comunidade de community.something.com para o site principal tenha prejudicado mais do que ajudado, o que realmente aconteceu por um curto período).
Não tenho certeza do que se pode concluir com o acima, mas continuarei testando e observando. Certamente, esse pico repentino é interessante. Aliás, verifiquei antes/depois de maio e depois desse pico recente, e notei que, em todos esses casos, muitos artigos perderam impressões e, de repente, quase os mesmos artigos recuperaram a mesma quantidade de impressões. Ou seja, não foram apenas um ou dois artigos/páginas afetados, mas algo que fez o Google penalizar todo o site e, em seguida, manter essa penalidade em todo o site, independentemente dos esforços feitos na qualidade do conteúdo.
Espero que tudo isso faça sentido. Fiquem à vontade para me avisar se tiverem alguma dúvida,
Abraços!
Se não me engano, o Discourse tenta servir uma versão estática de suas páginas para os rastreadores, correto? Seria possível servir essa versão estática a todos os usuários não logados? Essas penalidades de LCP sugerem que o Google está visualizando a versão não estática do nosso fórum.
Temos investigado isso intermitentemente há meses, inclusive contratando consultores externos, e tudo continua apontando para o nosso fórum ser severamente penalizado pelo Google por violações de LCP após a atualização de 4 de maio.