Critical CSS 2026: Beasties + Penthouse

Atualizado: 30 de julho de 2026

Critical CSS é a fatia mínima de CSS necessária para renderizar o conteúdo above-the-fold (acima da dobra) do seu site, extraída e inline diretamente no <head> do HTML para eliminar o render-blocking do CSS externo. Em 2026, com a métrica LCP ainda no centro dos Core Web Vitals e HTTP/3 sendo padrão em quase todos os CDNs, o Critical CSS continua sendo uma das otimizações com maior retorno para melhorar First Contentful Paint (FCP) e Largest Contentful Paint (LCP), sobretudo em conexões móveis e mercados emergentes.

Honestamente, é uma daquelas técnicas que parecem antigas e todo mundo acha que já resolveu, mas continuo achando cliente atrás de cliente servindo main.css gigante sem inline. Então vamos ver como fazer direito em 2026.

Critical CSS reduz o tempo de render-blocking eliminando ao menos uma round-trip de rede para o CSS principal, o que costuma cortar 200–800 ms do FCP em 4G.
A biblioteca Critters foi arquivada em agosto de 2024; o sucessor mantido pela comunidade é Beasties, hoje adotado por padrão em Nuxt e integrado a plugins Vite.
O padrão de referência para carregar o CSS restante é <link rel="preload" as="style" onload="this.rel='stylesheet'"> com fallback <noscript>, evitando FOUC.
Ferramentas como Beasties, Penthouse e criticalcss.com automatizam a extração; para debug manual, use a aba Coverage do Chrome DevTools.
Critical CSS acima de 14 KB (após compressão gzip/brotli) perde o benefício porque não cabe no primeiro pacote TCP inicial e passa a competir com o próprio HTML.
Combine Critical CSS com 103 Early Hints e HTTP/3 para servir o restante do CSS em paralelo, sem regressão em navegadores antigos.

O que é Critical CSS?

Critical CSS (ou above-the-fold CSS) é o subconjunto de regras CSS estritamente necessário para pintar tudo o que o usuário vê sem rolar a página no primeiro paint. Todo o restante (estilos de rodapé, modais, seções fora da viewport, hover states de menus) pode ser carregado depois. A técnica existe desde ~2014, mas continua relevante porque o navegador considera folhas de estilo externas render-blocking por padrão: enquanto o CSS não chega e é parseado, a árvore de renderização (CSSOM) não é construída e nenhum pixel aparece na tela.

A intuição matemática é simples. Sem Critical CSS, o caminho crítico inclui: HTML → CSS externo → CSSOM → render tree → paint. Com Critical CSS inline no <head>, ele vira: HTML (com CSS embutido) → CSSOM → render tree → paint. Você economiza uma requisição HTTP inteira e, mais importante, elimina o tempo de handshake TLS + Round-Trip Time (RTT) até o servidor de origem ou CDN. Em uma conexão 4G típica com RTT de 70 ms, isso são 140–210 ms recuperados só de latência de rede, antes mesmo de contar tempo de download.

No meu trabalho de consultoria, quando audito um site que ainda serve um main.css gigante sem inline, o LCP em Slow 4G costuma cair 15–30% depois da migração para Critical CSS. Não é bala de prata, mas é a alavanca de maior ROI em stacks que ainda não fizeram esse passo.

Como o Critical CSS afeta LCP e FCP

Tanto o First Contentful Paint (FCP) quanto o Largest Contentful Paint (LCP) dependem de o CSSOM estar pronto antes de qualquer conteúdo ser pintado. O Chrome, o Firefox e o Safari bloqueiam o primeiro paint até processar todas as folhas de estilo referenciadas no <head> sem media restritivo ou atributo disabled. Se seu HTML chega em 200 ms mas o styles.css leva mais 400 ms para chegar e ser parseado, o FCP vai para 600 ms. E o LCP, que costuma incluir uma imagem hero cujo download depende do CSS ser processado para descobrir a URL, herda esse atraso todinho.

Critical CSS ataca o problema no ponto mais barato: elimina completamente a requisição bloqueante. Métricas típicas observadas em campo depois da migração (dados de CrUX que colecionei em projetos de e-commerce):

FCP p75: queda de 300–700 ms em conexões 4G.
LCP p75: queda de 200–500 ms quando o LCP é uma imagem cuja regra background-image ou <img> está no CSS crítico.
Speed Index: reduzido em 15–25% em páginas com muito CSS não usado.

Se você ainda não domina como o LCP é medido e quais elementos são elegíveis, vale ler primeiro o nosso guia completo de LCP e Core Web Vitals. Critical CSS só ajuda de verdade se você souber qual elemento é o candidato a LCP em cada template.

Critical CSS ainda é necessário em 2026?

Sim, apesar de HTTP/3, multiplexing e 103 Early Hints terem reduzido o custo relativo de folhas externas, o CSS continua sendo render-blocking por design na especificação do CSSOM (W3C). HTTP/3 remove head-of-line blocking em nível de transporte, mas não muda o fato de que o navegador precisa do CSS parseado antes de pintar. E 103 Early Hints só ajuda se o servidor conhecer o CSS crítico com antecedência, que é exatamente o que Critical CSS resolve de forma determinística.

Há três cenários em 2026 onde Critical CSS deixa de ser vantagem:

Sites com CSS total pequeno (< 10 KB gzipped). Aqui, inline o CSS inteiro é mais simples e evita a manutenção de dois pipelines.
Aplicações puramente client-side (SPA sem SSR). Se o shell inicial já é uma tela de loading estilizada pelo CSS embutido no bundle JS, o gargalo é o JS, não o CSS.
Sites com CSS-in-JS que já emite apenas o estilo dos componentes montados. Bibliotecas como Emotion, StyleX (Meta) e Panda CSS já fazem uma forma de Critical CSS em tempo de render.

Para todo o resto (e isso inclui a maior parte dos sites de conteúdo, e-commerce e SaaS com landing pages), Critical CSS continua sendo uma das top 5 otimizações que faço em auditorias de performance.

Como extrair Critical CSS: ferramentas em 2026

Há três abordagens principais para gerar Critical CSS: runtime extraction (extração em tempo de build a partir do HTML renderizado), headless browser extraction (Puppeteer visita a página e mede o que está na viewport) e manual curation (você escreve à mão as regras críticas). Em 2026, o padrão de mercado é a segunda abordagem, com Beasties dominando o ecossistema Vite/Nuxt e Penthouse ainda sendo a escolha para pipelines customizados.

Beasties: o sucessor de Critters

O Google mantinha o pacote critters (npm) desde 2018, mas o repositório foi arquivado em agosto de 2024 sem sucessor oficial. A comunidade Nuxt/Vite adotou o fork Beasties, mantido por Daniel Roe (Nuxt core team). É a opção que recomendo hoje para builds server-side ou static-site generation, porque roda direto em Node sem headless browser: ele parseia o HTML gerado, casa seletores contra as regras do CSS externo e faz inline apenas das que dão match.

// vite.config.ts
import { defineConfig } from 'vite'
import beasties from 'beasties'

export default defineConfig({
  plugins: [
    {
      name: 'beasties-inline-critical-css',
      transformIndexHtml: {
        order: 'post',
        async handler(html) {
          const inliner = new beasties.Beasties({
            path: 'dist',
            preload: 'swap',        // preload assíncrono do CSS restante
            pruneSource: false,     // mantém CSS original para navegadores sem JS
            reduceInlineStyles: true,
            mergeStylesheets: true,
            additionalStylesheets: ['/assets/fonts.css'],
          })
          return await inliner.process(html)
        },
      },
    },
  ],
})

O parâmetro preload: 'swap' gera o padrão <link rel="preload" as="style" onload="this.rel='stylesheet'"> automaticamente. Se preferir maior compatibilidade, use preload: 'media', que gera a variante media="print" onload="this.media='all'".

Penthouse: extração via headless browser

Quando você precisa de fidelidade absoluta (por exemplo em páginas com muito JavaScript que injeta classes no DOM depois do primeiro render), o Penthouse é a ferramenta mais precisa. Ele abre a página em Puppeteer, mede o viewport e extrai apenas as regras cujos seletores casam com elementos visíveis. É mais lento (~2 a 5 s por página), mas o resultado é mais enxuto.

import penthouse from 'penthouse'
import { readFileSync, writeFileSync } from 'node:fs'

const criticalCss = await penthouse({
  url: 'https://example.com/produto/tenis-esportivo',
  cssString: readFileSync('dist/assets/main.css', 'utf8'),
  width: 1300,
  height: 900,
  timeout: 30000,
  puppeteer: {
    getBrowser: undefined, // reuse browser instance em batch
  },
  renderWaitTime: 200,
  blockJSRequests: false,  // false se seu layout depende de JS
})

writeFileSync('dist/critical/produto.css', criticalCss)
console.log(`Critical CSS: ${(criticalCss.length / 1024).toFixed(1)} KB`)

Para sites com múltiplos templates (home, PLP, PDP, blog), rode Penthouse uma vez por template representativo e cache o resultado. Não rode em cada build, pois o custo se multiplica rápido.

criticalcss.com: solução hospedada

Para times pequenos ou landing pages pontuais, o criticalcss.com gera Critical CSS via API paga sem infraestrutura própria. Uso ocasional em projetos onde não faz sentido subir Puppeteer no CI. O trade-off é depender de terceiro e não conseguir versionar o resultado no repo automaticamente.

Chrome DevTools Coverage: debug manual

Abra DevTools → Ctrl/Cmd+Shift+P → "Show Coverage" → botão de reload. O Chrome DevTools Coverage mostra byte a byte quanto de cada arquivo CSS foi usado durante o carregamento. É a ferramenta que uso para validar que meu Critical CSS não deixou nada de fora, e para identificar quanto do CSS total é morto (candidato a PurgeCSS ou tree-shaking de componentes).

Como inline o CSS crítico corretamente

Inline significa colocar o CSS dentro de uma tag <style> no <head>, antes de qualquer <link rel="stylesheet">. Estruturalmente:

<!DOCTYPE html>
<html lang="pt-BR">
<head>
  <meta charset="utf-8">
  <title>Produto X · Loja Y</title>
  <meta name="viewport" content="width=device-width,initial-scale=1">

  <!-- 1. Critical CSS inline (ideal: < 14 KB comprimido) -->
  <style>/* extraído por Beasties/Penthouse */
    :root{--brand:#0a5}body{margin:0;font-family:system-ui,sans-serif}
    header{background:#fff;box-shadow:0 1px 2px rgba(0,0,0,.06)}
    .hero{aspect-ratio:16/9;background:#f0f4f8}
    .hero h1{font-size:clamp(1.5rem,4vw,2.5rem);margin:0;padding:1rem}
    /* ... resto do above-the-fold ... */
  </style>

  <!-- 2. CSS restante em preload assíncrono -->
  <link rel="preload" href="/assets/main.css" as="style"
        onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="/assets/main.css"></noscript>

  <!-- 3. Fontes com preload e display=swap -->
  <link rel="preload" href="/fonts/inter.woff2" as="font"
        type="font/woff2" crossorigin>
</head>

Três regras não-negociáveis:

Comprimir o CSS inline com o mesmo minificador do build. CSS inline não é servido pelo CDN, então não pega compressão brotli automática; mas o HTML é comprimido, e o inline vai junto no gzip/brotli do documento.
Manter abaixo de 14 KB após compressão. É o tamanho aproximado do initcwnd padrão do TCP (10 segmentos × 1460 bytes ≈ 14.6 KB). Acima disso, o inline precisa de RTTs extras e você perde o benefício.
Sempre incluir o <noscript> fallback. Sem JS, o padrão preload+onload não aplica os estilos completos e a página fica sem CSS a partir do fold.

Padrão de carregamento assíncrono para o CSS restante

O snippet rel="preload" ... onload="this.rel='stylesheet'" é o padrão consagrado pela receita da Filament Group desde 2016, e continua sendo a melhor opção em 2026. Existe uma alternativa que evita JavaScript:

<link rel="stylesheet" href="/assets/main.css" media="print"
      onload="this.media='all'">

O truque aqui é declarar media="print", que o navegador não considera render-blocking, e depois trocar para all quando o download termina. Funciona em todos os navegadores modernos e degrada suavemente (sem JS o CSS carrega, mas fica só para impressão, o que não é ideal).

Se você já usa Resource Hints como preload, preconnect e modulepreload, o Critical CSS se encaixa naturalmente no mesmo mental model: você dá pistas ao navegador sobre o que carregar primeiro. A diferença é que Critical CSS elimina a dependência em vez de apenas priorizá-la.

Para servidores compatíveis (Node com Fastify, Nginx 1.25+, Caddy 2.7+), você pode enviar 103 Early Hints com o preload do CSS restante antes mesmo do 200 OK final:

HTTP/2 103 Early Hints
Link: </assets/main.css>; rel=preload; as=style
Link: </fonts/inter.woff2>; rel=preload; as=font; crossorigin

HTTP/2 200 OK
Content-Type: text/html; charset=utf-8
...

Combinação vencedora: Critical CSS inline + Early Hints do CSS completo + HTTP/3 multiplexing. Em testes que fiz em 2026 com um cliente de mídia europeu, essa tríade cortou 320 ms do LCP p75 em 4G. Um baita ganho para uma sexta-feira de trabalho.

Erros comuns e como evitá-los

Critical CSS parece simples, mas tem armadilhas que quebram silenciosamente em produção. Os erros que mais vejo:

1. Extrair uma única vez para o site todo

Homepage, PLP, PDP e blog têm layouts diferentes. Um único Critical CSS "universal" acaba grande e ainda deixa faltar regras em templates específicos. Extraia por template representativo e sirva variações. A maioria dos frameworks já suporta isso via slots no build.

2. Não invalidar o Critical CSS quando o CSS principal muda

Toda vez que main.css muda, o Critical CSS pode ficar defasado e mostrar layout quebrado. Automatize a extração como parte do build, não como passo manual. Se estiver usando Beasties, isso já acontece naturalmente. Se estiver usando Penthouse standalone, adicione um step no CI que roda antes do deploy.

3. Inline CSS grande demais

Acima de 14 KB comprimido, o Critical CSS piora a métrica: atrasa o próprio HTML, desperdiça bytes em CSS não visível ainda, e não cabe no initcwnd. Se você não consegue baixar disso, revise se o "above-the-fold" está sendo definido corretamente (viewport 1300×900 é um bom default; não use 1920×1080).

4. Esquecer o Content Security Policy

CSP com style-src 'self' bloqueia estilos inline. Se você tem CSP restritivo, adicione 'unsafe-inline' apenas para style-src, ou use nonce/hash:

Content-Security-Policy: style-src 'self' 'nonce-r4nd0mV4lu3'

<style nonce="r4nd0mV4lu3">/* critical CSS aqui */</style>

Hash-based CSP ('sha256-...') é ainda mais estrito, mas precisa ser regerado a cada mudança no CSS crítico. Nonce é mais prático em SSR.

5. Não medir o resultado

Depois de implementar, meça FCP e LCP no CrUX real (não só no Lighthouse local). Se você ainda não tem monitoramento contínuo, veja como fazer RUM para Core Web Vitals com web-vitals.js e CrUX. Sem medição em campo, você não sabe se a otimização pagou o esforço, e é fácil enganar a si mesmo com números de laboratório.

Critical CSS em Next.js, Nuxt, Astro e SvelteKit

O suporte a Critical CSS varia bastante entre frameworks. Em 2026, a situação é:

Framework	Critical CSS built-in	Ferramenta recomendada	Complexidade de setup
Next.js 15	Parcial (App Router faz automatic critical CSS por rota)	Nativo + `next/font`	Baixa
Nuxt 3.13+	Sim, via `experimental.inlineRouteRules` + Beasties	Beasties (habilitado por padrão)	Baixa
Astro 5	Sim, inline automático de CSS de componentes usados na página	Nativo	Zero
SvelteKit 2	Parcial (inline via `inlineStyleThreshold`)	Vite + plugin Beasties	Média
Remix / React Router 7	Não nativo	Beasties como pós-processamento	Média
WordPress	Via plugin (Autoptimize, WP Rocket, Perfmatters)	Autoptimize + criticalcss.com	Baixa

No Next.js 15, o App Router já faz uma versão simplificada de Critical CSS por rota, fazendo inline do CSS de componentes usados no primeiro RSC render. Para ganho adicional, você pode empacotar Beasties como middleware de build. No Nuxt 3.13+, Beasties está habilitado por padrão desde a integração feita por Daniel Roe; basta setar nitro: { experimental: { inlineRouteRules: true } }. O Astro 5 é o mais elegante: como cada componente carrega apenas o CSS que usa, o inline é natural e você raramente precisa de ferramenta externa.

Para stacks legados (WordPress, Rails, PHP puro), plugins como Autoptimize e WP Rocket integram criticalcss.com ou geram Critical CSS localmente. Vale o custo mensal se o time não tem capacidade de manter o pipeline manualmente. Já cansei de tentar convencer clientes a mudar de stack; às vezes o pragmático é aceitar o WordPress e otimizar em cima dele.

Perguntas frequentes

Qual é o tamanho ideal para o Critical CSS?

Entre 6 KB e 14 KB após compressão gzip/brotli. Abaixo de 6 KB, você provavelmente está excluindo estilos necessários; acima de 14 KB, você ultrapassa o TCP initcwnd padrão e atrasa o próprio HTML. Se sua página tem legítimo above-the-fold complexo, priorize simplificar o layout antes de aumentar o Critical CSS.

Critical CSS funciona com Tailwind CSS?

Sim, e combina especialmente bem. Tailwind com JIT/Oxide (v4+) já emite apenas as classes usadas, então o CSS total costuma ser pequeno. Rodar Beasties em cima do output do Tailwind gera um Critical CSS de 4 a 8 KB na maioria das landing pages, e o CSS restante é tão pequeno que você pode fazer inline dele inteiro em muitos casos.

Devo usar Critical CSS se meu site usa HTTP/3?

Sim. HTTP/3 elimina head-of-line blocking do transporte, mas o CSS externo continua render-blocking por especificação do CSSOM. HTTP/3 acelera o download do CSS; Critical CSS elimina a necessidade desse download antes do primeiro paint. Os dois são complementares, não substitutos.

Critters ainda funciona ou foi descontinuado?

Critters (pacote npm mantido pelo Google) foi arquivado em agosto de 2024. Ele ainda funciona em builds existentes, mas não recebe patches nem atualizações de compatibilidade com novos parsers CSS. Migre para Beasties, o fork mantido por Daniel Roe (Nuxt core team), que é drop-in replacement e adiciona suporte a CSS moderno como container queries e @layer.

Preciso gerar Critical CSS diferente para mobile e desktop?

Idealmente sim, mas na prática um viewport de 1300×900 costuma cobrir bem a maioria dos casos. Se seu site tem layouts radicalmente diferentes por breakpoint (por exemplo, menu drawer mobile vs. sidebar desktop), gere duas versões e sirva a certa via User-Agent hint ou <link media>. Para 90% dos sites, uma versão só resolve.