100 pontos no PageSpeed: o que mudámos para lá chegar

O valor de partida era 58 em 100 no telemóvel. Não é um valor mau para um site com efeito 3D no cabeçalho, mas é um valor que a Google penaliza de forma percetível na pesquisa móvel. No fim ficaram 100 pontos no computador e 98 no telemóvel, com igualmente 100 para acessibilidade.

O que se segue não é uma lista de verificação genérica, é o percurso real – incluindo os sítios em que nos enganámos.

O ponto de partida

As cinco intervenções que realmente contaram

1. Substituir a biblioteca, não otimizá-la

O cabeçalho mostra uma nuvem de partículas em 3D. Para isso corria uma biblioteca gráfica conhecida – 458 KB depois de reduzida. A medição indicava que 51 KB dela nunca chegavam sequer a ser executados.

O olhar decisivo foi a pergunta sobre quanto precisávamos de facto. Eram onze blocos: renderizador, cena, câmara, geometria, material e algumas classes auxiliares. Tudo isso se pode programar diretamente contra a interface gráfica do navegador.

Resultado: 458 KB passaram a 6 KB. A apresentação é idêntica – mantivemos os mesmos shaders.

2. A compressão estava só meio ligada

Na configuração do servidor a compressão estava «ligada» – mas a linha que indica que tipos de ficheiro devem ser comprimidos estava comentada. É a predefinição de muitas distribuições. Resultado: só o HTML era comprimido.

A biblioteca gráfica seguia portanto sem compressão pela linha. Depois de ligada: 1243 KB passaram a 251 KB. Além disso, guardamos agora as versões comprimidas já calculadas ao lado, para o servidor não ter de calcular de novo a cada pedido.

Esforço: duas linhas de configuração. Efeito: quase um megabyte por primeiro acesso.

3. Remover por completo a biblioteca de animação

Para as aparições durante o scroll corria outra biblioteca, 114 KB. A medição apontava-a ainda como causadora de recálculos forçados de layout – consultava a geometria durante o scroll e obrigava o navegador a recalcular o layout a meio do movimento.

Substituída por um IntersectionObserver que se limita a colocar uma classe. O movimento em si é feito pelo CSS. Menos 114 KB, sem recálculos, cerca de 40 linhas de código próprio.

4. O favicon tinha 205 KB

Uma pequenez com efeito surpreendente, porque é carregada muito cedo. Substituído por um ficheiro SVG de 6 KB, gerado a partir do logótipo existente.

5. Consultar a geometria dentro do frame de animação

Um script lia a altura total do documento em cada evento de scroll. Essa propriedade o navegador não consegue responder de memória – tem de recalcular o layout de toda a página, a meio do scroll.

A regra que daí resulta e que vale em toda a parte: ler no evento, escrever no frame seguinte. Nunca ao contrário. Desde então a altura da página é medida uma vez e guardada, em vez de ser consultada sessenta vezes por segundo.

O erro que custou 24 pontos

O que rendeu pouco

Por uma questão de rigor, as medidas que constam de todos os guias e que, no nosso caso, mal foram mensuráveis:

Formatos de imagem. A nossa página inicial quase não tem imagens – o logótipo é um ficheiro SVG. Onde há imagens, a conversão compensa evidentemente; como alavanca principal só serve em páginas com muitas imagens.

Reduzir mais as fontes. Alojamos nós próprios duas famílias tipográficas e pré-carregamos as necessárias à área visível. Mais otimização seria possível, mas não move o valor.

Localização do servidor. Muito recomendada, no nosso caso irrelevante: o tempo até ao primeiro byte já era de 20 milissegundos. Quem já está bem aí não ganha nada com uma rede de distribuição.

O procedimento para repetir

1. Medir antes de mudar seja o que for. Móvel e computador em separado, anotando os valores.
2. Procurar o maior ficheiro transferido. É quase sempre JavaScript. A questão não é como reduzi-lo, é se é preciso.
3. Verificar a compressão. Não se está ligada, mas para que tipos de ficheiro.
4. Contar os pedidos bloqueantes. Cada folha de estilos no cabeçalho atrasa a primeira renderização.
5. Verificar saltos de layout sem travagem. O teste que nos faltou.
6. Medir de novo depois de cada alteração. Senão, no fim não se sabe o que fez efeito.

Ajuda-me a traduzir o relatório de PageSpeed da minha página numa
sequência de prioridades. Sê rigoroso; não elogies nada.

As minhas medições:
- Móvel: [pontuação], computador: [pontuação]
- LCP, TBT, CLS por dispositivo: [valores]
- Maiores ficheiros transferidos com tamanho: [lista]
- Pedidos que bloqueiam a renderização: [lista]
- Avisos do relatório: [colar texto]

Sobre a página:
- Como está construída: [CMS / estática / construtor]
- O JavaScript é preciso para o conteúdo visível? [sim/não]
- Como é entregue o CSS? [externo / em linha / parcialmente]

Tarefas:
1. Atribui cada aviso a uma causa e diz que métrica ele afeta –
   LCP, TBT ou CLS.
2. Ordena as medidas por efeito face ao esforço. Indica em cada
   uma quantos pontos move de forma realista e porquê.
3. Indica as medidas do relatório que, com a minha forma de
   construção, praticamente não rendem nada – e fundamenta, em
   vez de as omitires.
4. Em cada ficheiro JavaScript grande, pergunta primeiro se ele é
   preciso, antes de propores reduzi-lo.
5. Chama a atenção se o CSS for entregue apenas parcialmente em
   linha, e explica porque é que isso pode ser pior para o CLS do
   que não o fazer de todo.
6. Indica o que devo voltar a medir depois de cada alteração.

Não inventes medições.

Conclusão

A pontuação em si não é o objetivo – é uma medição, não um resultado de negócio. O que conta é a experiência por trás: uma página legível ao fim de 1,4 segundos é lida por mais pessoas do que uma que demora seis. Em visitantes móveis por rede celular a diferença é maior do que qualquer otimização de texto.

O caminho até lá passou, no nosso caso, por uma única pergunta recorrente: precisamos disto? Cinco de seis intervenções consistiram em remover algo, não em acrescentar.

Perguntas frequentes