PRNext 0.1.18 versus Next.js: CPU, RAM e sono

#Os resultados em resumo

Com duas CPUs e 1 GiB, o candidato atinge 224.70 respostas por segundo versus 142.97 na página 100-row SSR, cerca de 57% a mais de rendimento. Na página 1,000-row com o mesmo orçamento, Next.js lidera. A hidratação medida também é mais rápida com Next.js em ambas as máquinas VPS.

No VPS pequeno, o custo comum do SSR CPU cai cerca de 37%, mas o PRNext usa mais memória. O sono do trabalhador libera RAM em troca de um despertar mais lento. As seções a seguir fornecem versões, medidas e limitações de cada cenário.

Explore medições por CPU orçamento, memória e cenário

#A versão exata por trás dos números

As medições de outubro 29, 2026 usam o candidato de desenvolvimento 0.1.18-alpha no commit 2856155. Seu manifesto ainda carregava a versão interna 0.1.17-alpha, mas seu código e otimizações diferem do pacote npm 0.1.17-alpha. A fonte medida exata e os hashes do artefato estão vinculados no final deste artigo.

A referência é Next.js 16.4.3, usando a mesma família React 19.3.1 e fonte de aplicação. O pequeno VPS executa Node.js 22.23.4; o grande executa Node.js 24.22.1. Dentro de cada máquina, cada mecanismo usa exatamente o mesmo executável do Node. As diferenças entre máquinas não podem ser atribuídas apenas ao hardware porque o Node também muda.

PRNext executa o perfil Balanceado e seu renderizador da Web padrão. Os dados associados incluem o binário Linux completo e os hashes do pacote candidato, resultados antes das correções e intervalos de rendimento. A versão npm 0.1.18-alpha publicada em outubro 30 vem do commit 05a9ccd, com correções adicionais de construção e desenvolvimento. Esta campanha, portanto, não mede nem o pacote npm 0.1.17-alpha nem os arquivos 0.1.18-alpha finais. Os números descrevem o candidato identificado sem atribuir uma nova referência às alterações subsequentes.

#O que medimos

O primeiro VPS possui uma vCPU e cerca de 1.9 GiB de RAM. O segundo possui oito vCPUs e cerca de 23 GiB. Os processos de destino recebem cgroup v2 CPU e limites de memória sem troca. A máquina pequena está limitada a 70% de um CPU e 700 MiB; a máquina grande é testada em um CPU e 384 MiB, duas CPUs e 1 GiB, depois quatro CPUs e 2 GiB.

A matriz principal contém janelas 96: quatro orçamentos, quatro cenários, três variantes e duas passagens alternadas. As variantes são PRNext antes das correções, o candidato medido PRNext e Next.js. Cada janela tem cinco segundos de aquecimento seguidos de quinze segundos medidos, usando dezesseis conexões e gzip. As tabelas comparam o candidato com Next.js e informam a mediana das duas janelas para cada métrica.

Os cenários são uma página 100-row SSR dinâmica, uma página 1,000-row, uma JSON API de dezesseis entradas e uma página com atraso de suspense 40 ms. Identificadores e cookies atualizados verificam a correção e o isolamento da resposta. A taxa de transferência conta apenas respostas validadas e bem-sucedidas. Esta não é uma comparação de páginas estáticas servidas por um CDN.

O p95 é a duração dentro da qual 95% das solicitações terminam em uma janela. CPU são milissegundos de trabalho de CPU por resposta bem-sucedida, não latência. RAM é o tamanho médio do conjunto proporcional, ou PSS, em toda a árvore de processos de destino, incluindo o mecanismo nativo e os trabalhadores do Node. Uma resposta pode levar 100 ms enquanto usa apenas alguns milissegundos de CPU.

O gerador de carga tem limites separados, mas compartilha o único CPU físico do pequeno VPS. Os cenários API rápidos podem atingir seu teto, especialmente na máquina pequena e no cenário quatro-CPU. Os serviços existentes permanecem ativos: as cotas não eliminam a contenção nestes VPSs. Duas passagens curtas não fornecem um intervalo de confiança. Pequenas diferenças não devem tornar-se promessas de marketing.

#VPS pequeno: menos CPU, sem uma vitória geral de RAM

Em 0.7 CPU e 700 MiB, PRNext fornece respostas de 81.33 SSR por segundo contra 51. de Next.js. Seu p95 é 264.25 ms contra 420.90 ms. O custo de CPU cai de 13.39 para 8.46 ms por resposta, cerca de 37% menos. A memória, entretanto, é 113.88 MiB contra 101.38 MiB: PRNext usa cerca de 12% mais nesta página.

O streaming atinge 138.13 solicitações por segundo em relação a 80.03, com cerca de 42% menos CPU por resposta. A página pesada está muito mais próxima, em 11.33 contra 10.33 solicitações por segundo. O API favorece o PRNext nesta campanha, mas a competição do gerador pelo mesmo CPU físico permanece uma limitação.

PRNext usa mais PSS que Next.js em todos os quatro cenários desta máquina. A vantagem observada é principalmente a eficiência de CPU em SSR comum e streaming. Uma afirmação geral de RAM inferior representaria mal estes resultados.

#Um CPU e 384 MiB: uma restrição e compensação diferentes

No grande VPS limitado a um CPU e 384 MiB, a página SSR atinge 99.77 solicitações por segundo contra 59.90. CPU o custo é cerca de 41% menor e o PSS cerca de 13% menor. O streaming atinge 220.90 em relação a 86.27 solicitações por segundo, usando 4.51 em relação a 11.47 ms de CPU por resposta.

A política de memória mais restrita do candidato também reduz RAM em relação ao nosso código PRNext anterior, mas o API perde cerca de 13% de taxa de transferência em relação ao código anterior. PRNext ainda lidera Next.js nesta medição; isso não apaga a regressão interna. O equilíbrio entre coleta de lixo e rendimento precisa de mais trabalho.

#Duas CPUs: um claro ganho SSR e um limite de renderização pesado

Com duas CPUs e 1 GiB, a página 100-row SSR atinge 224.70 solicitações por segundo em PRNext contra 142.97 em Next.js. Isso representa 57% mais rendimento, cerca de 26% menos CPU por resposta e 32% menos PSS. O p95 é 89.80 ms contra 154.60 ms.

A página 1,000-row inverte o resultado: Next.js atinge 27.63 solicitações por segundo contra 24, de PRNext com um p95 de 622.20 ms contra 740.80 ms. PRNext usa menos RAM, mas cerca de 29% mais CPU por resposta. A renderização pesada de React continua sendo uma meta concreta de melhoria.

O streaming retém cerca de 56% mais taxa de transferência e cerca de 30% menos CPU por resposta. Estes resultados aplicam-se a esta aplicação, perfil e orçamento dinâmicos, e não a todos os projetos React.

#Quatro CPUs: a topologia também é importante

Com quatro CPUs e 2 GiB, PRNext usa dois trabalhadores. Next.js usa dois processos atrás de um proxy de nó privado, cujos CPU e RAM estão incluídos. Os outros três orçamentos utilizam servidores diretos. Essa diferença de topologia faz parte do resultado.

PRNext atinge 383.30 SSR solicitações por segundo em relação a 247.13 para esta referência Next.js. Seu PSS é 206.60 MiB contra 458.33 MiB. Isso não estabelece uma economia universal de 55% RAM: uma topologia ou proxy diferente pode alterar o resultado. O API também pode alcançar o teto do gerador.

O candidato perde cerca de 10% de rendimento de SSR e cerca de 6% na página pesada em comparação com nosso código PRNext anterior com este orçamento. Mais CPUs não garantem que todos os caminhos melhorem. O escalonamento entre trabalhadores e as alocações de renderização pesada ainda precisam de trabalho.

#Navegação: corrigindo nossa própria regressão

A primeira auditoria encontrou um retorno incomumente lento a uma página grande. O transporte diferencial de vôo produziu muitos fragmentos pequenos. O candidato limita o trabalho de comparação, agrupa os dados disponíveis e retém um substituto de resposta completa quando uma diferença não vale a pena. O objetivo é reduzir o trabalho sem esperar por futuros blocos de streaming.

No Chromium 153, repetimos uma jornada de página grande, página pequena e retorno à página grande. Cada jornada verifica 3,000 células visíveis, estado do contador e identidade do documento. No VPS pequeno, o retorno de PRNext cai de 1,475.6 para 307.2 ms; no grande, de 932.1 a 228.6 ms.

O ganho de aproximadamente quatro a cinco vezes é contra nosso código PRNext anterior, não Next.js. O candidato fica um pouco atrás de Next.js nesta jornada no pequeno VPS e avança no grande. Oito contextos por variante são executados em um PC através de um túnel; estes não são Core Web Vitals coletados pelos visitantes.

A hidratação não apresenta a mesma melhora. Sua mediana é 421.6 ms para PRNext contra 349.8 ms para Next.js no VPS pequeno e 399.2 contra 299.1 ms no grande. Transferir menos bytes não é suficiente para tornar o cliente interativo mais rapidamente.

#Modo de suspensão: libere RAM entre visitas

Um site de baixo tráfego não passa o dia saturando um processador. A memória ociosa pode ser mais importante do que o pico de produtividade. PRNext pode retirar seus trabalhadores do Node após um período ocioso enquanto mantém o servidor Rust escutando. A próxima solicitação de renderização recria os trabalhadores necessários.

Testamos esse mecanismo no VPS pequeno com uma página SSR simples e um limite de inatividade acelerado de dois segundos. A memória é observada após a aposentadoria do trabalhador, que durou cerca de dois segundos; o controle de manter aquecido espera cerca de seis segundos. Esta é uma sonda funcional por configuração, separada dos testes de carga e resistência.

Nesta investigação, o PSS cai para cerca de 10.5 MiB após a aposentadoria do trabalhador, contra 106.8 MiB quando mantido aquecido. O custo aparece na solicitação de ativação: cerca de 1.13 segundos em relação a 22.6 ms. A figura 10.5 MiB descreve a árvore de processos deste aplicativo simples nesse estado, não o VPS inteiro ou todos os aplicativos.

O pré-aquecimento de inicialização com --prewarm inicializa a estrutura antes de aceitar solicitações. Ele não impede a desativação ociosa subsequente e não chama páginas de aplicativos ou manipuladores API. Para reter os hosts de renderização usados, a configuração explícita é --worker-idle-seconds 0. O pré-aquecimento por si só, portanto, não elimina o custo de acordar após dormir.

Nenhuma configuração de suspensão Next.js equivalente foi testada neste teste. Não estabelece que a infraestrutura externa não possa parar ou reiniciar Next.js.

#Benefícios indiretos para hospedagem compartilhada

Para vários projetos pequenos visitados em momentos diferentes, a liberação da memória dos trabalhadores inativos pode deixar mais espaço para aplicativos ativos. Uma melhor eficiência do CPU também pode deixar um trabalho mais útil dentro da mesma cota. Isto pode ser relevante para pequenos sites públicos, demonstrações e ferramentas internas intermitentes.

Esta é uma inferência das medições, não uma referência de densidade de hospedagem. Não estabelecemos quantos projetos adicionais cabem em um servidor nem medimos uma conta ou economia de energia. O sistema operacional, banco de dados, gateway, rajadas e ativações simultâneas também consomem recursos.

A estrutura também possui um comando local prnext host que pode colocar um aplicativo inteiro em suspensão atrás de um gateway. Isto é separado da aposentadoria do trabalhador medida aqui. O gateway permanece ativo; solicitações e conexões rastreadas protegem o trabalho em andamento e uma visita posterior pode ativar o aplicativo. Esta campanha não quantifica o seu custo total.

O sono descarta o estado mantido apenas dentro dos processos. Os dados duráveis ​​pertencem ao disco ou a um serviço apropriado; o trabalho em segundo plano não rastreado não deve depender de um processo permanecer ativo. O serviço gerenciado PRNext Host é outra camada novamente. Este artigo não mede seu preço ou desempenho de implantação.

#Estabilidade observada e os limites do teste

Seis execuções de carga mista de dez minutos cobrem as três variantes em ambos os VPSs. Cada execução é seguida por trinta cancelamentos de streaming e 46 segundos de silêncio. Nenhuma falha de conteúdo, erros de carregamento ou perda de memória dos servidores testados foram observadas nessas campanhas finais.

Uma tentativa inicial de resistência expôs a retenção de memória no gerador de carga, não no servidor testado. Após a fixação da ferramenta, todas as seis execuções finais foram repetidas integralmente com o mesmo gerador corrigido. O link da ferramenta aponta para o commit fb59284, separado do commit do mecanismo medido.

A memória ainda varia: no grande VPS restrito, PRNext passa de 119.0 para 130.4 MiB entre o primeiro e o último minuto. Seu rendimento misto está cerca de 12% abaixo do nosso código PRNext anterior nessa configuração. Dez minutos não estabelecem ausência de vazamentos nem estabilidade ao longo de várias semanas.

Após o cancelamento e a espera, os descritores de arquivo de PRNext voltam para 44.. Isso não é suficiente para declarar um vazamento ou descartá-lo em períodos mais longos. A verificação do navegador adiciona contextos cronometrados 48 e dez verificações funcionais, incluindo substitutos forçados. Não demonstra compatibilidade completa com todos os aplicativos Next.js.

#O que esses resultados significam para PRNext

O argumento mais forte é a eficiência do CPU para o SSR comum e o streaming em vários orçamentos restritos. A memória também pode ser favorável, mas não está no pequeno VPS físico desta campanha. O sono oferece outra opção para projetos intermitentes: liberar RAM ou preservar uma resposta calorosa.

As próximas prioridades são alocações pesadas de renderização, hidratação, regressões de rendimento sob alguns orçamentos e escalonamento entre trabalhadores. As poucas medidas de construção nesta campanha também não apoiam uma afirmação geral de construções mais rápidas.

PRNext permanece experimental e sua compatibilidade com Next.js é parcial. Para decidir se ele se adapta à sua aplicação, reproduza suas rotas caras, tráfego, períodos de silêncio e despertares com um artefato identificado. Estes resultados fornecem um ponto de partida verificável e não uma classificação universal de estruturas.

Como avaliar o desempenho de React SSR

Quanto RAM Next.js precisa em um VPS?

PRNext e Next.js: guia de compatibilidade e migração