Next.js: Transmisión de procesamiento para reducir TTFB y la carga de la CPU

Una cosa para mencionar ...

El renderizado de transmisión generalmente no agregará muchas mejoras a la CPU, ya que la cantidad de trabajo por hacer es la misma. Pero reducirá el tiempo de respuesta.

Es una muy buena idea proporcionar una forma de personalizar el sistema de renderizado SSR. Pero creo que por ahora, nos quedaremos con los métodos renderToString () de React por defecto.

Esto es algo que podríamos hacer después de 2.0.

El renderizado de transmisión generalmente no agregará muchas mejoras a la CPU, ya que la cantidad de trabajo por hacer es la misma.

_de aickin / react-dom-stream _

Una llamada a ReactDOM.renderToString puede dominar la CPU y eliminar otras solicitudes. Esto es particularmente problemático en servidores que sirven una combinación de páginas grandes y pequeñas.

¿La transmisión no reduciría sensiblemente la asignación de memoria y el uso de CPU para páginas grandes al ser asincrónica y parcial?

Pensé que esto iba en la misma línea. ¿Alguien ha probado https://github.com/FormidableLabs/rapscallion ?

Proporciona una interfaz de transmisión para que pueda comenzar a enviar contenido al cliente de inmediato.

Otras características de los documentos:

• La renderización es asincrónica y sin bloqueo.
• Rapscallion es aproximadamente un 50% más rápido que renderToString.
• Proporciona una interfaz de transmisión para que pueda comenzar a enviar contenido al cliente de inmediato.
• Proporciona una función de creación de plantillas, de modo que puede envolver el HTML de su componente en un texto estándar sin renunciar a los beneficios de la transmisión.
• Proporciona una API de almacenamiento en caché de componentes para acelerar aún más su renderizado.

Se agregó un ejemplo de Rapscallion en # 2279 ... puede confirmar que Rapscallion + Next es una locura. El renderizado en streaming / basado en promesas es asombroso, pero el almacenamiento en caché a nivel de componente es un cambio de juego para nosotros ...: godmode:

Ahora que React 16 tiene su propio renderToNodeStream , sería una gran ventaja para next.js agregar una opción para usarlo en lugar de renderToString . ¿Qué opinas, @timneutkens?

Está en nuestra lista de cosas para agregar ya 👍

¿Alguna noticia sobre esto?

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

¿Hay noticias?

Next.js necesita exponer render (con renderToString como renderizador predeterminado) para que el usuario use su renderizador asíncrono personalizado, creo.
Sin embargo, la falta de esta función me obligó a usar razzle para usar un renderizador asíncrono :( (su DX no está cerca de NextJS, pero tuve que aceptarlo para continuar).

Me encanta todo sobre Next.js excepto dos cosas:

• Procesador asíncrono personalizado.
• Configuración de babel personalizada tanto para el servidor como para el cliente.

¿Alguna hoja de ruta / plan de soporte de renderizado en streaming? tan esperado tener esto en next.js.

Está pendiente que el equipo de React implemente React Fizz / su plan para ello.

@timneutkens ¿Cuál es el problema, PR para rastrear aquí?

De la publicación del blog de Facebook, publicada el 8 de agosto de 2019
https://reactjs.org/blog/2019/08/08/react-v16.9.0.html

Una actualización sobre la representación del servidor
Hemos comenzado a trabajar en el nuevo renderizador de servidor compatible con Suspense, pero no esperamos que esté listo para el lanzamiento inicial del modo concurrente. Sin embargo, esta versión proporcionará una solución temporal que permitirá que el renderizador del servidor existente emita HTML para los fallbacks de Suspense inmediatamente y luego renderice su contenido real en el cliente. Esta es la solución que estamos usando actualmente en Facebook hasta que el renderizador de transmisión esté listo.

Para cualquiera que todavía esté esperando el soporte de transmisión del servidor :)

¿Hay alguna actualización o algún otro método para implementar renderToNodeStream en next.js?

¿Hay alguna actualización?

<3

¿Cualquier actualización?

@StarpTech Me también tengo curiosidad por esta función!) Y parece que el equipo de reacción está trabajando en algo llamado react-flight , que probablemente será la base para la solución de transmisión que estamos esperando aquí. :)

reaccionar-vuelo:

Este es un paquete experimental para consumir modelos de transmisión React personalizados.

Las relaciones públicas relevantes que arrojan algo de luz sobre el funcionamiento interno, interpretadas por mí (no soy un experto en nada de esto 🙈)
# 17285 : API básica para vuelo, el servidor debería poder transmitir todo como una cadena, pero dejar marcadores de posición para los fragmentos que se resuelven de forma asincrónica en el servidor. Una sintaxis incompleta, pero interesante, de cómo reaccionar sabría de una secuencia qué tipo de datos representa realmente está aquí .

# 17398 Relaciones públicas más recientes, agrega una api para Chunks, por lo que (si se siente afortunado) puede probar esa parte usted mismo. No estoy seguro de cómo saldría todo junto pero, sin embargo, estoy un poco feliz de ver que se está haciendo todo este trabajo :)

_Esto puede ser un poco fuera de tema, pero es de esperar que sea interesante para las personas que se suscriben a este número :) _

@pepf ¡ gracias por la información!

Hm. Gracias a todos, información interesante. Solo estoy pensando por qué NextJS debería esperar a que React soporte SSR para suspenso y esas cosas, y no solo usar streamAsString ahora.

@arunoda Creo que reducirá el consumo de memoria, muy importante para funciones lambda de baja memoria o Cloudflare Workers.

¿Alguna noticia sobre esto?

¿Hay noticias?

¿Alguna noticia chicos? :PAGS

Dado que el suspenso de reacción se siente como si nunca saliera, ¿hay alguna forma de que podamos revisar esto? Veo tiempos de renderizado iniciales de 800-1000ms en páginas bastante genéricas de bajo contenido (que se renderizan desde una función sin servidor en vercel). La transmisión del HTML en teoría podría aumentar ese punto de contacto inicial y conducir a una experiencia de usuario de primera carga mucho más rápida.

¿Es esa una limitación de Vercel en lugar de NextJS? ¿Vercel es víctima del mismo tipo de arranque en frío que Lambda? Mi equipo ejecuta un montón de sitios con mucho contenido y nuestros tiempos son inferiores a 50 ms para toda la solicitud. No creo que la transmisión sea una solución milagrosa aquí.

No espero que sea una solución milagrosa, pero sin duda sería una mejora bienvenida.

50 ms suena minúsculo y relativamente insignificante para optimizar en comparación con los tiempos de inicio en frío mencionados, pero no lo es cuando se renderiza en el borde con algo como Cloudflare Workers (es tanto como el ping a la ubicación de borde de Cloudflare más cercana, o al menos la mitad ), Los trabajadores de Cloudflare responden muy rápidamente, normalmente en menos de 5 milisegundos, cuando se arranca en frío. Por el contrario, las funciones Lambda y Lambda @ Edge pueden tardar un segundo en responder desde un arranque en frío.
Sé que esto no representa un mejor caso para Varcel (que crea su propio cdn) empleó desarrolladores de next.js para priorizar esto.

¿Existe documentación o repositorios en los que las personas hayan implementado con éxito next.js para los trabajadores de cloudflare? Busqué en Google y no pude encontrar mucho sobre él. Eso sería sorprendente.

Enviado desde mi teléfono

El 5 de julio de 2020, a las 5:47 p.m., Wis [email protected] escribió:

50 ms suena realmente bajo y relativamente insignificante de optimizar en comparación con los tiempos de inicio en frío mencionados, pero 50 ms es mucho cuando se renderiza en el borde con algo como Cloudflare Workers (es tanto como el ping a la ubicación de borde de Cloudflare más cercana, o al menos la mitad), los trabajadores de Cloudflare responden muy rápidamente, normalmente en menos de 5 milisegundos, cuando se arranca en frío. Por el contrario, las funciones Lambda y Lambda @ Edge pueden tardar un segundo en responder desde un arranque en frío.
Sé que esto no representa un mejor caso para Varcel (que crea su propio cdn) empleó desarrolladores de next.js para priorizar esto.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub o cancele la suscripción.

50 ms suena minúsculo y relativamente insignificante para optimizar en comparación con los tiempos de arranque en frío mencionados

Para aclarar, no me estaba quejando de mis tiempos de respuesta de 50 ms; solo estaba señalando que el SRR de NextJS tiene un rendimiento relativamente alto incluso en el norte de 3k solicitudes / minuto para páginas con mucho contenido, por lo que el problema de Switz podría estar en otra parte.

¿Existe alguna documentación o repositorios donde las personas hayan implementado con éxito next.js para los trabajadores de cloudflare?

Eso también me interesaría. Actualmente estamos ejecutando en Fargate, pero llevar nuestra aplicación al límite sería el siguiente paso lógico.

¡Hice todas las mejoras posibles en mi HTML y el tiempo de respuesta del servidor es increíble! :(

@huggler puedes combinar este ejemplo con cacheable-response . Puede usar Redis (o caché en memoria, por ejemplo) para almacenar html en caché. Mejora el tiempo de respuesta del servidor.

¿Existe documentación o repositorios en los que las personas hayan implementado con éxito next.js para los trabajadores de cloudflare? Busqué en Google y no pude encontrar mucho sobre él. Eso sería sorprendente.

@switz @ tills13 ¿ https://fab.dev/ ? Jugamos con él a principios de 2020 y estaba en estado de prelanzamiento, pero parece que han llegado bastante lejos. Una de las limitaciones que los respaldaba era Cloudflare en sí, pero las cosas podrían haber cambiado a estas alturas.

No he mirado en un tiempo. Tendría que reevaluar. La última vez que miré, hubo algunas compensaciones bastante serias.

También estoy atento a https://github.com/flareact/flareact.

¿Algún avance en esto?