Skip to content
Serviços

Performance para Sites

Sites rápidos, estáveis e acessíveis: Core Web Vitals otimizados e nota Lighthouse alta no mobile e no desktop.

Um site lento perde visitante antes mesmo de carregar. Cada segundo a mais de espera derruba conversão, prejudica o ranqueamento no Google e passa uma impressão de descaso. Performance não é vaidade técnica — é experiência do usuário e resultado de negócio.

Na Monto IA, performance é parte do produto desde o primeiro dia, não um ajuste de última hora. Construímos com foco em carregamento rápido, estabilidade visual e acessibilidade — e medimos tudo com ferramentas reais.

O que está incluído

  • Core Web Vitals: otimização e monitoramento de LCP (carregamento), CLS (estabilidade visual) e INP (resposta à interação) — as métricas que o Google usa para ranquear
  • Imagens otimizadas: formatos modernos (WebP/AVIF), dimensionamento responsivo e carregamento sob demanda (lazy loading)
  • Entrega enxuta: CSS e JavaScript mínimos, sem frameworks pesados desnecessários — só o que a página realmente precisa
  • CDN e cache: distribuição global via Cloudflare, com cache configurado para servir cada visitante do ponto mais próximo
  • Acessibilidade: contraste, navegação por teclado e semântica correta — um site rápido que todo mundo consegue usar

Por que isso importa

  • Conversão: páginas que carregam em até 2s convertem muito mais que as que passam de 5s
  • SEO: desde 2021 o Google usa Core Web Vitals como fator de ranqueamento
  • Custo de mídia: em campanhas de Ads, páginas rápidas melhoram o índice de qualidade e reduzem o custo por clique

Relatório Lighthouse

O Lighthouse é a ferramenta do Google que audita desempenho, acessibilidade, boas práticas e SEO. É assim que entregamos nossos sites — todas as notas no verde, no mobile e no desktop.

90+ Desempenho
100 Acessibilidade
100 Boas Práticas
100 SEO

A nota de desempenho é a única que não depende inteiramente de nós: mesmo em teste de laboratório (rede e processador simulados), há variação de execução para execução por fatores fora do nosso controle — carga do servidor de teste do Google no momento, latência até ele, ruído de rede. E, na vida real, a experiência de cada visitante também varia com o aparelho e a conexão dele. Por isso garantimos desempenho a partir de 90 — a primeira faixa verde do Google — enquanto acessibilidade, boas práticas e SEO, que dependem só do desenvolvimento, entregamos em 100.

Nota no verde não é sorte: é resultado de decisões técnicas tomadas ao longo de todo o projeto. E, mais importante que o número, é a experiência real de quem visita — um site que abre rápido em qualquer conexão.

Lighthouse x PageSpeed Insights: qual a diferença?

As duas ferramentas nascem do mesmo motor — o PageSpeed Insights (PSI) roda o Lighthouse por trás dos panos e usa as mesmas quatro categorias (desempenho, acessibilidade, boas práticas e SEO). A diferença está no tipo de dado que cada uma mostra:

  • Lighthouse (Chrome DevTools, extensão ou linha de comando): só dados de laboratório — um teste simulado, em ambiente controlado, com rede e CPU limitadas artificialmente para reproduzir um celular médio. É o que rodamos durante o desenvolvimento, porque é repetível e não depende de tráfego real no site.
  • PageSpeed Insights: mostra o mesmo teste de laboratório e soma dados de campo — métricas reais coletadas de visitantes de verdade do site nos últimos 28 dias, via CrUX (Chrome User Experience Report, o painel de telemetria agregada do próprio Chrome). É por isso que o PSI tem duas seções separadas: “Dados de campo” (o que seus visitantes realmente sentiram) e “Dados de laboratório” (o teste simulado, mesmo número que o Lighthouse mostraria).

Na prática: o Lighthouse (e a aba “laboratório” do PSI) mede o site em condição controlada — é o que garantimos no contrato. Os “dados de campo” do PSI refletem a diversidade real de quem visita — aparelho, conexão, região — e é influenciado por fatores que nenhum desenvolvedor controla sozinho.

Validação W3C: por que código sem erros importa

O W3C (World Wide Web Consortium) é o órgão internacional que define os padrões da web — as regras que dizem como HTML e CSS devem ser escritos para funcionar de forma previsível em qualquer navegador, leitor de tela ou motor de busca. O validador de marcação do W3C confere se o HTML de uma página segue essas regras.

Nossos sites passam por essa verificação a cada build — não fica só no discurso: é um bloqueio automático que impede a publicação se o HTML gerado tiver erros equivalentes aos do validador do W3C. Alguns dos pontos verificados:

  • IDs duplicados: cada id precisa ser único na página — repetido, quebra links de âncora, rótulos de formulário (label for) e buscas de elemento via JavaScript
  • Aninhamento correto de elementos: a especificação define o que cada tag pode conter (um <div>, por exemplo, não pode ficar dentro de um <button> ou de um parágrafo)
  • Um único <main> por página, fechamento de tags na ordem certa, e uso correto de caracteres especiais (como &) no texto visível

Vale uma ressalva: validação W3C não é sinônimo de acessibilidade. Marcação válida é pré-requisito para acessibilidade, mas o padrão de acessibilidade em si (WCAG) é outro conjunto de regras — inclusive é o que o Lighthouse audita separadamente na nota de “Acessibilidade”.

O benefício: menos trabalho de correção para o navegador, mais consistência para quem visita

Navegadores modernos seguem uma especificação de recuperação de erros (o algoritmo de parsing do HTML5): diante de uma marcação malformada, eles não travam nem “adivinham” ao acaso — aplicam regras determinísticas para corrigir a estrutura nos bastidores. Mas essa correção tem custo e efeitos colaterais reais:

  • Processamento extra: o navegador gasta ciclos adicionais reconstruindo a árvore do documento em vez de só interpretar o que já está correto
  • Estrutura final imprevisível: o HTML “consertado” pelo navegador pode ficar diferente do que foi escrito — isso quebra seletores de CSS, buscas de JavaScript e a leitura por leitores de tela, que dependem da estrutura semântica correta
  • Inconsistência entre ferramentas: navegador, crawler de busca, leitor de tela e serviço de pré-visualização de link (compartilhamento em redes sociais) nem sempre corrigem o mesmo erro da mesma forma — HTML válido garante que todos “leem” a página exatamente igual

O ganho de performance aqui é real, mas indireto e secundário: código limpo elimina esse retrabalho de correção e evita reflows causados por uma árvore inesperada. Quem continua pesando mais na nota de desempenho é o que já descrevemos acima — peso de imagem, JavaScript e CSS entregues, tempo de resposta do servidor. HTML válido não torna um site lento em rápido sozinho; ele remove atrito silencioso que compromete consistência entre navegadores, acessibilidade e manutenção — e protege o desempenho que já foi construído.

Outros serviços