Remover CSS que bloqueia a renderização no Next.js para obter melhores Core Web Vitals
Remova o CSS que bloqueia a renderização no Next.js para obter Core Web Vitals mais rápidos

Remover CSS que bloqueia a renderização no Next.js
O CSS bloqueia a renderização. O navegador não pintará um único pixel até ter baixado e analisado todas as folhas de estilo no <head>. Em um aplicativo Next.js, isso significa dois arquivos CSS externos por padrão: uma folha de estilo global e uma folha de estilo específica da página. Em uma conexão 3G rápida, o download desses dois arquivos custa 600ms antes mesmo de o navegador começar a renderizar. Isso significa 600ms adicionados diretamente ao seu First Contentful Paint e Largest Contentful Paint.
Última revisão por Arjen Karel em março de 2026
Table of Contents!
- Remover CSS que bloqueia a renderização no Next.js
- App Router vs Pages Router
- Opção 1: Gerar CSS crítico (Pages Router)
- Opção 2: Inserir todo o CSS inline no head (Pages Router)
- Opção 3: Styled Components (Pages Router)
- Opção 4: CSS inline com inlineCss (App Router, Next.js 15+)
- Uma observação sobre CSS Modules e Tailwind CSS
- Qual opção devo usar?
Em média, em todos os meus clientes e em todos os dispositivos, eu meço cerca de 200ms de atraso causado pelo CSS que bloqueia a renderização. De acordo com o Web Almanac de 2025, 85% das páginas móveis ainda falham na auditoria de recursos que bloqueiam a renderização. A página mediana carrega 8 arquivos CSS totalizando 79 KB. Em conexões móveis lentas, o atraso de renderização pode representar 69% do tempo total de LCP. É hora de corrigir isso.

App Router vs Pages Router
A correção depende de qual roteador do Next.js você usa. O Pages Router (usando _document.tsx) e o App Router (usando app/layout.tsx) lidam com a entrega de CSS de forma diferente. A inserção inline de CSS crítico através do critters não funciona com o App Router porque o streaming é incompatível com a forma como o critters processa o HTML. Se você estiver no App Router, pule para a Opção 4.
O App Router é o padrão desde o Next.js 13.4. Mas muitos aplicativos em produção ainda rodam o Pages Router, e as três primeiras opções abaixo continuam válidas para eles.
Opção 1: Gerar CSS crítico (Pages Router)
A opção mais rápida é gerar CSS crítico. O CSS crítico é uma coleção de regras CSS necessárias para renderizar a parte visível da página. Essas regras são colocadas inline no <head>. Então, em paralelo, os arquivos CSS originais são baixados enquanto o navegador continua a renderizar. Uma vez que os arquivos CSS originais são baixados, eles são injetados na página.
O CSS crítico está disponível no Next.js como um recurso experimental. Adicione experimental: { optimizeCss: true } ao seu next.config.js. O Next.js agrupa a biblioteca critters internamente, então você não precisa instalá-la separadamente. Observe que o pacote critters original está obsoleto (substituído pelo fork beasties), mas o Next.js ainda não fez a mudança.
const nextConfig = {
reactStrictMode: true,
experimental: { optimizeCss: true }
}
Esta opção funciona apenas com o Pages Router. Ela não suporta o App Router porque o critters precisa de todo o HTML renderizado, o que é incompatível com o streaming.
Opção 2: Inserir todo o CSS inline no head (Pages Router)
Se você não deseja habilitar recursos experimentais em seu aplicativo Next.js, você pode considerar a inserção inline do seu CSS manualmente. Crie uma seção head personalizada e referencie-a no seu _document.tsx.
A desvantagem é que o CSS inline será maior do que com o primeiro método porque você está inserindo tudo inline, não apenas as regras críticas. No entanto, se você mantiver suas folhas de estilo limpas e enxutas, isso melhorará significativamente os Core Web Vitals para o seu aplicativo Next.js.
import { Html, Head, Main, NextScript } from "next/document";
import { readFileSync } from "fs";
import { join } from "path";
class InlineStylesHead extends Head {
getCssLinks: Head["getCssLinks"] = ({ allFiles }) => {
const { assetPrefix } = this.context;
if (!allFiles || allFiles.length === 0) return null;
return allFiles
.filter((file: any) => /\.css$/.test(file))
.map((file: any) => (
<style
key={file}
nonce={this.props.nonce}
data-href={`${assetPrefix}/_next/${file}`}
dangerouslySetInnerHTML={{
__html: readFileSync(join(process.cwd(), ".next", file), "utf-8"),
}}
/>
));
};
}
export default function Document() {
return (
<Html>
<InlineStylesHead />
<body>
<Main />
<NextScript />
</body>
</Html>
);
}
Opção 3: Styled Components (Pages Router)
Styled Components é uma ferramenta de CSS-in-JS que permite escrever CSS em arquivos JavaScript. Você pode criar escopo para nomes de classes, remover CSS não utilizado automaticamente e gerenciar estilos juntamente com seus componentes. Para os Core Web Vitals, isso significa que apenas os estilos necessários naquela página são injetados.
Adicione compiler: { styledComponents: true } ao seu next.config.js, instale o styled-components (yarn add styled-components e yarn add -D @types/styled-components), e então atualize _document.js para suportar a renderização do lado do servidor para componentes estilizados.
const nextConfig = {
reactStrictMode: true,
compiler: {
styledComponents: true,
}
}
import Document, { DocumentContext } from "next/document";
import { ServerStyleSheet } from "styled-components";
export default class MyDocument extends Document {
static async getInitialProps(ctx: DocumentContext) {
const sheet = new ServerStyleSheet();
const originalRenderPage = ctx.renderPage;
try {
ctx.renderPage = () =>
originalRenderPage({
enhanceApp: (App) => (props) =>
sheet.collectStyles(<App {...props} />),
});
const initialProps = await Document.getInitialProps(ctx);
return {
...initialProps,
styles: (
<>
{initialProps.styles}
{sheet.getStyleElement()}
</>
),
};
} finally {
sheet.seal();
}
}
}
Se você usar o App Router com styled-components, você precisará de uma configuração diferente. Crie um componente cliente de registro de estilo usando useServerInsertedHTML e envolva seu layout raiz com ele. Componentes estilizados funcionam apenas em Client Components no App Router. Consulte o guia de CSS-in-JS do Next.js para ver o padrão completo.
Opção 4: CSS inline com inlineCss (App Router, Next.js 15+)
Para o App Router, o Next.js 15 introduziu experimental.inlineCss. Isso substitui todas as tags de folha de estilo <link> por tags <style> inline, eliminando inteiramente a cascata de bloqueio de renderização.
const nextConfig = {
experimental: {
inlineCss: true,
}
}
Isso ainda é experimental e a equipe do Next.js ainda não recomenda para produção. Ele insere todo o CSS inline (não apenas o CSS crítico), o que aumenta o tamanho do HTML. Para sites que usam Tailwind CSS, esse trade-off funciona bem porque o Tailwind gera pacotes de CSS pequenos e atômicos. Para sites com folhas de estilo grandes, o inchaço do HTML pode prejudicar o Time to First Byte.
Uma observação sobre CSS Modules e Tailwind CSS
CSS Modules e Tailwind CSS são as duas abordagens de estilização mais populares no Next.js hoje. Ambos compilam para arquivos CSS padrão no momento do build e são servidos como tags <link>. Isso significa que eles bloqueiam a renderização por padrão.
O Tailwind tem uma vantagem: como ele expurga classes não utilizadas, a saída é tipicamente muito pequena (frequentemente menos de 10 KB compactado com gzip). O impacto de bloqueio de renderização de um arquivo de 10 KB é mínimo. Os CSS Modules podem crescer se você não tomar cuidado com estilos não utilizados.
De qualquer forma, todas as opções acima se aplicam. Se você deseja eliminar completamente o CSS que bloqueia a renderização, combine sua abordagem de estilização preferida com optimizeCss (Pages Router) ou inlineCss (App Router).
Qual opção devo usar?
Depende do seu roteador e da sua estratégia de CSS:
- App Router + Tailwind: Use
inlineCss. Pequenos pacotes de CSS tornam a inserção inline prática. - App Router + CSS grande: Espere o
inlineCssse estabilizar ou use uma configuração personalizada do beasties. - Pages Router: Use
optimizeCss(Opção 1). É a correção mais simples e insere inline apenas o que é crítico. - Pages Router + CSS-in-JS: Use styled-components ou Emotion com os padrões de SSR mostrados acima.
Entre os sites Next.js monitorados pelo CoreDash, aqueles que usam CSS crítico inline mostram uma melhoria mediana de FCP de 400ms em comparação com a entrega de CSS padrão. Essa é a diferença entre um FCP score bom e medíocre.
Qualquer que seja a opção escolhida, verifique os resultados com o Monitoramento de Usuários Reais (RUM). Pontuações de laboratório dizem o que pode acontecer. Dados de campo dizem o que realmente aconteceu.
Para saber mais sobre como o CSS e o JavaScript interagem com o pipeline de renderização, consulte o guia completo para corrigir recursos que bloqueiam a renderização. Se você estiver otimizando um aplicativo Next.js, verifique também os guias sobre como corrigir scripts de terceiros e como medir os Core Web Vitals no Next.js. Para uma visão mais ampla sobre a estratégia de carregamento, o guia de priorização de recursos aborda como os navegadores decidem o que buscar primeiro.
Performance degrades unless you guard it.
I do not just fix the metrics. I set up the monitoring, the budgets, and the processes so your team keeps them green after I leave.
Start the Engagement
