Como ter um site nota 100

Quem publica um site na Internet com certeza tem algumas expectativas sobre ele. É muito provável que uma delas, na maioria dos casos, é ser "bem visto" pelos usuários que acessarem o conteúdo e pelos buscadores (ao menos o melhor possível).

Isso depende de muitas variáveis, mas poucas pessoas compreendem isso. As mais óbvias e importantes são a quantidade, qualidade e relevância do conteúdo publicado, como também o segmento e a autoridade do site no assunto.

Mas, como essas variáveis são muito variáveis (e estão fora do escopo da minha especialidade), neste artigo eu venho explorar pontos mais técnicos, envolvendo a forma como um site é desenvolvido, publicado na Internet, seu funcionamento e a performance de entrega do conteúdo no momento do acesso às páginas.

Site nota 100!? E quem dá notas aos sites?

Os pontos aqui são relacionados à qualidade do código e à performance do site, de acordo com as métricas das ferramentas de avaliação mais relevantes e que são desenvolvidas pela Google: o Lighthouse e o PageSpeed Insights.

As métricas avaliadas são: Desempenho, Acessibilidade, Práticas Recomendadas e SEO. Elas analisam características do código e do carregamento das páginas de um site e cada métrica tem uma pontuação que vai de 0 a 100.

As ferramentas citadas acima são usadas pelo robô de indexação de buscas do Google para avaliar os sites e dar a eles uma pontuação técnica que pode influenciar seu ranking.

Por isso, a performance e a qualidade do código de um site são importantes para ele ser "bem visto" pelos buscadores e, segundo informações de pesquisas a respeito, pelos usuários que acessam o conteúdo também. Na veradade, a pontuação dessas métricas foi criada com base nessas pesquisas a respeito de como os usuários reagem a páginas com diferentes performances.

Então, vamos falar um pouco sobre o que pode influenciar a métrica de Desempenho.

Desempenho

Esta é a métrica que torna mais difícil alcançar a pontuação máxima por um motivo muito simples: ela se baseia na velocidade de carregamento da página.

E não adianta pensar nisso tendo em mente a Internet banda larga de fibra ótica que você tem em casa ou no trabalho, porque o Google toma como base a velocidade média da Internet móvel 3G/4G. Os testes feitos pelo PageSpeed Insights emulam o acesso com dispositivos móveis por padrão.

Sendo assim, cada byte e cada milisegundo aqui contam. Desde o tamanho dos arquivos que compõem a página até o tempo de resposta do servidor onde ela está hospedada.

Claro que isso pode envolver muitos detalhes, mas vamos tentar resumir alguns importantes.

HTML/CSS/JS/...

Provavelmente os pontos mais básicos aqui já devem ser observados por muitos devs, mas nem sempre, visto ser muito comum que a maioria dos devs apenas confia nos recursos de um framework e não se importa muito com detalhes.

Por exemplo, minificar CSS e JS é um recurso básico já pronto em muitos frameworks, mas e o HTML? Alguém se importa em minificar HTML? E lembre-se que quanto mais conteúdo na página, maior será o HTML, com muito mais tags, geralmente publicado mesmo em produção com muitos espaços e indentação, enviando bytes desnecessários na resposta da requisição.

E mesmo a minificação de CSS e JS geralmente não é tratada com muito cuidado. Frameworks fazem apenas o básico, mas se o desenvolvedor não seguir boas práticas para evitar "compilação" de código extra e desnecessário, muita coisa inútil vai encher o código.

Nesse quesito, infelizmente os frameworks frontend estão fadados a perder pontos, pois eles não podem isolar somente o código necesário para a entrega de uma página específica, toda a base de funcionalidades do framework (e outras coisas, dependendo de como o dev faz o código) sempre carregarão junto com qualquer página.

E quem gosta de usar frameworks CSS como Bootstrap, por exemplo, também terá uma biblioteca inteira de estilos carregados em uma página que provavelmente não usa nem a metade.

De fato, um dos avisos mais comuns nas ferramentas de análise é exatamente sobre CSS e JS desnecessários carregando junto com a página. Algumas ideias para otimizar um pouco este ponto podem ser encontradas no meu artigo: Como otimizar a performance de aplicações web frontend.

Resposta do servidor

Este também é um problema para a maioria dos sites na Internet. E há dois motivos principais para isso:

1 - A maioria dos sites está hospedado em uma infraestrutura pronta sobre a qual não se tem muito controle para configurar

Quem quer gerenciar infraestrutura para hospedagem de sites hoje em dia? Quase ninguém, nem eu! Hospedamos o site em algum serviço que nos parece bom e confiável o suficiente e o resto é com eles.

Podemos tentar escolher a melhor opção possível para as nossas necessidades, talvez um serviço em nuvem como os mais famosos já conhecidos ou alguma alternativa que faça mais sentido ou que talvez ofereça algumas opções de otimização.

Mas já adianto (e talvez nem precise dizer) que hospedagem compartilhada e barata pode ser uma escolha ruim.

Aliás, ironicamente, existem hospedagens em nuvem de alto nível que são incomparavelmente melhores em qualidade e performance e que são gratuitas. Inclusive já escrevi algo sobre isso: Melhores hospedagens gratuitas para sites JAMstack.

Então, escolha bem onde (ou como) hospeda o seu site!

2 - Muitos sites são desenvolvidos com programação backend para SSR (Server Side Render)

Se você não sabe o que significa SSR, resumo: as páginas do site são processadas e construídas dinamicamente no servidor por uma linguagem de programação no exato momento em que o usuário acessa cada página do site.

Sim, isso afeta diretamente a performance do site e é uma péssima notícia para quem tem um site feito com Wordpress, Squarespace, Wix ou qualquer outra plataforma pronta para criação de sites, coisa muito comum por aí na Internet.

Mais do que isso... É também uma má notícia para quem desenvolve um site usando frameworks modernos como Next.js, Nuxt, Svelte Kit, Angular Universal, etc... e fica totalmente empolgado com o SSR, que é tão falado atualmente como se fosse uma super novidade revolucionária, mas é apenas uma releitura do que praticamente todos os sites dinâmicos sempre foram usando frameworks de backend MVC.

E ainda que seu site seja desenvolvido completamente personalizado, usando alguma linguagem de programação de backend, com algum framework de alto nível (ou sem, tanto faz) e hospedado em algum serviço em nuvem... Ainda assim, perderá pontos de performance.

Isso acontece porque as páginas do site não estão realmente "prontas" para acesso, elas precisam ser processadas pelo servidor no momento exato em que são acessadas. É como se elas não existissem de verdade, são dados virtualmente preparados para uma página web que é "criada" apenas no momento que alguém acessa o seu endereço.

Esse inevitável tempo de processamento para a entrega do conteúdo impede a maioria dos sites na Internet de ter uma boa pontuação de performance. Inclusive os mais famosos sites de notícias que você provavelmente conhece.

E, se isso for combinado com o ponto anterior, uma resposta lenta do servidor pode prejudicar muito mais a performance. É o que geralmente ocorre com as plataformas prontas já citadas e as hospedagens compartilhadas.

Então, como alcançar essa nota 100?

Há muitos detalhes que poderiam ser observados para montar um cenário ideal, mas vou comentar aqui a única opção que realmente parece ser mais eficaz e mais aplicável na prática: site estático.

Sim, ter as páginas HTML e todos os arquivos já prontos para serem servidos diretamente em seu formato final, para simplesmente serem carregados rapidamente, sem necessidade de processamento... Essa é provavelmente a única maneira de alcançar o máximo de performance.

Digo isso não apenas como uma suposição, mas após muitos testes e comparações em diferentes projetos, arquiteturas e hospedagens, inclusive criando várias versões deste mesmo site, onde você está lendo isso agora.

Além disso, essa é a ideia mais difundida nas comunindades JAMstack pela Internet e que deu força ao conceito dos frameworks SSG (Static Site Generators).

Mas é possível transformar qualquer site dinâmico em estático?

Isso depende de muitas variáveis, mas acredito que talvez seja possível para a grande maioria. Mais uma vez, digo isso de acordo com a minha experiência, mas também ressalto que isso pode exigir uma arquitetura de solução bastante engenhosa.

A maioria dos sites dinâmicos não necessitam realmente de ter as páginas processadas novamente a cada acesso dos usuários. Na verdade eles apenas dependem de um backend de dados que alimentam o conteúdo das páginas dinamicamente, mas que uma vez criadas dificilmente mudarão de novo.

Portanto, poderíamos pensar nisso como uma arquitetura "híbrida", onde temos um backend dinâmico que gerencia os dados para as páginas e uma outra camada que obtém esses dados sempre que necessário e processa a criação das páginas HTML estáticas para serem publicadas prontas para acesso.

Ok, isso ainda pode parecer inviável para alguns casos. Então o que fazer para ao menos melhorar a pontuação o máximo possível?

O melhor a fazer é analisar o site com as ferramentas citadas e conferir os pontos de alerta. Eles geralmente estão acompanhados de um link para documentações no Google a respeito. Compreendendo os detalhes e fazendo os ajustes necessários, pode-se melhorar a pontuação e talvez até o seu ranking nos resultados de pesquisa.

Você pode começar por aqui: Measure page quality (web.dev)