Voce fez o básico de performance. E agora?
A maioria das equipes de desenvolvimento é marketing ja sabe o script: comprimir imagens, habilitar GZIP, ativar cache do browser, servir assets de uma CDN, minificar CSS é JavaScript. Essas otimizações sao o ABC de performance web, é se voce ainda não as implementou, comece por elas. Mas é quando voce ja fez tudo isso é o Lighthouse ainda aponta um LCP de 3,2 segundos ou um INP de 280ms?
E aqui que entra o PageSpeed avancado: as otimizações que vao além do básico é que frequentemente sao a diferenca entre um site que passa nos Core Web Vitals é um que fica nos 'Needs Improvement' frustrantes, apesar de todos os esforcos anteriores.
A Trilion trabalha com otimização de performance avancada para clientes que ja fizeram o básico é precisam eliminar os últimos gargalos que impactam o ranking é a experiência do usuario. Este artigo cobre as técnicas que efetivamente movem o ponteiro.
Render-blocking resources: o assassino silencioso do LCP
O Largest Contentful Paint (LCP) mede o tempo até o maior elemento visivel da página ser renderizado. Um dos bloqueadores mais comuns do LCP é a presença de recursos que bloqueiam a renderizacao no <head> da página: scripts JavaScript é folhas de estilo CSS que o browser precisa baixar é processar antes de poder exibir qualquer conteúdo visivel.
Identificando render-blocking resources
No Chrome DevTools, va em Performance > Record é análise a cascata de carregamento. Recursos render-blocking aparecem na faixa principal de thread como blocos que atrasam o First Paint. O Lighthouse também lista esses recursos diretamente no relatorio, com estimativa de economia de tempo para cada um.
Tecnicas para eliminar render-blocking
- Defer de scripts não criticos: adicione
deferouasynca todos os scripts que não sao necessários para o conteúdo above the fold. Scripts comdefersao executados apos o parsing do HTML; scripts comasyncsao executados assim que baixados, sem bloquear o parser - Remocao de CSS não útilizado: use Coverage no Chrome DevTools para identificar o percentual de CSS de cada folha de estilos que é realmente usado na página. CSS não útilizado deve ser removido ou movido para folhas separadas carregadas sob demanda
- Preload de recursos criticos: use
<link rel="preload">para instruir o browser a baixar com prioridade alta os recursos que serao necessários logo (fonte principal, imagem do hero, CSS critico)
Critical CSS inline: eliminando a folha de estilos do caminho critico
Uma das otimizações mais eficazes para LCP é o Critical CSS inline. A ideia é simples: extraia apenas os estilos CSS necessários para renderizar o conteúdo above the fold (o que o usuario ve sem rolar a página) é injete-os diretamente no <head> do HTML como um bloco <style>. O restante do CSS é carregado de forma assincrona, sem bloquear a renderizacao inicial.
Ferramentas para gerar o Critical CSS automáticamente incluem Critical (biblioteca npm), Penthouse é o proprio Lighthouse que identifica o CSS critico ausente. Em CMS como WordPress, plugins como Autoptimize com configuração avancada podem automatizar o processo.
O ganho de LCP com Critical CSS pode ser de 0,3 a 1,5 segundos dependendo do volume de CSS do site, um impacto significativo considerando que o limiar entre 'Good' é 'Needs Improvement' é apenas 1 segundo (2,5s vs 4s).
Lazy loading de componentes: carregue so o que o usuario vai ver
O principio do lazy loading é simples: não carregue recursos que o usuario não ve ainda. Aplicado corretamente, pode reduzir drasticamente o volume de dados transferidos no carregamento inicial é melhorar tanto o LCP quanto o INP.
Lazy loading de imagens
O atributo nativo loading="lazy" no elemento <img> instrui o browser a adiar o carregamento de imagens que estao abaixo do fold até que o usuario role a página até elas. Importante: nunca aplique lazy loading ao elemento LCP (normalmente a imagem hero ou banner principal), pois isso piora exatamente a métrica que voce quer melhorar.
Lazy loading de componentes JavaScript
Em aplicações React, Vue ou Angular, use code splitting é dynamic imports para carregar componentes apenas quando necessários. Um modal de contato, um chatbot, um componente de mapa ou um widget de reviews não precisa ser carregado no bundle inicial. Cada KB retirado do bundle inicial melhora o tempo de parse é execução do JavaScript, impactando positivamente o INP.
- Em React: use
React.lazy()éSuspensepara code splitting de componentes - Em Vue: use
defineAsyncComponent()para imports assincronos de componentes - Em JavaScript vanilla: use
import()dinâmico para carregar modulos sob demanda baseado em interação do usuario
font-display:swap é otimização de web fonts
Fontes web customizadas sao uma das maiores causas de Cumulative Layout Shift (CLS) é de atraso no LCP. Quando o browser precisa baixar uma fonte antes de renderizar o texto, o usuario ve um flash de texto invisivel (FOIT) ou uma troca brusca de fonte (FOUT) apos o carregamento, ambas experiências ruins que afetam métricas de Core Web Vitals.
font-display:swap
A propriedade CSS font-display: swap instrui o browser a usar uma fonte fallback imediatamente é trocar pela fonte customizada assim que ela carregar. Isso elimina o FOIT é melhora o LCP, embora possa causar um pequeno FOUT. Para minimizar o FOUT, escolha fontes fallback com métricas similares (altura x, largura, espassamento) a fonte customizada.
Preconnect é preload de fontes
Se as fontes vem de um CDN externo como Google Fonts, adicione um <link rel="preçonnect"> para o domínio do CDN no <head>. Isso estabelece a conexão DNS TCP TLS antecipadamente, economizando 100-300ms no tempo de download da fonte. Para fontes criticas, use <link rel="preload"> para iniciar o download com prioridade máxima.
Prefetch é preçonnect para recursos criticos
Alem do preload de fontes, as diretivas de resource hints sao poderosas para otimizar o carregamento de recursos que serao necessários em breve.
- preçonnect: estabelece conexão antecipada com domínios de terceiros que serao necessários (CDN, APIs, tracking). Use para no máximo 3-5 domínios para não saturar a banda
- dns-prefetch: versão mais leve do preçonnect, faz apenas a resolução DNS sem estabelecer conexão. Util para domínios que podem ou não ser usados
- prefetch: instrui o browser a baixar recursos que provavelmente serao necessários na proxima navegação (página seguinte do fluxo). Muito eficaz para e-commerces (pre-carregar página do produto seguinte) ou sites com jornadas lineares previsivels
- prerender: renderiza completamente uma página em segundo plano antes do usuario clicar. Extremamente eficaz mas de alto custo de banda; use apenas em páginas com alta probabilidade de acesso imediato
'A diferenca entre um site que passa nos Core Web Vitals é um que fica a margem frequentemente não esta nas otimizações obvias, mas nos detalhes: uma fonte carregada sem font-display:swap, um terceiro script sem async, um componente de mapa carregado no bundle inicial que so aparece no rodape. Esses sao os gargalos que encontramos na Trilion quando fazemos profiling avancado de performance para nossos clientes.' - Time de Performance, Trilion
Priorizando otimizações por impacto no LCP é INP
Com tantas otimizações possíveis, como priorizar? A resposta esta em entender quais problemas afetam mais diretamente as métricas que o Google usa como sinal de ranking.
Para melhorar o LCP
O LCP é determinado pela velocidade com que o elemento maior da página é renderizado. Identifique qual elemento é o LCP (geralmente uma imagem hero ou H1 grande) é trace o caminho critico de carregamento até ele. Cada recurso que bloqueia ou atrasa esse caminho critico é um candidato a otimização prioritaria.
Priorizacao recomendada para LCP: 1) Eliminar render-blocking resources, 2) Implementar Critical CSS, 3) Otimizar a imagem LCP (formato WebP/AVIF, preload, tamanho correto), 4) Melhorar TTFB do servidor (que tem impacto direto no LCP).
Para melhorar o INP
O Interaction to Next Paint (INP) substituiu o FID em 2024 é mede a responsividade a interações do usuario. Um INP alto geralmente indica JavaScript excessivo bloqueando o main thread. Priorizacao recomendada para INP: 1) Reduzir o bundle de JavaScript total com code splitting, 2) Mover tarefas pesadas para Web Workers, 3) Usar scheduler.yield() para dividir tarefas longas, 4) Adiar a inicializacao de scripts de terceiros.
Ferramentas de profiling avancado para performance web
Para identificar os gargalos que o Lighthouse básico não captura, o profiling avancado é indispensavel.
- Chrome DevTools Performance panel: o mais completo para análise de main thread, long tasks, layout shifts é timing de LCP
- Lighthouse CI: integrado ao pipeline de CI/CD para detectar regressoes de performance automáticamente a cada deploy
- WebPageTest: oferece filmstrip visual do carregamento, testes de multiplas localizacoes é comparacoes lado a lado com concorrentes
- Chrome UX Report (CrUX): dados de usuarios reais em campo, a fonte que o Google usa para calcular os Core Web Vitals do seu site
- DebugBear: monitoramento continuo de Core Web Vitals com alertas de regressao é comparativo histórico
A Trilion oferece auditorias de performance avancada para sites que ja fizeram o básico é precisam dar o proximo passo. Nossa abordagem combina análise de dados de campo (CrUX) com profiling sintético aprofundado para identificar exatamente o que esta bloqueando seus Core Web Vitals de entrar na faixa 'Good'.
Seu site ainda não passou nos Core Web Vitals? A Trilion identifica é resolve os gargalos avancados de performance que o básico não cobre. Entre em contato para uma auditoria especializada.
