Puntos clave a la hora de elegir SSR, CSR y renderizado en streaming

Muchos equipos debaten sobre SSR, CSR y renderizado de streaming, y lo primero que preguntan es sobre el rendimiento.

¿Cuánto dura el tiempo de la primera pantalla? ¿Se puede suprimir LCP? ¿Se puede ayudar el SEO? ¿Se pueden paralelizar las interfaces? ¿Se puede esqueletizar la transmisión antes? Por supuesto, esto es importante, pero cuando se trata de proyectos, lo primero que estropea la página es a menudo cuántas veces se han obtenido los mismos datos, en qué capas se almacenan en caché y quién los cerrará después de un error.

Mi opinión es: ** La clave de la estrategia de renderizado de front-end no es quién es más avanzado, SSR, CSR o renderizado de transmisión, sino que los datos de la misma página tienen que pasar por varias veces de recuperación, varias veces de hidratación y varios conjuntos de reversiones de fallas. Una vez que una página busca SEO, velocidad de interacción y aciertos de caché al mismo tiempo, lo primero que se sale de control suele ser la coherencia de los datos, la cobertura de errores y los costos de resolución de problemas. **

Lo que realmente estropea la página no suele ser el método de renderizado en sí.

He visto muchas páginas y al principio era solo una página de detalles de contenido muy común:

• Haga clic en la página de la lista para obtener más detalles;
• Esperamos que los motores de búsqueda puedan rastrear la primera pantalla, por eso necesitamos SSR;
• Hay interacciones como colecciones, comentarios y recomendaciones en la página, por lo que el cliente tiene que seguir realizando solicitudes;
• Para que la primera pantalla sea más rápida, la interfaz se divide en datos principales y bloques secundarios;
• Para mejorar la tasa de aciertos, el servidor agrega almacenamiento en caché perimetral y el cliente agrega una capa de almacenamiento en caché de solicitudes.

Hasta este punto, cada decisión puede justificarse.

El problema es que una vez que se acumulan estas decisiones, en realidad hay al menos cuatro rutas para que “los datos lleguen a la escena” en la página:

1. Los datos obtenidos durante la primera prestación del servidor;
2. Los datos bajados cuando el navegador está hidratado;
3. Una vez montado el cliente, reenvía la solicitud para obtener los nuevos datos;
4. Datos derivados que se actualizan localmente después de la interacción del usuario.

Si no hay una prioridad clara entre estas cuatro rutas, la página comenzará a tener algunos problemas extraños y familiares:

• Lo que ves en HTML es el precio anterior y aparecerá el nuevo precio después de la hidratación;
• La primera representación de la pantalla muestra “Favorito”, pero después de que el cliente toma el control, vuelve a cambiar a “No favorito”;
• El bloque recomendado llega un paso tarde y la página actualizada vuelve parcialmente al valor anterior;
• Cuando el servidor informó un error, mostró un conjunto de detalles y, después de que el cliente volvió a intentarlo, mostró otro conjunto de detalles.

Estos problemas se deben al hecho de que el mismo estado de página se genera y sobrescribe varias veces, pero nadie define quién tiene la última palabra.

SSR resuelve la visibilidad de la primera pantalla, pero no resuelve automáticamente la verdad de la fuente de datos.

Una situación común es pensar en SSR como “escupir la página correcta primero”, pero esta oración solo es cierta bajo una premisa muy estrecha: ** Los datos obtenidos por el servidor son los datos finales que el usuario realmente debería ver esta vez. **

En realidad, esta premisa muchas veces no es cierta.

Por ejemplo, la información del producto en la pantalla de inicio de la página de detalles la muestra el servidor, pero la siguiente información a menudo no lo hace:

• Si el usuario ha hecho clic en favoritos;
• Qué conjunto de recomendaciones se ve afectado actualmente por el grupo experimental;
• Inventario geográficamente relevante;
• Precios o derechos relacionados con el inicio de sesión;
• Las actualizaciones asincrónicas se completaron justo después de montar la página.

En este momento, SSR solo puede garantizar que “primero escupe una versión para mostrar los resultados”, pero no puede garantizar que esta versión de los resultados sea la verdad final de toda la página.

Una vez que el equipo también requiere que “el servidor produzca HTML primero y el cliente se haga cargo y luego agregue personalización”, el sistema naturalmente se dividirá en dos conjuntos de juicios:

• El servidor determina primero cómo debería verse la página;
• El cliente determina cómo debería verse finalmente la página.

Si las condiciones de acceso, el tiempo de almacenamiento en caché y las estrategias de tolerancia a fallas de ambos lados no son completamente consistentes, la página definitivamente será inconsistente.

Entonces, lo que SSR realmente debería preguntar es:

• ¿Durante cuánto tiempo se pueden mantener actualizados los datos generados por el servidor esta vez?
• Qué campos se pueden cubrir después de la hidratación;
• Qué campos deben basarse en los últimos resultados del cliente;
• ¿Las fallas del lado del servidor y las fallas del lado del cliente tienen el mismo conjunto de semánticas?

Sin aclarar estos problemas primero, SSR solo enviará una determinada versión de la respuesta al usuario en un momento anterior, en lugar de resolver la coherencia en un nivel superior.

El verdadero problema con CSR es que es fácil escribir la semántica de actualización de manera flexible

A menudo se critica a la RSE por ser lenta en la parte superior de la página, y con razón. Pero mi problema más común es que los proyectos de RSE tienden a escribir “volver a extraer los datos” como una acción predeterminada sin restricciones.

La página se inicializa y se extrae una vez; Corta la pestaña y tira de ella una vez; Vuelva a centrar la ventana; Después de que la operación del usuario sea exitosa, tírela nuevamente fácilmente; La biblioteca de solicitudes vuelve a intentarlo automáticamente.

El código parece natural, pero el efecto final puede ser:

• El estado de la página se sobrescribe varias veces en un corto período de tiempo;
• La solicitud anterior devuelta más tarde anulará la nueva solicitud devuelta primero;
• La actualización optimista acaba de entrar en vigor y fue retrasada por una nueva recuperación completa;
• Un determinado componente local se actualiza por separado y el estado a nivel de página se vuelve a ensamblar en otra versión del resultado.

Este tipo de problema es particularmente común en CSR, porque el cliente naturalmente considera “obtener los datos más recientes ahora” como una acción de bajo costo. Pero siempre que una página tenga una lista, un resumen y comentarios interactivos, volver a buscar es un acto de volver a juzgar el estado de toda la página.

Si no hay reglas claras, la RSE eventualmente se convertirá en: no importa quién obtiene los datos primero, quién tiene la última palabra y quién obtiene los datos con éxito al final.

Por supuesto, la página es inestable en este momento. Tiene menos que ver con la CSR en sí y más con abrir demasiado la ruta de escritura.

El costo de la renderización de transmisión que se subestima más fácilmente es el costo de la interpretación del estado causado por la “llegada de lotes”

Se puede decir fácilmente que el streaming en los últimos dos años es un beneficio neto:

• El esqueleto llega antes;
• El contenido clave aparece primero;
• No importa si el bloque secundario es posterior;
• La experiencia del usuario será más fluida.

Todo esto es cierto. Pero tiene un precio que rara vez se considera seriamente en las revisiones de planes: la página ** ya no solo tiene dos estados: “llegado” o “no llegado”, sino que tiene múltiples bloques que llegan en lotes, errores en lotes y reversiones en lotes. **

Una vez que la página se divide en fragmentos asincrónicos, como contenido principal, comentarios, recomendaciones, espacios publicitarios y capas flotantes personalizadas, no solo es necesario abordar el rendimiento, sino también los siguientes problemas de ingeniería:

• Si la versión de los datos maestros en la que se basa un determinado bloque que llega tarde y la versión de la primera pantalla son la misma;
• Cuando el bloque principal tiene éxito y el bloque secundario falla, si toda la página aún puede considerarse exitosa;
• Si el contenido que ya se muestra en la secuencia puede ser anulado por fragmentos posteriores;
• El usuario ya inició la operación después de que llega el primer fragmento de página. ¿Los fragmentos posteriores sobrescribirán los resultados de la interacción?

Este costo no es abstracto. He visto una página que muestra mediante SSR la información principal y agrega recomendaciones relacionadas y derechos de usuario en formato de transmisión. Resulta que el error más difícil de solucionar en línea es “la copia de derechos vista por algunos usuarios cambiará dos veces en dos segundos”.

Finalmente comprobado, es:

• El primer segmento del servidor utiliza la antigua instantánea de equidad en el caché público;
• Los segmentos de transmisión posteriores utilizan una nueva interfaz con modo de usuario;
• Una vez hidratado el cliente, los campos de visualización se vuelven a calcular en función del estado de inicio de sesión local.

Los tres conjuntos de fuentes tienen sentido, pero cuando se combinan, la página no parece un sistema.

Lo que se debe diseñar primero es la línea de datos principal de la página.

Al final de la discusión sobre estrategias de renderizado, me preocupé cada vez más por si la página tenía una línea principal de datos clara.

La llamada línea principal de datos consiste en determinar de antemano lo siguiente:

1. ¿Qué datos son la línea base de la primera pantalla?

Cuando aparece el HTML de la primera pantalla, se debe indicar claramente qué campos ya pueden considerarse como valores verdaderos visualizables y cuáles son solo resultados de marcador de posición.

Por ejemplo:

• El texto del artículo puede basarse en los resultados de la RSS;
• El estado similar del usuario sólo puede determinarse mediante la solicitud de estado de inicio de sesión del cliente;
• El bloque recomendado se declara desde el principio como “finalización asincrónica, no participa en el valor verdadero de la primera pantalla”.

Mientras esta capa no esté definida, cada ronda posterior de solicitudes competirá con la ronda anterior por los derechos de interpretación.

2. ¿Qué campos se pueden sobrescribir y qué campos solo se pueden completar de forma incremental?

Muchas páginas están escritas de forma desordenada porque todos los datos que aparecen después son “los más recientes y más confiables”. No precisamente.

Algunos campos son adecuados para la cobertura, como inventario, precio y número de personas en línea; Algunos campos solo se pueden completar, como la paginación de comentarios y la lista de recomendaciones; Algunos campos deben sobrescribirse con juicio de versión, como el estado de recopilación que el usuario acaba de operar.

Si no hay reglas de anulación a nivel de campo, cuantas más solicitudes posteriores haya, mayor será la probabilidad de que el valor anterior reemplace al nuevo valor.

3. ¿Las fallas del lado del servidor y las fallas del lado del cliente tienen la misma semántica?

Esto se pasa fácilmente por alto.

En algunos sistemas, cuando falla la solicitud del servidor, se degradará directamente al módulo predeterminado; cuando el cliente falla, se muestra un botón de reintento de error independiente. El resultado que ve el usuario es:

• Al actualizar la página, este contenido desaparece silenciosamente;
• Después de montar la página, este contenido muestra repentinamente un estado de error.

Esto se debe a que el sistema no tiene una explicación unificada para el “fallo”.

En el mismo bloque, si la semántica de falla del servidor y del cliente es diferente, será difícil responder al solucionar el problema: ¿Es esto una degradación normal o una visualización anormal?

Un malentendido común: tomar “extraer los datos más recientes una vez más” como un seguro

Cuando muchos equipos encuentran problemas de coherencia, su primera reacción es “luego el cliente extraerá los datos más recientes nuevamente”.

Este truco suele ser eficaz a corto plazo porque actualiza algunos de los datos SSR antiguos. Pero a largo plazo, el problema puede fácilmente escalar desde “la primera pantalla a veces es un poco vieja” hasta “toda la página está compitiendo por los derechos de interpretación finales”.

El enlace fallido más típico es este:

1. El servidor primero toma los datos de la versión A y muestra la primera pantalla;
2. Una vez montado el navegador, el cliente extrae automáticamente la versión B;
3. El usuario inmediatamente hizo clic en la colección y la actualización optimista local cambió a C;
4. La versión B solicita una devolución tardía y hace retroceder a C;
5. Regrese a la interfaz de la colección y la página volverá a D.

Técnicamente, cada paso es “correcto”.

Pero para los usuarios, la página cambió las respuestas cuatro veces en tres segundos. En este punto, es difícil decir si el núcleo del problema es SSR o CSR, porque el problema real es: ** La página no especifica qué prioridad se debe dar a la escritura interactiva o a la actualización completa. **

Contraejemplo: No todas las páginas son dignas de SSR o streaming

También existe un malentendido muy real: considerar la estrategia de renderizado como una lista de capacidades de la plataforma.

Si el marco admite SSR, tiende a ser SSR en todo el sitio; Admite renderizado en streaming y comienza a eliminar bloques; Si le preocupa el SEO, utilice el lado del servidor para todas las páginas de detalles de forma predeterminada; Si le preocupa la lentitud, agregue otra capa de caché del cliente.

Finalmente, los costos de interpretación del sistema se dispararon.

Algunas páginas simplemente no merecen estrategias de renderizado complejas:

• Páginas de backend con un estado de inicio de sesión sólido, una fuerte personalización y un valor bajo en los motores de búsqueda;
• Una página de transacciones cuyos datos en tiempo real son mucho mayores que el valor de una primera pantalla estática;
• Una página de operaciones con poco contenido en la primera pantalla pero muchas interacciones.

Si se instala SSR en dichas páginas y luego se agrega extracción suplementaria y transmisión parcial del lado del cliente, los beneficios a menudo no son tan buenos como escribir los datos bajo CSR honestamente.

Por el contrario, las páginas de detalles basadas en contenido, las páginas de destino públicas y las páginas de información con una estructura estable son más adecuadas para aprovechar al máximo los ingresos por SSR o streaming. La premisa sigue siendo si los límites de datos de la página se pueden separar claramente**.

Para elegir un método, mira primero tres cosas

Si realmente desea juzgar entre SSR, CSR y renderizado de transmisión, le recomiendo leer estas tres cosas primero en lugar de leer primero la página promocional del marco.

Primero, verifique si el contenido de la primera pantalla tiene un valor verdadero estable.

Si la mayor parte del contenido de la primera pantalla se puede obtener en el lado del servidor y la diferencia en el modo de usuario es pequeña, SSR será más estable.

Si la primera pantalla depende en gran medida del estado de inicio de sesión, el estado del dispositivo y el estado en tiempo real, y el servidor solo obtiene un valor aproximado que caduca rápidamente, entonces los ingresos de SSR se descontarán porque el cliente pronto tendrá que volver a calcularlos.

Segundo, verifique si la página permite una explicación por lotes

Si naturalmente se puede acceder a la página en bloques, como el texto primero, los comentarios al final y las recomendaciones al final, la representación en streaming es más valiosa.

Si varios bloques en la página comparten una gran cantidad de estado, y la llegada tardía de uno anulará los dos anteriores, entonces la renderización de transmisión no solo traerá optimización del rendimiento, sino también costos de coordinación de estado.

En tercer lugar, vea si la escritura interactiva entrará en conflicto con la ruta de actualización.

Siempre que haya acciones como colecciones, carritos de compras, formularios y cambio de permisos en la página que cambiarán el estado inmediatamente, es necesario centrarse en si la ruta de escritura interactiva y la ruta de actualización de la página se cubrirán entre sí.

Este asunto no está solucionado, no importa qué estrategia de renderizado elija, simplemente cometerá errores de otra manera.

Límites aplicables

Este artículo analiza principalmente:- Buscar simultáneamente SEO, velocidad en la mitad superior de la página y páginas web personalizadas;

• La misma página tiene una primera representación del lado del servidor, una representación complementaria del lado del cliente y bloques asincrónicos locales;
• Problemas de hidratación, almacenamiento en caché y ensamblaje de transmisión que se encuentran naturalmente cuando se utilizan marcos front-end modernos.

Si la página es muy simple, ya sea pura visualización de contenido o pura operación en segundo plano, la complejidad de la estrategia de representación no será tan alta. El problema que es más probable que surja es la página que “parece simplemente una página de detalles, pero en realidad incluye distribución de contenido, conversión comercial e interacción del usuario al mismo tiempo”.

Resumen

SSR, CSR y renderizado en streaming no están mal. Lo que está mal es considerarlos como puros interruptores de rendimiento.

Una vez que una página tiene requisitos de primera pantalla, requisitos de almacenamiento en caché y requisitos de interacción al mismo tiempo, lo que realmente se sale de control primero es qué versión de los datos se cuenta, quién será responsable del error y quién tiene prioridad en la escritura interactiva y las rutas de actualización.

Por lo tanto, lo que la estrategia de renderizado front-end realmente debería determinar primero es cuántas veces se generará esta página de datos, cuántas veces se sobrescribirá, cuántas veces no podrá retroceder y qué capa finalmente la cerrará.

Este asunto no está claro. Cuanto más avanzado es el esquema de representación, más parece que la página está escrita mediante muchos conjuntos de mecanismos razonables al mismo tiempo.