Como criar sites rápidos com HTML, CSS e Cloudflare

O que o Google mede: Core Web Vitals

Core Web Vitals são três métricas que o Google usa para avaliar a experiência de quem abre a página. Cada uma olha para um momento diferente da visita. Os limites abaixo vêm do web.dev, o portal de desenvolvimento web mantido pelo Google.

O web.dev recomenda medir no percentil 75 das visitas, separando celular e computador. Em outras palavras: 3 de cada 4 visitas precisam bater a meta. Um teste único no seu notebook com internet boa não basta.

Por que o HTML puro sai na frente

Um site estático é feito de arquivos prontos: HTML, CSS, JavaScript e imagens. O servidor não monta nada na hora da visita, só entrega o arquivo. Se você quer entender essa arquitetura a fundo, veja o que são sites estáticos.

Em um site com sistema de gestão, cada visita pode passar por banco de dados, tema e plugins antes de virar HTML. Com cache bem configurado, isso fica rápido. Sem cache, o tempo de resposta do servidor cresce, e o web.dev mostra que esse tempo, o TTFB (Time to First Byte), entra direto no LCP.

O HTML puro não é rápido por mágica. Ele só tira do caminho as partes que você não pediu. O resto depende das escolhas abaixo.

Passo a passo para um site rápido

Siga esta ordem. Ela começa pelo que costuma pesar mais na maioria dos sites.

1. Meça antes de mexer. Anote LCP, INP e CLS da página inicial no celular e no computador.
2. Ache o elemento de LCP. Normalmente é a foto do topo ou o título principal.
3. Otimize as imagens. Tamanho certo, formato leve, largura e altura no código.
4. Libere o carregamento. Coloque defer nos scripts e deixe o CSS pequeno.
5. Corte dependências. Cada biblioteca, fonte e script de terceiro precisa justificar o peso.
6. Ative o cache. Publique na Cloudflare e defina por quanto tempo cada tipo de arquivo fica guardado.
7. Meça de novo. Compare os números e repita na próxima página importante.

Imagens: onde está o maior peso

Imagem costuma ser o maior arquivo da página e, quase sempre, o próprio elemento de LCP. Três cuidados resolvem boa parte do problema.

Primeiro, defina largura e altura. O MDN explica que esses atributos permitem ao navegador calcular a proporção da imagem antes dela chegar. Assim ele reserva o espaço e a página não pula, o que protege o CLS.

Segundo, não adie a imagem do topo. O web.dev é direto: nunca use carregamento preguiçoso (lazy) na imagem de LCP. Em vez disso, marque essa imagem com prioridade alta.

Terceiro, use lazy nas imagens de baixo. O MDN descreve que o atributo adia o download até a imagem chegar perto da área visível. Isso economiza dados de quem só lê o começo.

<!-- Imagem do topo: prioridade alta, sem lazy -->
<img src="/img/fachada-800.webp" width="800" height="500"
     fetchpriority="high" alt="Fachada da loja vista da calçada">

<!-- Imagens mais abaixo: carregamento adiado -->
<img src="/img/equipe-600.webp" width="600" height="400"
     loading="lazy" alt="Equipe de atendimento no balcão">

Se a mesma foto aparece em telas de tamanhos diferentes, use srcset com versões de larguras distintas. O navegador escolhe a mais adequada. Para tirar dúvidas de layout em telas pequenas, veja como criar um site responsivo.

CSS e JavaScript sem bloquear a tela

O navegador para de desenhar a página enquanto baixa CSS e scripts síncronos do head. Por isso o web.dev diz que quase nunca é preciso colocar script síncrono no head. Use defer, que baixa o arquivo em paralelo e executa depois que o HTML foi lido.

<head>
  <link rel="stylesheet" href="/css/site.css">
  <script src="/js/menu.js" defer></script>
</head>

No CSS, a regra é tamanho. O web.dev recomenda que a folha de estilo seja menor que a imagem de LCP, para não atrasar o desenho. Um site institucional costuma caber em um único arquivo CSS pequeno, sem framework inteiro carregado para usar 5% dele.

Scripts de terceiros merecem atenção dobrada. Chat, pixel de anúncio, mapa incorporado e player de vídeo carregam código que você não controla. Pergunte de cada um: ele traz cliente? Se não traz, saia com ele. Se traz, carregue depois da interação ou só na página que precisa.

A criação é grátis quando você contrata uma hospedagem da HostGator em ciclo anual pelo link do MundoBlá. A gente ganha uma comissão da HostGator quando você contrata pelo link, sem custo extra para você. O escopo do site é combinado no WhatsApp antes de começar.

Cache e CDN na Cloudflare

CDN (Content Delivery Network, rede de entrega de conteúdo) é um conjunto de servidores espalhados que guarda cópias dos seus arquivos. A documentação da Cloudflare descreve esses centros de dados como mais próximos do usuário do que o servidor de origem. O arquivo viaja menos e chega antes.

Um detalhe pega quem está começando. Segundo a Cloudflare, a CDN não guarda HTML nem JSON em cache por padrão no proxy comum. Ela guarda por extensão de arquivo, como imagens, CSS, JavaScript e fontes. Para incluir o HTML, você cria uma regra de cache no painel.

No Cloudflare Pages, o serviço de publicação de sites da Cloudflare, os arquivos são publicados direto na rede global da empresa. A documentação informa 500 deploys (publicações) por mês no plano grátis. Você pode ver o processo completo na página sobre Cloudflare Pages.

No Pages, o tempo de cache de cada arquivo pode ser definido em um arquivo chamado _headers, na pasta publicada. O exemplo segue o modelo da documentação, com cache longo para arquivos que mudam de nome a cada versão:

/css/*
  Cache-Control: public, max-age=31536000, immutable

/img/*
  Cache-Control: public, max-age=31536000, immutable

Use o immutable só se o nome do arquivo mudar quando o conteúdo mudar, como site.v2.css. Caso contrário, o visitante pode ficar com a versão antiga. A Cloudflare limita o arquivo a 100 regras e 2.000 caracteres por linha.

Quando você publica uma alteração e ela não aparece, a função Purge, citada na documentação de cache, apaga as cópias guardadas. A Cloudflare busca a versão nova na próxima visita.

Como medir sem se enganar

Meça a mesma página, no mesmo tipo de aparelho, antes e depois de cada mudança. O PageSpeed Insights mostra os dados de usuários reais quando o site tem visitas suficientes, e um teste de laboratório para achar a causa. O passo a passo da ferramenta está no guia de melhorar o desempenho do site.

Olhe primeiro os dados reais, porque são eles que o Google usa. O teste de laboratório serve para descobrir o culpado: qual imagem, qual script, qual arquivo bloqueou a tela. Se a sua dúvida é sobre o que vem antes de tudo isso, a resposta curta sobre o que é preciso para criar um site ajuda a organizar o começo.

Erros comuns que deixam o site lento

1. Subir foto direto da câmera, com milhares de pixels de largura, para exibir em 800.
2. Aplicar lazy em todas as imagens, inclusive na do topo.
3. Esquecer width e height e ver a página pular quando a foto chega.
4. Carregar uma biblioteca inteira de JavaScript para abrir um menu.
5. Usar 4 famílias de fonte com 6 pesos cada.
6. Colocar cache longo em arquivo que muda sem trocar o nome.
7. Medir só no computador do escritório, com internet de fibra.

Se você ainda está decidindo a base do projeto, a comparação entre WordPress ou HTML puro mostra quando cada um compensa. E o guia de como criar sites sem WordPress junta código, GitHub e Cloudflare em uma sequência só. Outras dúvidas do tema têm resposta no Mundo Criação de Sites, e a resposta para o resto está na página inicial do MundoBlá.

Lembrete de transparência: a criação é grátis com a hospedagem anual da HostGator contratada pelo nosso link, e a HostGator paga uma comissão ao MundoBlá por isso. Hospedagem e domínio você paga direto à HostGator.

Em outros Mundos

Velocidade é só uma parte de aparecer no Google. No Mundo SEO você encontra o que fazer com o conteúdo, os links e a pesquisa de palavras.