El amanecer de las aplicaciones SPA de una sola página
El modelo de aplicación de página única (SPA) ha ganado popularidad en los últimos años. Es comprensible, este enfoque da cierta ganancia en términos de velocidad, calidad de servicio y crea la base para nuevos patrones de desarrollo web del cliente.
Como creo que todos saben, SPA funciona dentro del navegador y no requiere recargar la página durante su uso.
¡Gran idea! Pero, por supuesto, hay trampas.
Entre los casos más comunes (si toma algún tutorial sobre react o vue), la página principal index.html contiene un archivo HTML casi vacío con una pequeña cantidad de CSS, JavaScript, fuentes, etc. que son globales para todo el proyecto.
Y este es el problema:
- Durante la representación inicial, el usuario tendrá que esperar a que se cargue todo el código base y todos los recursos (por supuesto, hay excepciones y puede implementar la carga dinámica de los llamados fragmentos js / css, pero esa es otra historia)
- Algunos rastreadores o analizadores que no pueden esperar la carga de solicitudes asincrónicas simplemente verán todas las páginas en blanco.
Bueno, ya captas la idea:
<!DOCTYPE html>
<html>
<head>
<title>My first SPA app</title>
<script src="https://cdn__"></script>
</head>
<body>
<div id="app"></div>
<script>
...
,
...
</script>
</body>
</html>
Representación del lado del servidor SSR
A diferencia de Client Side Rendering (CSR), que usa el navegador para representar todo el contenido de la aplicación y recuperar datos de API y similares, SSR usa ... el servidor. Es decir, el servidor procesa toda la misma representación y recuperación de datos (NodeJS usando Express, Next, Vue SSR, Nuxt o lo que sea ...), y luego una respuesta con marcado HTML, estilos, scripts y los datos recibidos de la API, enviado al navegador.
Por lo tanto, puede aprovechar dos enfoques: velocidad / SEO e interactividad / UX.
Entonces, ¿qué es la hidratación / rehidratación?
La rehidratación es una especie de puente entre SSR y CSR.
Existe un indicador del rendimiento de la página web como First Contentful Paint (FCP); traducido de manera aproximada, sonará como una "primera representación significativa", el momento en que el navegador comenzó a mostrar texto e imágenes (incluido el fondo). Estos son los primeros elementos que verá el usuario en la página. Cuando crea un informe con Lighthouse en Chrome, en la pestaña de rendimiento, verá inmediatamente esta métrica.
El tiempo dedicado a generar contenido en el servidor será el tiempo de First Contentful Paint.
Inmediatamente después de eso, JavaScript del lado del cliente comienza a ejecutarse para crear una aplicación de cliente completa (en la mayoría de los casos, los marcos populares son dom virtual y una interfaz de enlace para administrarlo).
En este punto, no es necesario volver a renderizar el DOM completo en el cliente, pero debe agregar los eventos, métodos y, en algunos casos, elementos que no se renderizaron en el servidor.
Es este proceso el que se llama hidratación / rehidratación. Se puede encontrar una descripción un poco más detallada en la Guía Vue SSR (que también está en ruso), pero, en consecuencia, con algunas características de este marco en particular.
Actuación
Pero en esta parte aparecen algunos problemas. La rehidratación tiene un cierto inconveniente: es el tiempo antes de la interacción o Time to Interactive, que se puede ver en el mismo, conocido por nosotros, Lighthouse Chrome. Incluso si ha organizado todo perfectamente en el lado del servidor y la página tiene un primer renderizado rápido del contenido, el usuario solo podrá interactuar con él después de la rehidratación CSR, que a veces es bastante lenta. Esta es una gran desventaja en términos de UX.
Otro indicador del retardo de primera entrada potencial máximo es el retardo de la primera entrada (FID), una de las métricas de rendimiento de la página web que describe el tiempo transcurrido desde que el usuario comenzó a interactuar con la página web, es decir, mi. haga clic en un enlace, botón o utilice un control basado en JavaScript hasta que el navegador web pueda responder a la interacción (según lo definido por mozilla).
Y el tiempo de rehidratación afecta directamente a este indicador. Y cuantos más componentes y lógica haya en su página, más rápido aumentará este indicador.
Una solución es la carga perezosa para la hidratación.
Un ejemplo de implementación de un enfoque similar en Vue SSR / NuxtJS es el paquete vue-lazy-hydration(en el repositorio npm), que implementa la hidratación solo en la parte visible de la ventana gráfica del navegador y "hidrata" el resto solo si se desplaza por la página. También se encontraron recomendaciones para usar este paquete en habr en el tutorial Creamos una tienda en línea en Nuxt.js , para lo cual el autorAntonMoskalchenkoQuiero expresar mi especial agradecimiento. En su artículo, Lighthouse Chrome logró un rendimiento del 100%.