Como melhorar o desempenho web: técnicas práticas a partir do caso Oodles Theatre

Remover recursos desnecessários e compressão

O primeiro passo consiste em eliminar ficheiros que não aportam valor, como espaços em branco e comentários, e aplicar minificação a CSS e JavaScript. O Lighthouse sinaliza a auditoria "Unminified CSS & JavaScript"; ao usar o plugin Uglify JS no webpack, o código é reduzido significativamente. Em seguida, a compressão gzip – já ativada por padrão no Firebase Hosting – diminui o tamanho dos ficheiros enviados. Algoritmos mais avançados, como Zopfli e Brotli, oferecem ainda mais redução, sobretudo para recursos estáticos.

Políticas de cache eficientes

O audit "Inefficient cache policy" revela que recursos são reenviados em visitas subsequentes. Definir cabeçalhos Cache‑Control: max‑age permite que o navegador reutilize ficheiros já armazenados, reduzindo latência. É recomendável combinar períodos longos de cache com tokens de validação (ETag ou Last‑Modified) para garantir que alterações sejam reconhecidas sem descarregar tudo novamente.

Eliminar código morto

Com o tempo, aplicações acumulam bibliotecas que já não são usadas. No caso do Oodles Theatre, a biblioteca Material Components foi mantida mesmo após a migração para um design personalizado, ocupando cerca de 95 % de CSS inutilizado. A auditoria de cobertura de código no DevTools expôs esse desperdício, permitindo a remoção de CSS e JavaScript redundantes e reduzindo o bundle em 20 vezes. A prática deve ser acompanhada de testes de regressão visual para evitar que componentes críticos percam estilos.

Reduzir payloads de rede

Auditar o peso total dos recursos mostrou um bundle JavaScript de 2 MB não comprimido e um pacote "unicode" de 1,6 MB. Ferramentas como webpack‑bundle‑analyzer e o plugin Import Cost identificam dependências pesadas. Substituir o módulo "unicode" por alternativas de 2,2 KB reduziu o tamanho total em 2,1 MB, resultando em um ganho de 65 % na velocidade de carregamento quando o código é gzipped e minificado.

Code‑splitting e tempo de arranque do JavaScript

O audit "JavaScript boot‑up time" revelou 1,8 s de tempo gasto a processar um bundle monolítico. Ao migrar para importações dinâmicas, o Oodles Theatre passou a dividir o código por rotas e componentes, carregando apenas o necessário. O tempo de arranque caiu para 0,78 s – uma melhoria de 56 % – e o tamanho dos bundles foi reduzido. Estratégias complementares, como "tree‑shaking" e a utilização do repositório webpack‑libs‑optimizations, reforçam este efeito.

Otimização de imagens

As auditorias de imagem do Lighthouse indicaram que todas as três verificações falharam: falta de compressão, dimensionamento inadequado e formatos sub‑ótimos. Ferramentas como ImageOptim ou a biblioteca imagemin podem ser integradas ao pipeline de build para gerar versões WebP ou AVIF, reduzir a resolução a valores necessários e aplicar compressão sem perdas visíveis. Cada kilobyte poupado beneficia especialmente utilizadores em redes 3G, onde o Oodles Theatre inicialmente demorava 15 s para o primeiro paint significativo.