專案上線後，今天用工具實際檢視效能，並回頭討論 Day 7 提過、關於 API 金鑰安全性的架構優化方向。

使用 Lighthouse 檢查 PWA 品質

Chrome 開發者工具內建 Lighthouse ，可以針對效能、無障礙、最佳實踐、PWA 規範打分數：

1. 打開正式網址，按 F12 開啟開發者工具。
2. 切到 Lighthouse 分頁，勾選 Performance 與 Progressive Web App。
3. 點擊「Analyze page load」，等待報告產生。

常見會被扣分的項目：

• 圖片檔案太大（建議把 icon 等圖片壓縮，或使用 WebP 格式）。
• 沒有設定快取標頭（Vercel 通常會處理靜態資源快取，但仍值得檢查）。
• Service Worker 涵蓋範圍不完整（回顧 Day 21 的快取清單是否遺漏重要檔案）。

減少不必要的 API 呼叫

回顧 Day 10 的輪詢邏輯，如果使用者把分頁切到背景，其實不需要繼續每 30 秒打一次 API：

// src/main.js
let pollTimer = null;

function startPolling() {
  if (pollTimer) return;
  pollTimer = setInterval(loadArrivals, POLL_INTERVAL_MS);
}

function stopPolling() {
  clearInterval(pollTimer);
  pollTimer = null;
}

document.addEventListener('visibilitychange', () => {
  if (document.hidden) {
    stopPolling();
  } else {
    loadArrivals();
    startPolling();
  }
});

這個小改動能明顯減少不必要的網路請求與電量消耗，對行動裝置使用者特別友善。

回頭處理架構債：金鑰安全性

Day 7 曾提到，純前端架構會讓 API 金鑰暴露在瀏覽器中。如果要更進一步，可以：

1. 用 Vercel 的 Serverless Functions（在專案中新增 api/ 資料夾，寫簡單的 Node.js 函式），由伺服器端保管金鑰、代理呼叫 TDX 與 Google Maps。
2. 前端只跟自己的 /api/arrivals 這類端點溝通，不直接接觸第三方金鑰。

這已經超出「純前端 PWA」的範疇，但值得在文章中誠實記錄下來——教學版本的簡化，不代表正式系統該有的樣子 ，這也是軟體工程中很重要的一課：先求能動，再求穩健，但要清楚知道兩者的差距在哪裡。

明天，我們要暫停技術細節，回顧整個開發歷程。