告別繁瑣的 Service Worker：宣告式 Web Push 如何重塑 Web 通知體驗

Web 通知的演進與回歸簡約

在 WWDC25 的技術發表中，Apple 為 Web 開發者帶來了一個極具里程碑意義的更新：宣告式 Web Push（Declarative Web Push）。自 2009 年 iPhone OS 3 首次引入推送通知以來，這項技術已成為現代行動平台不可或缺的基石。然而，過去幾年 Web Push 的標準化進程過度依賴 JavaScript（JS）與 Service Worker 的執行週期，雖然提供了靈活性，卻也顯著增加了開發複雜度與系統開銷。

我們始終在追求「以簡馭繁」。宣告式 Web Push 的核心價值在於：將原生 App 的高效能、高可靠性與隱私優勢重新帶回 Web 環境。透過「更少的程式碼，更高的可靠性」，這項技術正重新定義 Web 通知的架構藍圖。

零程式碼實作的架構優勢（The Architectural Case for Zero-Code）

為什麼「不編寫程式碼」反而能提升系統強度？從軟體架構的角度來看，傳統依賴 Service Worker 的 Web Push 模式存在兩大核心缺陷：

1. 資源效率 Resource Efficiency：正如 WebKit 架構團隊所言，執行任何程式碼的效率都遠低於「什麼都不執行」。即使 JS 引擎再快，喚醒 Service Worker、解析腳本並執行事件處理，對行動裝置的功耗與記憶體仍是負擔
2. 隱私保護與生命週期：在智慧防追蹤（ITP）的機制下，瀏覽器會嚴格限制 JS 的執行生命週期。由於 Service Worker 的喚醒常被視為潛在的追蹤向量，這使得傳統 Web Push 在嚴苛的隱私限制下顯得異常脆弱

宣告式 Web Push 允許系統在無需喚醒任何應用程式碼的情況下，直接由作業系統層級渲染通知。這種設計消除了開發者維護複雜異步邏輯的負擔，實現了真正的效能最佳化。

解構「8030」魔數數字與標準化格式

宣告式 Web Push 的實作關鍵在於一個遵循標準化格式的 JSON Payload，讓瀏覽器能直接解析其意圖。

標準宣告式 JSON 範例

{
  "web_push": 8030,
  "notification": {
    "title": "來自 Browser Pets 的新訊息",
    "body": "您的寵物肚子餓了！",
    "navigate_url": "https://browserpets.com/status",
    "tag": "pet-status",
    "silent": false
  }
}

關鍵技術規範

• 魔數數字 web_push: 8030：這是宣告式訊息的標誌。8030 取自 IETF RFC 8030 標準。瀏覽器偵測到此 key 後，會自動進入宣告式處理路徑，跳過 Service Worker 的啟動流程
• 標準化映射：Payload 中的 notification 物件直接對應 W3C 標準的 NotificationOptions 字典，這使得現有的通知邏輯遷移變得極其簡單（Trivial）
• 導向自動化：透過 navigate_url 欄位，瀏覽器會自動處理點擊通知後的頁面跳轉，完全取代了過去容易出錯且繁瑣的 notificationclick 事件處理程序

訂閱解耦：從 Service Worker 釋放的 JavaScript

過去，要獲取推送訂閱（Subscription），開發者必須強制先註冊並啟動 Service Worker。這在架構上將「訂閱流程」與「背景生命週期」過度耦合。

在宣告式 Web Push 的架構下，PushManager 現在可以直接透過 window 物件存取。這意味著：

• Lifecycle Decoupling 生命週期解耦：開發者只需在使用者觸發行為時，直接調用 window.pushManager.subscribe 即可完成獲取訂閱
• 輕量化初始化：對於純粹只需要顯示通知與導航的 Web App，現在可以完全不撰寫 Service Worker，將所有通知顯示與點擊邏輯交由瀏覽器原生管理

「可變動性 Mutable」的混合力量與優雅降級

在某些進階場景（如端對端加密 E2EE 或精確的未讀計數更新），我們仍需要 JS 的介入。宣告式 Web Push 透過 mutable: true 提供了一種極為穩健的混合模式。

處理流程與優雅降級 Graceful Degradation

1. 驗證與辨識：瀏覽器接收 JSON → 驗證 web_push: 8030 → 發現包含 "mutable": true
2. 分發與備份：瀏覽器嘗試啟動 Service Worker。關鍵細節在於：push 事件現在會包含一份由宣告式 JSON 建議的通知副本（a copy of the proposed notification）
3. 腳本處理：Service Worker 接收副本，進行解密或修改後，呼叫 showNotification 提供替代內容
4. 穩定性機制（Fallback）：若 Service Worker 因為資源受限、隱私限制或解密失敗而無法提供替代通知，瀏覽器將自動降級並顯示原始的宣告式 JSON 內容

這種設計確保了「絕對送達率」，即使在極端的資源壓力下，通知也不會消失，而是以預設的內容呈現在使用者面前。

完美相容的漸進式增強策略

對於現有的大型專案，宣告式 Web Push 並非破壞性的改變，而是優雅的增強。以 Browser Pets 專案為例，過去其 JSON 格式是自定義的（Ad-hoc），例如使用 clickURL 這種非標準欄位，且高度依賴 Service Worker 進行手動解析。

重構與相容邏輯：

• 重構成本：開發者只需將自定義欄位重新映射至 NotificationOptions 標準名稱（如 clickURL 改為 navigate_url），並加上 8030 魔數數字
• 雙重相容性路徑：
• 新版瀏覽器：識別出 8030 後，直接由系統自動高效處理
• 舊版／不支援瀏覽器：由於 JSON 格式依然相容，瀏覽器會退回到（Fallback）傳統模式，調用既有的 Service Worker 事件處理常式

這讓開發者能在不犧牲任何舊有使用者的前提下，立即享受新技術帶來的效能紅利。

Web 開發者的新里程碑

宣告式 Web Push 是 Web 平台向原生體驗看齊的重大躍進。它不僅降低了開發門檻，更從底層架構上優化了 Web App 的效能與隱私表現。以下是各平台的支援時程：

• macOS：Safari 18.5＋
• iOS／iPadOS：18.4＋（需為「加入主畫面」之 Web App）

當 Web 通知變得像原生 App 一樣透明、高效且易於實作時，這將徹底改變我們規劃使用者互動體驗的方式。現在正是檢視你的推送架構，告別繁瑣 Service Worker 並擁抱標準化未來的最佳時刻。