PWA 新增至主畫面實作: 自定義 A2HS 提示介面以引導使用者完成安裝流程 | 前端三分鐘

文章目錄

1. 什麼是 A2HS (新增至主畫面)？
2. PWA 入門：什麼是新增至主畫面 (A2HS)？
1. 2.1. 為什麼需要加入主畫面 (A2HS)?
3. 如何在瀏覽器中體驗 A2HS？
1. 3.1. 目前哪些瀏覽器支援 A2HS?
2. 3.2. 加入主畫面 (A2HS) 不存在哪些增強功能?
4. 怎麼讓 Web App 有 PWA 的增強功能 (A2HS-ready)?
1. 4.1. Firefox Install criteria
2. 4.2. Chrome Install criteria
5. Web App Manifest 教學：讓 App 具備 A2HS 功能的關鍵
6. Promoting installation 推薦安裝提示
7. beforeinstallprompt 實作：自訂安裝提示流程
8. Promoting 推薦介面設計模式
9. FAQ：PWA A2HS 常見問題

什麼是 A2HS (新增至主畫面)？

A2HS (Add to Home Screen) 是一種 Progressive Web App (PWA) 的核心功能，允許使用者將 Web 應用程式「安裝」到行動裝置的主畫面或電腦桌面上。與傳統書籤不同，透過 A2HS 安裝的 PWA 會擁有專屬的圖示（Icon）、啟動畫面（Splash Screen），並能以獨立視窗（Standalone）模式運行，完全隱藏瀏覽器網址列，提供與原生 App (Native App) 極其相似的操作體驗。其實作關鍵在於滿足瀏覽器的「安裝標準」（如 HTTPS、Manifest 與 Service Worker），並透過監聽 beforeinstallprompt 事件來自定義安裝提示流程。

PWA 入門：什麼是新增至主畫面 (A2HS)？

新增至主畫面（Add to Home screen），在 PWA 開發中常縮寫為 A2HS。您可以把它想像成讓使用者為 Web App 進行「安裝」的過程。雖然底層技術只是在桌面或手機主畫面上建立捷徑，但 PWA 的目標是透過「漸進式增強」，讓這個動作提供更貼近原生 App (Native App) 的使用者體驗。

小編覺得 A2HS 的迷人之處在於，它不僅讓網站更容易被找到，還能讓 Web App 整合進系統的應用程式管理介面，甚至支援離線快取功能。

Chrome 的使用說明

為什麼需要加入主畫面 (A2HS)?

A2HS 是 Progressive Web App 設計理念的其中一部份，經過 “安裝” 這個動作讓 web apps 也能像 native app 有類似的使用者體驗。

在加入主畫面後，使用者就可以透過點擊主畫面上的 icon 直接去使用 Web App，PWA 的相關支援目前在各大平台的支援程度都在逐漸提高中，不過漸進式增強功能在各平台都有各自需要注意的地方。

如何在瀏覽器中體驗 A2HS？

當您透過支援的瀏覽器開啟符合標準的 PWA 網站時，網址列通常會多出一個安裝按鈕。小編在這邊提醒大家，不同瀏覽器的圖示與位置可能略有差異。

按下按鈕後，通常會彈出一個確認視窗。這就是 A2HS 實作 帶來的直覺體驗。

MDN 提供了一個簡單輪播圖片的範例，可以直接用手機打開來看，連結如下:

https://mdn.github.io/pwa-examples/a2hs/

雖然網站很簡單，但其中也實作了 service worker 來快取資源讓網站在安裝後能夠離線瀏覽。

self.addEventListener("install", (e) => {
  e.waitUntil(
    caches
      .open("fox-store")
      .then((cache) =>
        cache.addAll([
          "/pwa-examples/a2hs/",
          "/pwa-examples/a2hs/index.html",
          "/pwa-examples/a2hs/index.js",
          "/pwa-examples/a2hs/style.css",
          "/pwa-examples/a2hs/images/fox1.jpg",
          "/pwa-examples/a2hs/images/fox2.jpg",
          "/pwa-examples/a2hs/images/fox3.jpg",
          "/pwa-examples/a2hs/images/fox4.jpg",
        ])
      )
  );
});

目前哪些瀏覽器支援 A2HS?

加入主畫面這個功能幾乎是全面支援，除了:

iOS webview 不支援
Chromium desktop 部分支援
Firefox Mobile v58 後支援

想要了解更多詳細狀況，可以參考 caniuse.com，連結如下:

https://caniuse.com/web-app-manifest

加入主畫面 (A2HS) 不存在哪些增強功能?

加入主畫面的過程只是讓 Web App 更方便存取，並沒有將 App 的資源下載或快取，所以並無法讓 Web App 做到離線使用。

離線使用的功能必須額外搭配 Service Worker API 來處理、儲存資料和資源，像是透過 Web storage 或 IndexedDB 都是不錯的解決方案。

在實作完相關快取機制後，記得要註冊後才可以使用:

if ("serviceWorker" in navigator) {
  navigator.serviceWorker.register("/pwa-examples/a2hs/sw.js").then(() => {
    console.log("Service Worker Registered");
  });
}

怎麼讓 Web App 有 PWA 的增強功能 (A2HS-ready)?

各家的瀏覽器其實都有相關的 “安裝前的審核標準”，只有在滿足相關條件後，才會讓瀏覽器支援 “漸進式增強的安裝”，而非單純的加入捷徑到主畫面，底下列出 Firefox 和 Chrome 的標準，也附上各平台的相關標準參考連結:

Firefox Install criteria

HTTPS
manifest 配置檔必填欄位都有填，且有在 HTML head 引入
有 icon 的圖片，提供在主畫面中顯示用

Chrome Install criteria

HTTPS
web App 沒有被安裝過
Meets a user engagement heuristic (使用者在這個網域有互動超過 30 秒)
有註冊 service worker 且搭配 fetch handler
manifest 配置檔須包含
- short_name 或 name
- icons 包含 192px 跟 512px
- start_url
- display 要填 fullscreen、standalone、minimal-ui
- prefer_related_applications 不需要，或是給 false

Web App Manifest 教學：讓 App 具備 A2HS 功能的關鍵

這其中有一個關鍵就是 manifest 這個配置檔，它是讓瀏覽器辨識您的網站是否為 PWA 的關鍵。

somefilename.webmanifest
manifest.json

在加入這個檔案後記得在 <head> 中引入 <link rel="manifest" href="manifest.webmanifest">

那要支援 A2HS 有幾個必填欄位如下:

background_color: 在加入主畫面後，啟動時 splash screen 的背景主視覺，在還沒安裝前的網址列也會改變顏色
display: 定義 App 開啟後的顯示方式目前有三種，各有細微差異 fullscreen、standalone、minimal-ui
icons: 主畫面或是任務切換時顯示
name/short_name: 安裝後的 App 名稱 short_name 會用在顯示上有限制的地方
start_url: App 開啟預設頁，須注意為相對路徑跟 manifest 位置相關，有填 Chrome 才會跳提示

MDN 提供的完整範例如下:

{
  "background_color": "purple",
  "description": "Shows random fox pictures. Hey, at least it isn't cats.",
  "display": "fullscreen",
  "icons": [
    {
      "src": "icon/fox-icon.png",
      "sizes": "192x192",
      "type": "image/png"
    }
  ],
  "name": "Awesome fox pictures",
  "short_name": "Foxes",
  "start_url": "/pwa-examples/a2hs/index.html"
}

恭喜!!! 看到這裡就可以發現，其實很快就可以很快地做出一個初階版的 PWA 了，所以其實 PWA 對網頁開發者來說，幾乎可以說是只有優點沒有太多缺點。

Promoting installation 推薦安裝提示

當我們的 Progressive Web App 滿足了安裝前的審核標準，瀏覽器就會觸發 beforeinstallprompt 這個事件，當事件被觸發後，才能夠進行後續的安裝過程。

所以在實作安裝流程上會分成下面三個步驟:

監聽 beforeinstallprompt 這個事件
觸發後記得把事件存起來，後續在安裝的流程上會需要
告知使用者，這個 App 可以被安裝，並提供按鈕讓使用者繼續後續的相關流程

beforeinstallprompt 實作：自訂安裝提示流程

您可以透過 beforeinstallprompt 實作 來自定義安裝按鈕，不論按鈕打算放在哪，都要先隱藏。這是因為 PWA 在還沒達到 A2HS 的安裝前的審核標準前，並無法被安裝。

安裝流程主要會有兩種

透過自訂按鈕安裝流程
透過網址列或是瀏覽器協助安裝

前置準備

1	<button class="add-button">Add to home screen</button>

1
2
3

let deferredPrompt;
const addBtn = document.querySelector(".add-button");
addBtn.style.display = "none";

自訂安裝按鈕

宣告 deferredPrompt 變數儲存事件
收到 beforeinstallprompt 觸發後要 e.preventDefault();，因為 Chrome 67 以前的版本會自動觸發內建提示視窗
要記得把事件存起來，後續在安裝的流程上會需要
讓 “安裝按鈕” 顯示
點選後 “安裝按鈕” 隱藏 (也可以停用)
點選按鈕後才觸發提示視窗
等待使用者確認或拒絕
從 userChoice 的結果判斷是否安裝成功
deferredPrompt 用過就不能再用了

// https://github.com/mdn/pwa-examples/blob/master/a2hs/index.js

// 1. 宣告變數儲存事件
let deferredPrompt;

window.addEventListener("beforeinstallprompt", (e) => {
  // 2. 停用 Chrome 67 前的公版提示視窗
  e.preventDefault();
  // 3. 記得把事件存起來，後續在安裝的流程上會需要
  deferredPrompt = e;
  // 4. 讓 "安裝按鈕" 顯示
  addBtn.style.display = "block";

  addBtn.addEventListener("click", (e) => {
    // 5. 點選後 "安裝按鈕" 隱藏 (也可以停用)
    addBtn.style.display = "none";
    // 6. 點選按鈕後才觸發提示視窗
    deferredPrompt.prompt();
    // 7. 等待使用者確認或拒絕
    deferredPrompt.userChoice.then((choiceResult) => {
      // 8. 從 userChoice 的結果判斷是否安裝成功
      if (choiceResult.outcome === "accepted") {
        console.log("User accepted the A2HS prompt");
      } else {
        console.log("User dismissed the A2HS prompt");
      }
      // 9. 用過就不能再用了
      deferredPrompt = null;
    });
  });
});

透過網址列或瀏覽器安裝

透過網址列、瀏覽器元件自動的提示、瀏覽器中的選單進行安裝的話，開發者無法知道是否 App 已經被安裝，所以需要透過 appinstalled 這個事件。

window.addEventListener("appinstalled", () => {
  // "安裝按鈕" 隱藏 (也可以停用)
  addBtn.style.display = "none";
  // 用過就不能再用了
  deferredPrompt = null;
  // 安裝成功
  console.log("PWA was installed");
});

Promoting 推薦介面設計模式

PWA 安裝的流程介面設計上 Google 有幾個建議

只在滿足安裝前的審核標準並觸發 beforeinstallprompt 才顯示
讓安裝建議的提示和原來的使用者歷程分開，減少影響相關的互動與轉化
提供並且記住使用者拒絕或延後安裝的選擇結果，只在使用者狀態改變時再次提示，像是登入後或著是完成一次購買時
可以運用各種介面設計模式來提示安裝，但盡量不要放太多

底下圖片皆取自於 https://web.dev/

瀏覽器自動提示

當 PWA 滿足安裝前的審核標準時，大部分瀏覽器會自動地跳出可以被安裝的提示。

桌面版本提示:

手機版本提示:

簡易安裝按鈕

最簡單的 UX 就是透過一個安裝按鈕來提示，簡易安裝按鈕。

像是購物網站或是論壇入口，就蠻適合將安裝按鈕提示放在固定的 Header 上進行提示。

透過適當的 RWD 設計，讓按鈕可以更好看。

融入到選單

如果網站本來就有選單，可以透過設計把按鈕融入到選單中，記得不要打擾使用者使用選單並透過文案告知安裝好處。

到達頁面

當使用者進入到達頁面時，蠻適合趁機推廣安裝，此時記得

配合使用者導流進來的關鍵字給一個想要安裝的理由
確認提示的位置夠明顯，推廣的標語要夠明確

大部分的手機使用者已經習慣 banner 跳出提示了，所以其實也可以這麼做，但有兩個重點:

但盡量等到使用者對您的網站表現出興趣後，再顯示 Banner
如果使用者關閉了，就不要再次顯示。除非觸發了一個轉化事件，例如在購買或註冊帳戶
簡要說明安裝 PWA 的價值

Temporary UI

透過彈出通知提示，幾點注意事項

4 到 7 秒，有足夠的時間查看它並做出反應但又不妨礙操作
避免將其顯示在其他臨時 UI 上
等到有接受強烈興趣信號後再使用此模式，例如重複訪問、用戶登錄或類似的轉化事件

轉換後提示

像是購買後的結帳清單頁面，使用者明顯完成一次轉化，代表其實有興趣，這時候就蠻適合推薦。

購買或結帳流程中適度推廣

如果安裝能有獨特的優惠，或是能夠有相關優點就要透過提示告知，像是能夠接收推播來追蹤商品等等，但要注意不要影響了原來的使用者歷程。

登入頁面過程中提示

考慮在登入頁面中置入推薦，因為使用者已完成註冊，這時候推薦其實不影響，算是適合放置的地方。

把推廣融入在內容中

新聞文章或其他訊息列表間出現一個推薦安裝的訊息，底下三個注意事項:

限制頻率
能夠取消
記住使用者曾選擇關閉

FAQ：PWA A2HS 常見問題

Q1：為什麼我的網站滿足了所有條件，卻沒有觸發 beforeinstallprompt 事件？

A：除了技術條件外，瀏覽器（尤其是 Chrome）通常還有「使用者參與度」的權重。例如，使用者必須在頁面上停留超過 30 秒，或是有進行點擊互動。此外，如果使用者在過去幾小時內剛拒絕過安裝提示，瀏覽器也可能暫時不再觸發。

Q2：iOS 上的 A2HS 實作有什麼不同？

A：iOS Safari 目前不支援 beforeinstallprompt 自動觸發。您無法透過程式碼控制彈出安裝視窗，只能透過 UI 導引（如彈出氣泡框）告訴使用者點選 Safari 下方的「分享」按鈕，然後手動選擇「加入主畫面」。

Q3：如何偵測 PWA 是否已經被安裝？

A：您可以監聽 appinstalled 事件來捕捉「安裝成功」的瞬間。對於之後的開啟，可以使用 CSS 的 display-mode: standalone 或 JS 的 matchMedia() 來判斷當前是否運行於安裝模式。

透過精心設計的 A2HS 安裝流程，您可以顯著提升 Web App 的使用者回訪率與忠誠度。持續優化您的安裝提示介面，讓 Web 應用在行動端也能綻放原生光芒！

更多相關文章

喜歡這篇文章，請幫忙拍拍手喔 🤣

PWA 新增至主畫面實作自定義 A2HS 提示介面以引導使用者完成安裝流程