Impacto da Atualização Principal do Google de 4 de maio nos fóruns do Discourse

Comunidade
91

Concordo completamente. Meu resultado de busca rápida não era o ponto e certamente não foi destinado a ser qualquer tipo de teste autoritário; e quando o postei, não fiz tais alegações também. Apenas fiz uma pergunta baseada nos resultados da minha busca. Deveria ter feito logout antes de realizar a busca, porque quando faço logout, obtenho os mesmos resultados de “falta de” dados, LOL

O único “ponto técnico tangível” que realmente fiz é que o Google declarou publicamente que usará o LCP (e outras métricas de experiência da web) a partir de maio de 2021.

Também fiz o ponto de negócios de que o Google não pode fazer declarações como essa e enganar as pessoas. Isso seria um grande erro para uma grande empresa de capital aberto. Eles não estão cometendo tal erro, é minha suposição, e quando o Google diz que ainda não está usando o LCP como sinal, não tenho motivo para não acreditar neles.

Se os postadores bem-intencionados que argumentam que o LCP está afetando o SEO e que estavam certos de “suas descobertas” e defendiam que o Discourse fizesse mudanças estruturais em seu código devido a essas “descobertas” tivessem o código disponível para revisão, de código aberto, para que todos pudessem examiná-lo, suas “evidências”, após uma revisão por pares, poderiam ser convincentes.

Isso não é nada pessoal nem adversarial de forma alguma; na verdade, só vimos alguns gráficos e nenhum código, enquanto o Google declarou publicamente que nem mesmo está usando o LCP como sinal de SEO neste momento.

Em toda “justiça técnica”, não vimos realmente nenhuma “evidência” de que o Google esteja usando o LCP como sinal agora. É apenas um palpite e não há código para revisar e submeter a uma revisão por pares para apoiá-lo.

Todos aqui gostariam de saber quais alterações são necessárias para otimizar o SEO e aumentar a receita. No entanto, precisamos de fatos tangíveis, código para revisar, onde possamos ser convencidos de que o Google está realmente usando o LCP como sinal.

O Google afirma que não está usando o LCP como sinal agora; e começará a usar o LCP como sinal de SEO em maio de 2021. Até agora, não vimos motivo para duvidar do que o Google declarou publicamente; e não vimos nenhuma “evidência concreta revisada por pares” em contrário.

Espero que isso ajude.

4 curtidas
92

Então, para todos aqueles que reclamaram de maio de 2020, nada disso se compara ao que talvez venha em maio de 2021? :wink: Quero dizer, você também está dizendo que as comunidades do Discourse PODEM sofrer um impacto em termos de resultados de pesquisa no próximo ano (já veremos o que acontece).

2 curtidas
93

Sim, concordo plenamente com você e com todos aqui preocupados com o LCP e o efeito que os Core Web Vitals do Google vão ter.

Além disso, elogo sinceramente todos que estão se esforçando para encontrar respostas e soluções para esse problema iminente.

Quanto ao colapso de SEO de maio de 2020, isso aconteceu conosco também em servidores LAMP; portanto, não é, de forma alguma, um problema do Discourse em si; e ainda não sabemos os passos exatos para corrigir esse problema de maio de 2020, pois, se soubéssemos o que corrigir com alto grau de confiança, todos nós poderíamos “corrigir” e “ajustar”.

Ao longo dos anos, todos nós vimos resultados muito estranhos da IA do Google e como ela classifica conteúdo e manipula os resultados da SERP.

Meu ponto anterior foi que me pareceu infundado ler, neste tópico, alguém pressionar a equipe Meta do Discourse a fazer mudanças estruturais muito substanciais em todo o seu ecossistema com base em suposições e palpites, e não em fatos concretos fundamentados em código revisável.

Dito isso, o LCP será muito importante, de qualquer forma, num piscar de olhos.

Abraços.

4 curtidas
94

Isso já é assim que o Discourse funciona desde sempre :laughing:

A novidade é que o LCP está sendo capturado a partir dos celulares Android das pessoas. O Android é a plataforma mais lenta que operamos, e isso nos afeta de forma desproporcional.

O que @sam sugeriu também era servir essa visualização para alguns usuários anônimos por meio de um plugin, mas isso não é algo que faremos em breve.

7 curtidas
95

Ok. Estou com lacunas de conhecimento sobre como funciona exatamente (mas parece que ainda há algum carregamento inicial a ser feito, e poderia ser mais rápido. Daí todo esse tópico). Essa discussão já ocorreu em certa medida em 14 de outubro, acima. O próprio Jeff na verdade levantou a ideia:

Por que não pegar o conteúdo e criar um site estático totalmente pré-gerado? Algo tão rápido quanto possível. E enviar isso aos motores de busca em vez do fórum real? A ideia seria que o conteúdo é o mais importante aqui, não a experiência. E focar na rapidez da entrega, já que parece ser isso que é importante para os motores de busca.

A rolagem infinita não tem sido culpada ultimamente, mas você criaria páginas estáticas pré-geradas sem rolagem infinita. E você projetaria como um carro de rally: Cada grama de peso que não seja estritamente necessária, você se livra dela. Sem menu hambúrguer, sem logotipo, sem avatar para os postadores. Você se foca apenas no conteúdo e na velocidade.

Seria como um bom restaurante (=o fórum Discourse), onde você monta um drive-thru com pedidos para levar. A mesma ótima comida (=o conteúdo), mas sem nenhuma da experiência. Você faz o pedido em um alto-falante ao chegar (=sua pesquisa no motor de busca) e recebe sua comida pré-embalada jogada pela sua janela. Toda a ideia é que é o que é demandado, e apenas a comida (=conteúdo) e a velocidade de entrega são importantes. Se as pessoas gostarem da comida, talvez voltem e aproveitem toda a experiência lá dentro.

Depois, cabe a cada dono (=admin) fazer uma escolha: Você acha que um drive-thru é ruim para sua marca e se recusa a fazê-lo, ou você segue esse caminho para atrair mais pessoas, sabendo que muitas podem nunca vir comer lá dentro (muitas já não o fazem, mas pode ficar ainda pior. E talvez seu restaurante pareça muito menos agradável apresentado dessa forma). Mas talvez aquele famoso site que recomenda restaurantes envie mais pessoas para você (resta ver se é eficaz).

O que seria necessário é um plugin ou módulo para gerar essas páginas estáticas conforme o conteúdo é adicionado ao fórum (acho que não deveria ser excessivamente complicado). Você apenas adicionaria um link aqui e ali ao seu fórum real (configurado para “não rastrear” pelos motores de busca). Caberia a cada admin usar ou não essa solução.

Se o que foi dito acima está correto em princípio, e esse problema pode piorar no futuro, isso parece uma solução aceitável para mim. Ou talvez eu não tenha entendido bem. (Nota: tudo isso seria APENAS LEITURA, claro)

1 curtida
96

Já servimos HTML puro, sem JavaScript, para os rastreadores :upside_down_face:

Como disse acima, o problema é que a nova pontuação LCP é capturada nos navegadores dos usuários, não nos rastreadores.

7 curtidas
97

Ok, mas o que eu não consigo entender, então, é que ninguém sai ganhando nesse caso, certo? Por que isso afetaria os resultados de busca? Se os sites Discourse performam tão bem quanto os outros (“tão bem” ou “tão mal” ;)). Outros sites também são abertos no Android, não são?

2 curtidas
98

O Android tem desempenho inferior à média em processamento de núcleo único, o que afeta aplicativos de página única pesados, como o Discourse. Abordamos esse tema em profundidade em O estado do JavaScript no Android em 2015 é… precário

O iPhone de ponta é 10 vezes mais rápido que o último Pixel ao renderizar o Discourse. A Google não leva em conta a renderização do iPhone no LCP, pois simplesmente não pode, já que não há um Chrome real no iOS.

9 curtidas
99

Então, pode haver realmente uma vantagem nesse aspecto em gerar um site de “páginas pequenas” para enviar aos mecanismos de busca. Não valeria a pena? (talvez não). Ou os administradores precisam oferecer novos celulares de alto desempenho aos seus usuários? :wink: Esse é o propósito de todos esses anúncios dizendo que você ganhou o último iPhone? :rofl:

Obrigado pelas explicações, Falco!

1 curtida
100

Ao dar uma olhada rápida aqui Overview of CrUX  |  Chrome UX Report  |  Chrome for Developers, parece que o Google obtém as informações monitorando os usuários (com permissão), então você teria que convencer muitos deles a usar o seu Discourse de baixa custo :slight_smile:

4 curtidas
103

Parece que você está confundindo Ember e Ember CLI. O Ember é o framework que já estamos usando (e usamos há mais de 8 anos). O Ember CLI são as ferramentas de linha de comando que estamos migrando para substituir o pipeline de assets do Rails. Menciono isso porque algumas coisas que você diz (versões anteriores à 3 exigem reescrita) não seriam verdadeiras para o Ember CLI, mas poderiam ser verdadeiras para o Ember.

Novamente, o Ember CLI não faz renderização. O Ember sim e, às vezes, tem problemas de desempenho. Note que isso não é algo específico do Ember — todos os frameworks atuais têm armadilhas de desempenho das quais você precisa estar ciente. Após anos trabalhando com o Ember, identificamos dois caminhos críticos (cabeçalho e visualização do tópico) que precisavam de melhor desempenho e mudamos para uma abordagem baseada em DOM virtual.

Pode ser que nem sempre precisemos fazer isso, dependendo de como o Glimmer/Ember Octane se sair, mas o código é bastante estável e roda rápido até em dispositivos móveis mais antigos agora.

O Ember Octane foi introduzido na versão 3.15, e desde então já houve duas versões LTS (3.16 e 3.21). Vamos fazer a atualização para ele, mas de forma gradual. Felizmente, a equipe do Ember permite que você opte por entrar (até mesmo por arquivo!) no formato que deseja usar.

Dito tudo isso, há bastante coisa para criticar no Ember. No passado, quando o desempenho era um problema maior para o Discourse, houve algumas versões prometidas que acabaram nos prejudicando em vez de nos ajudar. Isso foi difícil. Tivemos que ficar muito atentos a ele por um longo tempo para atender às nossas necessidades.

Hoje, ele também tem uma fração da popularidade de frameworks mais recentes como o React. No entanto, o React não existia há 8 anos! Nossas únicas opções eram Angular, Ember e Knockout. Se você acha que atualizar o Ember é difícil, veja o que o Angular passou das versões 1 para 2 (sem mencionar suas aventuras secundárias com Dart!).

Atualizar o Ember ao longo dos anos foi muito trabalho, mas pelo menos é uma opção! Nenhum dos outros frameworks ofereceu qualquer tipo de caminho de atualização como esse.

Quanto a reescrever em Vue/Next/React, acho que as pessoas subestimam severamente a quantidade de código que temos e que funciona perfeitamente. Seria uma quantidade impensável de trabalho.

19 curtidas
104

Sim, isso está correto. Quando sua base de usuários possui dispositivos antigos, seu site geralmente recebe uma classificação mais baixa.

6 curtidas
105

Estou considerando isso, @justin e @awesomerobot, mas gostaria que o Robin se manifestasse sobre os detalhes do Ember CLI primeiro.

No cerne da questão, há um certo paradoxo do tipo “o que acontece quando uma força irresistível encontra um objeto imóvel?” (Irresistible force paradox - Wikipedia). Somos, de forma muito intencional, um aplicativo JavaScript (ou SPA), e isso envolve compensações que decidimos fazer em 2012/2013 com base na nossa melhor previsão de como seria o futuro em 2022/2023. Embora eu esteja obviamente enviesado, diria que nossa previsão de “nossa, o desempenho dos navegadores em dispositivos móveis será indistinguível do desempenho em navegadores de desktop” foi certeira.

Aliás, fomos além da meta, já que a maioria dos iPhones recentes é mais rápida que laptops e desktops. :astonished_face: Isso… eu não esperava!

:bullseye:

Embora continuemos a melhorar o que pudermos em termos de velocidade de carregamento inicial — e velocidade em geral —, acho que nosso histórico aqui é louvável. Por um lado, obtivemos tanta publicidade em 2015 que o Google internamente fez várias melhorias no V8, no Chrome e no Android para abordar o fraco desempenho de SoCs Qualcomm medido em JavaScript.

Nosso calcanhar de Aquiles tem sido… Qualcomm. Infelizmente, a Qualcomm não se saiu muito bem no front de desempenho até agora, já que o dispositivo Android com “melhor” desempenho está apenas em um nível aproximado ao do iPhone 7. Leva tempo para que dispositivos Android mais antigos saiam do mercado, mas os 855 e 865 foram ambos desempenho decentes, em um nível aproximado ao do iPhone 7:

image
image2110×1854 536 KB

Preciso rolar mais para baixo para chegar a um dispositivo Apple tão lento quanto o dispositivo Android mais rápido, mas se eu fizer isso, a correspondência mais próxima é o iPhone X / iPhone 8, com ~910 pontos no Geekbench. Infelizmente, o 865, por razões que não compreendo totalmente, tem um desempenho um pouco inferior na web, então ainda estamos no nível de desempenho do iPhone 7 no Speedometer:

image
image650×650 30.8 KB

Gostaria que vivêssemos em um mundo onde houvesse dispositivos Android lançados com uma variedade de SoCs de diversas empresas, todas competindo para construir os SoCs mais rápidos e poderosos… :crying_cat: Por outro lado, o desempenho do iPhone 7 é sólido para o Discourse e estou feliz que eventualmente todos os dispositivos Android, até mesmo os antigos, serão “pelo menos tão rápidos quanto um iPhone 7”. Também estou torcendo pelo próximo Snapdragon 875; deve haver mais detalhes sobre isso nos próximos meses. :crossed_fingers:

De acordo com os resultados do Geekbench 5, podemos ver que o Xiaomi Mi 11 é alimentado pelo Snapdragon 875 de 5nm (como sugerido por ninguém menos que o executivo da Xiaomi, Lu Weibing). O futuro Xiaomi Mi 11 conseguiu pontuar 1.102 pontos no teste de núcleo único e 4.113 pontos no teste de múltiplos núcleos.

Se for verdade, isso o colocaria no nível do A12, e esperamos que isso se manifeste também no lado da web!

De qualquer forma, há uma decisão arquitetônica central aqui no Discourse de ser um aplicativo JavaScript… e estamos totalmente comprometidos com esse caminho no futuro previsível.

Deal_with_it_dog_gif

23 curtidas
109

Para quem está de olho nas suas estatísticas, aqui está mais uma data para anotar. Será interessante ver o que acontece nas próximas semanas em relação à atualização principal mais recente do Google, de dezembro de 2020.

https://searchengineland.com/googles-december-2020-core-update-was-big-even-bigger-than-may-2020-says-data-providers-344429

1 curtida
110

Não se pode esquecer dos Macs com Apple Silicon anunciados recentemente! :grinning:

Por curiosidade, de onde veio essa publicidade?

O chip A10 ainda está se mantendo por um fio.

Por precaução, estou baixando minhas expectativas. A Apple sempre esteve à frente.

Dito isso, os smartphones Android ainda estão tentando alcançar. É absolutamente ridículo. A Apple já tem o chip A14 e, provavelmente, já está trabalhando no chip A15 para o próximo ano.

2 curtidas
111

Obrigado por compartilhar isso. Alguns pontos relevantes para esta discussão, extraídos do artigo:

O que fazer se você for afetado. O Google já ofereceu orientações sobre o que considerar caso sua página seja impactada negativamente por uma atualização principal. Não há ações específicas para se recuperar e, na verdade, uma queda no ranking pode não indicar que há algo errado com suas páginas. No entanto, o Google apresentou uma lista de perguntas a considerar se seu site for afetado por uma atualização principal. O Google também afirmou que é possível observar uma leve recuperação entre atualizações principais, mas a maior mudança que você verá ocorrerá após outra atualização principal.

Isso também é útil.

https://searchengineland.com/google-advice-on-improving-your-sites-ranking-for-future-core-ranking-update-320184

7 curtidas
112

Na minha opinião, ao falar sobre SEO, que é a otimização dos resultados dos mecanismos de busca em comparação com outros sites, discutir sobre o hardware do usuário é, em grande parte, irrelevante.

Por quê?

Na verdade, é bastante simples.

Pegue o caso de uma pessoa e seus resultados de busca em seu dispositivo portátil.

Independentemente da velocidade do dispositivo ou do chipset, o desempenho será semelhante em todos os sites, porque a experiência do usuário final (desempenho) de um único dispositivo do usuário na rede será a mesma, na maior parte dos casos, em todos os sites de desempenho similar. Sites mais rápidos serão mais rápidos e sites mais lentos serão mais lentos, independentemente do chipset, etc., do dispositivo do usuário final. Uma maré alta levanta todos os barcos e uma maré baixa afunda todos os barcos. No SEO, os dispositivos do usuário final são “ruído” como sinal de SEO em comparação com o aplicativo de serviço, que é o que é otimizado no “SEO”.

Portanto, se um telefone móvel for o mais rápido de todo o universo, todos os sites serão rápidos (ou lentos), dependendo da velocidade da rede e do design do site. O foco do SEO está na otimização do aplicativo web e na entrega desse aplicativo, não nos dispositivos do usuário final. Se um aplicativo web se comporta “incrivelmente bem” em um chipset, todos os outros sites de design similar também o fazem. O foco do SEO não é o dispositivo do usuário final; é a otimização do aplicativo web, do conteúdo, do tempo de carregamento com base no servidor; não no dispositivo do cliente. Os dispositivos do cliente visitam, em teoria, todos os sites, e tudo isso é “ruído” na relação sinal-ruído do SEO.

Do ponto de vista do SEO de um site, sua otimização para mecanismos de busca baseada na experiência do usuário será a mesma em toda a rede para todos os usuários da mesma classe (características de desempenho) de todos os dispositivos móveis do usuário final. A única coisa que dará a um site uma vantagem de SEO sobre outro site é o desempenho do site (e de sua rede), não dos dispositivos do usuário final.

Por quê?

Porque os dispositivos do usuário final terão o mesmo desempenho em todos os sites, de modo geral. Se o celular do usuário for lento devido à memória ou ao chipset, ele será lento em todo o ciberuniverso de sites. Em outras palavras, a discussão sobre como os dispositivos do usuário final afetam o SEO é inútil. A otimização para mecanismos de busca é uma operação do lado do servidor, não do lado do cliente.

O que importa é o conteúdo, a apresentação e o desempenho; e como a IA do Google avalia esses fatores em todo o ciberuniverso. Se, por exemplo, todas as pessoas do mundo inteiro atualizarem para telefones móveis com computação quântica, o SEO será o mesmo, porque todos os usuários finais terão as mesmas “curvas de desempenho do dispositivo do usuário final”. A otimização ocorre no provedor (o site). Da mesma forma, se todo o ciberuniverso degradar para telefones móveis com chipsets lentos, os rankings dos mecanismos de busca serão, em grande parte, os mesmos; porque a otimização que precisa acontecer ocorre pelos servidores que entregam o conteúdo da web.

Claro, o Discourse, sendo uma SPA (Single Page Application) impulsionada por JavaScript, terá um melhor desempenho após o carregamento se os celulares forem mais rápidos. O mesmo vale para todos os outros sites! Geralmente, é o desempenho da rede, bem como o desempenho do servidor, que importa, e não o dispositivo do usuário final, no que diz respeito ao SEO. Isso não é minha opinião; é um fato científico e de engenharia. Minha opinião ou conexão emocional com JavaScript ou EmberJS não altera como o SEO funciona. O que funciona para o SEO é o conteúdo e o desempenho do aplicativo web.

Para encerrar, o Google utiliza IA avançada, principalmente redes neurais artificiais, para determinar como classifica e indexa o conteúdo da web. A otimização para mecanismos de busca é baseada em como a IA do Google classifica o site, o desempenho do site e o “apelo do site à IA do Google”. O quanto amamos JavaScript, Ruby ou Python, ou o quanto gostamos ou adoramos a elegância e os mecanismos de qualquer aplicativo web que oferecemos aos usuários finais, não é relevante; a menos que nossa paixão pelo nosso aplicativo atraia a IA do Google e estejamos criando conteúdo único que seja bem apresentado à IA do Google e como a IA do Google percebe o desempenho; não como percebemos o desempenho e o conteúdo.

Nós não classificamos nossos próprios sites. A IA do Google faz a classificação.

Como o Google afirmou publicamente:

“Uma maneira de pensar sobre como uma atualização principal funciona é imaginar que você fez uma lista dos 100 melhores filmes de 2015. Alguns anos depois, em 2019, você atualiza a lista. Ela vai mudar naturalmente. Alguns filmes novos e maravilhosos que nunca existiram antes agora serão candidatos para inclusão. Você também pode reavaliar alguns filmes e perceber que mereciam um lugar mais alto na lista do que tinham antes. A lista vai mudar, e os filmes que estavam anteriormente mais altos na lista e que caíram não são ruins. Simplesmente há filmes mais merecedores que estão aparecendo antes deles”, escreveu o Google.

A empresa apresentou a seguinte lista de perguntas a considerar ao avaliar seu conteúdo:

  • O conteúdo fornece informações originais, reportagens, pesquisas ou análises?
  • O conteúdo fornece uma descrição substancial, completa ou abrangente do tópico?
  • O conteúdo fornece uma análise perspicaz ou informações interessantes que vão além do óbvio?
  • Se o conteúdo se baseia em outras fontes, ele evita simplesmente copiar ou reescrever essas fontes e, em vez disso, fornece valor adicional substancial e originalidade?
  • O título e/ou o título da página fornecem um resumo descritivo e útil do conteúdo?
  • O título e/ou o título da página evitam ser exagerados ou chocantes?
  • Este é o tipo de página que você gostaria de marcar como favorito, compartilhar com um amigo ou recomendar?
  • Você esperaria ver esse conteúdo em ou referido por uma revista impressa, enciclopédia ou livro?

Isso é SEO, e o negócio principal do Google é criar algoritmos para que máquinas possam classificar e classificar sites.

https://searchengineland.com/google-advice-on-improving-your-sites-ranking-for-future-core-ranking-update-320184

2 curtidas
113

Isso é inconsistente com os registros — sabemos que o Google está coletando tempos reais de carregamento de páginas a partir de dispositivos Android e utilizando esses dados para ranqueamento de páginas.

4 curtidas
114

Sim, mas todos os dispositivos Android (do mesmo tipo) performam basicamente da mesma forma em todos os sites web (do mesmo tipo). Ou seja, se você otimiza um site baseado em JavaScript que usa webpacker e bundler, você está competindo, do ponto de vista de SEO, com todos os outros sites que são SPAs em JavaScript usando webpacker e bundler, etc.

Eu não disse que o Google não está coletando essas informações. Estou tentando explicar que focar no dispositivo do cliente não vai resolver o problema de desempenho de SEO de SPAs. Uma “maré alta levanta todos os barcos”, então um CPU mais rápido que processa JS comprimido bem (rápido, otimizado, etc.) terá bom desempenho em todos os sites web similares.

Ou seja, o SEO está no lado do servidor (como escrevi com bastante tempo e detalhe acima), não no lado do cliente.

Isso é bem documentado, aliás.

Deixa pra lá :). Prefiro não debater isso aqui no meta. Obrigado.

O Google tem sido bastante claro sobre o que considera sinais importantes de SEO, agora e até 2021. Eles vão constantemente redesenhar sua IA, com base em eventos e situações no ciberespaço.

2 curtidas
115

Do ponto de vista de SEO, você realmente está competindo com sites tecnicamente semelhantes.

Mas do ponto de vista de negócios, você está competindo com outros sites do seu mercado, independentemente da tecnologia deles. E isso pode levar as pessoas a considerar mudar para uma tecnologia percebida como “melhor” do ponto de vista de SEO. E é essa a situação em que algumas pessoas estão.

5 curtidas