Web Push 透過將寄件者身分標準化，擺脫了應用程式商店的封閉生態

早期的 Web Push 可在 Chrome 中運作，但後端路徑仍須經由 Firebase Cloud Messaging，且需要 Google 專屬的專案憑證。這使得這套開放 API 對服務多種瀏覽器的開發者而言，顯得不那麼開放。

Chrome 於 2016 年的互通性說明描述了這項修正：FCM 開始接受標準的 Web Push Protocol，而 VAPID 則以公開／私密金鑰對提供寄件者驗證，取代了 GCM 寄件者 ID 與專屬的 Authorization 標頭。

實際結果是只需一條程式碼路徑。Chrome 自家的指引指出，VAPID 意味著開發者不再需要 Firebase 專案，且可在 Chrome 與 Firefox 中使用相同的訂閱與傳送流程。

Apple 的 WebKit 後來也在 macOS Ventura 上的 Safari 16 加入這條標準路徑。WebKit 表示，Web Push 是由 Push API、Notifications API 與 Service Workers 共同啟用，且符合標準的網站無需加入 Apple Developer Program 即可觸及 Safari 使用者。

讓推播寄件者身分可攜

它讓瀏覽器推播保持去中心化：每個瀏覽器可執行自己的服務，而應用程式則使用單一協定。

它以隨請求傳送的密碼學身分，取代了廠商註冊。

它要求使用者可見的通知，使推播與網路的權限模型保持一致。

當一項網路標準能從常見路徑中移除廠商註冊步驟時，它就能勝出。

在 VAPID 之後，Chrome 與 Firefox 共用同一條以標準為基礎的傳送路徑，而 Safari 則於 2022 年加入 Web Push 支援。網頁應用程式得以在主要引擎上通知使用者，而無需僅為了推播而建置原生應用程式。