前言

昨天（Day 23）我們把 Magento 的 HTTP 請求流程與 Page Cache 插手時機 講清楚了，也更確定真正決定快取命中的，是那把鑰匙——identifier。
今天就把我們的改善方案攤開來說：透過「修改請求識別符（identifier）」與「移除不必要參數」來降低重複快取，讓 Redis 更乾淨、命中率更穩定。

目標

優化請求的傳遞過程，讓相同內容的頁面只會對應到同一把 key。

需求與原則

1. 修改請求識別符

   • 更新識別符格式，移除不必要的部分，確保簡潔並符合安全要求。

2. 移除不必要的參數

   • 只保留會影響頁面內容的參數；其他（例如行銷追蹤）直接過濾掉，減少請求負擔。

3. 參數排序（lexicographical order）

   • 對「保留下來的參數」依字母序排序，讓同樣的參數組合有固定順序，避免同頁面被重複快取。

預留參數（為什麼要留）

我們只針對 URL 中「?」後面的參數 做處理；保留的原則很單純：

只保留會影響實際輸出的 HTML 的參數——也就是會改變頁面內容、排序、分頁或篩選結果的那些；其餘不影響內容（例如行銷追蹤、分析識別）的參數一律移除。

分類頁

• Product Attributes（所有可篩選屬性）：會改變列表的商品集合 → 影響 HTML
• product_list_order（排序欄位）：會改變呈現順序 → 影響 HTML
• product_list_dir（升／降冪）：會改變呈現順序 → 影響 HTML
• q（搜尋）：會改變列表內容 → 影響 HTML
• p（頁數）：會顯示不同分頁內容 → 影響 HTML
• cat（分類 ID）：會切換分類來源 → 影響 HTML

Blog 分類頁

• s（搜尋）：改變文章列表內容 → 影響 HTML
• np（頁數）：顯示不同頁段 → 影響 HTML

其他

• 後台自訂輸入：提供一個設定欄位，可手動加入額外需要保留的參數（應付特殊頁面或第三方模組）。

除了以上清單之外，其餘參數一律丟掉，以確保快取一致性。

實際範例

原始請求

https://www.mrliving.com.tw/catalogsearch/result/index/?MRL_filters_coftable=341&abc=222&MRL_filters_preorder=134&product_list_dir=asc&q=sofa&product_list_order=name&gad_source=1&gclid=xxx

處理動作

• 移除不必要的：abc=222、gad_source=1、gclid=xxx
• 保留真正會影響 HTML 的參數（篩選、排序、搜尋…）
• 對保留參數做字母序排序

處理後

https://www.mrliving.com.tw/catalogsearch/result/index/?MRL_filters_coftable=341&MRL_filters_preorder=134&product_list_dir=asc&product_list_order=name&q=sofa

重點：不管同一組參數原本順序怎麼換，最後都會被「正規化」成同一個樣子，因此會命中同一個快取 key。

我們要交付什麼

• 識別符正規化流程（如上三步：移除、保留、排序）
• 預留參數白名單（上方清單 + 後台自訂欄位）
• 實例驗證（前／後 URL 對照，確認 HTML 輸出一致）

預期效果

• 減少重複快取：相同內容不再用不同 key 存多份。
• 提升命中率：同一頁面後續請求更容易命中。
• 降低 Redis 壓力：空間與 I/O 都會下降。
• 維持內容正確：因為只保留「會影響 HTML」的參數，呈現不會走鐘。

結語

Day 24 我們把策略講完：用「保留必要參數 + 移除噪音 + 字母序排序」來讓快取更乾淨。
明天（Day 25）我們就把這套邏輯實際落到程式裡，並用幾組前／後對照來驗證：

• 正規化前後的 URL
• 兩邊輸出的 HTML 是否一致
• Redis 佔用與命中率的變化（觀察趨勢）