← Casos Velocidade 16–22 out 2026 · PageBrick 1.8.0 e tema 2.2.0
Do relatório do PageSpeed ao conserto
O pagebrick.org roda no PageBrick, então o relatório do PageSpeed dele é o relatório do próprio produto. Em menos de uma semana a nota no celular foi de 95 para 98 e a maior reclamação sumiu, medida do mesmo jeito na mesma página. Dois números secundários pioraram, e eles também estão neste caso.
- 98Desempenho no celular, antes 95 (PageSpeed Insights, 16 → 22 out 2026)
- 2,2 sMaior elemento da página (LCP) no celular, antes 2,9 s
- 410 → 0KiB que o navegador baixava de novo a cada visita (a reclamação do cache, no celular)
- 176 → 59KiB de economia ainda sugerida em imagens, no celular
O problema
Em 16 de outubro de 2026 o site tirou 100 no computador e 95 no celular. O relatório apontava três coisas: os arquivos estáticos vinham sem tempo de cache (410 KiB baixados de novo a cada visita, no celular), a foto do destaque era enviada com 1400 × 1045 pixels e mostrada com 372 × 278 (165 KiB), e nenhuma imagem tinha srcset. Uma parte era do tema e outra do núcleo, então consertar só um dos lados não bastaria.
A decisão
Duas etapas, o tema primeiro. Etapa 1, tema 2.2.0: cada imagem ganhou cópias menores com srcset; a primeira imagem da página é pedida primeiro; a animação de entrada que a escondia por cerca de um segundo agora se move em vez de esmaecer; as duas fontes são pedidas junto com a página; e a fonte serifada foi reduzida de 132 KB para 86 KB.
Etapa 2, PageBrick 1.8.0: um botão em Configurações escreve as linhas de cache do navegador no fim do .htaccess (um ano para os arquivos cujo endereço muda quando o arquivo muda, uma semana para os demais), e cada foto nova guarda uma cópia de 960 pixels.
A promessa aos sites que já existem decidiu os detalhes. O HTML que um tema já imprime não pode mudar, então o srcset é algo que o tema pede (img(sizes: …)), nunca algo que o núcleo acrescenta. E como uma atualização nunca mexe no .htaccess, os sites instalados antes recebem o cache por um botão, que confere o site depois e tira as linhas sozinho se a hospedagem responder com erro.
A prova
Antes de publicar, uma instalação nova foi medida com o Lighthouse: com as linhas de cache desligadas, o relatório apontava 9 arquivos (240 KiB); com elas ligadas, essa auditoria passou. Num celular de 375 pixels com o dobro de densidade, o navegador escolheu a cópia de 960 pixels: 8,6 KB em vez de 19,7 KB na foto de teste. A atualização da 1.7.1 para a 1.8.0 rodou num navegador de verdade, 31 de 31 conferências, incluindo apertar o botão do cache num site instalado antes e desligar de novo para o .htaccess voltar byte a byte. Depois o site no ar foi medido de novo com a mesma ferramenta.
O resultado
Em 22 de outubro a nota no celular era 98 (antes 95) e o maior elemento da página levava 2,2 s (antes 2,9 s). A reclamação do cache sumiu, e a das imagens caiu de 176 KiB para 59 KiB no celular. No computador a nota continuou 100.
Nem tudo melhorou. No celular, o primeiro elemento visível (FCP) foi de 0,9 s para 1,1 s e o Speed Index de 2,1 s para 3,3 s; no computador, o maior elemento foi de 0,4 s para 0,5 s e o Speed Index de 0,7 s para 1,1 s. O PageSpeed varia de uma medição para outra, então a leitura justa é: o que mais importa aqui (maior elemento, cache, peso das imagens) andou na direção certa, algumas métricas secundárias andaram na errada, e os próximos itens da lista são 5 KiB de CSS e uma animação que não é composta.
O que ficou
Um relatório de velocidade só vale como prova se o mesmo teste roda antes e depois, na mesma página, e os números que pioraram também são publicados.