soulmatt.com.tw效能優化成果2026-08

站台優化成果

首頁載入時間縮短 76%,客人手機要下載的資料量減少 92%,並建立了自動異地備份。所有數字都是實際量測,不是估算。

首頁載入

2.7

原本 11.55 秒 快 4.3 倍

手機下載量

92%↓

每位客人少下載 59 MB

快取命中率

98.5%

圖片與影片由 台北節點 供應

加壓測試

0次失敗

連續 108 次 請求全數成功

01

客人實際等待的時間

以台灣的一般家用網路連線量測,模擬瀏覽器同時抓取整頁內容。第三條「快取命中」是客人逛下一頁或稍後回訪時的數字:圖片與程式檔瀏覽器已經有了,只需要取網頁本體。

首頁完整載入含全部圖片與影片
快 4.3 倍
優化前
11.55 秒
優化後
2.70 秒
快取命中
0.12 秒
畫面開始出現從點下連結到看到東西。兩個數字都是快取命中時量的
快 5.6 倍
優化前
0.62 秒
優化後
0.11 秒
手機要下載的資料量用 4G 的客人感受最直接
省 92%
優化前
64.10 MB
優化後
5.06 MB
快取命中
0.04 MB
6 人同時進購物車結帳流程的反應速度。這幾頁刻意不快取,沒有命中的情況
快 2.2 倍
優化前
5.40 秒
優化後
2.46 秒

下載量為什麼能少 92%。 首頁原本有兩張動畫 GIF,合計 61 MB,客人光是開首頁就要把它們下載完。改成同畫面的 MP4 影片後降到 2.1 MB,看起來完全一樣。

02

這次優化到底改善了什麼

快取是把算過一次的結果存起來重複使用。同一個商品頁,在「有拿到快取」和「要重新計算」兩種情況下,優化前後各量一次,四個數字擺在一起就看得出效益在哪。

商品頁回應時間,數值越小越好。取自台灣端實際發出的請求。
有拿到快取一般瀏覽、逛商品 要重新計算結帳、廣告連結 兩者差距
優化前2026-08-19 0.661 秒 1.905 秒 2.9 倍快取有在作用
優化後2026-08-20 0.125 秒快 5.3 倍 1.508 秒快 1.3 倍 12.1 倍快取價值放大

怎麼看這張表。 左邊那一欄是絕大多數客人走的路,這次從 0.661 秒縮短到 0.125 秒,快了 5.3 倍,這是本次優化的主要成果。

右邊那一欄只快了 1.3 倍,因為這條路每次都必須把整套程式重跑一遍,快取幫不上忙。這也解釋了為什麼結帳頁比瀏覽頁慢:結帳的內容因人而異,本來就不能存起來重複使用。

所以效益的關鍵是:讓越多客人走左邊那條路越好。 優化前兩條路差 2.9 倍,優化後差到 12.1 倍,等於命中快取的價值變得比以前更高。

一個投放廣告前建議先處理的項目。 從 Facebook 廣告點進來的連結,網址後面會帶一段追蹤碼,而且每一次點擊的追蹤碼都不一樣。系統會把它當成一個全新的網址,因此每位廣告客人都走右邊那條慢路。

實測:一般網址 0.12 秒;帶廣告追蹤碼的網址 1.31 - 1.42 秒,慢了約 10 倍。

修正方式是讓系統在比對快取時忽略追蹤碼,廣告數據完全不受影響。不需額外費用,建議在募資投放前完成。

03

快取涵蓋了多少

上一節說的是命中快取有多划算,這一節是實際有多少比例命中了。

98.5%

圖片、影片、程式檔

67 項中命中 66 項
以資料量計 100%

100%

網頁本體

首頁、商品列表、6 個商品頁
第二位訪客起全數命中

3 / 3

結帳流程正確排除

購物車、結帳、會員頁一律不快取
避免看到別人的資料

04

同時多少人在線不會塞車

募資檔期的流量是尖峰型的,所以針對「同時有多少人在操作」做了階梯式加壓測試。

取中位數。全程共 108 次請求,成功率 100%。
情境同時人數成功率一般客人等待最慢的人等待
瀏覽商品5 人100%0.26 秒0.33 秒
10 人100%0.30 秒0.51 秒
20 人100%0.61 秒1.01 秒
40 人100%0.88 秒1.38 秒
購物車操作3 人100%1.18 秒1.33 秒
6 人100%2.46 秒2.48 秒
10 人100%2.74 秒4.16 秒
14 人100%4.33 秒5.29 秒

換算成營運語言。 站台可以從容承接數百人同時在站上瀏覽,40 人同時看商品仍然在 1 秒內。真正的瓶頸在結帳環節,建議把同時按下結帳的人數控制在 10 人以內,超過會開始出現 3 秒以上的等待。如果預期開賣瞬間會有更集中的湧入,可以再擴充規格。

05

這次做了哪些檢查與優化

先把整台主機從頭檢查一遍,找出真正的問題所在,再動手。所有判斷都以實測數據為準,不憑經驗猜測。

檢查階段全程只讀取資料、不修改任何設定。
檢查項目做了什麼查出什麼
全機健檢規格、負載、磁碟、資料庫結構一次盤點找出 489 MB 垃圾日誌、116 張無用資料表,以及一個尖峰必當機的設定
主機方案實測比較開三台不同方案的機器實際跑分,測完立即銷毀高階方案沒有比較快,因此不採用。若採用,主機年費約為現在的 3 倍
網站程式負擔量測比較「載入全部外掛」與「不載入外掛」的時間差網站程式本身只要 0.35 秒,47 個外掛佔掉 1.66 秒
快取逐項掃描首頁 73 項資源與 11 個頁面逐一檢查快取狀態圖片影片命中 98.5%、網頁本體 100%、結帳流程正確排除
階梯式加壓測試模擬 5 至 40 人同時操作,共 108 次請求全數成功,零失敗;找出結帳環節的人數上限
站台驗收24 項檢查,含結帳流程與三個廣告 feed全數通過
備份還原演練把備份實際還原一次,不是只有備份就算數確認可以還原
郵件設定檢查檢查訂單信相關的網域設定收信網域與寄件驗證正常;目前尚未設定 DMARC,建議補上以提高訂單信送達率
每項變更前都先確認備份是最新的,並保留可以還原的方式。
優化項目做了什麼效益
首頁動畫兩張合計 61 MB 的 GIF 改成同畫面的 MP4 影片首頁下載量 64.10 MB → 5.06 MB,畫面看起來一樣
全球加速啟用加速服務,圖片影片由台北節點供應不必每次都連回主機拿,命中率 98.5%
主機規格由 1 核 2 GB 提升為 2 核 4 GB同時處理人數上限提高,記憶體脫離吃緊狀態
同時處理上限原設定超出實體記憶體數倍,尖峰一定會觸發當機改為安全值,從「會當機」變成「會排隊」
背景排程原本由訪客的請求順便執行,改為系統固定執行訪客不再替背景工作等待
垃圾日誌清除 489 MB,並修正產生的源頭產生速率 每小時 4 MB → 0.6 MB
資料庫整理封存 116 張早已移除的外掛留下的資料表資料表 303 → 187 張,封存不是刪除,隨時可還原
快取排除規則逐條驗證購物車、結帳、會員頁確實不被快取避免客人看到別人的購物車或個資
異地備份從零建立,加密後自動上傳雲端主機全毀也能復原,已實測
06

資料保全

優化前站台沒有任何備份。主機一旦故障、被入侵或誤刪,訂單與商品資料將無法復原。這是本次風險等級最高的一項,已建立完整機制。

項目內容
備份頻率資料庫每 6 小時、網站檔案每週
存放位置雲端儲存,與主機完全分離。主機全毀不受影響
加密方式AES-256,上傳前就先加密。就算儲存空間外洩也讀不出內容
還原演練已實測還原成功,不是只有備份而沒驗證過
保護機制還原預設是模擬執行,必須明確指定才會真的覆寫;覆寫正式站前會自動先另存一份現況

募資開賣前建議把頻率再調密。 資料庫備份改成每小時,儲存費用仍在免費額度內,不會增加成本。

07

費用

主機規格由 1 核 2 GB 提升為 2 核 4 GB,並新增異地加密備份與狀態監控,因此年費有調整。

年費

14,000元/年

原本 4,800 元/年 增加 9,200 元

  • 主機 2 核 4 GB(原 1 核 2 GB)
  • 異地加密備份與狀態監控
  • 全球加速服務
  • 維運代操

避免的支出

3倍主機年費

原先評估要升級到更高階的方案,實測後證明不必要

  • 實測結果:高階方案的單核效能與現用方案相同,磁碟反而慢 63%
  • 若採用,光是主機的年費就約為現在的 3 倍
  • 因此改為只提升記憶體與核心數,效果相同、費用低很多
  • 三台測試機用完即刪,測試成本不到 2 元

綜合來看。 一年多付 9,200 元,換到的是首頁快 4.3 倍、回訪客人快到 0.12 秒、傳輸量少 92%、承載能力翻倍,以及從零開始建立的自動備份。同時避開了一筆實測證明沒有效果、主機年費約 3 倍的升級。

08

目前狀態與後續建議

項目狀態
主機位置日本東京
主機規格2 核 / 4 GB
全球加速已啟用,台灣客人由台北節點供應
異地備份運作中,已實測可還原
加壓測試108 次請求 零失敗
站台驗收24 項檢查 全數通過,含結帳流程與三個廣告 feed
依建議處理順序排列。
建議項目原因費用
讓廣告連結也能命中快取目前每位廣告客人都走慢路,1.31 秒 對 0.12 秒。修正後廣告數據不受影響不需費用
補上 DMARC 設定提高訂單確認信的送達率,避免客人收不到信不需費用
備份頻率調為每小時募資期間訂單密集,縮短資料遺失的時間範圍不需費用
圖片轉為新格式再省約 1.8 MB 下載量,31 張圖片皆為舊格式不需費用
尖峰時段複測本報告量測於離峰時段,數字代表能力上限不需費用