翊珍香电商系统案例｜图片性能、会员与促销后台

问题背景

老字号食品品牌要的不只是形象页，而是能承接商品、会员、促销与内容运营的完整电商。难点有两个：一是商品与活动图片量大，若不先处理图片管线，最大内容绘制（LCP）会被原始大图拖垮；二是促销规则复杂——多档活动同时进行、会员分层折扣、优惠券叠加条件——这些规则若写死在程式里，每档新活动都要等工程师改版上线，运营节奏会被开发时程绑死。

实践方式

• —以 Next.js、GraphQL、PostgreSQL 与 Redis 建立电商核心：前台经由 GraphQL 取得商品、会员与促销资料，三者各自建模；Redis 承接热门查询的缓存，降低数据库压力。
• —图片管线先行：上传的原始图在输出时转换为现代格式，并依版位裁切多种尺寸，前台依装置载入对应版本，而不是把原图直接交给浏览器缩放。
• —检查 LCP 资源载入链：确认首屏主图的载入优先序、预载与尺寸宣告，把性能目标订在 LCP 2.5 秒以内，于交付时验证。
• —促销规则后台化：把 19 种活动类型（满额、满件、赠品、限时折扣等）与 5 层会员等级建成可组合的规则模型，运营人员在后台设定条件与档期，前台结帐时由后端依规则计算——上新活动不需要改程式。

隼讯实际负责范围

• 电商前台、商品与内容页面
• 会员、活动与优惠券运营规则
• GraphQL API、数据库与缓存整合
• 图片输出与主要载入路径优化

购物与运营资料流

1. 01消费者由商品或活动页进入购物流程，页面图片依装置载入对应尺寸的优化版本。
2. 02前台透过 GraphQL 取得商品、会员与促销所需资料，热门查询由 Redis 缓存供应。
3. 03结帐时后端依会员等级、进行中活动与优惠券规则计算最终金额；多条规则同时命中时依明确的优先序处理，不在前端计算价格。
4. 04运营人员由后台维护商品、内容与活动档期，规则生效不需要修改程式或重新部署。

限制、失败降级与替代方式

• —图片优化数字只描述技术资产差异，不推导为营收成长。
• —性能表现会随页面、图片、装置、网络与第三方服务变动，不能视为永久固定值。
• —会员与活动功能数量代表系统范围，不等于实际使用率或促销成效。
• —促销金额一律由后端计算，前端显示仅供参考，避免规则变更期间出现价格不一致。

证据如何核对

• ✓可由公开网站核对品牌、商品与主要购物介面。
• ✓88.8% 是同一批商品图优化前后的档案总体积对比，属一次性技术量测，量测对象是图片资产本身，非持续监测数据。
• ✓LCP 目标与功能规模来自既有公开作品纪录。
• ✓未取得可公开的 GA4、GSC、转换率、订单或营收资料。

可公开的量测与能力