Como usar preload, preconnect e fetchpriority em uma landing page criada por IA — Blog

Uma landing page criada por IA pode carregar todos os arquivos corretos e ainda descobrir tarde demais o recurso mais importante. A imagem hero aparece apenas depois do CSS, a fonte crítica espera outra conexão e cinco scripts disputam rede antes do conteúdo principal.

preload, preconnect e fetchpriority ajudam em partes diferentes desse problema. Usá-los como uma lista de “boas práticas” em todo recurso apenas muda a disputa: quando tudo é urgente, nada recebe uma prioridade útil.

Este guia mostra como identificar o caminho crítico, escolher o mecanismo certo, validar a ordem real no navegador e republicar sem adicionar hints que baixam arquivos duplicados ou desnecessários.

Comece pela waterfall, não pelo markup

Antes de adicionar uma tag ao <head>, carregue a URL publicada com cache vazio e registre a waterfall.

Para o recurso candidato, anote:

URL:
tipo:
iniciador:
momento de descoberta:
prioridade inicial e final:
início e duração do download:
bloqueia renderização?
participa da primeira dobra?
é o elemento de LCP?
origem:
cache:

Procure uma cadeia concreta:

HTML → CSS → imagem de fundo da hero
HTML → CSS → @font-face → fonte do título
HTML → JavaScript → import dinâmico → componente inicial
HTML → script de terceiro → request essencial

Se o recurso já aparece cedo e baixa com prioridade adequada, um hint pode não ajudar. Se ele não é necessário para a primeira renderização, antecipá-lo pode piorar a disputa por banda.

O guia de Core Web Vitals em sites criados por IA mostra como identificar LCP, INP e CLS antes de editar. Use o elemento e a fase lentos como ponto de partida.

Diferencie os três mecanismos

Mecanismo	O que antecipa	Quando faz sentido
`preload`	descoberta e fetch de uma URL	recurso crítico conhecido, mas descoberto tarde
`preconnect`	conexão com uma origem	origem crítica conhecida, URL exata ainda não
`fetchpriority`	prioridade relativa do fetch	recurso já descoberto precisa subir ou descer na disputa

O HTML Standard define preload como um fetch preventivo para um recurso altamente provável na navegação atual. O atributo as informa o destino e participa da chave que permite reaproveitar a resposta.

O mesmo padrão define preconnect como a antecipação de uma conexão a uma origem quando pagar DNS, TCP e TLS antes tende a beneficiar a experiência.

Já fetchpriority aceita high, low e auto para sinalizar prioridade relativa entre recursos com o mesmo destino. É um hint; o navegador continua tomando decisões próprias.

Não confunda este preload de recurso com HSTS preload. O primeiro atua no carregamento da página atual. O segundo envolve uma lista de transporte HTTPS e consequências de longo prazo, tratadas no guia de HSTS para sites criados por IA.

Torne o recurso crítico descobrível no HTML

A melhor otimização costuma ser permitir que o parser encontre o recurso cedo sem ajuda extra.

Para uma imagem hero real:

<img
  src="/assets/hero.avif"
  width="1280"
  height="720"
  alt="Demonstração do produto"
  fetchpriority="high"
  decoding="async"
/>

Evite colocar a imagem de LCP atrás de:

JavaScript que monta todo o conteúdo;
data-src trocado por script;
loading="lazy";
um carrossel que só revela a primeira imagem depois de inicializar;
CSS carregado tarde;
múltiplos redirects.

O artigo sobre otimizar imagens antes de publicar cobre dimensões, formato, srcset, sizes e lazy loading. Prioridade alta não corrige um arquivo desnecessariamente grande.

Use `preload` para descoberta tardia comprovada

Uma imagem de fundo usada na primeira dobra pode ser descoberta apenas depois do CSS. Um preload pode antecipá-la:

<link rel="preload" href="/assets/hero.avif" as="image" type="image/avif" fetchpriority="high" />

O preload precisa corresponder ao request real. Confira:

URL final;
destino em as;
tipo em type;
política CORS;
credenciais;
media quando houver variação;
seleção responsiva da imagem;
prioridade desejada.

Se esses atributos não combinarem, o navegador pode baixar o arquivo no preload e fazer outro request quando o recurso for usado.

Para fontes críticas:

<link
  rel="preload"
  href="/assets/fonts/marca-regular.woff2"
  as="font"
  type="font/woff2"
  crossorigin
/>

Fontes normalmente usam CORS mesmo quando são do mesmo Site. O guia de revisão de fontes web mostra como limitar pesos, validar caracteres e decidir se o preload compensa.

Não preloade tudo que aparece acima da dobra. CSS já descoberto cedo, a logo pequena e cinco pesos tipográficos podem competir com o próprio LCP.

Use `preconnect` quando a origem é inevitável

Para um recurso crítico em outra origem:

<link rel="preconnect" href="https://cdn.exemplo.com" crossorigin />

O preconnect pode antecipar:

resolução DNS;
conexão TCP;
negociação TLS;

Ele não baixa o arquivo. Isso o torna útil quando a origem é conhecida, mas a URL exata será descoberta depois.

Use em poucas origens comprovadamente críticas, como a fonte externa que permanece no caminho inicial após a revisão. Não abra conexões preventivas para cada analytics, vídeo, chat, mapa e widget que talvez nem seja usado.

Uma conexão tem custo de socket, certificado e estado. Em celular, vários preconnects podem competir entre si e com a origem principal. Para origens menos prováveis, dns-prefetch tem custo menor, mas também benefício menor.

O guia do web.dev sobre preconnect e dns-prefetch recomenda reservar preconnect para as origens mais importantes e medir o efeito real.

Use `fetchpriority` como sinal relativo

Para a imagem de LCP descoberta no HTML, a prioridade alta pode evitar que ela comece como uma imagem comum:

<img
  src="/assets/hero.webp"
  width="1440"
  height="810"
  alt="Equipe usando o produto"
  fetchpriority="high"
/>

Para uma imagem fora da primeira dobra:

<img
  src="/assets/galeria-04.webp"
  width="960"
  height="640"
  alt="Detalhe do projeto"
  loading="lazy"
  fetchpriority="low"
/>

Não aplique high em todas as imagens visíveis. Prioridade é relativa; você precisa declarar qual recurso merece avançar e deixar os demais sob decisão automática ou explicitamente abaixo quando houver evidência.

A orientação atual do web.dev sobre Fetch Priority diferencia descoberta de prioridade: preload encontra cedo; fetchpriority influencia como o fetch concorre. Os dois podem se complementar em uma imagem de fundo crítica, mas a combinação precisa ser medida.

Trate scripts pela função, não pelo tamanho isolado

Um script pode ser pequeno e bloquear o parser. Outro pode ser grande, mas carregar depois sem afetar a primeira dobra.

Revise:

scripts sem async, defer ou type="module";
ordem dentro do <head>;
dependências entre scripts;
imports dinâmicos;
widgets de terceiros;
execução necessária antes da interação;
código sem uso.

fetchpriority="high" não remove o bloqueio de um script síncrono e fetchpriority="low" não muda quando ele executa. Primeiro escolha a semântica de carregamento correta; depois ajuste prioridade somente se a waterfall justificar.

O artigo sobre scripts de terceiros antes da publicação ajuda a separar necessidade, segurança, consentimento e custo de cada integração.

Evite os antipadrões mais comuns

Preload não consumido

O navegador baixa um recurso que a página não usa logo depois. DevTools pode emitir um aviso, mas a prova principal é a waterfall e a ausência do request consumidor compatível.

Download duplicado

O preload usa URL, as, CORS ou credenciais diferentes do uso real. Corrija a correspondência; não aceite duas transferências como custo normal.

Hero responsiva errada

O preload fixa uma imagem desktop enquanto srcset escolhe outra em celular. Em <link rel="preload" as="image">, represente a mesma decisão com imagesrcset e imagesizes; srcset e sizes pertencem ao <img> ou <source> consumidor. Se o hint não puder repetir essa seleção, deixe o parser descobrir a imagem para evitar duas variantes baixadas.

Preconnect para origem opcional

A conexão é aberta, mas o visitante nunca aciona o vídeo ou widget. Remova o hint ou adie a própria integração.

Tudo com prioridade alta

Hero, logo, ícones, fontes, scripts e analytics competem no mesmo nível. Volte ao elemento de LCP e ao caminho crítico.

Hint que esconde arquitetura ruim

O agente adiciona preload para um recurso que só aparece tarde porque toda a página depende de JavaScript. Prefira tornar o conteúdo essencial parte do HTML inicial.

Valide antes e depois

Rode pelo menos três medições comparáveis com cache vazio antes da alteração e três depois. Registre mediana, não apenas a melhor execução.

No DevTools, confira:

request inicial e final;
initiator;
priority inicial e final;
conexão reutilizada;
download duplicado;
warning de preload não usado;
elemento de LCP;
tempo de descoberta e início do recurso;
impacto nos outros recursos críticos.

No Lighthouse ou PageSpeed Insights, trate a mudança de LCP como apoio, não como prova isolada. Em dados de campo, a melhora demora a refletir a nova versão e depende das visitas reais.

Teste também:

celular com rede lenta;
desktop;
imagem responsiva em larguras diferentes;
cache quente;
página sem o recurso opcional;
URL padrão e domínio próprio;
navegação depois da republicação.

Preserve o contrato de publicação

preload, preconnect e fetchpriority fazem parte do HTML enviado. Por isso, o projeto consegue controlá-los dentro do pacote do Site no Ar.

Antes de publicar:

gere uma build limpa;
confirme que as URLs dos hints existem no pacote;
verifique que hashes e caminhos correspondem ao HTML atual;
procure downloads duplicados no preview da build;
aplique as mudanças pelas file tools e publique pelo contrato de Publicação;
valide a URL final;
preserve o Site ID ao republicar.

Quando um novo build troca hero.123.avif por hero.456.avif, o HTML e o preload precisam mudar juntos. Um hint para asset antigo desperdiça rede e pode sobreviver em cópias de HTML em cache. O guia de assets antigos depois da republicação mostra como verificar a coerência da versão.

Prompt copiável para o agente

Revise a prioridade de carregamento desta landing page sem publicar ainda.

Fonte e build: [caminhos]
URL atual: [URL]

- Meça a waterfall com cache vazio e identifique o elemento de LCP.
- Registre initiator, descoberta, prioridade, origem e duração dos recursos críticos.
- Prefira tornar o recurso descobrível no HTML antes de adicionar hints.
- Use preload só para URL crítica conhecida e descoberta tarde.
- Use preconnect só para poucas origens críticas inevitáveis.
- Use fetchpriority como sinal relativo, nunca high em tudo.
- Confira `as`, `type`, `crossorigin`, credenciais e `media`.
- Em preload responsivo de imagem, confira `imagesrcset` e `imagesizes` no `<link>`, além de `srcset` e `sizes` no `<img>` ou `<source>` consumidor.
- Rejeite downloads duplicados e preloads não consumidos.
- Compare pelo menos três medições antes e depois.
- Valide o pacote e a URL publicada no mesmo Site.

Checklist final

Priorizar recursos não é dar urgência a cada arquivo. É permitir que o navegador descubra cedo o que define a primeira experiência, pague conexões inevitáveis no momento certo e mantenha banda para o que realmente precisa aparecer primeiro.