A pesar de todas sus ventajas, aplicar Jamstack a sitios web de comercio electrónico con grandes catálogos y actualizaciones frecuentes implica muchos desafíos. Si está ejecutando un sitio de comercio electrónico en una plataforma de backend como Salesforce Commerce Commerce Cloud, Magento o SAP-Hybris, probablemente ya se esté enfrentando a algunos de ellos.
Este artículo cubre los desafíos clave en la construcción de sitios de Jamstack de comercio electrónico a gran escala y cómo Layer (ahora Edgio) puede ayudarlo a abordar estos problemas.
Para ver la versión completa de la presentación del CTO de Layer0 Ishan Anand en Jamstack Conference 2020, visite el canal oficial de YouTube de Layer0.
¿Qué es Layer0 (ahora Edgio)?
Layer0 trae las ventajas de Jamstack al comercio electrónico, acelerando la velocidad del sitio y simplificando los flujos de trabajo de desarrollo. Al transmitir datos almacenados en caché desde el borde al navegador, antes de que se soliciten, Edgio puede mantener los sitios web 5 segundos por delante de los toques de los compradores. Sharper Image, REVOLVE y Shoe Carnival son solo ejemplos de sitios que aprovechan la plataforma Layer0 Jamstack para aumentar la productividad de los desarrolladores y ofrecer sus sitios web de subsegundos.
¿Cuáles son los desafíos de usar Jamstack para el comercio electrónico a escala?
El uso de Jamstack y headless para el comercio electrónico, especialmente en sitios con catálogos grandes, actualizaciones frecuentes o aquellos en plataformas monolíticas de comercio electrónico, se asocia típicamente con hacer frente a los siguientes desafíos:
- Largos tiempos de construcción
- Actualizaciones frecuentes
- Migraciones de sitios complicadas
- Datos dinámicos
- Personalización
- Pruebas A/B.
- API incompletas
- Arquitectura de canalización de datos
- Personalizaciones perdidas por APIs
- Límites de conexión de base de datos
- Capacidad de equipo
- Integración CMS
- Estilos incrustados en contenido CMS
- Integración del flujo de trabajo de backoffice
Construir fricción de tiempo y otros desafíos a escala
Jamstack tiene una escalabilidad de alto tráfico incorporada. Pero el paso de construcción introduce una nueva dimensión de escalado, ya que el renderizado estático típico ocurre durante la construcción. A medida que amplías tu sitio web o realizas cambios más frecuentes, sales del punto dulce donde Jamstack es rápido y ágil. El resultado es la fricción del tiempo de construcción. Es fácil barrer el problema debajo de la alfombra si está trabajando en un sitio pequeño, pero ese no es el caso para el sitio típico de comercio electrónico.
Otra cosa importante a recordar es que los sitios son construidos tanto por no desarrolladores como por desarrolladores. Debido a que el contenido, el marketing y la comercialización cambian constantemente las cosas, la fricción del tiempo de construcción puede convertirse rápidamente en un problema para toda la organización.
Todo esto es para decir que “a escala” sucede más de lo que pensarías, y no se limita al comercio electrónico. Echa un vistazo a esta comparación entre los minoristas y los sitios web de noticias. Para los sitios de comercio electrónico, el número de SKU es un proxy para el número de páginas.
Sitios de comercio electrónico con muchos productos (SKU), Editores con muchos artículos
Editores con muchos artículos
Si bien puede pensar que solo sitios como Amazon tratan con millones de SKU, esto no es cierto. Los sitios web de piezas de automóviles son un gran ejemplo: Albergan millones de productos basados en los criterios de búsqueda de año/modelo/marca/vehículo (YMMV). Por ejemplo, TruPar.com vende piezas de carretilla elevadora exclusivamente, con SKUs 8M.
Afortunadamente, algunas técnicas de renderizado estático y dinámico ayudan a lidiar con los problemas de Jamstack a escala.
Técnicas “estáticas”
- Optimización de tiempos de construcción
- Representación del lado del cliente
- (Re)generación estática incremental
Técnicas “dinámicas”
- Renderizado sin servidor del lado del servidor + CDN
- Representación estática paralela
Técnicas de renderizado “mixtas”
- Elegir la mejor técnica de renderizado para cada clase de páginas
- Elegir un marco y una plataforma que le permita mezclar técnicas según sea necesario
En los párrafos siguientes, discutiremos lo que significan estas técnicas.
Técnicas estáticas
Optimización de tiempos de construcción
Existen varios métodos para optimizar los tiempos de compilación de las páginas dinámicas de Javascript.
Construcciones incrementales
Con las compilaciones incrementales, puedes guardar artefactos de compilación y solo regenerar lo que ha cambiado. Si solo se cambia una sola página, regenerarás esa sola página.
Construcciones paralelas
El marco divide la construcción en múltiples procesos o hilos. Esto es útil para el procesamiento de imágenes.
Generadores estáticos alternativos del sitio
Los SSGs con alimentación nativa son un método emergente y se ha encontrado que reportan mejores tiempos de construcción. Los ejemplos incluyen Hugo (Go) y NIFT (C++). Sin embargo, muchos generadores de sitios estáticos escritos de forma nativa no funcionan bien con sitios web pesados con Javascript. Un brindis relativamente nuevo está tratando de hacer frente a eso.
La advertencia es que el soporte de proveedores de infraestructura y nube para compilaciones paralelas e incrementales varía. No todos lo apoyan, y aquellos que sí ofrecen solo un apoyo limitado.
Posible exceso de costo para páginas con visitas poco frecuentes
También está la cuestión del posible exceso de costo. Si tiene un sitio grande con decenas de miles de SKU o más, la mayor parte de su tráfico sigue una distribución de energía y pasa tiempo de cálculo adicional para reconstruir páginas que nunca serán visitadas. Cuanto más actualice el sitio, mayor será el costo. Tenga esto en cuenta cuando piense en algunas de estas técnicas.
Según willit.build (una página de referencia de compilación de Gatsby, que proporciona tiempos de compilación históricos de sitios construidos en Gatsby Cloud), los tiempos de compilación para sitios Contentful y WordPress son de aproximadamente 200 ms por página, lo que significa que para un sitio con 10k páginas, una compilación completa del sitio podría tardar 25 minutos. Las construcciones incrementales pueden llevarte a unos minutos, mostrando el poder de las construcciones incrementales. Esta técnica puede ser útil si no haces compilaciones completas.
Representación del lado del cliente
También conocido como el shell de la aplicación o el modelo de respaldo de SPA, el renderizado del lado del cliente es el enrutamiento CDN. Si su sitio aloja un millón de productos, todos estos son enrutados por esta capa de CDN al index.html y se convierten en un archivo estático que contiene un shell de aplicación y se renderiza del lado del cliente. Cuando el navegador carga esa página, el router cliente-sitio recogerá y renderizará el contenido de la página en el navegador.
Con el renderizado del lado del cliente, puede alojar efectivamente un número infinito de páginas, pero hay algunas consideraciones importantes:
La RSC puede afectar negativamente al SEO
La advertencia con el renderizado del lado del cliente es que podría dañar el rendimiento, porque la página no puede renderizarse hasta que se cargue Javascript. A partir de mayo de 2021, Google clasificará los sitios web en función de las métricas de tres velocidades, CLS, LCP y FID, denominadas colectivamente Core Web Vitals. El renderizado del lado del cliente puede afectar negativamente a todos estos, especialmente los cambios de diseño acumulativo. No es imposible, y es difícil obtener un buen CLS con el modelo de shell de la aplicación. Para hacerlo, debe crear versiones personalizadas del shell de la aplicación para cada tipo de página.
Las páginas renderizadas del lado del cliente no pueden ser leídas por (algunos) bots
Algunos bots no pueden leer contenido renderizado del lado del cliente. Google afirma que sus bots pueden renderizar Javascript e interpretarlo, pero sabemos que la mayoría de los demás bots no pueden, incluyendo los de la mayoría de las plataformas sociales, que es una fuente de tráfico importante para muchos sitios.
CSR requiere soporte para reglas de reescritura y redirección
La tercera advertencia en la implementación de la RSC es que requiere el soporte de su proveedor de CDN para reescribir y redirigir reglas, y algunos lo hacen con más elegancia que otros. Por ejemplo, tiene que comprar esto en AWS CloudFront a través de su soporte de 404 páginas o usar controladores Lambda@Edge.
Afortunadamente, las principales plataformas de Jamstack Netlify, Vercel y Layer0 ofrecen una manera bastante fácil de habilitar la RSC.
En Netlify, tiene un archivo de redirecciones. Con los modificadores 200, es una reescritura, pero es una redirección oculta que el usuario nunca ve.
Netlify
Vercel ofrece soporte de reescritura en vercel.json, también se integra muy estrechamente con Next.js.
Vercel
El shell de comandos CDN-as-javascript en Layer0 ofrece Next.js reescribe y admite otros frameworks.
Layer0 (Edgio)
Generación estática incremental
Esta técnica fue pionera por Next.js e implicó la generación de nuevas páginas estáticas a pedido en respuesta al tráfico entrante. El navegador solicita una nueva página que aún no ha sido visitada, y para cada página, independientemente de cuál sea la página, la CDN devolverá rápidamente una página de respaldo universal que solo contiene datos de marcador de posición y ningún contenido.
Mientras se muestra la página de respaldo, el proceso de compilación estática de la página se ejecuta en segundo plano. Cuando esa compilación se completa, la página de respaldo carga los datos estáticos de JSON y muestra la página final. A partir de entonces, las futuras visitas obtendrán el HTML construido estáticamente.
Regeneración estática incremental
Hay una versión de la generación estática incremental llamada regeneración estática incremental, que es esencialmente el mismo proceso. Aún así, implica actualizar una página estática existente en respuesta al tráfico. Por lo tanto, si los datos subyacentes cambian, están reejecutando el proceso de compilación, inspirado en un protocolo de caché popular pero no muy apreciado. Esto servirá una versión obsoleta de la página en lugar de la reserva mientras está reconstruyendo la página y luego cambiará eso por la nueva versión una vez que finalice el proceso de compilación.
Regeneración estática incremental:
- Actualiza las páginas estáticas existentes en respuesta al tráfico,
- Sirve como una versión obsoleta de la página en lugar de un respaldo.
La regeneración estática incremental tiene un impacto menor en el SEO y la compatibilidad, especialmente en la primera página. La página de respaldo es completamente CSR y no tiene datos, por lo que no está claro cómo responderán los bots.
Técnicas dinámicas
Además de las técnicas estáticas, los sitios web de comercio electrónico también pueden beneficiarse de técnicas dinámicas como:
- Renderizado sin servidor del lado del servidor + CDN
- Representación estática paralela
Renderizado sin servidor del lado del servidor + CDN
El uso de SSR en conjunto con la CDN le permite generar páginas bajo demanda en respuesta al tráfico, lo que le da algunas ventajas. Esta técnica también es más compatible con la forma en que se hacen las plataformas tradicionales de comercio electrónico. Le permite admitir muchas páginas (puede generarlas dinámicamente cuando sea necesario) y garantiza una alta compatibilidad con las plataformas heredadas.
Sin embargo, esta técnica también es un poco controvertida. La comunidad de Jamstack tiende a ser muy dogmática sobre lo que es Jamstack y afirma que Jamstack requiere generación estática.
El renderizado del lado del servidor sin servidor es efectivamente Jamstack-ish cuando se cumplen 2 condiciones:
- Cero DevOps y servidores para administrar. Es sin servidor y los desarrolladores no tienen que administrar Scale-way. Es la misma sin servidor que muchas plataformas de Jamstack usan para alimentar sus API, lo que dice que puedes usarla para alimentar datos HTML y a través de SSR.
- HTML se sirve desde la CDN. Esta es una condición crítica. Después de la primera pérdida de caché, el sitio servido por CDN es tan rápido como un sitio de Jamstack generado estáticamente. Tenga en cuenta que esto requiere una gestión de caché adecuada y es más difícil para los sitios de varias páginas.
Renderizado estático paralelo / precarga SSR
Layer0 le permite especificar el conjunto de URLs que deben preprocesarse y almacenarse en caché en el perímetro durante la implementación para garantizar que los usuarios obtengan una experiencia de subsegundos al acceder a su sitio.
La prerepresentación estática implica el envío de solicitudes al código de la aplicación y el almacenamiento en caché del resultado justo después de que se implementa el sitio. De esta manera, simplemente construyes tu aplicación para implementar el renderizado del lado del servidor y obtener los beneficios de velocidad de un sitio estático para algunas o todas tus páginas. Esta característica es especialmente útil para sitios grandes y complejos con demasiadas URL para pre-ender sin incurrir en tiempos de compilación excepcionalmente largos.
La precarga SSR es otra técnica utilizada por Layer0 para acelerar las velocidades de página. Es muy similar a la tubería SSR regular, pero se basa en el análisis de los registros de tráfico después de la implementación. Las páginas de alto tráfico se cargan previamente en paralelo al despliegue. Dejamos que el despliegue ocurra instantáneamente y de forma asíncrona construimos las páginas de alto tráfico. De esta manera, desacoplas el despliegue de la compilación. Por lo tanto, obtiene implementaciones inmediatas al tiempo que maximiza los accesos de caché.
Esencialmente, si hay una solicitud para una página con altos niveles de tráfico, lo más probable es que haya un golpe de caché. Es la mejor manera de obtener los mejores accesos de caché posibles en este entorno.
El renderizado estático paralelo le permite:
- Analice los registros para páginas de alto tráfico
- Obtenga y almacene HTML para páginas de alto tráfico de forma asíncrona después de la implementación
- Implemente inmediatamente mientras maximiza los hits de caché
Preinscripción estática
Técnicas de renderizado mixto
No tienes que elegir entre técnicas de renderizado estático y dinámico. Puedes elegir lo que es correcto para cada clase de páginas en tu sitio. Es posible que desee declarar como dinámicos el “Acerca de nosotros”, la “Política de devolución” o el blog estático y otras páginas como carrito, producto y categorías. Recomendamos elegir un proveedor de plataformas que le permita mezclar de forma flexible las técnicas según sea necesario, especialmente si lo está haciendo a escala.
Elija la mejor técnica de renderizado para cada clase de páginas, por ejemplo, declarar algunas páginas estáticas (por ejemplo, blog, Acerca de nosotros, etc.), y otras páginas dinámicas (por ejemplo, carrito, productos, categorías, etc.)
Elija un proveedor de marcos y plataformas que le permita mezclar técnicas de manera flexible según sea necesario
Jamstack a escala con Layer0
Las imágenes de caché CDN actuales, JavaScript y CSS, pero no los archivos JSON o HTML, y eso es lo que mantiene los tiempos de carga de la página. Layer0 CDN-AS-JavaScript hace que sea posible mantener en caché esos datos en el borde incluso en un entorno SSR dinámico y sin servidor.
Jamstack saca al servidor de la ecuación y permite que la CDN administre eficazmente el tráfico, lo que puede hacer con facilidad independientemente de las fluctuaciones del tráfico. Layer0 hace lo mismo pero de manera diferente: En lugar de renderizar en la compilación, renderizamos a petición, pero almacenamos en caché cada compilación en el borde, por lo que una compilación ya no es necesaria después de 1 compilación.
Renderizar cada página en Build está bien para sitios más pequeños, pero el tiempo de construcción se vuelve casi insoportable una vez que eres más grande. La falta de personalización/personalización o las soluciones alternativas para ofrecerlas hace que el enfoque de Jamstack en el tiempo de construcción sea menos relevante para sitios web a gran escala impulsados por bases de datos como eCommerce y Travel.
CDN-AS-JavaScript
Layer0 CDN-AS-javascript le da un poderoso control de borde sobre las claves de caché, encabezados, cookies y más, y también funciona con su código. Entiende su código y el enrutamiento de su marco y se puede emular localmente o en entornos de preproducción.
Las reglas de borde viven en tu código, al igual que en el clásico Jamstack, lo que te brinda un control completo sobre el borde con registros en vivo, versiones y retrocesos de 1 clic.
Vea el libro de cocina Layer0/Edgio para ver algunos ejemplos detallados de patrones de enrutamiento en CDN-AS-JavaScript.
Monitor de rendimiento
Para maximizar las tasas de acierto de la caché, es importante saber cuáles son estas tasas en primer lugar, pero esta información generalmente se encuentra enterrada en los registros de acceso de su CDN.
Layer0 ha incorporado la supervisión del rendimiento, lo que facilita la comprensión de cuándo ocurren errores y errores en la caché de la página y expone esta información al desarrollador de una manera muy amigable. El Monitor de Rendimiento en Layer0 le permite:
- Entiende el tráfico basado en las rutas, no en las URL, porque así es como los desarrolladores piensan sobre su aplicación. También rastrea cada despliegue, para que los desarrolladores puedan identificar cualquier regresión.
- Mida los problemas de rendimiento en la pila y escenarios de carga (API, SSR, Edge, etc.)
Layer0 también ha creado una herramienta para diagnosticar si la respuesta proviene del borde del origen: Devtools. Devtools te ayuda a determinar si la respuesta proviene del borde del origen. El ejemplo a continuación presenta cómo funciona en la parte superior de una shell de aplicación construida con React Storefront, que muestra cuándo llega una solicitud. La respuesta en este ejemplo viene a través de la red perimetral Layer0 (ahora Edgio).
Layer0 DevTools le permite diagnosticar si las respuestas provienen del borde o del origen
Entender si una respuesta proviene del borde o el origen es crítico para obtener previamente en escalas, lo cual es otra cosa que Layer0 hace por usted.
Prefetching a escala
La preobtención es importante para el rendimiento porque desbloquea velocidades de página instantáneas. Las pruebas de velocidad de página tradicionales, como las que pruebas con Lighthouse, se centran en lo que sucede después de que el cliente haga clic. Pero puedes empezar a hacer mucho antes de que el cliente toque y obtenga latencia cero y ancho de banda casi infinito.
Layer0 DevTools le permite diagnosticar si las respuestas provienen del borde o del origen
Los sitios web en Layer0 son increíblemente rápidos porque utilizan prefetching predictivo avanzado junto con Layer0 CDN-AS-JavaScript, lo que les permite mantenerse 5 segundos por delante de los toques de los compradores. Esto se hace transmitiendo datos dinámicos almacenados en caché desde el borde a los navegadores de los usuarios antes de hacer clic en cualquier cosa, en función de lo que se espera que hagan clic en Siguiente. En otras palabras, su tienda puede servir datos JSON para los diferentes productos que está ofreciendo, sus precios e información en una fracción del tiempo.
Migración incremental
Layer0 ofrece migración iterativa (gradual, progresiva), que le permite migrar iterativamente una sección de la aplicación a la vez, siguiendo el patrón de Martin Fowler Strangler. De esta manera, se “estrangulan” funcionalidades específicas y las reemplazan con nuevas aplicaciones y servicios. Es como mover una montaña piedra por piedra.
La migración incremental requiere un control enrutado en el borde o el origen de la CDN. Aquí hay un ejemplo de cómo hacer esto en Layer0 usando CDN-AS-JavaScript.
Personalización y segmentación
La migración gradual, gradual y progresiva es importante para los sitios grandes. ¡Pero no se limita a la personalización! También abarca el lenguaje, la geografía, etc. Y tiene sentido porque los sitios grandes generalmente funcionan en toda la geografía, y deben ser capaces de personalizar el contenido a los usuarios a medida que visitan el sitio.
La guía general es: Si este contenido está por debajo del pliegue, recomendamos la carga tardía y la representación del lado del cliente. Si es contenido personalizado por encima del pliegue, lo desea en una salida renderizada por servidor.
Por encima del pliegue personalizado = añadir personalización a la clave de caché
En Layer0, puede declarar una clave de caché personalizada y personalizarla, por ejemplo, en función de la moneda o el comportamiento. Puede personalizar las promociones y ordenar el orden en las páginas de la categoría, según si alguien es un visitante frecuente o un nuevo visitante, con solo unas pocas líneas en CDN-AS-javascript.
Pruebas A/B y la Layer0
Las pruebas A/B y la personalización añaden una nueva capa de complejidad a la construcción de sitios de Jamstack. Las pruebas son muy importantes para los sitios grandes y las grandes organizaciones, donde las decisiones están impulsadas por el ROI y se debe demostrar que mejoran las tasas de conversión.
En Jamstack tradicional, sin embargo, la única opción que tiene es la prueba A/B del lado del cliente que se ejecuta en el navegador. El problema es que esto puede afectar el rendimiento y anular sus pruebas de dos maneras. Puede dañar el rendimiento de sus variantes, borrando cualquier tipo de mejora. Y a veces, las pruebas A/B tienen efecto después de que el ojo ha superado los elementos probados. Es posible que tenga la prueba A/B en el encabezado, y el usuario ya ha escaneado más allá de ese encabezado una vez que el JavaScript se ejecuta y cambia ese elemento.
Los problemas con las pruebas A/B del lado del cliente
- Por lo general, la única opción para sitios estáticos
- No se ejecuta hasta que se ejecuta JavaScript
- Pobre rendimiento que posiblemente anula la prueba
Los experimentos de Layer0 Edge solucionan estos problemas al permitir pruebas A/B en el borde. En la XDN, las nuevas experiencias son siempre nativas, almacenadas en caché y sub-segundos. Esto se extiende más allá de las pruebas A/B a cualquier variante de su sitio web.
Experimentos de borde
Layer0 también viene con un potente motor Edge Experiments incorporado. El módulo es parte de CDN-AS-JavaScript y está al tanto de todas sus variantes, asegurando que cada una se almacena en caché por separado en el borde. Esto le da control sobre exactamente qué visitantes ven qué variante.
Los experimentos Edge te permiten:
- Enrute el tráfico en vivo a cualquier sucursal implementada en el borde de la red
- Ejecute pruebas A/B, despliegues canarios o banderas de características
- Escribe reglas de enrutamiento basadas en probabilidades o valores de encabezado e incluso
- Direcciones IP
Con Edge Experiments, puede dividir fácilmente las pruebas sin afectar el rendimiento de su sitio. Las divisiones se ejecutan en el borde a través de una interfaz fácil de usar pero potente. Los experimentos Edge se pueden utilizar para pruebas A/B y multivariantes, despliegues canarios, pruebas azul-verdes, migración iterativa fuera de un sitio web heredado, personalización y más.
Cómo nuestros clientes se benefician de Layer0
Layer0 proporciona una transición sin fricciones a Jamstack y headless y ofrece una gran ventaja para sitios con catálogos grandes, actualizaciones frecuentes o aquellos que ejecutan plataformas de comercio electrónico heredadas. Shoe Carnival y Turnkey Vacation Rentals son dos ejemplos de equipos de desarrolladores en sitios grandes que usan Jamstack y Headless para comercio electrónico en Layer0.
Llave en mano
Turnkey Vacation Rentals es una empresa de gestión de propiedades de alquiler de vacaciones de servicio completo para casas de alquiler de lujo y premium en los principales destinos de viaje en todo el país. A diferencia de sitios como Airbnb, Turnkey solo ofrece listados previamente examinados. También maneja los detalles de la gestión de forma centralizada, utilizando un conjunto estandarizado de herramientas tecnológicas.
Configuración original
Turnkey estaba ejecutando una aplicación dentro de Docker en AWS Elastic Beanstalk y estaba buscando una solución para proporcionarles un mayor control y conocimiento del rendimiento.
Consideraron algunas soluciones de Jamstack, pero querían una plataforma que soportara Next.js de forma nativa, como Layer0. Uno de los factores decisivos fue que con Layer0, podían evitar refactorizar cómo funcionaba su base de código y su canalización de datos.
Layer0 ha ayudado a la llave en mano a aumentar la agilidad con algunas características enumeradas a continuación.
Entornos
En el pasado, la llave en mano usaba una tubería personalizada construida dentro de Jenkins, y el equipo se desplegaba desde una rama troncal, sin tener una confianza total en lo que se estaba preparando para salir a la producción.
Con Layer0, las sucursales tienen entornos individuales, y el equipo de Turnkey puede configurar entornos prístinos; no se fusionan con el entorno de puesta en escena hasta que saben que algo ha pasado el control de calidad. Esto elimina la carga mental asociada con el QA.
Registros
Explorar los registros del servidor en Beanstalk puede ser una pesadilla: Tienes que averiguar exactamente qué registros estás buscando, en qué servidor están, si están equilibrados de carga, etc. Con Layer0, puede transmitir registros en vivo directamente desde su compilación, lo que le permite encontrar la compilación que desea solucionar, presionar PLAY y ver el registro.
Migración incremental
Turnkey tenía páginas, no en React/Next.js, y se ejecutaba en la arquitectura antigua. Con Layer0, podrían tomar lo que ya habían migrado, ponerlo en la XDN y continuar migrando gradualmente.
Layer0 le dio al equipo de Turnkey herramientas para centrarse en el rendimiento.
Carnaval de zapatos
Shoe Carnival Inc. Es un minorista estadounidense de calzado. La compañía actualmente opera una tienda en línea junto con 419 tiendas de ladrillo y mortero en las regiones del medio oeste, Sur y Sudeste de los Estados Unidos.
A continuación se presentan algunas de las características de Layer0 que el equipo de Shoe Carnival encontró especialmente útiles.
Flexibilidad
Shoe Carnival utiliza Salesforce Commerce Cloud, que no está destinado a ejecutar frontend sin cabeza como el de Shoe Carnival. Así que había mucha ingeniería y comprensión en el lado del backend para ejecutar los datos en el frontend. Esos desafíos podrían resolverse debido a la flexibilidad que ofrecía el backend Layer0 entre Salesforce y el frontend React. El equipo de Shoe Carnival pudo construir libremente con React e ignorar las limitaciones de Salesforce.
Tiempo para un impulso de producción
El tiempo de producción de Shoe Carnival aumentó dramáticamente. El equipo puede separarse de los ciclos de desarrollo de Salesforce y realizar cambios muy rápidos en la implementación.
Velocidad del sitio
La velocidad a la producción es un gran beneficio, pero el rendimiento del sitio generalmente es difícil de ignorar, ya que el Carnaval de Zapatos pasó de 5-6 segundos de carga promedio de página a sub-segundos. Pueden almacenar en caché las cosas a un nivel muy granular y tener las herramientas para garantizar que los clientes están buscando siempre disponibles y actualizados.
Despliegue incremental
La implementación incremental permite que el equipo se implemente en producción mucho más rápido que la creación de una aplicación completa para implementarla.
En cuanto al impacto de la migración a Layer0, cuando Shoe Carnival probó el sitio de origen contra el sitio sin cabeza para las conversiones 50/50 a nivel CDN, el sin cabeza siempre ganó, superando al sitio de origen y mejorando la velocidad y visibilidad.
Resumen
En Layer0, creemos que Jamstack es el futuro del desarrollo web. Layer0 esencialmente trae los beneficios de rendimiento y simplicidad de Jamstack a los equipos de desarrolladores de front-end en sitios de comercio electrónico grandes y dinámicos donde las técnicas estáticas tradicionales normalmente no se aplican. Nos gusta llamarlo Jamstack dinámico. Hace que los sitios web DE SPA se carguen instantáneamente y sean más fáciles de desarrollar.
Layer0 viene con un CDN-as-JavaScript compatible con la aplicación, que puede aumentar o incluso reemplazar su CDN actual y llevar todas las características de seguridad web que necesita al borde. Layer0 también viene con un montón de tecnologías enfocadas en el desarrollo que hacen todo el proceso de desarrollo, despliegue, previsualización, experimentación, monitoreo, etc. y ejecutando su frontend sin cabeza simple, incluyendo URL de vista previa de pila completa automatizadas, un backend JavaScript sin servidor para frontend, monitoreo de caché avanzada y más.
Layer0 es una plataforma de desarrollo todo en uno que le 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
