翊珍香電商系統案例｜圖片效能、會員與促銷後台

問題背景

老字號食品品牌要的不只是形象頁，而是能承接商品、會員、促銷與內容營運的完整電商。難點有兩個：一是商品與活動圖片量大，若不先處理圖片管線，最大內容繪製（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、轉換率、訂單或營收資料。

可公開的量測與能力