Gaming Google — A pontuação perfeita para um farol

Sempre hesitei em compartilhar meu código. Não é que eu acredite que esteja abaixo da média, nem sou atormentado pela síndrome do impostor. Só que compartilhar código oferece um vislumbre da loucura que é minha mente, e isso parece um tanto cruel para todos os outros. Permita-me guiá-lo em uma jornada que quase me levou à beira da sanidade. Tudo começou com a atualização do Google Lighthouse.

Para os não iniciados em SEO, a atualização Lighthouse do Google representou uma mudança substancial no ranking de busca, dependendo do desempenho de um site e da adesão às melhores práticas. Se você quiser testar seu site, basta abri-lo no Chrome em um desktop, pressionar F12 para abrir as ferramentas de desenvolvedor do Chrome e clicar na guia “Farol”. Escolha Desktop ou Mobile e clique em “Analisar”. Após cerca de um minuto, você receberá cinco pontuações, cada uma variando de 0 a 100, para desempenho, acessibilidade, melhores práticas, SEO e Progressive Web App (PWA).

Antes de me aprofundar nos detalhes técnicos, deixe-me me apresentar. Meu nome é Jonathan Grantham e sou o orgulhoso proprietário de uma pequena empresa B2B SaaS, a Nexoid, especializada em software ERP e ITSM. O site que estou discutindo neste artigo é www.nexoid.com. Sinta-se à vontade para dar uma olhada e abrir o código-fonte. Você também pode me seguir no LinkedIn. Meu perfil é www.linkedin.com/in/jonathongrantham/

Após o lançamento da atualização do Google Chrome Lighthouse, fiz o que qualquer empresário consciente faria: verifiquei meu site. Para minha consternação, os resultados estavam longe de ser satisfatórios. Com pontuações de 21/100 para desempenho, 30/100 para acessibilidade, 45/100 para melhores práticas, 11/100 para SEO e uma falha para PWA, fiquei chocado. Eu construí pessoalmente o site, uma arquitetura de página única bastante padrão usando o React.js. O placar foi um golpe esmagador.

Sem me deixar abater pelo revés inicial, lancei o MS Code e comecei a resolver os problemas um por um, com o desempenho sendo meu primeiro alvo. Os guias fornecidos na ferramenta Lighthouse se mostraram bastante úteis. Converti todas as imagens de JPEGs e PNGs em arquivos WebP modernos e assegurei que cada tag img fosse equipada com uma propriedade de largura e comprimento para evitar mudanças no layout. Somente essas modificações aumentaram minha pontuação de 21/100 para 60/100. Foi uma melhoria significativa, mas está longe de ser perfeita. A única sugestão restante foi “reduzir o JavaScript não utilizado”, o que não foi particularmente útil. O único JavaScript presente era a estrutura React.js, pois todo o resto havia sido eliminado.

Com a Nexoid, a AM Digital também conseguiu estender os benefícios de uma solução de ITSM unificada para suas operações voltadas para o cliente. O portal do cliente, integrado ao Azure, ofereceu uma experiência mais conectada, dinâmica e perfeita para seus clientes, resultando em maior satisfação e engajamento do cliente. O portal permitiu a sincronização em tempo real com os dados do cliente, garantindo que todas as informações fossem atualizadas e precisas, aprimorando a prestação de serviços e fortalecendo o relacionamento cliente-empresa.

Apesar dos meus esforços persistentes para corrigir o problema, me deparei com obstáculos constantes. Tentei remover partes do React.js, explorei o “carregamento lento” e testei vários otimizadores e compressões. No entanto, o problema surgiu do próprio React.js, que tinha aproximadamente meio megabyte de tamanho.

Quase consigo ouvir desenvolvedores web experientes gritando: “Não use o React para um site! É destinado à criação de aplicativos web!” Estou bem ciente disso agora.

O que começou como uma tarefa aparentemente simples de converter algumas imagens agora se transformou em uma revisão completa do site usando uma nova estrutura. Frustrada e proferindo algumas palavras bem escolhidas, parti em busca de um substituto adequado. Primeiro considerei o Vue e depois o Angular, sem dúvida os maiores concorrentes do React.js. No entanto, ambos apresentaram o mesmo problema.

Na tentativa de simplificar as coisas, decidi pesquisar tecnologias mais antigas e experimentei o jQuery. No entanto, me deparei com o mesmo problema. Ficou claro que não havia uma estrutura de arquitetura de página única pronta para uso que pudesse apaziguar as divindades do Google.

Parecia que minha única opção restante era recorrer ao JavaScript básico.

Minha série de experimentos começou com uma página HTML básica sem JavaScript. Em seguida, tentei uma página HTML com uma div cujo conteúdo poderia ser substituído. Eu rapidamente percebi que fazer várias alterações simultâneas na página via JavaScript incorria em penalidades do Lighthouse. A solução foi manipular o conteúdo da tag body como uma string e depois reintegrá-la, criando assim apenas uma única alteração visível no DOM.

Agora eu tinha uma página HTML minimalista com uma tag de corpo vazia, complementada por uma pequena função onload na tag head. Essa função inspecionou o URL e executou uma solicitação HTML GET para recuperar o arquivo de texto correspondente contendo o HTML do corpo da página. Alguém poderia pensar que essa é uma solução adequada. Infelizmente, falhou quando tentei carregar dinamicamente a funcionalidade JavaScript.

Diferentemente de outras tags, se você adicionar uma tag de script com um simples alerta (“sim, foi acionada”) na string de conteúdo do corpo, ela não será executada. Embora não fosse a ideal, uma solução alternativa era analisar a string do corpo, identificar todo o conteúdo da tag de script e colocá-lo em uma função de avaliação de JavaScript. A abordagem foi um pouco eficaz, mas falhou ao lidar com namespaces, e o console do desenvolvedor foi inundado com avisos desagradáveis. A solução foi extrair as tags de script do HTML e adicioná-las como um elemento de script após a renderização do DOM. O Google não penalizou essa ação por algum motivo.

O progresso estava sendo feito e eu tinha uma solução básica de arquitetura de página única. Mas não tão rápido. Embora o Google seja eficiente na indexação de páginas de arquitetura de página única (eles fazem isso abrindo-as em um navegador, permitindo que todo o JavaScript seja executado e, em seguida, escaneando o DOM), o Bing, o Yahoo e outros grandes mecanismos de pesquisa usam um método semelhante e mais simples. No entanto, a maioria das outras plataformas, como Facebook, Reddit, LinkedIn e WhatsApp, buscam apenas o arquivo HTML, recuperando um pequeno arquivo HTML com um corpo em branco. Minha solução não era viável. Agora eu tinha que replicar esse conceito para todas as páginas do site e incluir o JavaScript para mudar para o modo de arquitetura de página única quando um usuário clicava em um link.

Eu precisava de uma ferramenta capaz de gerar HTML para cada página, com base na minha solução. Ocorreu-me que eu tinha o recurso perfeito à minha disposição: meu próprio sistema ERP, o Nexoid. Eu criei um modelo Nexoid abrangendo objetos de dados de um site e de uma página da web. O registro do site facilitou a criação de um modelo genérico de página da web, enquanto os registros da página da web continham o conteúdo de cada página individual. A peça final do quebra-cabeça era uma função ou script de fluxo de trabalho que podia ler o registro do site e todos os registros da página da web relacionados para gerar os arquivos HTML. Depois de alguns dias, estava operacional. Eu criei um Sistema de Gerenciamento de Conteúdo (CMS) básico. Desenvolver um CMS até esse ponto não é muito complexo; o verdadeiro desafio surge ao integrar outros fluxos de trabalho, aprovações, localizações, visualizações, etc.

Um requisito fundamental para o novo site era a localização; nosso objetivo era lançá-lo em 11 idiomas. Sendo uma empresa de TI, naturalmente me inclinei para soluções tecnológicas. Em vez de contratar um tradutor para cada página, optei pelo AWS Translate. Embora os tradutores de IA sejam decentes, eles não são perfeitos e os erros são perceptíveis o suficiente para revelar uma origem não humana. Um funcionário que falava francês avaliou a tradução da IA e atribuiu-lhe uma nota 6/10, descrevendo-a como “compreensível, mas não em francês adequado”.

No entanto, nos deparamos com um truque valioso. Descobrimos que alimentar o texto em inglês por meio do ChatGPT primeiro, pedindo que ele “arrume isso” e depois colando-o, ele reformula o texto de uma forma que ainda é em inglês, mas é muito mais compatível com os modelos de idioma. Usar o inglês reformulado pelo ChatGPT como base para a tradução melhora significativamente a qualidade da tradução, elevando-a para 9 ou até mesmo 10 de 10.

Tendo desenvolvido uma base tecnológica sólida para criar o site, eu estava progredindo. No entanto, um novo desafio surgiu quando começamos a criar páginas mais complexas. De acordo com as novas diretrizes do Lighthouse, tornou-se necessário consolidar todo o JavaScript, CSS e HTML em um único arquivo. Isso também se aplica às versões da arquitetura de página única.

Recorremos à inserção de todos os arquivos JavaScript e CSS como tags embutidas. Uma estratégia semelhante foi necessária para a versão Single Page Architecture. Criamos um arquivo JSON contendo todos os scripts, estilos e HTML.

O Lighthouse identificou o próximo problema como o tamanho dos ativos; os arquivos de página HTML e JSON eram excessivamente grandes. Resolvi esse problema usando 'minify', uma biblioteca Node.js projetada especificamente para compactar arquivos HTML, CSS e JavaScript. Essa solução resultou em uma redução do tamanho do arquivo de texto em mais de 40%. Além disso, o minify ofereceu o benefício adicional de ofuscação, tornando o código bruto mais difícil de ler, aumentando a segurança.

Vamos nos aprofundar no tópico da hospedagem. Tradicionalmente, um Sistema de Gerenciamento de Conteúdo (CMS) opera por meio de um servidor de aplicativos que processa a solicitação HTML do usuário. Ele interpreta a solicitação de página do URL, localiza os ativos correspondentes em um banco de dados, recupera o registro do banco de dados (possivelmente junto com outros), processa as informações para montar a página e, finalmente, as entrega ao usuário final como um documento HTML simples. Essa descrição se refere principalmente à solicitação inicial de HTML quando um usuário visita um novo site, embora eu conheça o AJAX e outras tecnologias similares.

No entanto, esse modelo convencional apresenta algumas desvantagens no contexto do novo mundo do Lighthouse. Em primeiro lugar, a comunicação de ida e volta entre o servidor de aplicativos e o servidor de banco de dados, bem como a compilação de páginas, introduz atrasos. Em segundo lugar, em sua forma mais simples, um servidor de aplicativos e um servidor de banco de dados só estão disponíveis fisicamente em um único local. Essa configuração é excelente se você estiver no mesmo prédio ou cidade, mas significativamente menos eficiente se estiver tentando acessar o site do outro lado do mundo. Por exemplo, a latência média de ping entre a Austrália e o Reino Unido é de aproximadamente 250 milissegundos.

Nossa solução para esses desafios envolve a utilização do AWS S3 para hospedar os arquivos estáticos gerados pelo script de publicação mencionado anteriormente e do AWS CloudFront para distribuição global de conteúdo. No momento em que este artigo foi escrito, o AWS CloudFront estava distribuindo conteúdo para mais de 90 cidades em 47 países. Para um indivíduo em Melbourne, Austrália, acessando um site do Reino Unido, o AWS CloudFront reduziu a latência de ping de 250 milissegundos para meros 13 milissegundos (essa é a diferença horária entre Melbourne e os servidores de borda da AWS em Sydney).

Agora chegamos ao componente Progressive Web Application (PWA) do teste Lighthouse, que não era algo que eu havia considerado muito antes. Para quem não conhece, um PWA envolve um trabalhador de serviços JavaScript que gerencia o site como um aplicativo web. Se isso for um pouco complexo, considere o seguinte: é essencialmente uma ferramenta automática de download e armazenamento em cache. Quando um usuário visita seu site, o objetivo é fazer com que as solicitações subsequentes sejam o mais rápidas e perfeitas possível. O service worker do PWA permite que você já tenha os próximos ativos baixados na máquina local do usuário, eliminando a necessidade de outra solicitação GET pela Internet.

No momento da redação deste artigo, o site da Nexoid era relativamente pequeno, contendo apenas 19 páginas. No entanto, essas 19 páginas são traduzidas para 11 idiomas diferentes, perfazendo um total de 209 páginas. Inicialmente, tentei baixar todos os ativos para o service worker, o que totalizou cerca de 5 MB. Esse tamanho era muito grande para uma carga inicial, e Lighthouse me penalizou por isso. Decidi baixar apenas os arquivos JSON da página em inglês, que incluem todo o CSS, HTML e JavaScript necessários para exibir cada página.

A estrutura final é a seguinte: um bucket do S3 abriga os arquivos HTML compilados, nomeados sem a extensão.html. Por exemplo, www.nexoid.com/en representa o HTML da página inicial em inglês, www.nexoid.com/de é para o HTML da página inicial alemã e www.nexoid.com/en/platform se refere ao HTML da plataforma em inglês e assim por diante. Além disso, existem arquivos JSON que contêm as partes do corpo e da cabeça que mudam ao navegar entre as páginas, como https://www.nexoid.com/en.json, https://www.nexoid.com/de.json e https://www.nexoid.com/en/platform.json, entre outros.

Concluindo, compreender o Lighthouse representou um desafio significativo. Não acredito que os produtos CMS tradicionais e prontos para uso possam lidar com essa tarefa com eficácia. Refletindo sobre minha experiência com plataformas como WordPress e Drupal, acho difícil acreditar que elas possam ser otimizadas para obter uma pontuação perfeita no Lighthouse. No geral, acredito que o esforço vale a pena e o Google tem razão em dar mais ênfase ao desempenho. No entanto, essa mudança é e continuará sendo um problema considerável para web designers e agências.

Se você estiver interessado em aprender mais sobre a Lighthouse ou se quiser discutir os produtos e serviços da Nexoid, não hesite em entrar em contato. Você pode entrar em contato pelo LinkedIn ou pela página “Fale conosco” em nosso site.