Caso de e-commerce da 翊珍香: desempenho das imagens e administração de membros e promoções

Contexto do problema

As marcas de alimentos tradicionais não precisam apenas de uma página de apresentação, mas de um sistema de comércio eletrónico completo que possa gerenciar produtos, membros, promoções e conteúdo. Os desafios incluem: (1) o grande volume de imagens de produtos e eventos; se a gestão de imagens não for tratada primeiro, a maior carga de conteúdo (LCP) será afetada pelas imagens originais; e (2) a complexidade das regras promocionais: múltiplas promoções simultâneas, descontos segmentados para membros, combinação de cupons – se essas regras forem codificadas no programa, cada nova promoção exigirá que um engenheiro faça as alterações, o que afetará o ritmo das operações.

Forma de implementação

• —Criar o núcleo do comércio eletrónico com Next.js, GraphQL, PostgreSQL e Redis: o front-end obtém dados de produtos, membros e promoções através do GraphQL, cada um modelado separadamente; o Redis armazena em cache as consultas mais frequentes, reduzindo a carga no banco de dados.
• —Priorizar a gestão de imagens: as imagens originais carregadas são convertidas para formatos modernos e cortadas em vários tamanhos, o front-end carrega as versões correspondentes para cada dispositivo, em vez de simplesmente fornecer as imagens originais para o navegador ampliar.
• —Verificar a cadeia de carregamento dos recursos de LCP: confirmar a prioridade de carregamento, o pré-carregamento e as dimensões declaradas da imagem principal da primeira tela. Definir a meta de desempenho de LCP em até 2.5 segundos e verificá-la na entrega.
• —Regras de promoção gerenciadas pelo painel administrativo: combinar 19 tipos de campanha, como valor mínimo de compra, quantidade mínima de itens, brindes e descontos por tempo limitado, com 5 níveis de membros em um modelo de regras configurável. A equipe define as condições e os períodos no painel, e o backend calcula os valores conforme essas regras durante o checkout. Novas campanhas não exigem alterações no código.

Escopo real de responsabilidade do Falcon

• Interface do usuário do comércio eletrónico, páginas de produtos e conteúdo
• Regras de operação para membros, eventos e cupons
• Integração de API GraphQL, banco de dados e cache
• Otimização da saída de imagens e principais caminhos de carregamento

Fluxo de dados de compra e operação

1. 01Os clientes entram no fluxo de compra a partir das páginas de produtos ou promoções, com versões otimizadas das imagens da página carregadas de acordo com o tamanho do dispositivo.
2. 02O front-end obtém os dados de produtos, membros e promoções necessários através do GraphQL, com consultas frequentes fornecidas pelo cache do Redis.
3. 03No checkout, o back-end calcula o valor final com base no nível do membro, nas promoções em andamento e nas regras de cupons; quando várias regras são aplicadas simultaneamente, elas são processadas de acordo com uma ordem predefinida, sem calcular o preço na frente.
4. 04Os funcionários de operações mantêm os prazos de produtos, conteúdo e promoções no painel de controle, sem a necessidade de modificar o código ou reimplantar.

Limitações, falhas e alternativas

• —O número de otimizações de imagens descreve apenas as diferenças de ativos técnicos, sem derivar o crescimento da receita.
• —O desempenho pode variar dependendo da página, imagens, dispositivo, rede e serviços de terceiros, e não deve ser considerado um valor fixo.
• —O número de membros e funcionalidades representa o escopo do sistema, e não o uso real ou o impacto nas vendas.
• —O valor promocional é calculado no backend, e a exibição no frontend é apenas para referência, a fim de evitar inconsistências de preços durante as alterações das regras.

Como verificar as evidências

• ✓É possível verificar a marca, os produtos e a interface de compra principal em um site público.
• ✓88.8% representa o tamanho total de arquivos antes e depois da otimização das imagens, sendo uma medição técnica única. O objeto da medição são os próprios ativos de imagem, e não dados de monitoramento contínuo.
• ✓Os objetivos de LCP e o tamanho da funcionalidade são provenientes de registros públicos existentes.
• ✓Não foram obtidos dados públicos de GA4, GSC, taxa de conversão, pedidos ou receita.

Medições e capacidades disponíveis