Por que usar window.location.href em _app.js do Next.js causa recarregamento total da página

Muita gente tenta implementar redirecionamentos de autenticação no Next.js usando window.location.href, e acaba criando um efeito colateral que ninguém espera: o recarregamento completo da página.

---

No React e Next, essa abordagem parece prática, mas não é a mais inteligente. Quando você manipula window.location diretamente, o navegador trata como uma navegação completa, o que faz perder o benefício do SPA e sobrecarrega o servidor. A decisão fica mais saudável quando o time consegue medir o impacto depois.

---

A solução mais adequada é usar o sistema de roteamento do Next.js, que mantém a navegação dentro do cliente, evitando o reload. Você pode usar o hook useRouter e seus métodos push ou replace para fazer a navegação condicional. Sem esse critério, a solução pode parecer simples no começo e cara no suporte. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco.

---

Por exemplo, ao invés de fazer assim:

if(!user){
  window.location.href = '/login'
}

Prefira:

import { useRouter } from 'next/router'

const router = useRouter()

if(!user){
  router.replace('/login')
}

Essa mudança melhora a experiência do usuário, evita recarregamentos desnecessários, e mantém seu app mais performático.

No seu caso, o uso de window.location.href em _app.js pode estar forçando a página a recarregar toda vez que a condição é avaliada, o que é um desperdício de recursos e pode gerar problemas de estado, especialmente se o app depende de contextos ou dados carregados na inicialização. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar. A decisão fica mais saudável quando o time consegue medir o impacto depois.