Next.js: Renderização de fluxo para reduzir TTFB e carga de CPU

Uma coisa a mencionar ..

A renderização de fluxo geralmente não adiciona muitas melhorias de CPU, já que a quantidade de trabalho a ser feita é a mesma. Mas isso reduzirá o tempo de resposta.

É uma boa ideia fornecer uma maneira de personalizar o sistema de renderização SSR. Mas acho que, por enquanto, ficaremos com os métodos renderToString () do React por padrão.

Isso é algo que poderíamos fazer após 2.0.

A renderização de fluxo geralmente não adiciona muitas melhorias de CPU, já que a quantidade de trabalho a ser feita é a mesma.

_from aickin / react-dom-stream _

Uma chamada para ReactDOM.renderToString pode dominar a CPU e privar outras solicitações. Isso é particularmente problemático em servidores que atendem a uma combinação de páginas pequenas e grandes.

O streaming não reduziria sensivelmente a alocação de memória e o uso da CPU para páginas grandes por ser assíncrono e parcial?

Pensei que fosse na mesma linha. Alguém tentou https://github.com/FormidableLabs/rapscallion ?

Ele fornece uma interface de streaming para que você possa começar a enviar conteúdo ao cliente imediatamente.

Outros recursos dos documentos:

• A renderização é assíncrona e sem bloqueio.
• Rapscallion é cerca de 50% mais rápido do que renderToString.
• Ele fornece uma interface de streaming para que você possa começar a enviar conteúdo ao cliente imediatamente.
• Ele fornece um recurso de modelagem, para que você possa envolver o HTML do seu componente em um padrão sem abrir mão dos benefícios do streaming.
• Ele fornece uma API de cache de componente para acelerar ainda mais sua renderização.

Adicionado um exemplo de Rapscallion em # 2279 ... pode confirmar que Rapscallion + Next é insano. A renderização baseada em promessa / streaming é incrível, mas o cache de nível de componente é uma virada de jogo para nós ...: godmode:

Agora que o React 16 tem seu próprio renderToNodeStream , seria uma grande vantagem para next.js adicionar uma opção para usá-lo em vez de renderToString . O que você acha, @timneutkens?

Já está na nossa lista de coisas para adicionar 👍

Alguma notícia sobre isso?

https://github.com/zeit/next.js/pull/4074#issuecomment -466996162

Alguma novidade?

Next.js precisa expor render customizado (com renderToString como renderizador padrão) para que o usuário use seu renderizador assíncrono customizado, eu acho.
A falta desse recurso me forçou a usar razzle para usar um renderizador assíncrono :( (seu DX está longe de NextJS, mas eu tive que aceitar isso para continuar).

Eu amo tudo sobre Next.js, exceto duas coisas:

• Renderizador assíncrono personalizado.
• Configuração de babel customizada para servidor e cliente.

algum roteiro / plano de suporte à renderização de streaming? tão esperado tem isso em next.js.

O está pendente para a equipe React implementar React Fizz / seu plano para isso.

@timneutkens Qual é o problema, PR para rastrear aqui?

Da postagem do blog do Facebook, publicada em 8 de agosto de 2019
https://reactjs.org/blog/2019/08/08/react-v16.9.0.html

Uma atualização na renderização do servidor
Iniciamos o trabalho no novo renderizador de servidor com capacidade para Suspense, mas não esperamos que ele esteja pronto para o lançamento inicial do Modo Simultâneo. Esta versão, no entanto, fornecerá uma solução temporária que permite que o renderizador de servidor existente emita HTML para fallbacks de Suspense imediatamente e, em seguida, renderize seu conteúdo real no cliente. Esta é a solução que estamos usando atualmente no Facebook até que o renderizador de streaming esteja pronto.

Para quem ainda está esperando pelo suporte de streaming do servidor :)

Existe alguma atualização ou qualquer outro método para implementar renderToNodeStream em next.js?

Existe alguma atualização?

<3

Qualquer atualização?

@StarpTech Eu olhei um pouco sobre isso (curioso por este recurso também!) E parece que a equipe de reação está trabalhando em algo chamado voo-reação , que provavelmente será a base para a solução de streaming que estamos esperando aqui :)

voo de reação:

Este é um pacote experimental para consumir modelos de streaming React personalizados.

Os PRs relevantes que iluminam o funcionamento interno, interpretados por mim (não sou um especialista em nada disso 🙈)
# 17285 : API básica para voo, o servidor deve ser capaz de transmitir tudo como uma string, mas deixar espaços reservados para os pedaços que são resolvidos de forma assíncrona no servidor. Uma sintaxe incompleta, mas interessante, de como react saberia de um fluxo que tipo de dados ele realmente representa aqui .

# 17398 PR mais recente, adiciona uma API para Chunks, então (se você estiver se sentindo com sorte) você mesmo pode experimentar essa parte. Não tenho certeza de como tudo funcionaria, mas mesmo assim estou muito feliz em ver todo esse trabalho sendo feito :)

_Isso pode ser um pouco fora do assunto, mas espero que seja interessante para as pessoas que assinam esta edição:) _

@pepf obrigado pela informação!

Hm. Obrigado a todos pessoal, informação interessante. Só estou pensando por que o NextJS deveria esperar pelo React suportar SSR para suspense e outras coisas, e não apenas usar streamAsString agora?

@arunoda Acho que vai reduzir o consumo de memória, muito importante para funções lambda com pouca memória ou Cloudflare Workers.

Alguma notícia sobre isso?

Alguma novidade?

Alguma notícia pessoal? : P

Dado que o suspense da reação parece que nunca vai acontecer, há alguma maneira de revisitar isso? Estou vendo tempos de renderização iniciais de 800-1000ms em páginas bastante genéricas e de baixo conteúdo (que são renderizadas a partir de uma função sem servidor no vercel). Teoricamente, o streaming de HTML poderia aumentar esse ponto de contato inicial e levar a um ux de primeira carga percebido muito mais rápido.

Isso é uma limitação do Vercel em vez do NextJS? O Vercel é vítima do mesmo tipo de inicialização a frio que o Lambda faz? Minha equipe administra vários sites de conteúdo pesado e nossos tempos são inferiores a 50 ms para toda a solicitação. Não acho que o streaming seja uma bala de prata aqui.

Não espero que seja uma solução mágica, mas certamente seria uma melhoria bem-vinda.

50ms soa minúsculo e relativamente insignificante para otimizar em comparação com os tempos de inicialização a frio mencionados, mas não é ao renderizar na borda com algo como Cloudflare Workers (é tanto quanto o ping para o local de borda Cloudflare mais próximo, ou pelo menos metade ), Os Workers do Cloudflare respondem muito rapidamente, normalmente em menos de 5 milissegundos, na inicialização a frio. Em contraste, as funções Lambda e Lambda @ Edge podem levar mais de um segundo para responder a partir de uma inicialização a frio.
Eu sei que isso não é um caso melhor para a Varcel (que cria seu próprio cdn) empregou desenvolvedores de next.js para priorizar isso.

Existe alguma documentação ou repositório onde as pessoas implantaram com sucesso next.js para trabalhadores do Cloudflare? Eu fiz algumas pesquisas no Google e não consegui encontrar muito sobre ele. Isso seria incrível.

Enviado do meu telefone

Em 5 de julho de 2020, às 17:47, Wis [email protected] escreveu:

50ms soa muito baixo e relativamente insignificante para otimizar em comparação com os tempos de inicialização a frio mencionados, mas 50ms é muito quando renderizar na borda com algo como Cloudflare Workers (é tanto quanto o ping para o ponto de borda Cloudflare mais próximo, ou pelo menos metade), os Cloudflare Workers respondem muito rapidamente, normalmente em menos de 5 milissegundos, na inicialização a frio. Em contraste, as funções Lambda e Lambda @ Edge podem levar mais de um segundo para responder a partir de uma inicialização a frio.
Eu sei que isso não é um caso melhor para a Varcel (que cria seu próprio cdn) empregou desenvolvedores de next.js para priorizar isso.

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub ou cancele a inscrição.

50 ms soa minúsculo e relativamente insignificante para otimizar em comparação com os tempos de inicialização a frio mencionados

Para esclarecer, eu não estava reclamando dos meus tempos de resposta de 50 ms - eu estava apenas apontando que o SRR do NextJS tem um desempenho relativamente alto, mesmo ao norte de 3 mil solicitações / minuto para páginas com muito conteúdo, então o problema de Switz pode estar em outro lugar.

Existe alguma documentação ou repositório onde as pessoas implantaram com sucesso next.js para Cloudflare workers

Eu também estaria interessado nisso. No momento, estamos executando em Fargate, mas levar nosso aplicativo ao limite seria o próximo passo lógico.

Eu fiz todas as melhorias possiveis dentro do meu HTML e o tempo de resposta do servidor esta altissimo! :(

@huggler você pode combinar este exemplo com resposta em cache . Você pode usar Redis (ou cache na memória, por exemplo) para armazenar html no cache. Melhora o tempo de resposta do servidor.

Existe alguma documentação ou repositório onde as pessoas implantaram com sucesso next.js para trabalhadores do Cloudflare? Eu fiz algumas pesquisas no Google e não consegui encontrar muito sobre ele. Isso seria incrível.

@switz @ tills13 você deu uma olhada em https://fab.dev/ ? Jogamos com ele no início de 2020 e estava em estado de pré-lançamento, mas eles parecem ter avançado muito. Uma das limitações por trás deles era o próprio Cloudflare, mas as coisas podem ter mudado agora.

Faz um tempo que não olho. Teria que reavaliar. Da última vez que olhei, houve algumas compensações muito sérias.

Também estou de olho em https://github.com/flareact/flareact.

alguma atualização disso?