儀表板效能：為什麼你的首頁要載三秒（以及怎麼修）

charles

儀表板做得越漂亮，開起來越慢。

這篇講為什麼慢，以及怎麼找出兇手。



先量，不要猜

• 按 F12 打開開發者工具
  
• 切到 Network 分頁
  
• 勾選 Disable cache
  
• 重新整理頁面
  
• 看最下面的統計：請求數、總大小、載入時間
  

健康的數字：

• 請求數：50 以內
  
• 總大小：3 MB 以內
  
• 載入完成：2 秒以內（內網）
  

超過的話往下看。

兇手一：HACS 自訂卡片太多

這是最常見的原因。

每一個自訂卡片都是一個 JavaScript 檔案，
瀏覽器要全部下載、解析、執行才能開始畫畫面。

怎麼檢查：

• 設定 → 儀表板 → 三個點 → 資源
  
• 看有幾個
  

我看過有人裝了 30 幾個，光是載入資源就要五秒。

怎麼處理：

• 把沒在用的刪掉 —— HACS 移除 + 資源清單刪掉
  
• 不確定有沒有在用 → 先停用，看哪一頁壞掉
  
• 功能重複的只留一個（例如同時裝了 Mushroom 和 Bubble Card
    但只用其中一個的功能）
  

實際數字：我從 18 個資源砍到 6 個，首頁載入從 3.2 秒變成 1.1 秒。



兇手二：一頁太多實體

每個顯示在畫面上的實體，前端都要訂閱它的狀態更新。

• 一頁 50 個實體 → 還好
  
• 一頁 200 個實體 → 開始卡
  
• 一頁 500 個實體 → 滑動會頓
  

最常見的爆量來源：

• auto-entities 沒設過濾（把所有 sensor 都列出來）
  
• 一張卡片列出整個區域的所有裝置
  
• 歷史圖表放了十條線
  

對策：

• 用可見性條件讓不需要的區塊不要載入
  
• 把「全部裝置」放到第二頁，不要放首頁
  
• auto-entities 一定要設 exclude
  

兇手三：圖表太多

history-graph 和 statistics-graph 要跟後端要歷史資料。

• 一張圖表 = 一次資料庫查詢
  
• 時間範圍越長、查詢越慢
  
• 資料庫越大、查詢越慢
  

對策：

• 首頁不要放圖表，放到專門的一頁
  
• 時間範圍設短一點（hours_to_show: 12 而不是 168）
  
• 用 statistics-graph 而不是 history-graph
    （前者查的是聚合後的長期統計表，快很多）
  

1. type: statistics-graph
2. entities:
3.   - sensor.total_energy
4. days_to_show: 30
5. stat_types:
6.   - sum
7. period: day

複製代碼

兇手四：攝影機串流

首頁放即時攝影機畫面是效能殺手。

• 每個串流都要持續傳輸
  
• 多個串流同時開，頻寬和 CPU 都會吃緊
  

對策：

1. type: picture-entity
2. entity: camera.front_door
3. camera_view: auto      # 預設，只顯示靜態快照
4. # camera_view: live    # 即時串流，只在需要時用

複製代碼

camera_view: auto 只會顯示定期更新的快照，
點下去才播即時畫面。

或者用 conditional，只在需要時顯示：

1. type: conditional
2. conditions:
3.   - condition: state
4.     entity: binary_sensor.doorbell
5.     state: "on"
6. card:
7.   type: picture-entity
8.   entity: camera.front_door
9.   camera_view: live

複製代碼

兇手五：card-mod 的範本太多

每個範本都要在狀態改變時重新計算。

• 一張卡片一個範本 → 沒問題
  
• 三十張卡片各三個範本 → 開始有感覺
  

對策：

• 能用靜態 CSS 就不要用範本
  
• 複雜的判斷搬到 HA 端（做成 template sensor），
    前端只讀結果
  

舉例：

1. # 不好：前端算
2. card_mod:
3.   style: |
4.     ha-card {
5.       background: {% if states('sensor.temp')|float(0) > 29 %}red
6.                   {% elif states('sensor.temp')|float(0) > 27 %}orange
7.                   {% else %}white{% endif %};
8.     }
10. # 好：HA 端算好，前端只讀
11. # template sensor: sensor.temp_level → "hot" / "warm" / "normal"
12. card_mod:
13.   style: |
14.     ha-card {
15.       background: var(--temp-{{ states('sensor.temp_level') }});
16.     }

複製代碼

前者每次溫度變化都要跑三個比較，後者只讀一個字串。

兇手六：底圖太大

平面圖的 PNG 如果有 3MB，每次開頁面都要下載。

對策：

• 圖片壓到 500KB 以內（用 TinyPNG 之類的工具）
  
• 尺寸不要超過 2000px
  
• SVG 版本通常小很多（20-80KB）
  

兇手七：瀏覽器本身

• 舊平板的瀏覽器很慢，這個改不了
  
• 開太多分頁
  
• 瀏覽器擴充套件干擾
  

測試方法：用無痕視窗開一次，
如果快很多，那就是擴充套件的問題。



一份優化清單（照順序做）

• 刪掉沒在用的 HACS 資源 —— 效果最大
  
• 首頁的實體數控制在 50 個以內
  
• 首頁不要放圖表和即時攝影機
  
• 圖片壓到 500KB 以內
  
• 複雜的範本搬到 HA 端
  
• 用可見性條件讓不需要的區塊不載入
  
• statistics-graph 取代 history-graph
  

一個常被忽略的：後端也可能是瓶頸

如果所有頁面都慢，那可能不是前端的問題。

檢查：

• 資料庫大小（設定 → 系統 → 儲存空間）—— 超過 1GB 就該瘦身
  
• CPU 使用率 —— 一直滿載的話是後端在忙
  
• 有沒有裝置在狂回報 —— 前面有一篇專門講 recorder 調校
  

實際的改善幅度

我自己家的數字：

• 優化前：首頁 3.2 秒、資源 18 個、實體 340 個
  
• 優化後：首頁 0.9 秒、資源 6 個、實體 62 個
  

最有效的三件事：

• 刪掉 12 個沒在用的 HACS 資源（省 1.4 秒）
  
• 把「所有裝置」搬到第二頁（省 0.6 秒）
  
• 首頁的圖表拿掉（省 0.4 秒）
  

全部都是「拿掉東西」，沒有一個是「優化程式碼」。

---

這也是我對儀表板的總結：

最好的優化是刪東西。

下一篇開始講 ESPHome。