Home Blogs Optimización de aplicaciones React, Angular o Vue de una sola página para el rendimiento
Applications

Optimización de aplicaciones React, Angular o Vue de una sola página para el rendimiento

About The Author

Outline

En esta publicación, veremos cómo Vue, React y Angular se comparan en términos de rendimiento y qué se puede hacer para optimizar los spas de comercio electrónico que se ejecutan en estos marcos frontend para obtener la mejor experiencia del usuario.

¿Cómo se compara Angular, React y Vue en términos de rendimiento

Ejecutar un sitio rápido conduce al crecimiento de resultados a través de un mejor posicionamiento SEO, más visitantes, sesiones más largas y, como resultado, más ingresos. Muchos líderes de comercio electrónico que entienden el papel de la velocidad ya han cambiado a la arquitectura de comercio sin cabeza, lo que permite la adopción de frontend modernos, como aplicaciones web progresivas y spas. Los frontend de SPA ligeros están ganando popularidad porque son una forma segura de resolver varios problemas de rendimiento inherentes a las plataformas modernas de comercio electrónico para que los operadores puedan ofrecer escaparates ultrarrápidos.

Bueno, esa es la teoría. Para verificar estas elevadas afirmaciones, realizamos un pequeño análisis interno del desempeño. Con este fin, probamos casi 2.000 sitios web de comercio electrónico populares que se ejecutan en los principales marcos de frontend y evaluamos su rendimiento en función de las puntuaciones de Lighthouse 6. Los hallazgos fueron sorprendentes: ¡La puntuación promedio de Lighthouse para las frontend de SPA probadas fue de solo 24, con una mediana de 19 (de 100)! Por más bajo que parezca, esto seguía siendo un 26% más alto que la puntuación media de los 500 principales minoristas de Internet de los EE.UU. Por ingresos.

Los sitios de Vue.js fueron los más rápidos, con un promedio de 27 con una mediana de 20. Los sitios web angulares vieron un promedio de 23; sin embargo, sus puntuaciones de rendimiento fueron más dispersas, con una mediana de solo 18. Los sitios web de React fueron los más lentos probados, con una puntuación promedio de Lighthouse de 22 y una mediana de 18. Esto fue sorprendente, especialmente porque el marco es utilizado por algunos de los jugadores más grandes, incluyendo sitios como PayPal, Grammarly y Vimeo, por nombrar algunos.

La conclusión de la prueba fue bastante clara: Aunque se cree que los spas son más rápidos que los sitios web tradicionales, todavía hay margen para mejorar. Además, Google Crux y otras herramientas de medición no rastrean las transiciones de página de las aplicaciones de una sola página (SPA), lo que las tergiversa como mucho más lentas de lo que son y penaliza sus puntuaciones. Escribimos más sobre este tema en otro post en el blog.

El impacto del tiempo de puesta en marcha y el rendimiento en tiempo de ejecución en las puntuaciones de Lighthouse

El rendimiento de las aplicaciones se define por dos métricas: Tiempo de inicio y rendimiento en tiempo de ejecución. El tamaño del paquete de código influye principalmente en el primero, es decir, el código de la aplicación y el código de marco combinados. El rendimiento en tiempo de ejecución depende de las características de optimización específicas del marco y la forma en que maneja la manipulación y actualización de DOM.

Tamaño del paquete

Los tres marcos tienen paquetes de código mínimos de tamaño similar. Aunque el tamaño del paquete del marco afecta el tiempo de inicio, la métrica no debe ser el enfoque principal al comparar el rendimiento de Angular, React y Vue.

Más precisamente hablando, el tamaño del paquete angular es solo ligeramente más grande que los tamaños de paquete de Vue y React, con los paquetes de Vue siendo un poco más pequeños que los paquetes de React. Además, vale la pena señalar que el equipo de desarrollo Angular está optimizando constantemente el tamaño de sus paquetes de código (fuente).

Vea la tabla de abajo para los números aproximados.

Angular, React y Vue ofrecen un gran rendimiento en tiempo de ejecución, y cada uno es igualmente apto para ser la columna vertebral de sitios web complejos y generadores de ingresos con tráfico pesado.

Las métricas TTI y LCP de Lighthouse

Lighthouse es una gran herramienta de prueba que devuelve valiosos conocimientos de velocidad. Identifica posibles problemas de rendimiento y ayuda a optimizar los diversos aspectos de un sitio. Una puntuación de faro se calcula en base a un promedio ponderado de múltiples métricas (vaya aquí para un resumen completo). Sin embargo, las pinturas contentful (LCP) más grandes, el tiempo de interacción (TTI) y el cambio de diseño acumulativo (CLS) son muy probablemente las más importantes desde la perspectiva del usuario. TTI y LCP están conectados directamente con la velocidad de carga percibida.

TTI es una buena representación del impacto del tamaño del paquete de un marco en la velocidad del SPA, ya que el paquete debe evaluarse por completo antes de que un usuario pueda interactuar con la aplicación. Los sitios con un TTI largo mostrarán varias partes del sitio mientras se cargan, pero no permitirán a los usuarios interactuar con él, lo que en última instancia puede conducir a la frustración.

La métrica LCP, por otro lado, mide cuánto tiempo tarda hasta que el elemento más grande del contenido de la página se renderiza en la pantalla.

Lighthouse vs. Crux datos de navegación de la vida real

Vale la pena señalar que las herramientas sintéticas de medición de velocidad (como Lighthouse) no cuentan la historia completa. La velocidad del sitio es más acerca de cómo el sitio «se siente» cuando los usuarios navegan a través de él. Una puntuación de rendimiento de Lighthouse es un buen punto de referencia, pero es algo arbitrario y difícil de correlacionar con una experiencia del mundo real. Por ejemplo, es difícil traducir cuánto mejor sería una puntuación de rendimiento de 60, en términos de experiencia de usuario, en comparación con una puntuación de 50.

Las pruebas sintéticas también tienden a simular dispositivos y conexiones más antiguos (por ejemplo, Lighthouse simula conexiones 3G), mientras que en realidad, la mayoría de los usuarios móviles están en redes LTE rápidas o incluso 5G.

Un sitio que se ejecuta en un marco específico puede «sentirse» más rápido, pero perder a otros sitios con respecto a su puntuación de rendimiento en bruto y viceversa. Esto se debe principalmente a trucos específicos (por ejemplo, carga perezosa) que cada marco emplea para mejorar la velocidad con la que el sitio se «siente» para los usuarios.

En las siguientes secciones, revisaremos las oportunidades que ofrece cada uno de estos marcos para mejorar el rendimiento del sitio web.

Angular

Angular extiende el código HTML con nuevas etiquetas y atributos e interpreta los atributos para realizar el enlace de datos.

Debido a sus características ricas, la aplicación de trabajo puede ser mucho más grande (aproximadamente 500KB) en comparación con Vue o React, lo que puede afectar ligeramente el rendimiento.

Abstracción MVC de angular (fuente)

Aquí hay un resumen rápido de los principales beneficios de Angular.

  • Generación de código. Angular genera código altamente optimizado para máquinas virtuales JavaScript, lo que brinda los beneficios del código escrito a mano. Las plantillas HTML combinadas con JavaScript abren la puerta a optimizaciones imposibles en otros marcos, por ejemplo, React.
  • División de código. Gracias a Component Router, las aplicaciones angulares se cargan rápidamente y ofrecen división automática de código. De esta manera, los usuarios cargan el código necesario para representar la vista que solicitan.
  • Real DOM. Angular utiliza DOM real; por lo tanto, es más adecuado para aplicaciones de una sola página donde el contenido solo se actualiza de vez en cuando, no los que cambian con frecuencia, como la mayoría de los sitios de comercio electrónico. Manipular el DOM virtual es mucho más rápido porque no se dibuja nada en la pantalla.

Reaccionar

Creado y desarrollado por Facebook, React es uno de los marcos de aplicaciones móviles de código abierto más populares. No proporciona una amplia gama de bibliotecas; por lo tanto, su tamaño es significativamente menor que el de Angular.

Con los datos de una sola dirección, React permite un mejor control sobre el proyecto: Al diseñar una aplicación, los desarrolladores de React pueden anidar los componentes secundarios dentro de los componentes principales de orden superior.

React ofrece algunas características interesantes, incluyendo:

  • Virtual DOM: Los nodos se renderizan solo según sea necesario. React compara los nuevos datos con el DOM original y actualiza la vista automáticamente. Esto mejora el rendimiento de las aplicaciones de todos los tamaños que necesitan actualizaciones de contenido regulares.
  • Enlace de datos unidireccional: React utiliza el enlace de datos unidireccional con la arquitectura de aplicación de Flux Controls. ReactJS ayuda a actualizar la vista para el usuario, y Flux controla el flujo de trabajo de la aplicación. Virtual DOM añade ventajas al comparar los nuevos datos con el DOM original y actualizar la vista automáticamente.
  • Soporte para agrupación y agitación de árboles: Minimiza la carga de recursos del usuario final.
  • Soporte de renderizado del lado del servidor (SSR): Ofrece ganancias de velocidad en implementaciones específicas.

En mayor medida que Angular y Vue, React utiliza ciertas técnicas que hacen que la página se “sienta” más rápido para los usuarios finales. Por ejemplo, el marco prioriza la entrada del usuario sobre la representación del contenido en la página.

Vue

Vue es rápido y muy pequeño a solo unos 30KB (gzipped), lo que resulta en primeras cargas más rápidas. Esto lo convierte en el más pequeño de los tres marcos y acelera significativamente el rendimiento de los sitios web que se ejecutan en Vue.

Vue ofrece:

  • Renderizado del lado del servidor (SSR)
  • Temblando de árboles
  • Agrupación
  • DOM virtual: Los cambios dentro de un proyecto no afectan al DOM correctamente. Modificar el DOM real es una tarea que requiere muchos recursos, por lo que las actualizaciones se aplican primero al DOM virtual.

Consulte este informe detallado de referencia para comparar los tiempos de inicio, la asignación de memoria y la duración de operaciones específicas en los principales marcos y bibliotecas de JavaScript. En comparación con React, Vue es ligeramente mejor en términos de asignación de memoria y tiempos de inicio, aunque React es un poco más rápido en tiempo de ejecución.

Angular y Vue utilizan plantillas HTML combinadas con JavaScript. Esto les da espacio adicional para la optimización que React no ofrece. Por ejemplo, Vue rastrea dependencias que impiden renderizaciones innecesarias de componentes secundarios.

Vue vs. React vs. Optimización de SPA angular

Sabemos que los puntos de referencia y las puntuaciones de rendimiento no cuentan toda la historia. La velocidad del sitio web puede variar dependiendo del tamaño de la aplicación y sus esfuerzos de optimización. Aquí hay algunas ideas para ayudar a optimizar Vue, React y Angular spas para la velocidad.

1. Renderizado del lado del servidor (SSR)

En general, hay cuatro beneficios clave de usar SSR con sitios de SPA:

  • SSR le permite cargar rápidamente una plantilla de SPA y mostrar contenido al usuario (aunque es posible que el usuario no pueda interactuar con ella inmediatamente). Sin SSR, los usuarios mirarían fijamente una pantalla vacía, esperando a que el contenido se cargue y se renderice en el navegador.
  • SSR reduce la carga en la máquina del usuario final.
  • Dado que Google ahora puede rastrear correctamente el contenido de SPA, el renderizado del lado del servidor puede no ser tan importante para el SEO como solía ser. Pero el beneficio de usar SSR es que muchos otros motores de búsqueda aún no entienden JavaScript y no pueden rastrear sitios con mucho JavaScript correctamente.
  • Las redes sociales a menudo no pueden mostrar correctamente el contenido compartido de los sitios de SPA renderizados por el cliente. Por ejemplo, el scraper de Facebook solo se basa en las etiquetas meta establecidas por el servidor, y no funciona con las etiquetas meta renderizadas del lado del cliente. Para controlar mejor cómo se ve su sitio de SPA cuando se comparte a través de Open Graph, SSR es una necesidad.
  • AMP acelera las primeras cargas en dispositivos móviles, pero no te permite usar JavaScript. Es imposible renderizar AMP de React en el cliente, debe hacerse en el servidor. Sin embargo, incluso con SSR en su lugar, hay un montón de aros para saltar a través de convertir una aplicación React en una aplicación AMP válida. Afortunadamente, algunos marcos frontend, como React Storefront, pueden manejar todo por ti.

SSR funciona mejor para sitios estáticos, pero los sitios web DE SPA DE comercio electrónico siguen siendo cacheables, con la infraestructura adecuada. Con Layer0, el contenido se renderiza en el lado del servidor fly y luego se almacena en caché en el borde con nuestro CDN-AS-JavaScript. De esta manera, los sitios web a gran escala impulsados por bases de datos, como los spas de comercio electrónico con miles, si no millones de páginas, la personalización, el inventario en tiempo real y más, pueden deleitar a los usuarios con cargas de páginas de subsegundos desde el aterrizaje hasta el pago.

El service worker de CDN-AS-JavaScript (llamado Layer0 Workers) obtiene de forma inteligente datos dinámicos desde el perímetro antes de que el visitante toque un enlace y lo transmita al navegador, en función de lo que probablemente tocará.

Las herramientas de red y monitoreo de Layer0 garantizan que los datos dinámicos se almacenen en caché al menos el 95% del tiempo, protegiendo su base de datos de las solicitudes adicionales creadas por prefetching. De esta manera, puede proporcionar cargas de páginas de subsegundos, ofreciendo a sus visitantes una experiencia perfecta desde el aterrizaje hasta el pago.

Herramientas de red y monitorización Layer0

En general, con respecto a las capacidades de SSR y la documentación detallada, Vue es superior a React, que necesita bibliotecas de terceros (por ejemplo, Next.js) para renderizar páginas del lado del servidor.

2. AMP

AMP crea experiencias mejores y más rápidas en la web móvil simplificando el HTML y aplicando estrictas limitaciones en CSS y JavaScript. Estas páginas se almacenan en caché y se renderizan previamente en el servidor de Google, lo que hace que la transición a tu aplicación sea casi instantánea.

La desventaja es que es diferente de cómo se escribe un PWA / SPA y significa una reescritura completa de la aplicación a menos que utilice un marco dedicado con soporte AMP incorporado, como React Storefront.

Las páginas AMP tienen una carga media de página de 500 ms para el tráfico procedente del SERP de Google. Estas velocidades son posibles porque los servidores de Google preobtienen y pre-guardan contenido AMP en el navegador de un usuario antes de hacer clic en el enlace de la página AMP. El sitio de comercio electrónico promedio obtiene una gran parte de su tráfico de la búsqueda de Google (tanto orgánica como de pago), por lo que estas ganancias pueden tener un impacto masivo.

Los sitios que usan AMP también ven tasas de rebote reducidas, ya que los usuarios que normalmente pueden rebote mientras esperan que una página se cargue ahora se encontrarán con una experiencia ultrarrápida.

3. División de código

Su aplicación de una sola página crecerá con el tiempo a medida que continúe agregando características. Pero sabemos que cada aplicación tiene algunas características que casi nunca se utilizan y se ralentizan innecesariamente. Debes implementar la división de código para mantener tu aplicación lo más rápido posible.

La división de código implica la creación de paquetes separados para cada componente de nivel superior de tu app. En el caso de un SPA DE comercio electrónico, habrá paquetes separados para la página de inicio, listas de productos y páginas de descripción de productos. De esta manera, cuando un usuario llega a tu app a través de un enlace a un producto específico, el navegador no necesita descargar y ejecutar el código de todas las páginas anteriores, reduciendo así los tiempos de TTI y FID.

Con la división de código, la aplicación puede «cargar» otros componentes de la página en segundo plano y usarlos si el usuario decide navegar por ellos. Esto ahorra ancho de banda y disminuye el retraso de la primera entrada o FID (nota FID a menudo se aproxima por tiempo a la métrica interactiva o TTI), mejorando la velocidad de su sitio web y la clasificación de los motores de búsqueda.

4. Carga perezosa

Vue, React y Angular soportan la carga perezosa, que, en combinación con SSR, puede proporcionar mejoras significativas de velocidad.

La carga perezosa presenta un desafío a la hora de implementar la SSR. El servidor debe saber qué componentes se utilizaron para procesar el HTML saliente y enviar el código para esos componentes junto con el HTML. De lo contrario, la aplicación tendrá que montar en el navegador y ejecutar dos ciclos de renderizado antes de que esté lista para ser interactiva, lo que aumentará FID (y TTI), lo que puede conducir a un flash de contenido o jank.

La carga perezosa y el SSR están conectados. La biblioteca que elija para la carga perezosa (por ejemplo, React Loadable) afectará a cómo se genera el HTML final enviado de vuelta en la respuesta. Para capturar los paquetes que deben cargarse para hidratar el HTML que se renderizó en el servidor, deberá agregar <loadable.capture></loadable.capture> a su código SSR, luego use la función getBundles de React Loadable para averiguar qué <script><las etiquetas /script> deben añadirse al cuerpo del documento.

Debido a que las sugerencias del cliente de carga perezosa aún no son compatibles globalmente por todos los navegadores, hay un par de soluciones para implementar la carga perezosa sin problemas.

Solución #1

En lugar de representar las imágenes en el lado del servidor, puedes dejar que se rellenen en el lado del cliente cuando se monta la aplicación.

Solución #2

Solo utilice la carga perezosa para las imágenes «debajo del pliegue», es decir, las que usted sabe no serán visibles inmediatamente después de la carga. Esto es un desafío porque la línea de plegado puede moverse hacia arriba y hacia abajo dependiendo del dispositivo del usuario y el tamaño de la pantalla. Sin embargo, algunas heurísticas ayudan. Por ejemplo, en una página de categoría de comercio electrónico, puede desactivar la carga perezosa para el primer conjunto de imágenes de productos (es probable que estén «por encima del pliegue)». Y para los artículos que sabes que estarán constantemente por encima del pliegue (por ejemplo, encabezados, logotipos de empresa, iconos de carrito), no debes habilitar la carga perezosa de todos modos y siempre puedes renderizarlos en el lado del servidor.

Solución #3

La detección del agente de usuario puede ayudar a servir una versión adecuada de la página renderizada por SSR. La detección de usuario-agente generalmente no se recomienda para implementar mejoras progresivas, pero hace el truco como una solución temporal mientras los navegadores se ponen al día e implementan sugerencias de clientes.

Esta solución requiere que normalice sus claves de caché apropiadamente; de lo contrario, podría fragmentar su caché significativamente.

5. CDN moderno

Optimizar tu SPA para mayor velocidad y usar una buena CDN además de eso impulsará tu sitio, pero no es suficiente para lograr velocidades de subsegundos. Esto se debe a que la mayoría de las CDN tradicionales solo son buenas para almacenar en caché archivos estáticos, pero en general no manejan tan bien los datos JSON/HTML/SSR, mientras que eso es exactamente de lo que están hechos los sitios SPA DE comercio electrónico. Hacer que estos sitios sean más rápidos requiere varias tecnologías web que funcionen eficientemente al unísono. A diferencia de otras CDN, Layer0 CDN compatible con aplicaciones funciona bien con spas de comercio electrónico. Optimiza las proporciones de acierto de caché a niveles inauditos y lleva la inteligencia al borde. Esto ayuda a los propietarios de negocios a descifrar tendencias y oportunidades de optimización al categorizar páginas similares como tales (por ejemplo, PDP, PLP y CART) en lugar de mostrar una lista interminable de URL. Esto le permite tomar medidas y ver una diferencia en los tiempos de carga del sitio web.

Pero lo más importante es que CDN-AS-JavaScript utiliza técnicas avanzadas de preobtención predictiva para transmitir datos almacenados en caché desde el perímetro a los navegadores de los usuarios antes de tocar cualquier cosa. Esto mantiene los sitios web 5 segundos por delante de los golpecitos de los compradores, lo que les permite deleitar a los usuarios con una experiencia de navegación instantánea.

6. Herramientas móviles

Angular es ideal para la construcción de aplicaciones móviles. Puedes usar el framework para crear una aplicación web que se ejecute en cualquier dispositivo o desarrollar aplicaciones nativas de iOS y Android combinando Angular con NativeScrip. Esto le permite reutilizar conceptos angulares como el enlace de datos, la inyección de dependencia, los servicios y el enrutamiento.

React Native es considerado el rey del desarrollo multiplataforma. Permite a los desarrolladores reutilizar hasta el 99% del código JavaScript entre Android e iOS con componentes similares a React. Esto significa que los desarrolladores pueden crear widgets 100% nativos que controlan su propio estilo. El marco maneja la capa de vista como una salida de estado puro, lo que facilita la creación de aplicaciones complementarias para iOS / Android con un aspecto y rendimiento nativos.

Aunque Vue se queda atrás de React, todavía ofrece varias soluciones valiosas para el desarrollo móvil. Por ejemplo, NativeScript le permite escribir aplicaciones Vue y compilarlas en aplicaciones nativas iOS / Android.

Luego viene Vue Native. El marco combina las ventajas de los ecosistemas Vue y RN, renderizado declarativo, enlace bidireccional y un conjunto de componentes básicos para crear una aplicación nativa multiplataforma.

Los spas son más rápidos, pero todavía tienen problemas de velocidad

El atractivo original de una aplicación de una sola página es que las páginas posteriores no se recargan durante la navegación, lo que conduce a una experiencia de navegación más rápida y sin fricciones. Pero los frontend modernos DEL SPA son solo parte de la solución de velocidad del sitio, y un par de problemas todavía necesitan ser abordados:

  • Los puntos de referencia de velocidad sintética y las pruebas no necesariamente cuentan toda la historia. La velocidad de estos marcos puede variar dependiendo del tamaño de la aplicación y sus esfuerzos de optimización.
  • Mientras que varias tecnologías frontend de vanguardia, incluyendo aplicaciones web progresivas, spas y AMP, pueden mejorar drásticamente la experiencia del cliente, la velocidad del sitio web es un problema de pila completa. Abarca el navegador, el borde y el servidor. Es por eso que se necesita una solución de pila completa para acelerar cualquier sitio web, SPA y aplicación de varias páginas.
  • Todas estas tecnologías pueden mejorar las velocidades, pero funcionan mejor cuando se aplican al unísono. Hacer que todas estas tecnologías funcionen juntas es una tarea compleja que los equipos internos pueden ser incapaces de manejar (por ejemplo, requiere crear una capa Node.js).

Layer0: Hacer que la Web sea instantánea y simple

Layer0 es una solución completa para hacer que los sitios web de comercio electrónico sean rápidos y fáciles de desarrollar. Combina técnicas avanzadas de optimización para acelerar sitios web a gran escala impulsados por bases de datos, como spas de comercio electrónico, junto con potentes herramientas que brindan a los desarrolladores un día a la semana al poner el código en el centro de sus flujos de trabajo. Layer0 esencialmente trae Jamstack a grandes sitios web de comercio electrónico.

Instantáneo: Al combinar frontend modernos con un CDN-as-JavaScript con una tasa de acierto de caché del 95% para contenido dinámico en el borde y un backend-for-frontend de Node.js, Layer0 ayuda a los sitios web complejos a optimizar la velocidad en toda la pila. Es la única plataforma que garantiza tiempos de Pintura de Contenido (LCP) medianos por debajo del segundo más grande para sitios web de comercio electrónico a gran escala.

Simple: Layer0 (ahora Edgio) es su plataforma todo en uno para desarrollar, implementar, previsualizar, experimentar, monitorear, y y ejecuta el frontend que te permite:

  • Utilice Jamstack para comercio electrónico a través de renderizado pre y justo a tiempo
  • Habilite redes de latencia cero mediante la obtención previa de datos de las API de su catálogo de productos
  • Configurar Edge de forma nativa en tu app (CDN-AS-JavaScript)
  • Ejecute reglas de borde localmente y en pre-prod
  • Cree URL de vista previa desde GitHub, GitLab o BitBucket con cada nueva rama y push
  • Ejecute divisiones en el borde para pruebas A/B de rendimiento, despliegues de canarias y personalización
  • JavaScript sin servidor que es mucho más fácil y confiable que AWS Lambda

Conclusión

Ejecutar un sitio más rápido no es solo un truco de lujo. Al final del día, usted no solo está tratando de sorprender a sus usuarios, sino también tratando de complacer al motor de búsqueda más grande del mundo. Dado que el ranking de Google pronto se determinará, en parte, por la velocidad de la página, no se puede tomar a la ligera. Un sitio rápido significa que aumenta tus rankings SEO y conversiones, lo que, a su vez, genera más ingresos.

Si bien se puede decir mucho sobre el rendimiento de cada marco, hay tres puntos a recordar:

  1. Las diferencias del mundo real en el rendimiento del marco pueden ser minúsculas. El rendimiento de los sitios de SPA depende de tantas variables que es imposible comparar estos marcos de una manera significativa.
  2. Ya sea que estés en Angular, Vue o React, todavía hay mucho espacio para mejorar.

Hacer que los spas sean más rápidos requiere una combinación de tecnologías web avanzadas que trabajen al unísono, y es posible que sus equipos internos no puedan implementarlos de manera eficiente. Afortunadamente, algunos proveedores con visión de futuro, incluyendo Layer0, han hecho el trabajo pesado para usted.

Layer0 combina el renderizado del lado del servidor con la preobtención predictiva avanzada y el prealmacenamiento en caché en el borde. Debido a que los datos dinámicos se almacenan en caché al menos el 95% del tiempo, su base de datos está protegida de las solicitudes adicionales creadas por la preobtención. El service worker de Layer0 CDN-AS-javascript obtiene de forma inteligente tus páginas dinámicas antes de que tu visitante toque un enlace. De esta manera, puede proporcionar cargas de páginas de subsegundos en aplicaciones de una sola página, ofreciendo a sus visitantes una experiencia perfecta desde el aterrizaje hasta el pago.