Home Blogs Jamstack para eCommerce em escala
Applications

About The Author

Outline

Apesar de todas as suas vantagens, aplicar o Jamstack a sites de comércio eletrônico com grandes catálogos e atualizações frequentes envolve muitos desafios. Se você estiver executando um site de comércio eletrônico em uma plataforma de back-end, como Salesforce Commerce Cloud, Magento ou SAP-hybris, provavelmente já está enfrentando alguns deles.

este artigo aborda os principais desafios na construção de sites Jamstack de comércio eletrônico em grande escala e como a Layer (agora Edgio) pode ajudá-lo a resolver esses problemas.

Para ver a versão completa da apresentação do CTO Layer0 Ishan Anand na Jamstack Conference 2020, acesse o canal oficial do YouTube Layer0.

O que é Layer0 (agora Edgio)?

Layer0 traz as vantagens do Jamstack para o eCommerce, acelerando a velocidade do site e simplificando os fluxos de trabalho de desenvolvimento. Ao transmitir dados armazenados em cache da borda para o navegador, antes de serem solicitados, o Edgio pode manter os sites 5 segundos à frente dos toques dos compradores. Sharper Image, REVOLVE e Shoe Carnival são apenas exemplos de sites que utilizam a plataforma Layer0 Jamstack para aumentar a produtividade do desenvolvedor e entregar seus sites sub-segundos.

Quais são os desafios de usar o Jamstack para eCommerce em escala?

O uso do Jamstack e sem cabeça para eCommerce, especialmente em sites com grandes catálogos, atualizações frequentes ou em plataformas monolíticas de eCommerce, é normalmente associado a lidar com os seguintes desafios:

  • Longos tempos de construção
  • Atualizações frequentes
  • Migrações de sites complicadas
  • Dados dinâmicos
  • Personalização
  • Testes A/B.
  • APIs incompletas
  • Arquitetura de pipeline de dados
  • Personalizações perdidas por APIs
  • Limites de conexão do banco de dados
  • Capacidade da equipa
  • Integração com CMS
  • Estilos incorporados no conteúdo do CMS
  • Integração do fluxo de trabalho do backoffice

Construa o atrito do tempo e outros desafios em escala

Jamstack tem escalabilidade de alto tráfego embutido. Mas a etapa de compilação introduz uma nova dimensão de escala, como a renderização estática típica acontece durante a compilação. À medida que você expande seu site ou realiza alterações mais frequentes, você sai do ponto ideal onde o Jamstack é rápido e ágil. O resultado é o atrito do tempo de construção. É fácil varrer o problema sob o tapete se você está trabalhando em um site pequeno, mas esse não é o caso do site de comércio eletrônico típico.

Outra coisa importante a lembrar é que os sites são construídos tanto por não desenvolvedores quanto por desenvolvedores. Como o conteúdo, o marketing e o merchandising mudam constantemente as coisas, a fricção do tempo de construção pode rapidamente se tornar um problema para toda a organização.

Tudo isso é dizer que “em escala” acontece mais do que você pensaria, e não se limita ao comércio eletrônico. Dê uma olhada nesta comparação entre varejistas e sites de notícias. Para sites de comércio eletrônico, o número de SKUs é um proxy para o número de páginas.

Sites de comércio eletrônico com muitos produtos (SKUs), editores com muitos artigos

Editores com muitos artigos

Embora você possa pensar que apenas sites como a Amazon lidam com milhões de SKUs, isso não é verdade. Os sites de peças de automóveis são um ótimo exemplo: Eles hospedam milhões de produtos com base nos critérios de pesquisa de ano/modelo/marca/veículo (YMMV). Por exemplo, a TruPar.com vende peças de empilhadeira exclusivamente, com SKUs 8M.

Felizmente, algumas técnicas de renderização estáticas e dinâmicas ajudam a lidar com problemas de escala do Jamstack.

Técnicas “estáticas”

  • Otimização dos tempos de construção
  • Renderização do lado do cliente
  • (Re)geração estática incremental

Técnicas “dinâmicas”

  • Renderização sem servidor no lado do servidor e CDN
  • Renderização estática paralela

Técnicas de renderização “mistas”

  • Escolhendo a melhor técnica de renderização para cada classe de páginas
  • Escolhendo uma estrutura e uma plataforma que permita misturar técnicas conforme necessário

Nos parágrafos seguintes, discutiremos o que essas técnicas significam.

Técnicas estáticas
Otimização dos tempos de construção

Existem vários métodos para otimizar os tempos de compilação para páginas JavaScript dinâmicas.

Compilações incrementais

Com compilações incrementais, você pode salvar artefatos de compilação e apenas regenerar o que mudou. Se apenas uma única página for alterada, você irá regenerar essa única página.

Compilações paralelas

A estrutura divide a compilação em vários processos ou threads. Isto é útil para o processamento de imagens.

Geradores estáticos alternativos do local

SSGs nativamente alimentados são um método emergente e foram encontrados para relatar melhores tempos de compilação. Exemplos incluem Hugo (Go) e Nift (C). No entanto, muitos geradores de sites estáticos escritos nativamente não funcionam bem com sites pesados em JavaScript. Relativamente novo torradas está tentando lidar com isso.

A ressalva é que o suporte ao framework e ao provedor de nuvem para compilações paralelas e incrementais variam. Nem todos eles apoiam isso, e aqueles que oferecem apenas suporte limitado.

Custo adicional potencial para páginas com visitas pouco frequentes

Há também a questão do potencial excesso de custo. Se você tem um site grande com dezenas de milhares de SKUs ou mais, a maior parte do seu tráfego segue uma distribuição de energia e você gasta mais tempo de computação reconstruindo páginas que nunca serão visitadas. Quanto mais você atualizar o site, maior será o custo. Tenha isso em mente ao pensar em algumas dessas técnicas.

De acordo com willit.build (uma página de benchmark de compilação do Gatsby, que fornece tempos de compilação históricos de sites construídos na nuvem do Gatsby), os tempos de compilação para sites Contentful e WordPress são de cerca de 200 ms por página, o que significa que para um site com 10 mil páginas, uma compilação completa do site pode levar 25 minutos. As compilações incrementais podem levá-lo a poucos minutos, mostrando o poder das compilações incrementais. Esta técnica pode ser útil se você não fizer compilações completas.

Renderização do lado do cliente

Também conhecida como shell de aplicativo ou modelo de fallback SPA, a renderização do lado do cliente é o roteamento CDN. Se o seu site hospeda um milhão de produtos, todos eles são roteados por essa camada CDN para o index.html e se tornam um arquivo estático contendo um shell de aplicativo e são renderizados no lado do cliente. Quando o navegador carrega essa página, o roteador cliente-site irá buscar e renderizar o conteúdo da página no navegador.

Com a renderização do lado do cliente, você pode hospedar efetivamente um número infinito de páginas, mas há algumas considerações importantes:

CSR pode impactar negativamente o SEO

A ressalva com renderização do lado do cliente é que pode prejudicar o desempenho, porque a página não pode ser renderizada até que o JavaScript seja carregado. A partir de maio de 2021, o Google classificará sites com base em métricas de três velocidades, CLS, LCP e FID, coletivamente chamados Core Web Vitals. A renderização do lado do cliente pode impactar negativamente todos esses itens, especialmente as mudanças de layout cumulativas. Não é impossível, e é difícil obter bons CLS com o modelo shell do aplicativo. Para fazer isso, você deve criar versões personalizadas do shell do aplicativo para cada tipo de página.

As páginas renderizadas do lado do cliente não podem ser lidas por (alguns) bots

Alguns bots não podem ler conteúdo renderizado no lado do cliente. O Google afirma que seus bots podem renderizar JavaScript e interpretá-lo, mas sabemos que a maioria dos outros bots não podem, incluindo os da maioria das plataformas sociais, que é uma fonte de tráfego significativa para muitos sites.

CSR requer suporte para reescrever e redirecionar regras

A terceira ressalva na implementação do CSR é que ele requer o suporte do seu provedor de CDN para reescrever e redirecionar regras, e alguns fazem isso de forma mais elegante do que outros. Por exemplo, você tem que fazer isso no AWS CloudFront por meio de seu suporte de 404 páginas ou usar manipuladores do Lambda Edge.

Felizmente, as principais plataformas Jamstack Netlify, Vercel e Layer0 oferecem uma maneira bastante fácil de habilitar CSR.

No Netlify, você tem um arquivo de redirecionamentos. Com os modificadores 200, é uma reescrita, mas é um redirecionamento oculto que o usuário nunca vê.

Netlify

O Vercel oferece suporte a regravações em vercel.json, ele também se integra muito bem com o Next.js.

Vercel

O shell de comando CDN-as-JavaScript no Layer0 oferece regravações do Next.js e suporta outros frameworks.

Layer0 (Edgio)

Geração estática incremental

Esta técnica foi pioneira pelo Next.js e envolveu a geração de novas páginas estáticas sob demanda em resposta ao tráfego de entrada. O navegador solicita uma nova página que ainda não foi visitada e, para cada página, independentemente do que é a página, a CDN retornará rapidamente uma página de retorno universal que contém apenas dados de espaço reservado e nenhum conteúdo.

Enquanto a página de retorno é exibida, o processo de compilação estática da página é executado em segundo plano. Quando essa compilação for concluída, a página de fallback carrega os dados JSON estáticos e exibe a página final. A partir de então, futuras visitas terão o HTML criado estaticamente.

Regeneração estática incremental

Há uma versão da geração estática incremental chamada regeneração estática incremental, que é essencialmente o mesmo processo. Ainda assim, envolve a atualização de uma página estática existente em resposta ao tráfego. Então, se os dados subjacentes mudarem, ele está reexecutando o processo de compilação, inspirado pelo stale-while-revalidate, um protocolo de cache popular, mas não amplamente apreciado. Isso servirá uma versão obsoleta da página em vez do fallback enquanto ela está reconstruindo a página e, em seguida, trocá-la pela nova versão assim que o processo de compilação terminar.

Regeneração estática incremental:

  • Atualiza páginas estáticas existentes em resposta ao tráfego,
  • Serve como uma versão obsoleta da página em vez de um fallback.

A regeneração estática incremental tem um pequeno impactos no SEO e na compatibilidade, especialmente na primeira página. A página de fallback é totalmente CSR e não tem dados, por isso não está claro como os bots responderão a ela.

Técnicas dinâmicas

Além de técnicas estáticas, os sites de comércio eletrônico também podem se beneficiar de técnicas dinâmicas como:

  • Renderização sem servidor no lado do servidor e CDN
  • Renderização estática paralela

Renderização sem servidor no lado do servidor e CDN

Usar o SSR em conjunto com o CDN permite gerar páginas sob demanda em resposta ao tráfego, o que lhe dá algumas vantagens. Essa técnica também é mais compatível com a forma como as plataformas de comércio eletrônico tradicionais são feitas. Ele permite que você suporte muitas páginas, você pode gerá-las dinamicamente quando necessário, e garante alta compatibilidade com plataformas legadas.

No entanto, essa técnica também é um pouco controversa. A comunidade Jamstack tende a ser muito dogmática sobre o que é Jamstack e afirma que Jamstack requer geração estática.

A renderização sem servidor é efetivamente Jamstack-ish quando 2 condições são atendidas:

  1. Zero DevOps e servidores para gerenciar. É sem servidor e os desenvolvedores não precisam gerenciar a escala. É o mesmo sem servidor que muitas plataformas do Jamstack usam para alimentar suas APIs, o que diz que você pode usá-las para alimentar dados HTML e por meio de SSR.
  2. HTML é servido a partir do CDN. Esta é uma condição crítica. Após a primeira falta de cache, o site do CDN é tão rápido quanto um site do Jamstack gerado por estática. Por favor, note que isso requer gerenciamento de cache adequado e é mais difícil para sites de várias páginas.

Renderização estática paralela / pré-carregamento SSR

Layer0 permite especificar o conjunto de URLs que devem ser pré-renderizadas e armazenadas em cache na borda durante a implantação para garantir que os usuários tenham uma experiência de sub-segunda ao acessar seu site.

A pré-renderização estática envolve o envio de solicitações para o código do aplicativo e o cache do resultado logo após a implantação do site. Dessa forma, você simplesmente cria seu aplicativo para implementar a renderização do lado do servidor e obter os benefícios de velocidade de um site estático para algumas ou todas as suas páginas. Esse recurso é especialmente útil para sites grandes e complexos com muitas URLs para pré-renderizar sem incorrer em tempos de compilação excepcionalmente longos.

O pré-carregamento SSR é outra técnica usada pelo Layer0 para acelerar as velocidades da página. É muito semelhante ao pipeline SSR regular, mas baseado na análise dos logs de tráfego após a implantação. As páginas de alto tráfego são pré-carregadas em paralelo à implantação. Deixamos que o deploy aconteça instantaneamente e de forma assíncrona, construa as páginas de alto tráfego. Desta forma, você desacoplar o deploy da compilação. Assim, você obtém implanta imediata, enquanto também maximiza os acessos de cache.

Essencialmente, se houver uma solicitação para uma página com altos níveis de tráfego, provavelmente haverá um hit de cache. É a melhor maneira de obter os melhores acessos de cache possíveis neste ambiente.

A renderização estática paralela permite que você:

  • Analise logs para páginas de alto tráfego
  • Busque e armazene HTML para páginas de alto tráfego de forma assíncrona após a implantação
  • Implante imediatamente enquanto maximiza os acessos de cache

Pré-renderização estática

Técnicas de renderização mista

Você não precisa escolher entre técnicas de renderização estáticas e dinâmicas. Você pode escolher o que é certo para cada classe de páginas em seu site. Você pode querer declarar a “Sobre nós”, “Política de devolução” ou blog estático, e outras páginas como carrinho, produto e categorias como dinâmico. Recomendamos escolher um provedor de plataforma que permita misturar de forma flexível as técnicas conforme necessário, especialmente se você estiver fazendo isso em escala.

Escolha a melhor técnica de renderização para cada classe de páginas, porexemplo, declare algumas páginas estáticas (por exemplo, blog, sobre nós, etc.), e outras páginas dinâmicas (por exemplo, carrinho, produtos, categorias, etc.)‍

Escolha um provedor de estrutura e plataforma que permita misturar técnicas de forma flexível conforme necessário

Jamstack em escala com Layer0

As imagens de cache CDN de hoje, JavaScript e CSS, mas não arquivos JSON ou HTML, e é isso que está mantendo os tempos de carregamento da página. Layer0 CDN-as-JavaScript faz com que seja possível manter o cache desses dados na borda mesmo em um ambiente SSR dinâmico e sem servidor.

O Jamstack tira o servidor da equação e efetivamente permite que o CDN gerencie o tráfego, o que ele pode fazer com facilidade, independentemente das flutuações de tráfego. Layer0 faz o mesmo, mas de forma diferente – em vez de renderizar na compilação, nós renderizamos sob solicitação, mas cache cada compilação na borda, então uma compilação não é mais necessária após a compilação 1.

Renderizar cada página na construção é bom para sites menores, mas o tempo de construção se torna quase insuportável quando você é maior. A falta de personalização/personalização ou as soluções alternativas para entregar isso fazem com que o foco da Jamstack no tempo de construção seja menos relevante para sites em grande escala, como eCommerce e Travel.

CDN como JavaScript

Layer0 CDN-as-JavaScript oferece um poderoso controle de borda sobre chaves de cache, cabeçalhos, cookies e muito mais, e também funciona com seu código. Ele entende o seu código e o roteamento da sua estrutura e pode ser emulado localmente ou em ambientes de pré-produção.

As regras de borda vivem em seu código, assim como no Jamstack clássico, dando a você controle total sobre a borda com logs ao vivo, versionamento e rollbacks de 1 cliques.

Veja o Layer0/Edgio Cookbook para alguns exemplos detalhados de padrões de roteamento no CDN-as-JavaScript.

Monitor de desempenho

Para maximizar as taxas de acerto do cache, é importante saber quais são essas taxas em primeiro lugar, mas essas informações geralmente são enterradas profundamente nos logs de acesso do seu CDN.

O Layer0 possui monitoramento de desempenho integrado, facilitando a compreensão quando o cache de páginas bate e falha acontecem e expondo essas informações ao desenvolvedor de uma maneira muito amigável. O Monitor de Desempenho no Layer0 permite:

  • Entenda o tráfego com base em rotas, não em URLs, porque é assim que os desenvolvedores pensam sobre seu aplicativo. Ele também rastreia cada implantação, para que os desenvolvedores possam identificar qualquer regressão.
  • Meça problemas de desempenho em todos os cenários de pilha e carregamento (API, SSR, Edge, etc.)

Layer0 também criou uma ferramenta para diagnosticar se a resposta vem da borda da origem: DevTools. DevTools ajuda você a determinar se a resposta vem da borda da origem. O exemplo abaixo apresenta como ele funciona em cima de um shell de aplicativo construído com React Storefront, mostrando quando uma solicitação é exibida. A resposta neste exemplo está vindo através da rede de borda Layer0 (agora Edgio).

Layer0 DevTools permite que você diagnostique se as respostas vêm da borda ou da origem

Entender se uma resposta vem da borda ou origem é fundamental para pré-busca em escalas, o que é outra coisa que Layer0 faz por você.

Pré-obtenção em escala

A pré-busca é importante para o desempenho porque desbloqueia velocidades de página instantâneas. Testes de velocidade de página tradicionais, como o que você testa com o Lighthouse, estão focados no que acontece após o cliente clicar. Mas você pode começar a fazer muito antes que o cliente toque e obter latência zero e largura de banda quase infinita.

Layer0 DevTools permite que você diagnostique se as respostas vêm da borda ou da origem

Os sites na Layer0 são incrivelmente rápidos porque usam pré-busca preditiva avançada juntamente com Layer0 CDN-as-JavaScript, o que permite que eles fiquem 5 segundos à frente dos toques dos compradores. Isso é feito através do streaming de dados dinâmicos armazenados em cache da borda para os navegadores dos usuários antes de clicar em qualquer coisa, com base no que eles devem clicar em seguida. Em outras palavras, sua loja pode fornecer dados JSON para os diferentes produtos que você está oferecendo, seus preços e informações em uma fração do tempo.

Migração incremental

Layer0 oferece migração iterativa (gradual, progressiva), que permite migrar iterativamente uma seção do aplicativo de cada vez, seguindo o padrão de estrangulamento de Martin Fowler. Desta forma, você incrementalmente “estrangulará” funcionalidades específicas e as substituirá por novos aplicativos e serviços. É como mover uma montanha pedra por pedra.

A migração incremental requer controle roteado na borda ou origem do CDN. Aqui está um exemplo de como você faz isso no Layer0 usando CDN-as-JavaScript.

Personalização e segmentação

A migração incremental, gradual e progressiva é importante para grandes locais. Mas não se limita à personalização! Também abrange a língua, geografia, etc. E faz sentido porque sites grandes geralmente funcionam em toda a geografia, e eles devem ser capazes de personalizar o conteúdo para os usuários enquanto visitam o site.

A diretriz geral é: Se este conteúdo estiver abaixo da dobra, recomendamos o carregamento tardio e a renderização do lado do cliente. Se estiver acima da dobra de conteúdo personalizado, você deseja que ele esteja em uma saída renderizada pelo servidor.

Acima da dobra personalizada: Adicione personalização à chave de cache

No Layer0, você pode declarar uma chave de cache personalizada e personalizá-la, por exemplo, com base na moeda ou no comportamento. Você pode personalizar as promoções e a ordem de classificação nas páginas de categoria, com base em se alguém é um visitante frequente ou um novo visitante, com apenas algumas linhas em CDN-como-JavaScript.

Teste A/B e o Layer0

Os testes A/B e a personalização adicionam uma nova camada de complexidade à construção de locais do Jamstack. Os testes são muito importantes para grandes sites e grandes organizações, onde as decisões são orientadas para o ROI e devem ser comprovadas para melhorar as taxas de conversão.

No Jamstack tradicional, no entanto, a única opção que você tem é o teste A/B do lado do cliente que é executado no navegador. O problema é que isso pode afetar o desempenho e anular seus testes de duas maneiras. Pode prejudicar o desempenho das suas variantes, apagando qualquer tipo de melhoria. E às vezes, os Testes A/B entram em vigor após o olho ter passado os elementos testados. Você pode ter o teste A/B no cabeçalho, e o usuário já digitalizou o cabeçalho depois que o JavaScript é executado e altera esse elemento.

Os problemas com o teste A/B do lado do cliente

  • Normalmente, a única opção para sites estáticos
  • Ele não é executado até que o JavaScript seja executado
  • Mau desempenho que possivelmente anula o teste

Os experimentos Layer0 Edge remediam esses problemas, habilitando Testes A/B na borda. No XDN, novas experiências são sempre nativas, armazenadas em cache e sub-segundas. Isso se estende além dos Testes A/B a qualquer variante do seu site.

Experiências de borda

Layer0 também vem com um poderoso motor Edge Experiments incorporado. O módulo faz parte do CDN-as-JavaScript e está ciente de todas as suas variantes, garantindo que cada um seja armazenado separadamente na borda. Isso lhe dá controle sobre exatamente quais visitantes veem qual variante.

As experiências de borda permitem que você:

  • Encaminhe o tráfego em tempo real para qualquer ramificação implantada na borda da rede
  • Execute Testes A/B, implanta canary ou sinalizadores de recursos
  • Escreva regras de roteamento com base em probabilidades ou valores de cabeçalho e até mesmo
  • Endereços IP

Com o Edge Experiments, você pode facilmente dividir testes sem afetar o desempenho do seu site. As divisões são executadas na borda através de uma interface fácil de usar, mas poderosa. Os experimentos Edge podem ser usados para Testes A/B e multivariados, implanta canary, testes azul-verde, migração iterativa fora de um site legado, personalização e muito mais.

Como nossos clientes se beneficiam com Layer0

Layer0 oferece uma transição sem atrito para Jamstack e sem cabeça e oferece uma enorme vantagem para sites com grandes catálogos, atualizações frequentes ou aqueles que executam plataformas de comércio eletrônico legadas. Shoe Carnival e Turnkey Vacation Rentals são dois exemplos de equipes de desenvolvedores em grandes sites que usam Jamstack e sem cabeça para eCommerce em Layer0.

Chave na mão

Turn Vacation Rentals é uma empresa de gestão de propriedades de aluguel de férias de serviço completo para casas de aluguel premium e de luxo em destinos de viagem de topo em todo o país. Ao contrário de sites como Airbnb, turnkey oferece apenas anúncios pré-avaliados. Ele também lida com detalhes de gerenciamento de forma centralizada, usando um conjunto padronizado de ferramentas tecnológicas.

Configuração original

O turnkey estava executando um aplicativo dentro do Docker no AWS Elastic Beanstalk e estava procurando uma solução para fornecer maior controle e insights sobre o desempenho.

Eles consideraram algumas soluções Jamstack, mas queriam uma plataforma que suportasse o Next.js nativamente, como o Layer0. Um dos fatores decisivos foi que, com Layer0, eles poderiam evitar refatorar como sua base de código e pipeline de dados funcionavam.

Layer0 ajudou o Turnkey a aumentar a agilidade com alguns recursos listados abaixo.

Ambientes

No passado, a Turnkey usou um pipeline personalizado construído dentro do Jenkins, e a equipe estava implantando a partir de uma ramificação do tronco, nunca tendo total confiança no que estava se preparando para entrar em produção.

Com Layer0, as filiais têm ambientes individuais, e a equipe da Turnkey pode configurar ambientes impecáveis, eles não se fundem no ambiente de preparação até que saibam que algo passou pelo QA. Isso remove a carga mental associada ao QA.

Registos

Pesquisar os logs do servidor no Beanstalk pode ser um pesadelo: Você tem que descobrir exatamente quais logs você está procurando, qual servidor eles estão, se eles são balanceados de carga, etc. Com Layer0, você pode transmitir logs ao vivo diretamente da sua compilação, o que permite que você encontre a compilação que deseja solucionar problemas, pressione play e assista ao log.

Migração incremental

Turnkey tinha páginas, não no React/Next.js, e executado na arquitetura antiga. Com Layer0, eles poderiam pegar o que já haviam migrado, colocar isso no XDN e continuar migrando incrementalmente.

Layer0 deu à equipe da Turnkey ferramentas para se concentrar no desempenho.

Sapato Carnaval

Shoe Carnival Inc. É um Varejista americano de calçados. A empresa atualmente opera uma loja online ao lado de 419 lojas físicas em todo o centro-oeste, sul e sudeste dos EUA.

Abaixo estão alguns dos recursos do Layer0 que a equipe do Shoe Carnival achou especialmente útil.

Flexibilidade

O Shoe Carnival usa o Salesforce Commerce Cloud, que não é destinado a correr frontends sem cabeça como o do Shoe Carnival. Então, havia muita engenharia e compreensão no lado do backend para executar os dados para o frontend. Esses desafios podem ser resolvidos por causa da flexibilidade oferecida pelo backend Layer0 entre o Salesforce e o frontend do React. A equipe do Shoe Carnival poderia construir livremente com o React e ignorar as limitações da Salesforce.

Tempo para um impulso de produção

O tempo de produção do Shoe Carnival aumentou drasticamente. A equipe pode ser separada dos ciclos de desenvolvimento do Salesforce e fazer alterações muito rápidas na implantação.

Velocidade do local

A velocidade para a produção é um enorme benefício, mas o desempenho do site geralmente é difícil de ignorar, pois o Carnaval de Sapato passou de 5-6 segundos de carga média de páginas para sub-segundos. Eles podem armazenar em cache coisas em um nível muito granular e ter as ferramentas para garantir que os clientes estão procurando esteja sempre disponível e atualizado.

Implementação incremental

A implantação incremental permite que a equipe implante na produção muito mais rápido do que criar um aplicativo completo para implantá-lo.

Quanto ao impactos da migração para Layer0, quando o Shoe Carnival testou o site de origem contra o site sem cabeça para conversões 50/50 no nível CDN, o headless sempre ganhou, superando o site de origem e melhorando a velocidade e a visibilidade.

Resumo

Na Layer0, acreditamos que Jamstack é o futuro do desenvolvimento web. O Layer0 essencialmente traz os benefícios de desempenho e simplicidade do Jamstack para equipes de desenvolvedores front-end em sites de comércio eletrônico grandes e dinâmicos onde as técnicas estáticas tradicionais normalmente não se aplicam. Nós gostamos de chamá-lo de Jamstack dinâmico. Isso torna os sites DE SPA carregamento instantâneo e mais fáceis de desenvolver.

O Layer0 vem com um CDN-as-JavaScript com reconhecimento de aplicativos, que pode aumentar ou até mesmo substituir seu CDN atual e trazer todos os recursos de segurança da Web que você precisa para a borda. Layer0 também vem com um monte de tecnologias focadas em desenvolvimento que tornam todo o processo de desenvolvimento, implantação, visualização, experimentação, monitoramento, monitoramento e desenvolvimento. e executar seu frontend sem cabeça simples, incluindo URLs de visualização de pilha completa automatizada, um backend JavaScript sem servidor para frontend, monitoramento de cache avançado e muito mais.

Layer0 é uma plataforma de desenvolvimento tudo-em-um que permite:

  • Utilize Jamstack para eCommerce através de renderização pré e just-in-time
  • Ative a rede de latência zero por meio de pré-busca de dados de APIs de catálogo de produtos
  • Configure o EDGE nativamente em seu aplicativo (CDN-as-JavaScript)
  • Execute regras de borda localmente e em pré-prod
  • Crie URLs de visualização a partir do GitHub, GitLab ou BitBucket com cada novo branch e push
  • Execute divisões na borda para testes A/B de desempenho, implanta canary e personalização
  • JavaScript sem servidor que é muito mais fácil e confiável do que o AWS Lambda