Hospedagem de Sites Profissional e de Alta Performance

Como Reduzir Requisições HTTP no Seu Site

Table of Contents

Como Reduzir Requisições HTTP no Seu Site

Corte pedidos redundantes. Entregue o essencial com o mínimo de conexões.

1) Por que reduzir requisições?

  • Menos viagens de rede significam menor latência total.
  • Reduz TTFB percebido, FCP e LCP. Melhora estabilidade.
  • Economiza CPU/bateria em mobile e dados em 4G/5G.

2) Priorize: carregue só o que aparece

  • Remova bibliotecas e widgets não usados.
  • Carregue JS e CSS por rota (code-splitting).
  • Adie tudo que não impacta o above the fold.

3) CSS crítico inline + resto assíncrono

<!-- CSS crítico inline (até ~20–30KB) -->
<style>/* Conteúdo crítico aqui */</style>

<!-- CSS não crítico de forma não bloqueante -->
<link rel="preload" as="style" href="/assets/app.css" onload="this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/assets/app.css"></noscript>

Isso elimina uma requisição bloqueante (o CSS crítico). E mantém o restante sem travar renderização.

4) JS: dividir, adiar e condicionar

<script type="module" src="/app/bootstrap.js" defer></script>
<!-- Carregar módulos sob demanda -->
<script type="module">
  if (document.querySelector('[data-slider]')) {
    import('/modules/slider.js');
  }
</script>
  • defer para scripts de página.
  • import() para componentes que aparecem.
  • Evite jQuery/Bootstrap se não forem essenciais.

5) Imagens: menos pedidos, tamanhos certos

  • Use srcset e sizes para evitar downloads duplicados.
  • lazy abaixo da dobra. preload para a hero.
  • Favicon único em .ico ou .png leve.
<img
  src="/img/hero.webp"
  srcset="/img/hero.webp 1x, /img/hero@2x.webp 2x"
  sizes="100vw"
  fetchpriority="high"
  width="1600" height="900" alt="Seção principal">

<img loading="lazy" decoding="async" src="/img/galeria-1.webp" width="800" height="600" alt="">

6) Ícones: prefira sprite SVG

Troque dezenas de PNGs/ICOs por um sprite único.

<!-- sprite.svg: vários <symbol> -->
<svg aria-hidden="true" style="display:none">
  <symbol id="icon-whatsapp" viewBox="0 0 24 24">...</symbol>
</svg>

<!-- uso -->
<svg class="icon"><use href="#icon-whatsapp"></use></svg>

Resultado: uma única requisição para todos os ícones.

7) Fontes: menos arquivos, menos peso

  • Use system fonts quando possível.
  • Quando customizadas, subset + apenas 2 pesos principais.
  • Hospede localmente e use preload + font-display: swap.
@font-face{
  font-family:"Inter";
  src:url("/fonts/Inter-400.woff2") format("woff2");
  font-weight:400;font-style:normal;font-display:swap;
}

8) Terceiros: audite e combine

  • Remova tags duplicadas (analytics/pixel/chat).
  • Carregue via consent mode e delay até interação.
  • Self-host de SDKs estáveis (quando licenças permitirem).
<script>
// atraso simples: só após interação
let armed=false;
const arm=()=>{ if(armed) return; armed=true; const s=document.createElement('script'); s.src='/js/analytics.js'; s.defer=true; document.head.append(s); };
['click','scroll','keydown'].forEach(e=>addEventListener(e,arm,{once:true,passive:true}));
</script>

9) Build: agrupe de forma inteligente

  • Use code-splitting por rota e vendor chunks.
  • Em HTTP/2/3, evite mega-bundles. Prefira poucos pacotes relevantes.
  • Remova CSS/JS não utilizados (tree-shaking + purge).
// vite.config.js (exemplo de manualChunks)
export default {
  build: {
    rollupOptions: {
      output: {
        manualChunks: {
          vendor: ['react','react-dom']
        }
      }
    }
  }
}

10) Cache forte para evitar requisições repetidas

# Nginx — assets versionados com cache longo
location ~* \.(?:css|js|woff2?|jpg|jpeg|png|gif|svg|webp|ico)$ {
  add_header Cache-Control "public, max-age=31536000, immutable";
  try_files $uri =404;
}

Versione arquivos no nome (hash). O navegador não precisa refazer pedidos em cada visita.

11) Service Worker: cache offline/prime

// sw.js — cache-first simples para estáticos
self.addEventListener('install', e => {
  e.waitUntil(caches.open('v1').then(c => c.addAll([
    '/', '/assets/app.css', '/assets/app.js', '/fonts/Inter-400.woff2'
  ])));
});
self.addEventListener('fetch', e => {
  e.respondWith(caches.match(e.request).then(r => r || fetch(e.request)));
});

Menos requisições após a primeira visita. Mais rapidez em navegação interna.

12) WordPress: passos rápidos

  • Desative emojis nativos e embeds se não usa.
  • Desregistre scripts/estilos de plugins em páginas onde não são usados.
  • Combine ícones em sprite SVG e hospede fontes localmente.
<?php
// functions.php — remover emojis
remove_action('wp_head','print_emoji_detection_script',7);
remove_action('wp_print_styles','print_emoji_styles');

// desregistrar assets de um plugin numa página específica
add_action('wp_enqueue_scripts', function(){
  if(!is_page('contato')){
    wp_dequeue_style('contact-form-7');
    wp_dequeue_script('contact-form-7');
  }
}, 100);

13) CDN e HTTP/3

Entregue estáticos por CDN próxima do usuário. Ative HTTP/3 + Brotli. Menos round trips, menos conexões paralelas.

14) Checklist rápido

  • Remover libs e plugins não usados.
  • Inline do CSS crítico. Resto assíncrono.
  • JS por rota + defer + import().
  • Sprite SVG para ícones.
  • Fontes com poucos pesos, local e swap.
  • Imagens com srcset, lazy e hero com preload.
  • Cache longo e versionamento por nome.
  • Service Worker cache-first para estáticos.
  • Auditar terceiros. Carregar sob demanda.

Perguntas Frequentes (FAQ)

Ainda faz sentido concatenar todos os arquivos?

Menos. Em HTTP/2/3 a multiplexação diminui a necessidade de mega-bundles. Prefira poucos pacotes por rota e cache agressivo. Sprites de imagem (PNG) valem a pena?

Hoje o melhor é sprite SVG para ícones vetoriais. Para bitmaps, foque em WebP/AVIF, srcset e cache. Sprites PNG são casos raros. Devo hospedar fontes do Google localmente?

Sim, quando possível. Menos dependência externa. Menos requisições a terceiros. Controle de cache total. Remover o jQuery melhora muito?

Depende do site. Em páginas simples, remover corta 1–2 requisições e dezenas de KB. Em apps legados, troque por JS nativo aos poucos. Posso usar HTTP/3 para reduzir requisições?

HTTP/3 não reduz o número, mas reduz o custo de cada pedido. Combine com cache e inlining crítico. Service Worker não é complicado?

O básico é simples. Um SW cache-first para estáticos já corta muitas requisições em navegação interna. Como medir o impacto?

Use DevTools (aba Network). Compare número de requests e tamanho transferido. Acompanhe LCP/FCP no PageSpeed. Lazy load atrapalha SEO?

Não, se feito corretamente. Imagens críticas não devem ser lazy. Garanta atributos de dimensão e conteúdo acima da dobra. Posso reduzir requisições sem mexer em código?

Sim. Desative plugins, remova widgets externos, ative cache/CDN e otimize configurações de tema. Qual o primeiro passo prático?

Audite a página inicial. Liste tudo que carrega no above the fold. Corte o que não é visto de imediato.

Tags

reduzir requisições http, performance web, css crítico, lazy load, sprite svg, fontes locais, cache, service worker, code splitting, http/2, http/3, webp, cdn, otimização de site, lighthouse, lcp, fcp

“É necessário construir frases curtas. Toda otimização dividirá em, no mínimo, duas frases.”

O QUE NOSSOS CLIENTES ESTÃO DIZENDO?

Velocidade e Confiabilidade, para o seu Site Decolar!

Fale conosco

Negócio Digital Color White