Como usar content-visibility em uma página longa criada por IA

Uma landing page longa pode ter depoimentos, comparações, perguntas, integrações e vários blocos de venda abaixo da primeira tela. O navegador recebe todo esse HTML e pode gastar tempo calculando estilo, layout e pintura de seções que a pessoa ainda não viu.

content-visibility: auto permite adiar parte desse trabalho. O navegador mantém o conteúdo no documento, mas pode pular a renderização dos descendentes enquanto a seção está longe da área visível.

Isso não conserta uma árvore HTML desnecessária nem reduz downloads. A técnica funciona quando o conteúdo precisa existir desde o início, mas não precisa ser renderizado imediatamente.

Entenda o trabalho que pode ser adiado

Ao aplicar content-visibility: auto, você permite que o navegador use contenção de layout, estilo e pintura. Fora da tela, ele também pode tratar o conteúdo como se tivesse apenas o tamanho reservado da seção.

Na prática, o navegador pode evitar parte de:

• cálculo de estilos dos descendentes;
• layout dentro da seção;
• pintura dos elementos;
• hit testing de conteúdo ainda distante.

Quando a seção se aproxima da área visível, o navegador volta a renderizá-la. O artigo do web.dev sobre content-visibility explica esse comportamento e registra suporte nos três principais motores de navegador desde setembro de 2024.

A propriedade não remove nós do DOM. Se a página tem milhares de wrappers, elementos duplicados ou listas que nunca deveriam ter sido criadas, comece pelo guia de redução de DOM excessivo.

Escolha seções independentes

Não aplique a regra na página inteira. Procure blocos que tenham fronteiras claras e fiquem abaixo da primeira dobra:

• grade extensa de recursos;
• coleção de depoimentos;
• tabela comparativa;
• lista de casos de uso;
• bloco de perguntas frequentes;
• rodapé grande;
• conteúdo editorial dividido em capítulos.

A unidade deve continuar fazendo sentido sozinha. Um wrapper que atravessa hero, navegação e formulário não é um bom candidato.

Evite começar por:

• hero e conteúdo que participa do LCP;
• navegação principal;
• mensagens de erro e estados urgentes;
• modal aberto no carregamento;
• elemento que recebe foco imediatamente;
• região cujo tamanho depende de outro bloco da página.

O objetivo é poupar trabalho fora da tela sem atrasar o que a pessoa precisa agora.

Registre uma linha de base

Meça antes de editar. Abra a URL publicada no Chrome DevTools, use o painel Performance e grave um carregamento com a configuração de CPU e rede anotada.

Registre:

URL e Version:
viewport, CPU e rede:
seções abaixo da dobra:
tempo em Recalculate Style:
tempo em Layout:
tempo em Paint:
LCP:
CLS:
INP da primeira interação importante:

Repita a captura algumas vezes. Compare a mesma rota, a mesma versão e as mesmas condições. O guia de orçamento de performance ajuda a transformar essa linha de base em um limite verificável.

Aplique a menor regra útil

Comece em uma ou duas seções longas:

.long-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 800px;
}

contain-intrinsic-size informa o tamanho que o navegador pode usar enquanto não renderiza os descendentes. O valor auto 800px usa 800 pixels como estimativa inicial e permite lembrar o tamanho real depois que a seção for renderizada.

O valor não precisa ser perfeito. Precisa ficar perto do tamanho habitual. Uma estimativa muito curta ou muito longa altera a altura calculada da página quando o conteúdo aparece. O resultado pode ser um salto na barra de rolagem ou um novo layout shift.

A referência do MDN para contain-intrinsic-size mostra como o navegador usa o tamanho estimado e depois guarda o tamanho renderizado.

Estime o espaço por tipo de seção

Não copie 800px para tudo. Meça os blocos no viewport que importa e agrupe elementos parecidos.

.testimonial-group {
  content-visibility: auto;
  contain-intrinsic-size: auto 720px;
}

.comparison-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 1100px;
}

Uma grade pode mudar muito entre celular e desktop. Nesse caso, use estimativas diferentes no media query do projeto.

.comparison-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 1100px;
}

@media (max-width: 720px) {
  .comparison-section {
    contain-intrinsic-size: auto 1900px;
  }
}

Teste o início, o meio e o fim da página. O tamanho reservado afeta a rolagem antes de a seção entrar na tela.

Não trate a propriedade como lazy loading

content-visibility adia renderização. Ele não impede que o navegador baixe uma imagem encontrada no HTML, nem evita a análise do documento ou a execução de JavaScript que percorre a seção.

Combine cada ferramenta com o custo que ela controla:

Os artigos sobre vídeos e iframes e JavaScript na thread principal cobrem os outros custos.

Revise o JavaScript que mede a seção

Uma leitura de geometria pode obrigar o navegador a renderizar conteúdo que ele pretendia pular. Procure código que percorre todas as seções e consulta propriedades como:

• offsetWidth e offsetHeight;
• getBoundingClientRect();
• getComputedStyle();
• posições usadas por bibliotecas de animação;
• medidas calculadas em cada evento de rolagem.

O próprio guia do web.dev alerta que certas APIs do DOM podem cancelar o ganho em uma árvore pulada. Meça apenas o bloco necessário e evite varrer a página inteira a cada frame.

Se uma biblioteca exige a geometria de todas as seções no carregamento, teste a integração antes de manter a regra. A correção pode ser mudar a biblioteca, limitar os alvos ou retirar content-visibility daquele trecho.

Teste navegação, busca e acessibilidade

Conteúdo com auto continua no DOM e na árvore de acessibilidade. Isso permite busca na página e navegação até o conteúdo. Ainda assim, a combinação com CSS e JavaScript do projeto pode criar falhas.

Teste:

1. links com fragmentos que levam a uma seção distante;
2. busca do navegador por texto fora da tela;
3. navegação por teclado até links e controles;
4. foco devolvido a um elemento depois de fechar um modal;
5. leitura por tecnologia assistiva;
6. conteúdo que começa com display: none ou visibility: hidden;
7. impressão e captura da página inteira quando fizerem parte do uso.

Não adicione aria-hidden apenas para obter ganho. Esse atributo remove o conteúdo da árvore de acessibilidade. Use-o somente quando a região realmente não deve ser apresentada.

O checklist de navegação por teclado ajuda a testar foco, ordem e controles depois da mudança.

Compare o carregamento e a rolagem

Grave novamente com as mesmas condições. Procure redução no trabalho inicial de Style, Layout e Paint. Depois role a página inteira e confirme que o custo não virou uma sequência de travadas.

Compare:

• duração da renderização inicial;
• tarefa longa antes da primeira interação;
• LCP e CLS;
• INP de menu, formulário ou comparação;
• frames lentos durante a rolagem;
• saltos quando cada seção aparece;
• memória e quantidade de nós, que podem continuar iguais.

Uma melhora na carga com rolagem ruim não fecha o trabalho. Ajuste o tamanho intrínseco, reduza a complexidade da seção ou retire a regra do bloco problemático.

Para acompanhar o resultado depois da publicação, use o fluxo de Core Web Vitals reais. Dados de campo mostram se a técnica ajudou nos aparelhos do público, além do resultado observado no trace local.

Publique como uma mudança isolada

Altere poucas seções por Version. Assim você consegue relacionar qualquer regressão de rolagem ou interação à regra aplicada.

No Site no Ar:

1. consulte o Site e a Version atuais;
2. edite o CSS e os arquivos dentro de public/;
3. revise as seções em diferentes viewports;
4. publique com deploy;
5. acompanhe deploy_status até um estado terminal;
6. abra a URL pública e repita a gravação;
7. compare a nova Version com a linha de base.

A documentação de Publicação descreve como arquivos, Versions e URL se relacionam. O guia de republicação preserva o mesmo Site enquanto você testa a alteração.

Prompt para revisar uma página longa

Revise a renderização desta página longa sem publicar ainda.

URL e Version: [URL e identificador]
Seções abaixo da dobra: [seletores]
Viewport, CPU e rede: [condições]

1. Grave a carga e separe Style, Layout e Paint.
2. Escolha somente seções independentes fora da primeira tela.
3. Teste content-visibility: auto com um contain-intrinsic-size medido.
4. Não aplique a regra à hero, navegação ou conteúdo do LCP.
5. Verifique leituras de geometria que forçam renderização.
6. Teste fragmentos, busca na página, teclado e tecnologia assistiva.
7. Compare carga, rolagem, CLS e primeira interação.
8. Proponha a publicação apenas se o ganho aparecer no trace sem regressão funcional.

content-visibility é uma otimização cirúrgica. Use-a quando o HTML precisa estar no documento, mas grande parte da renderização pode esperar. O trace deve mostrar o trabalho removido, e a rolagem deve continuar estável até o fim da página.