Os resultados de uma experiência de renderização e indexação de JavaScript destacam alguns desafios da execução de conteúdo dependente de JS.
Recentemente, li o fascinante artigo de Ziemek Bucko, Rendering Queue: Google Needs 9X More Time To Crawl JS Than HTML, no blog Onely.
Bucko descreveu um teste que eles fizeram mostrando atrasos significativos do Googlebot seguindo links em páginas dependentes de JavaScript em comparação com links em HTML de texto simples.
Embora não seja uma boa ideia confiar em apenas um teste como este, a experiência deles coincide com a minha. Já vi e dei suporte a muitos sites que dependem muito de JavaScript (JS) para funcionar corretamente. Espero não estar sozinho a esse respeito.
Minha experiência é que o conteúdo somente em JavaScript pode demorar mais para ser indexado em comparação com o HTML simples.
Lembro-me de vários casos em que recebi telefonemas e e-mails de clientes frustrados perguntando por que seus produtos não apareciam nos resultados de pesquisa.
Em todos os casos, exceto um, o desafio parecia ser porque as páginas foram construídas em uma plataforma somente JS ou principalmente JS.
Antes de prosseguirmos, quero esclarecer que este não é um “hit piece” em JavaScript. JS é uma ferramenta valiosa.
Como qualquer ferramenta, no entanto, é melhor usado para tarefas que outras ferramentas não podem fazer. Não sou contra JS. Sou contra usá-lo onde não faz sentido.
Mas há outras razões para considerar criteriosamente o uso de JS em vez de depender dele para tudo.
Aqui estão alguns contos de minha experiência para ilustrar alguns deles.
1. Texto? Que texto?!
Um site que eu apoiei foi relançado com um design totalmente novo em uma plataforma que dependia muito de JavaScript.
Uma semana após o lançamento do novo site, o tráfego de busca orgânica caiu para quase zero, causando um pânico compreensível entre os clientes.
Uma rápida investigação revelou que além do site ser consideravelmente mais lento (veja os próximos contos), o teste de página ao vivo do Google mostrou que as páginas estavam em branco.
Minha equipe fez uma avaliação e concluiu que o Google levaria algum tempo para renderizar as páginas. Depois de mais 2-3 semanas, porém, ficou claro que algo mais estava acontecendo.
Eu me encontrei com o principal desenvolvedor do site para entender o que estava acontecendo. Como parte de nossa conversa, eles compartilharam sua tela para me mostrar o que estava acontecendo no back-end.
É quando o “aha!” momento atingido. À medida que o desenvolvedor percorreu o código linha por linha em seu console, notei que o texto de cada página estava sendo carregado fora da viewport usando uma linha de CSS, mas foi puxado para o quadro visível por algum JS.
A intenção era criar um efeito de animação divertido, no qual o conteúdo do texto “deslizava” para a visualização. No entanto, como a página foi renderizada tão lentamente no navegador, o texto já estava visível quando o conteúdo da página foi finalmente exibido.
O efeito slide-in real não era visível para os usuários. Achei que o Google não conseguiu detectar o efeito slide-in e não viu o conteúdo.
Depois que esse efeito foi removido e o site foi rastreado novamente, os números de tráfego começaram a se recuperar.
2. É muito lento
Isso poderia ser vários contos, mas vou resumir vários em um. Plataformas JS como AngularJS e React são fantásticas para aplicativos de desenvolvimento rápido, incluindo sites.
Eles são adequados para sites que precisam de conteúdo dinâmico. O desafio surge quando os sites têm muito conteúdo estático que é direcionado dinamicamente.
Várias páginas em um site que avaliei obtiveram pontuações muito baixas na ferramenta PageSpeed Insights (PSI) do Google.
Ao pesquisar usando o relatório de cobertura nas ferramentas do desenvolvedor do Chrome nessas páginas, descobri que 90% do JavaScript baixado não foi usado, representando mais de 1 MB de código.
Quando você examina isso do lado do Core Web Vitals, isso representa quase 8 segundos de tempo de bloqueio, pois todo o código deve ser baixado e executado no navegador.
Conversando com a equipe de desenvolvimento, eles apontaram que, se carregarem antecipadamente todo o JavaScript e CSS que serão necessários no site, isso tornará as visitas subsequentes à página muito mais rápidas para os visitantes, pois o código estará nos caches do navegador. .
Embora o ex-desenvolvedor em mim concordasse com esse conceito, o SEO em mim não podia aceitar como a aparente percepção negativa do Google sobre a experiência do usuário do site provavelmente degradaria o tráfego da pesquisa orgânica.
Infelizmente, na minha experiência, o SEO geralmente perde para a falta de desejo de mudar as coisas depois de lançadas.
3. Este é o site mais lento de todos!
Semelhante ao conto anterior, vem um site que analisei recentemente que pontuou zero no PSI do Google. Até então, eu nunca tinha visto um placar zero antes. Muitos dois, três e um, mas nunca um zero.
Vou dar três suposições sobre o que aconteceu com o tráfego e as conversões daquele site, e as duas primeiras não contam!
Às vezes, é mais do que apenas JavaScript
Para ser justo, CSS excessivo, imagens muito maiores do que o necessário e fundos de vídeo de reprodução automática também podem diminuir o tempo de download e causar problemas de indexação.
Então, o que o SEO deve fazer nessas situações?
Soluções para problemas como esse envolvem estreita colaboração entre SEO, desenvolvimento e cliente ou outras equipes de negócios.
Construir uma coalizão pode ser delicado e envolve dar e receber. Como praticante de SEO, você deve descobrir onde os compromissos podem e não podem ser feitos e agir de acordo.
Comece do começo
É melhor construir SEO em um site desde o início. Depois que um site é lançado, alterá-lo ou atualizá-lo para atender aos requisitos de SEO é muito mais complicado e caro.
Trabalhe para se envolver no processo de desenvolvimento do site desde o início, quando os requisitos, especificações e metas de negócios são definidos.
Tente obter bots de mecanismo de pesquisa como histórias de usuários no início do processo, para que as equipes possam entender suas peculiaridades exclusivas para ajudar a indexar o conteúdo indexado de maneira rápida e eficiente.
Seja um professor
Parte do processo é a educação. As equipes de desenvolvedores geralmente precisam ser informadas sobre a importância do SEO, então você precisa informá-las.
Deixe seu ego de lado e tente ver as coisas da perspectiva dos outros times.
Ajude-os a aprender a importância de implementar as melhores práticas de SEO enquanto entende suas necessidades e encontra um bom equilíbrio entre elas.
Às vezes é útil realizar uma sessão de almoço e aprendizado e trazer um pouco de comida. Dividir uma refeição durante as discussões ajuda a derrubar barreiras – e também não prejudica nem um pouco como um suborno.
Algumas das discussões mais produtivas que tive com equipes de desenvolvedores foram sobre algumas fatias de pizza.
Para sites existentes, seja criativo
Você terá que ser mais criativo se um site já foi lançado.
Freqüentemente, as equipes de desenvolvedores passaram para outros projetos e podem não ter tempo para voltar e “consertar” coisas que estão funcionando de acordo com os requisitos que receberam.
Também há uma boa chance de que os clientes ou proprietários de empresas não queiram investir mais dinheiro em outro projeto de site. Isso é especialmente verdadeiro se o site em questão foi lançado recentemente.
Uma solução possível é a renderização do lado do servidor. Isso descarrega o trabalho do lado do cliente e pode acelerar significativamente as coisas.
Uma variação disso é combinar a renderização do lado do servidor com o cache do conteúdo HTML de texto simples. Esta pode ser uma solução eficaz para conteúdo estático ou semi-estático.
Ele também economiza muita sobrecarga no lado do servidor porque as páginas são renderizadas somente quando as alterações são feitas ou em uma programação regular, em vez de cada vez que o conteúdo é solicitado.
Outras alternativas que podem ajudar, mas não resolver totalmente os desafios de velocidade, são a minificação e a compactação.
A minificação remove os espaços vazios entre os caracteres, tornando os arquivos menores. A compactação GZIP pode ser usada para arquivos JS e CSS baixados.
Minificação e compactação não resolvem os desafios de tempo de bloqueio. Mas, pelo menos, eles reduzem o tempo necessário para baixar os arquivos.
Google e indexação JavaScript: O que dá?
Por muito tempo, acreditei que pelo menos parte do motivo pelo qual o Google era mais lento na indexação de conteúdo JS era o custo mais alto de processá-lo.
Parecia lógico com base na maneira como ouvi isso descrito:
- Uma primeira passagem pegou todo o texto simples.
- Uma segunda passagem foi necessária para capturar, processar e renderizar JS.
Concluí que a segunda etapa exigiria mais largura de banda e tempo de processamento.
Perguntei a John Mueller do Google no Twitter se essa era uma suposição justa e ele deu uma resposta interessante.
Pelo que ele vê, as páginas JS não são um grande fator de custo. O que custa caro aos olhos do Google é manter páginas que nunca são atualizadas.
No final, o fator mais importante para eles foi a relevância e utilidade do conteúdo.