SEO on Wayne's blog | 偉恩的部落格 | 技術博客

將網頁變成Progressive Web Application(PWA)，漸進式的網頁應用程式

Wed, 19 Oct 2022 00:00:00 +0000

前幾天與大家分享，當開啟Chrome內建的PWA功能，就可將PWA的網頁，一鍵變成一個應用程式，雖然說PWA只是在應用程式裡，包了Chrome的瀏覽器，但開啟時就像應用程式一般，讓網頁就像應用程式一般，其實簡單的來說，這就有點像PhoneGap的感覺，但比PhoneGap要來的簡單許多。

因此只要將網頁加入一些簡單的宣告與設定，立即就可將一般的網頁變成PWA的網頁應用程式，真心覺得PWA是個好物，因此只要你會寫網頁，就可將你所設計的網頁變成一隻應用程式！

將網頁變成Progressive Web Application(PWA)

Step1：下載 Chrome 擴充套件

點我前往「Web Server」擴充套件

首先，你可先下載Chrome的「Web Server」擴充程式，再點「CHOSOSE FOLDER」鈕，選擇已製作好的網頁目錄。

Step2：檢查網頁

點一下連結，並檢查網頁是否能正常呈現。

Step3：建立 manifest.json

更多 manifest.json 介紹，點我前往

接著建立一個新的文件檔，並依的輸入應用程式名稱、圖示、與應用程式的URL，再將它儲存為「manifest.json」檔。

manifest.json

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50


{
 "short_name": "Wayne's blog",
 "name": "Wayne's blog",
 "description": "偉恩的部落格，用於紀錄coding life查找的資料、筆記與文章，統整起來除了自己使用，也希望對各位有幫助。",
 "icons": [
 {
 "src":"./apple-touch-icon-57x57.webp",
 "sizes": "57x57",
 "type": "image/webp"
 },
 {
 "src":"./apple-touch-icon-114x114.webp",
 "sizes": "114x114",
 "type": "image/webp"
 },
 {
 "src":"./apple-touch-icon-120x120.webp",
 "sizes": "120x120",
 "type": "image/webp"
 },
 {
 "src":"./apple-touch-icon-180x180.webp",
 "sizes": "180x180",
 "type": "image/webp"
 },
 {
 "src":"./apple-touch-icon-192x192.webp",
 "sizes": "192x192",
 "type": "image/webp"
 },
 {
 "src":"./apple-touch-icon-512x512.png",
 "sizes": "512x512",
 "type": "image/png"
 },
 {
 "src":"./maskable_icon.webp",
 "sizes": "512x512",
 "type": "image/webp",
 "purpose": "any maskable"
 }
 ],
 "lang": "zh-Hant-TW",
 "start_url": "./?utm_source=web_app_manifest",
 "background_color": "#f5f5fa",
 "theme_color": "#57BCB9",
 "display": "standalone",
 "orientation": "landscape",
 "prefer_related_applications": false
}

Step4：html 加入 manifest.json

在head標籤中加入 manifest.json。

1
2
3


<!-- ... -->
<link rel="manifest" href="./manifest.json" />
<!-- ... -->

由於 manifest 在 IOS 上還不支援，因此如果 IOS 上也想要自訂 icon，就要改用 HTML 裡的 meta 來設定，如下：

1
2
3
4
5
6
7
8
9


<!-- ... -->
<link rel="manifest" href="./manifest.json" />
<link rel="apple-touch-icon" sizes="57x57" href="./apple-touch-icon-57x57.webp" />
<link rel="apple-touch-icon" sizes="114x114" href="./apple-touch-icon-114x114.webp" />
<link rel="apple-touch-icon" sizes="120x120" href="./apple-touch-icon-120x120.webp" />
<link rel="apple-touch-icon" sizes="180x180" href="./apple-touch-icon-180x180.webp" />
<link rel="apple-touch-icon" sizes="192x192" href="./apple-touch-icon-192x192.webp" />
<link rel="apple-touch-icon" sizes="512x512" href="./apple-touch-icon-512x512.png" />
<!-- ... -->

Step5：打開開發人員工具檢查 manifest.json 的設定

Step6：加入 `serviceWorker` 語法

更多 Service Worker 介紹，點我前往

在網頁前加入下方的語法。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


<script>
 if ("serviceWorker" in navigator) {
 console.log("Will service worker register?");
 navigator.serviceWorker.register("./service-worker.js").then(function(reg) {
 console.log("Yes it did.");
 }).catch(function(err) {
 console.log("No, it didn't. This happened: ", err);
 });
 }
</script>

Step7：建立 `service-worker.js` 檔案

接著再建立一個文件，並貼上下方的語法，儲存為 service-worker.js，這時可看到在原來的網頁中，分別會多了 manifest.json 與 service-worker.js 和圖片資料夾。

service-worker.js

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


self.addEventListener('install', function(event) {
 self.skipWaiting();

 var offlinePage = new Request('offline.html');
 event.waitUntil(
 fetch(offlinePage).then(function(response) {
 return caches.open('offline2').then(function(cache) {
 return cache.put(offlinePage, response);
 });
 }));
});
self.addEventListener('fetch', function(event) {
 event.respondWith(
 fetch(event.request).catch(function(error) {
 return caches.open('offline2').then(function(cache) {
 return cache.match('offline.html');
 });
 }));
});
self.addEventListener('refreshOffline', function(response) {
 return caches.open('offline2').then(function(cache) {
 return cache.put(offlinePage, response);
 });
});
self.addEventListener('push', function (event) {
 var data = event.data.json(); var opts = {
 body: data.body,
 icon: data.icon,
 data: {
 url: data.url
 }
 };
 event.waitUntil(self.registration.showNotification(data.title, opts));
});
self.addEventListener('notificationclick', function(event) {
 var data = event.notification.data; event.notification.close(); event.waitUntil(
 clients.openWindow(data.url)
 );
});

Step8：確認 Service Workers 是否正常

接著再回到網頁的「開發人員工具」的 Service Workers 時，就會看到綠色燈號。

Step9：安裝「頁面」

都完成後，再點 Chrome 右上的選單圖示，就可看到「安裝XXX」。

Step10：安裝

點一下，就會出現安裝畫面，再點「安裝」。

當安裝完畢後，就會開啟剛所安裝的應用程式，哈！是不是畫面乾淨許多，就像在使用一般的應用程式一樣，有了PWA後可實現透過網頁就能打造專屬的應用程式的夢想，且完全不用再學新語言，真是超方便的。

manifest.json 介紹

以下來說明一下 manifest.json

manifest.json 是在學 PWA 這塊時最簡單的部份，主要是建一支 JSON 檔就可以，相關的參數 MDN上或是 Google 一下就會看到，不用花太多的時間去記。

manifest.json是做什麼用的？

根據 MDN 上的解釋，manifest.json 是這樣子的：

它提供了應用程式相關的資訊（像是名稱、作者、圖示、描述）。 manifest 的功用是將 Web 應用程式安裝到設備的主畫面，為使用者提供更快速的訪問和更豐富的體驗。

簡單的說明就是，PWA 主要就是讓網頁可以模擬成一個手機的 App 來使用，要當成 App，就要有 App 的樣子，就要能在手機的桌面上有一個 icon 可以按，按下去後有一個幾秒鐘的啟動畫面讓使用者知道開啟的 App 是什麼，manifest 就是在處理這段。

另外，一般我們在手機上開 Chrome 或 Safari 看網頁時，最頂部會有一條網址列，但一般 App 是不會有的，而 manifest.json 也可以設定開啟頁面時不顯示網址列。

PWA 是把頁面模擬成 App 的一個方法，如果公司本身也有製作 App 呢？manifest.json 上也可以設定 App 在 Google Play、App Store 上的連結，並呈現一個推薦通知讓使用者可以進入並下載。

最後補充一點，不論是 PWA 的 Cache 或是推播功能，都要求網站要是 https，manifest.json 這點也不意外，如果網站不是 https，即便引用了 manifest.json，也不會被 Chrome 主動詢問是否要將網站加入到主畫面。

關於 manifest 的功能，Google 有一隻影片介紹：

Web App Manifest: Totally Tooling Tips

manifest.json 成員

成員列表整理如下：

欄位	說明
theme_color	應用程式的主要顏色
background_color	啟動畫面（splash screen）的背景色
icons	應用程式的圖示
name	應用程式的名稱
short_name	應用程式的簡寫
lang	主要語言
description	應用程式的描述
dir	文字書寫方向
display	應用程式的顯示模式
orientation	預設顯示的方向是直的或橫的
prefer_related_applications	是否要推薦一個原生的 App
related_applications	推薦原生 App 的連結
start_url	開啟應用程式時的預設網址
scope	應用程式的使用範圍

theme_color

應用程式的主要顏色，主要可以改變網址列那一條的顏色。

1

"theme_color": "#57BCB9"

background_color

啟動畫面（splash screen）的背景色，App 啟動時，會有一個 Splash Screen，翻譯成快閃頁、過場頁，本篇稱為啟動畫面。

Splash Screen 需要3個成員：background_color、icons、name。

1

"background_color": "red"

補充一點，Splash Screen，在 IOS 上是不支援的，但可以直接讀取一張圖檔來當作啟動頁面，在 head 裡加入以下就行：

1
2
3
4
5
6
7


<link rel="apple-touch-startup-image" href="images/splash-640x1136.png" media="(device-width: 320px) and (device-height: 568px) and (-webkit-device-pixel-ratio: 2) and (orientation: portrait)">
<link rel="apple-touch-startup-image" href="images/splash-750x1294.png" media="(device-width: 375px) and (device-height: 667px) and (-webkit-device-pixel-ratio: 2) and (orientation: portrait)">
<link rel="apple-touch-startup-image" href="images/splash-1125x2436.png" media="(device-width: 375px) and (device-height: 812px) and (-webkit-device-pixel-ratio: 3) and (orientation: portrait)">
<link rel="apple-touch-startup-image" href="images/splash-1242x2148.png" media="(device-width: 414px) and (device-height: 736px) and (-webkit-device-pixel-ratio: 3) and (orientation: portrait)">
<link rel="apple-touch-startup-image" href="images/splash-1536x2048.png" media="(min-device-width: 768px) and (max-device-width: 1024px) and (-webkit-min-device-pixel-ratio: 2) and (orientation: portrait)">
<link rel="apple-touch-startup-image" href="images/splash-1668x2224.png" media="(min-device-width: 834px) and (max-device-width: 834px) and (-webkit-min-device-pixel-ratio: 2) and (orientation: portrait)">
<link rel="apple-touch-startup-image" href="images/splash-2048x2732.png" media="(min-device-width: 1024px) and (max-device-width: 1024px) and (-webkit-min-device-pixel-ratio: 2) and (orientation: portrait)">

icons

應用程式的圖示，icons 裡放陣列，放不同尺寸下的主要圖示，如果 Splash Screen 裡要用的圖示，大小必須包含 192px、512px。

icons 裡，陣列裡的每一個物件有 3 個成員：

sizes 圖片尺寸，可用在多個尺寸上的話用空白鍵區隔。
src 圖片的路徑，如果是相對路徑，是以 manifest 所在的位置為基準。
type 圖檔類型，這項排必填，主要是告知裝置類型，讓不支援的裝置可以快速略過。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


"icons": [
 {
 "src": "icon/lowres.webp",
 "sizes": "48x48",
 "type": "image/webp"
 },
 {
 "src": "icon/lowres",
 "sizes": "48x48"
 },
 {
 "src": "icon/hd_hi.ico",
 "sizes": "72x72 96x96 128x128 256x256"
 },
 {
 "src": "icon/hd_hi.svg",
 "sizes": "72x72"
 }
]

由於 manifest 在 IOS 上還不支援，因此如果 IOS 上也想要自訂 icon，就要改用 HTML 裡的 meta 來設定，如下：

1
2
3


<link rel="apple-touch-icon" sizes="57x57" href="apple-icon-57x57.png" />
<link rel="apple-touch-icon" sizes="72x72" href="apple-icon-72x72.png" />
<link rel="apple-touch-icon" sizes="114x114" href="apple-icon-114x114.png" />

name

應用程式的完整名稱，會顯示在 Splash Screen上，以及主畫面上的名稱。

1

"name": "Wayne's blog"

short_name

應用程式的簡寫，當 name 太長而無法顯示時，會改成顯示簡寫。

1

"short_name": "Wayne's blog"

lang

主要語言，針對 name、short_name 這兩個使用的。

語言列表可以在這找：https://www.iana.org

1

"lang": "zh-Hant-TW"

description

應用程式的描述，描述這個應用程式是做什麼的。

1

"description": "偉恩的部落格，用於紀錄coding life查找的資料、筆記與文章，統整起來除了自己使用，也希望對各位有幫助。"

dir

文字書寫方向，值有 3 個：ltr（左至右）、rtl（右至左）、auto（讓瀏覽器自己決定），不填的話預設值是 auto。

1

"dir": "ltr"

display

應用程式的顯示模式，顯示模式指的是從主畫面點開 App 後，要顯示的樣子，有 4 個值可用：

fullscreen：全螢幕，就像在用原生 App 一樣，會隱藏所有的瀏覽器 UI。
standalone：會隱藏標準瀏覽器 UI 元素，如 URL 欄等。
browser：預設值，就像一般用瀏覽器一樣。
minimal： ui 會有導覽列最小的 UI，這個值 Chrome 不支援。

如果要 Chrome 主動提示加入主畫面的話，設定值必須要是 standalone。

1

"display": "standalone"

orientation

預設顯示的方向是直的或橫的，可以強制讓使用者必須裝置拿直的（landscape）或拿橫的（portrait）看。這點要設要仔細思考過才行，因為使用都大部份都喜歡自己決定是直看或横看。

如果是遊戲類型的，可以設定用橫的。

1

"orientation": "landscape"

prefer_related_applications

是否要推薦一個原生的 App，PWA 是模擬頁面為 App，如果網站本身有出 App，這項就可以設成 true，從主畫面點開頁面時就會出現可以下載 App 的提示。

如果這項為 true，則下面的 related_applications 就要填入值；這項的預設值為 false。

1

"prefer_related_applications": false

related_applications

推薦原生 App 的連結，值是陣列，裡面放 App 資訊的物件，每項物件有 2 個成員要填，是 Google Play 上的話則有 3 個成員。

platform：應用程式的平台，可填 play、itunes。
url：應用程式的網址。
id： Google Play上要填的 ID。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


"related_applications": [
 {
 "platform": "play",
 "url": "https://play.google.com/store/apps/details?id=com.example.app1",
 "id": "com.example.app1"
 },
 {
 "platform": "itunes",
 "url": "https://itunes.apple.com/app/example-app1/id123456789"
 }
]

start_url

開啟應用程式時的預設網址，如果有設定的話，開啟應用程式時就會進到設定的網址。沒設定的話就是使用者按加入主畫面時的那個網址。
如果填寫的是相對路徑，是以 manifest 所在的位置為基準。
建議可以在網址上加入 Google Analytics 的 utm 參數，這樣在 GA 上就可以看見多少來源是來自於 PWA，可以檢測成效。

如果要 Chrome 主動提示加入主畫面的話，這項必須填寫。

1

"start_url": "./?utm_source=web_app_manifest"

scope

應用程式的使用範圍，這項如果有填，那應用程式的作用域就會限在指定的目錄裡，超過指定目錄，就會當成一般的網頁瀏覽。

1

"scope": "/myapp/"

manifest.json 基本檔案內容

manifest 裡的成員不是每項都一定要填寫的，以下附上 manifest.json 的基本檔內容：

manifest.json

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50


{
 "short_name": "Wayne's blog",
 "name": "Wayne's blog",
 "description": "偉恩的部落格，用於紀錄coding life查找的資料、筆記與文章，統整起來除了自己使用，也希望對各位有幫助。",
 "icons": [
 {
 "src":"./apple-touch-icon-57x57.webp",
 "sizes": "57x57",
 "type": "image/webp"
 },
 {
 "src":"./apple-touch-icon-114x114.webp",
 "sizes": "114x114",
 "type": "image/webp"
 },
 {
 "src":"./apple-touch-icon-120x120.webp",
 "sizes": "120x120",
 "type": "image/webp"
 },
 {
 "src":"./apple-touch-icon-180x180.webp",
 "sizes": "180x180",
 "type": "image/webp"
 },
 {
 "src":"./apple-touch-icon-192x192.webp",
 "sizes": "192x192",
 "type": "image/webp"
 },
 {
 "src":"./apple-touch-icon-512x512.png",
 "sizes": "512x512",
 "type": "image/png"
 },
 {
 "src":"./maskable_icon.webp",
 "sizes": "512x512",
 "type": "image/webp",
 "purpose": "any maskable"
 }
 ],
 "lang": "zh-Hant-TW",
 "start_url": "./?utm_source=web_app_manifest",
 "background_color": "#f5f5fa",
 "theme_color": "#57BCB9",
 "display": "standalone",
 "orientation": "landscape",
 "prefer_related_applications": false
}

關於「Chrome 主動提示加入主畫面」

PWA 身為 Google 的親身兒子，在 Android 手機是很有吃香的點。
頁面引用了 manifest.json 後，使用者在手機上點選加入主畫面，頁面就可以像 App 一樣顯示在手機的主畫面上。

但很多使用者其實不知道有這功能，或是知道了也不常會去按。
貼心的 Google 針對這點做了一項措施，就是主動詢問使用者要不要將頁面加入主畫面。

根據 Google 的說明文件：Add to Home Screen，觸發 Chrome 主動詢問是否加入主畫面的條件如下：

使用者還沒加入主畫面
在有 manifes.json 的網域下，互動了至少 30 秒
manifset.json 裡有幾項成員一定要有：name 或 short_name、icons、start_url、display
頁面要是 https
頁面有裝 service-worker（sw.js），裡面有監聽並處理 beforeinstallprompt 事件

第 5 點，是否要有寫 beforeinstallprompt，好像不是必填項目，即便沒填，在測試時也會在底部出現一條詢問框。

在參考了這篇以後：PWA 實戰經驗分享
發現別人是用在 UX 上更優化的地方，就是自己選擇要出現詢問框時用的。

manifest 觀摩

我們來看看幾個知名的 PWA 都是怎麼寫他們的 manifest.json。

第一個是 PWA 界中很有名的 flipkart：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


{
 "name": "Flipkart Lite",
 "short_name": "Flipkart Lite",
 "icons": [
 {
 "src": "https:/https://static.coderbridge.com/img/techbridge/images1a.flixcart.com/www/linchpin/batman-returns/logo_lite-cbb3574d.png",
 "sizes": "192x192",
 "type": "image/png"
 }
 ],
 "gcm_sender_id": "656085505957",
 "gcm_user_visible_only": true,
 "start_url": "/?start_url=homescreenicon",
 "permissions": [
 "gcm"
 ],
 "orientation": "portrait",
 "display": "standalone",
 "theme_color": "#2874f0",
 "background_color": "#2874f0"
}

再來是鼎鼎大名的 twitter：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


{
 "background_color": "#ffffff",
 "description": "It's what's happening. From breaking news and entertainment, sports and politics, to big events and everyday interests.",
 "display": "standalone",
 "gcm_sender_id": "49625052041",
 "gcm_user_visible_only": true,
 "icons": [
 {
 "src": "https://abs.twimg.com/responsive-web/web/ltr/icon-default.604e2486a34a2f6e.png",
 "sizes": "192x192",
 "type": "image/png"
 },
 {
 "src": "https://abs.twimg.com/responsive-web/web/ltr/icon-default.604e2486a34a2f6e.png",
 "sizes": "512x512",
 "type": "image/png"
 }
 ],
 "name": "Twitter",
 "share_target": {
 "action": "compose/tweet",
 "params": {
 "title": "title",
 "text": "text",
 "url": "url"
 }
 },
 "short_name": "Twitter",
 "start_url": "/",
 "theme_color": "#ffffff",
 "scope": "/"
}

最後則是 Google I/O 2018：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


{
 "name": "Google I/O 2018",
 "short_name": "I/O 2018",
 "start_url": "./?utm_source=web_app_manifest",
 "display": "standalone",
 "theme_color": "#6284F3",
 "background_color": "#6284F3",
 "icons": [{
 "src": "static/images/homescreen/homescreen57.png",
 "sizes": "57x57",
 "type": "image/png"
 }, {
 "src": "static/images/homescreen/homescreen114.png",
 "sizes": "114x114",
 "type": "image/png"
 }, {
 "src": "static/images/homescreen/homescreen128.png",
 "sizes": "128x128",
 "type": "image/png"
 }, {
 "src": "static/images/homescreen/homescreen144.png",
 "sizes": "144x144",
 "type": "image/png"
 }, {
 "src": "static/images/homescreen/homescreen192.png",
 "sizes": "192x192",
 "type": "image/png"
 }, {
 "src": "static/images/homescreen/homescreen512.png",
 "sizes": "512x512",
 "type": "image/png"
 }],
 "prefer_related_applications": false,
 "related_applications": [{
 "platform": "play",
 "id": "com.google.samples.apps.iosched"
 }],
 "gcm_sender_id": "103953800507"
}

我滿喜歡觀察別人家的這些東西，因為你會發現很多你查資料時遺漏或是根本找不到的資訊，而且這些看久了你也會有個概念，知道哪些屬性特別常用，除了 manifest.json 以外，也可以參考 html 裡面的 tag，一樣能學習到很多。

Service Worker 介紹

加入 Service Worker 的目的就只有一個，那就是快取。透過 Service Worker（以下簡稱 SW），可以幫助我們在發送 request 之前就先攔截到並且做處理，而離線運行的原理也是這樣的，我們先在第一次開啟時註冊 SW，並且利用 SW 下載靜態檔案並快取住，之後若使用者離線，我們再用已經快取住的檔案來回覆，就不會發送真的 request，自然也不會發生無法連線的情況。

而 Google 有提供了一個方便的工具：Workbox 來幫助我們自動產生出 SW 以及利用更方便的語法來攔截 request。

舉例來說，我自己用的是 Webpack 的 plugin：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


new workboxPlugin.InjectManifest({
 swSrc: path.join(__dirname, '..', SRC_DIR, 'sw.js'),
 swDest: path.join(__dirname, '..', DIST_DIR, 'sw.js'),
 globDirectory: path.join(__dirname, '..', DIST_DIR),
 globPatterns: ['**/*.{js,css}']
}),

//sw.js
let precacheList = self.__precacheManifest || []
workbox.precaching.precacheAndRoute(precacheList)

只要這樣一寫，就會自動去找符合規則的檔案並且加入快取清單裡面，你只要一註冊 SW 的時候就會把那些檔案給快取起來。

除此之外呢，Workbox 也可以針對 URL 來監聽：

sw.js

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


// sw.js
workbox.routing.registerRoute(/(https?:\/\/)(.*)\/api\/(.*)/, args =>
 workbox.strategies
 .networkFirst({
 cacheName: 'data-cache',
 plugins: [
 new workbox.expiration.Plugin({
 maxEntries: 100,
 maxAgeSeconds: 2592000
 })
 ]
 })
 .handle(args)
 .then(response => {
 return response
 })
 .catch(err => {
 console.log('err:', err)
 })
)

像上面的程式碼就是針對路徑中含有 api 的 request 做快取，這樣在離線時也可以利用以前快取住的 API response。

Workbox 針對這種動態的快取提供幾種策略，分別是：staleWhileRevalidate、cacheFirst、networkFirst、networkOnly與cacheOnly，其實看名字就可以大概理解策略是什麼了，想知道詳細的內容可以參考官方文件：Workbox Strategies。

總之自從有了 Workbox 之後，基本上就不用自己手寫 SW 了，都靠著它提供的 API 以及功能就行了，就可以自動產生出符合需求的 SW。

最後要來談的是「安裝 PWA」這一塊，在 iOS Safari 上面別無他法，就只能自己叫出選單然後選取「Add to home screen」，可是在 Android Chrome 上面，如果你符合一定的條件（有設置 mainfest.json 以及有註冊 Service Worker），就會自動幫你跳出一個可愛的 Install banner。

（圖片來自：Changes to Add to Home Screen Behavior）

根據 Chrome 版本的不同，行為也有所不同。

在 Chrome 67（含）以前的版本，如果你在 beforeinstallprompt 事件裡面沒有特別用 preventDefault()，或是顯式的呼叫了 prompt()，就會出現最左邊那個頗大的 A2HS banner。

然後在 Chrome 68（含）之後的版本，無論你做了什麼，系統都會自動出現那個 Mini-infobar，但如果使用者關掉的話，要隔三個月才會再出現一次，實在是有夠久。

接著呢，上面這兩個 A2HS banner 跟 Mini-infobar，使用者點擊之後都會出現最右邊的 A2HS Dialog，提示使用者要不要安裝 PWA。

但是在 Chrome 68 以後，你也可以利用程式去呼叫 beforeinstallprompt 裡面拿到的 event.prompt() 把這個 dialog 顯示出來。

聽起來有點複雜對吧？

先來介紹 beforeinstallprompt 這個 event 好了，這個 event 在一切都準備就緒，確認你滿足條件可以顯示 prompt 的時候會被觸發，會傳來一個 event，你可以阻止顯示 prompt，把這個 event 存起來：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 此範例來自上面的官方文件
let installPromptEvent;

window.addEventListener('beforeinstallprompt', (event) => {
 // Prevent Chrome <= 67 from automatically showing the prompt
 event.preventDefault();
 // Stash the event so it can be triggered later.
 installPromptEvent = event;
 // Update the install UI to notify the user app can be installed
 document.querySelector('#install-button').disabled = false;
});

為什麼要存起來呢？因為使用者可能不想一打開網站就看到這個彈窗，或者他可能正在結帳結果你跳這個東西來干擾他，所以先把它存起來，等適當的時機再呼叫 installPromptEvent.prompt() 來跳出 Dialog。

但要注意的事情是你直接呼叫 installPromptEvent.prompt() 是沒用的，你必須要 within a user gesture，意思就是你要放在按鈕的 click 事件（或其他由使用者觸發的事件）裡才有效，直接呼叫是沒有用的，而且會看到 console 跳出錯誤訊息。

我之前一度很好奇它是怎麼做判斷的，後來發現原來有 event.isTrusted 可以用，可以判斷一個事件是不是被使用者主動觸發的，參考資料：MDN - Event.isTrusted。

總之呢，因為在不同版本上的 Chrome 有不同行為，所以最後我們決定用下面的程式碼針對不同版本有不同的反應：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


// 把 event 存起來
var installPromptEvent

// 要顯示 prompt 的延遲
var showTime = 30 * 1000

window.addEventListener('beforeinstallprompt', function (e) {
 e.preventDefault()
 installPromptEvent = e
 var data = navigator.userAgent.match(/Chrom(e|ium)\\/([0-9]+)\\./)
 var version = (data && data.length >= 2) ? parseInt(data[2], 10) : null
 if (version && installPromptEvent.prompt) {

 // 延遲一段時間才顯示 prompt
 setTimeout(function() {
 // 如果 Chrome 版本是 67（含）以下，可以直接呼叫
 if (version <= 67) {
 installPromptEvent.prompt()
 return
 }

 // 否則的話必須透過 user action 主動觸發
 // 這邊幫 #root 加上 event listener，代表點擊螢幕任何一處都會顯示 prompt
 document.querySelector('#root').addEventListener('click', addToHomeScreen)
 }, showTime)
 }
});

function addToHomeScreen(e) {
 if (installPromptEvent) {
 installPromptEvent.prompt()
 installPromptEvent = null
 document.querySelector('#root').removeEventListener('click', addToHomeScreen)
 }
}

如果是 67 以下，直接呼叫就可以顯示 prompt，否則的話還要再一步，要加個 event listener 才行，而我們也選擇延遲 30 秒才顯示。

出乎意料地，這樣一個小改動帶來驚人的成長，原本一天大概才 20、30 個人安裝 PWA，經過這樣調整之後瞬間變成八到十倍，看到 GA 的那個統計圖我也嚇了一跳，沒想到效果這麼好。

與其一直積極地要別人快點安裝 PWA，還不如只要求真的對你產品有興趣（停留超過 30 秒鐘）的人。

用 Firebase 做 Web Push

用到的資源

Web Push 推播功能，這陣子很常看到的一個功能，如果一進入網站，看到網站要求顯示通知的權限，就代表這個網站有用這功能：

那通常，很多網站 UX 設計不良，在使用者根本就還搞不清楚這網站是幹麻的情況下就跳通知，所以大部份都直接按封鎖了吧 XD？

總之，在踩了幾個坑以後，終於完整的寫出了 Web Push 的功能。

完整是指會在桌機、安卓手機發出推播通知，並且點了會進到指定的頁面，同時在 Firebase 儲存發送訊息的記錄。

用到的資源如下：

資料庫：Firebase Realtime Database
推播功能：Firebase Cloud Messaging
JS framework：Vue.js

Web Push 是 PWA 一個很重要的功能！

取得 FCM 金鑰

本篇是用 Firebase 的 Cloud Messaging功能（以下稱 FCM），去實作 Web Push。所以第一步是要先在 Firebase 上開一個專案。

以下截圖所用到的 Firebase 專案之後會刪掉，各種金鑰最後都不會存在，純示範用。

開完專案後，要取得推播金鑰，有了金鑰才能始用 FCM 的功能。

首先進到 Firebase 後台，點選齒輪後，再點選專案設定：

點擊 Cloud Messaging：

頁面往下拉，會看到一個「網路設定」的區塊，有一個「產生金鑰組」的按金，按下去：

就會產生一組 Web Push 用的金鑰，先存下來，Firebase Config 裡會用到：

新增 manifest.json、Firebase Config

取得金鑰後，第二步就是新增一個 manifest.json 的檔案，檔案內容大概如下：

manifest.json

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


{
 "short_name": "XXX",
 "name": "XXXXXX",
 "icons": [
 {
 "src": "./logo/logo192.png",
 "type": "image/png",
 "sizes": "192x192"
 },
 {
 "src": "./logo/logo512.png",
 "type": "image/png",
 "sizes": "512x512"
 },
 {
 "src":"./logo/maskable_icon.webp",
 "sizes": "512x512",
 "type": "image/webp",
 "purpose": "any maskable"
 }
 ],
 "start_url": "/",
 "background_color": "#ffffff",
 "display": "standalone",
 "scope": "/",
 "theme_color": "#000000",
 "gcm_sender_id": "103953800507"
}

最重要的是這一行：

1

"gcm_sender_id": "103953800507"

這行一定要有，key、value 是固定的，copy 貼上就行。

Firebase Config

建立一個首頁的檔案 index.html，在頁尾的部份引用 Firebase Config。
Firebase Config 一樣是後台有提供，點小齒輪，再點專案設定後，接著點代表 Web 的那個按鈕：

就會出現 Config 了：

copy 以後貼到 index.html，另外也一併貼上 FCM 的引用，整合後如下：

fcm-web-push-firebase-config.html

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


<script src="https://www.gstatic.com/firebasejs/5.9.1/firebase.js"></script>
<script>
 var config = {
 apiKey: "XXXXXXXXXX",
 authDomain: "XXXXXXXXXX.firebaseapp.com",
 databaseURL: "https://XXXXXXXXXX.firebaseio.com",
 projectId: "XXXXXXXXXX",
 storageBucket: "XXXXXXXXXX.appspot.com",
 messagingSenderId: "XXXXXXXXXX"
 };
 firebase.initializeApp(config);
 var database = firebase.database();
 var messaging = firebase.messaging();
 messaging.usePublicVapidKey('XXXXXXXXXXXXXXXXXXXX');
</script>

最後一行的：

1

messaging.usePublicVapidKey('XXXXXXXXXXXXXXXXXXXX');

XXX 就是要替換成第一步拿到的 FCM 金鑰。

取得使用者的 token

簡單來說，Web Push 推播功能的流程如下：

註冊 service-worker → 向使用者要求允許通知權限 →
FCM 產生這個裝置的 token → token 寫進資料庫 →
從後台使用 Web Push → Server 發 Web Push 到裝置上 →
裝置上的 service worker 接收 → service worker 執行 notification

token 是每一個裝置會有的，之所以會以裝置為單位，而不是以使用者為單位，是因為每一個裝置都可以註冊service worker，而且每次存的 token 都會不同，所以一個使用者在桌機的 Chrome、Fireox，或是安卓手機的Chrome、Firefox，都有不同的 token。

假設王小明在桌機的 Chrome、Firefox，都按下了允許通知，在安卓手機的 Chrome、Firefox 也按了允許通知，那當我們按下發送推播後，王小明就會在 4 個地方收到相同的通知。因為是用裝置來區分的。

IOS 目前還不支援 Web Push。
2020.04.10更新：
今天看到 iZooto 的一篇文章上寫，在比對了一下 Can I Use 中的 service workers 支援情況，可以看到 IOS11.3 開始支援 Service Workers 了，但 Web Push 的功能只支援在 MAC，尚未支援到 iPhone 上。

新增 sw.js

用 Workbox 新增一個 sw.js 檔案，把 Firebase 的 Config 放進去，程式碼如下：

fcm-web-push-sw1.js

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


importScripts("https://storage.googleapis.com/workbox-cdn/releases/3.6.3/workbox-sw.js");
importScripts('https://www.gstatic.com/firebasejs/5.7.0/firebase-app.js');
importScripts('https://www.gstatic.com/firebasejs/5.7.0/firebase-messaging.js');

workbox.clientsClaim();
workbox.skipWaiting();

workbox.precaching.precacheAndRoute([
 // 要快取的檔案
]);

// firebase config
var config = {
 apiKey: "XXXXXXXXXX",
 authDomain: "XXXXXXXXXX.firebaseapp.com",
 databaseURL: "https://XXXXXXXXXX.firebaseio.com",
 projectId: "XXXXXXXXXX",
 storageBucket: "XXXXXXXXXX.appspot.com",
 messagingSenderId: "XXXXXXXXXX"
};
firebase.initializeApp(config);

var messaging = firebase.messaging();

如果推播裡要放公司的 Logo，那 Logo 的圖檔就要寫進快取檔案的清單裡，到時推播才有圖檔可以顯示。

註冊 sw.js、存 Cookies、存 Firebase

如果拿到的 token 不存在 Cookies 裡，用 Cookies 判斷是否拿過 token，那使用者就會存到 2 組以上的 token，在發推播時，就會收到相同的訊息多次。

當然，如果使用者清除了快取，就會有別種情況發生，最好的方式還是讓使用者登入會員後，再取得 token，把 token 跟會員綁一起，就不會有奇奇怪怪的情形出現。

以下為 JS code：

fcm-web-push-get-token.js

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43


window.addEventListener('load', function() {
 if('serviceWorker' in navigator) {
 navigator.serviceWorker.register('/sw.js')
 .then(function(reg) {
 // firebase methods，用同一支sw.js
 messaging.useServiceWorker(reg);
 })
 // 註冊失敗
 .catch(function(err) {
 console.log('error: ', err);
 });
 }

 messaging.requestPermission().then(function() {

 // 先判斷cookies有沒有token，沒有再取token
 var ckv = document.cookie.replace(/(?:(?:^|.*;\\s*)augustusWsPush\s*\=\s*([^;]*).*$)|^.*$/, "$1") || null;

 // cookies不存在，跟使用者要求通知權限
 if(ckv === null) {
 // 拿到token，firebase-messaging-sw.js 就會存 Service Workers 裡
 messaging.getToken().then(function(currentToken) {

 // token存至firebase
 var id = currentToken.split(':')[0];
 firebase.database().ref('pushUsers/' + id).set({'token': currentToken});

 // token存至cookies
 document.cookie = "augustusWsPush=" + currentToken;

 });
 }
 // cookies 已存在，從 cookies 取出後傳至 firebase
 else {
 var id = ckv.split(':')[0];
 firebase.database().ref('pushUsers/' + id).set({'token': ckv});
 }

 }).catch(function(err) {
 console.log('使用者未允許通知', err);
 });

});

裡面有一行很重要：

1

messaging.useServiceWorker(xxx);

這是這次踩到的坑。

如果沒寫這行，就會發現網站存了 2 個 service worker，分別是 Firebase 的，以及我們自己的。這行可以讓 FCM 只存我們註冊的 sw.js，才可以在用 FCM 推播時，順利的執行推播及點擊後開啟指定的頁面。

成功的話，開啟 index.html，在開發人員工具的 Application → Service Workers，就會看見註冊了 sw.js 檔案：

註冊 sw.js 只能在 https 下，因此網域必須有S SL，不然會註冊失敗。

1

messaging.requestPermission()

這行會跟使用者要允許通知，使用者按下允許後

1

messaging.requestPermission()

這行就會產生 FCM 的 token，之後就是存進 Firebase 跟 Cookies。
Firebase 上會看到以下：

之後只要跑個迴圈，就可以一個個去發送 Web Push。

發送 Web Push

這邊新增一個 admin.html 來當做發送 Web Push 的後台介面，直接用 Vue.js 抓每個 input 的值。

Web Push 如果要判斷成效，直接用 Google Analytics 的 utm 參數就可以了，所以後台欄位有給 utm 用的 3 個主要參數。
不含樣式的原始碼文末會附上 GitHub 網址。
在發送 Web Push 時，還要填入伺服器的金鑰，這也是從 Firebase 後台可以拿到。點小齒輪 → 專案設定 → Cloud Messaging，第一個「伺服器金鑰」的值就是了：

發送 Web Push 的 JS 如下，寫在 admin.html 裡：

fcm-web-push-trigger.js

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


var notification = {
 'title': 'web push標題',
 'body': 'web push內文',
 'badge': 'logo圖檔路徑',
 'icon': 'logo圖檔路徑',
 'click_action': 'https://www.domain.com.tw',
 'data': {
 'url': 'https://www.domain.com.tw'
 }
};

fetch('https://fcm.googleapis.com/fcm/send', {
 'method': 'POST',
 'headers': {
 'Authorization': 'key=從firebase上取得伺服器金鑰',
 'Content-Type': 'application/json'
 },
 'body': JSON.stringify({
 'data': notification,
 'to': '使用者的token',
 })
}).then(function(response) {
 console.log(response);
}).catch(function(error) {
 alert(error);
});

接收 Web Push

接受 Web Push 有 2 種情況：

使用者正開啟官網頁面
使用者沒有開啟官網頁面

第一種情況，是在 index.js 下寫一個 messaging.onMessage 的 function 處理。
第二種情況，是在 sw.js 下寫一個 messaging.setBackgroundMessageHandler 的 function 處理。

使用者正開啟官網頁面

官網正開啟的狀況下，屬於 JS 的 notification 功能，function 範例如下：

fcm-web-push-notification.js

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


messaging.onMessage(function(payload) {
 var msgTitle = payload.data.title;
 var url = payload.data.click_action;
 var notification = new Notification(msgTitle, payload.data);

 // 點擊推播後要連去哪
 notification.addEventListener('click', function() {
 e.preventDefault();
 location.href = url;
 });
});

payload 就是傳來的值，點擊後要導到的頁面就用 location.href 來處理。

使用者沒有開啟官網頁面

使用者在上網，但沒有開啟官網的頁面，就是由之前註冊的 sw.js 處理，在 sw.js 加入以下：

fcm-web-push-sw2.js

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


var click_action;

// 監聽notifiction點擊事件
self.addEventListener('notificationclick', function(event) {
 var url = click_action;
 event.notification.close();
 event.waitUntil(
 clients.matchAll({
 type: 'window'
 }).then(windowClients => {
 // 如果tab是開著的，就 focus 這個tab
 for (var i = 0; i < windowClients.length; i++) {
 var client = windowClients[i];
 if(client.url === url && 'focus' in client) {
 return client.focus();
 }
 }
 // 如果沒有，就新增tab
 if(clients.openWindow) {
 return clients.openWindow(click_action);
 }
 })
 );
});

// FCM
messaging.setBackgroundMessageHandler(function(payload) {
 var data = payload.data;
 var title = data.title;
 var options = {
 body: data.body,
 icon: '/logo/logo192.png',
 badge: '/logo/logo192.png'
 };
 click_action = data.click_action;

 return self.registration.showNotification(title, options);
});

click_action 是點擊後要開啟的頁面網址，但要另外寫一個 notificationclick 來處理。

這邊踩了一個坑，如果按照一般順序來寫，會先寫了 messaging.setBackgroundMessageHandler 後，再寫 notificationclick。然後就會發現，Chrome 上可以正常運作，但在 Firefox 上怎麼點就是不會開啟頁面。

Google 了很久，才看到這篇：service worker notificationclick event doesn’t focus or open my website in tab

click_action 是 Chrome 用的，如果 messaging.setBackgroundMessageHandler 先寫了，那 FCM 就會全部接收 Web Push 的功能，就不會讓原生的 notificationclick 事件被運作，因此 notificationclick 得寫在前，讓原生事件運作後，再執行 FCM 的事件。

補充資源

有了發送、接收，基本上 Web Push 就可以順利運作了。
要注意的是 Web Push 只接受在 https 以下運行。
最後附上學習時參考的教學文，以及本篇的 GitHub 原始碼。

從建 Firebase 就開始教學的（英文）：Tutorial: Web Push notification using Firebase

建立 Service Worker Web Push Notification — (Firebase Push Notification實作紀錄)

Push Notification之成為訂閱用戶(Firebase實作)

Google 官方教學的原始碼：GitHub
Google 官方教學的功能示範：Notification Examples

SEO 反向連結建立：終極指南(2022)

Wed, 17 Aug 2022 00:00:00 +0000

本文翻譯自：LINK BUILDING FOR SEO:The Definitive Guide (2022)

這是一篇完整的 2022 年連結優化指南。
因此，如果你想要取得權威網站的反向連結。
你將會在這篇新指南中，享受本文可操作的技巧。
讓我們往深入其中吧。

第 1 章：連結優化基礎

在本章節，我將向你解答此問題：「什麼是連結建立？」

同時，我也會向你展現為何連結建立，在 2022 年的今天仍然很重要。

讓我們開始吧！

什麼是連結建立？

「連結建立」是一種打造單向超連結（又名反向連節），到另一個網站的方法。

希望藉此改善網站的搜尋引擎能見度。

常見的連結優化策略包含內容行銷、建立有用的工具、電子郵件推廣、破損連結優化與公共關係。

為什麼連結這麼重要？

若要理解它，你將需要跳上時光機，並重返早期網路時代的 Google 。

在過去的日子，搜尋引擎如 Yahoo！與 Alta Vista 是主要支配者。

他們排序搜尋結果的方式，100% 是基於網頁上的內容

輸入：Google

現今他們知名的 PageRank 演算法改變了這場遊戲。

Google 不是單純分析網頁的內容，而是查看有多少人連結到該頁面。

而他們是正確的。

在接近 20 年以後，連結仍然是衡量網頁品質的最好方法。

這就是為何 Google 仍然將反向連節視為排名的信號之一。

此外，由於企鵝演萬法的更新，Google 現在專注在連結的品質（而非連結數量）

你可能會疑惑：

什麼是高品質的連結，具體是什麼？我又該如何打造他們？

這就是我要在下一個章節涵蓋的內容。

繼續往下看…

第 2 章：如何找到高品質的連結

在我們深入連結優化的逐步策略前，知道什麼是好（或壞）連結很重要。

這樣，你可以專注在優化能改善 Google 排名的連結。

因此，以下是如何辨認值得優化連結的方法：

頁面權重

請問與你連結的那個網頁，在 PageRank 中是不是個有力人士？

如果是的話，那將會讓你的排名擁有一個巨大的影響。

事實上，從多年的測試中，我已經發現頁面權重的傳遞，將比任何其他因素更重要。

這是因為來自一個權威性頁面的連結，將提供更多權重值（又被稱為 PageRank）給你的網站。

（筆記：雖然 Google 並沒有公開分享關於 PageRank 的資訊，他們仍然將其視為演算法的基礎）

你可以使用 Semrush ，輕易的察看 PageRank 的大約指標。

只要在 Semrush 填入網址，並查看「Page Authority Score」數值。

網站權重

一個連結的品質，同樣受到該網域的「網站權重」決定。

普遍上來說，一個來自紐約時報的連結，將會比來自一個無名氣部落格的連結，產生還要大的影響力。

雖然這些連結很難取得，但它們仍然值得爭取。

同理，Semrush 一樣能派上用場。

在工具中輸入網域名稱，並查看它的「Authority Score」數值。

網站相關性

當我們提到連結，一個網站的權重很重要。

但該網站的關聯性同樣重要。

舉例來說，假設你經營一個關於「原始人減肥法」的網站。

你想要從一個權威性的網站取得連結….像是單輪車，這樣的連結仍算數嗎？

根據一位前 Googler 的訪談內容，結果顯示並非如此。

:::info

「從一個高 PageRank 頁面取得的連結，在過去通常很有價值。」

「如今，演算法更注重該網站與你內容的關聯性。」

「關聯性是新的 PageRank」

:::

大致上，你會想要從具權威性的網站取得連結，特別是該網站與你的內容，擁有相近的關聯。

頁面上連結的位置

請問你的連結，是否內嵌在部分內容中嗎？

或是埋在網頁的頁尾？

事實證明，你的連結在頁面上的位置很重要。

特別是埋藏在頁首與測攔的連結，並不如頁面正文區塊的連結有價值。

網站底部呢？你會希望你的連結出現在網頁的主要區塊。

連結是否由編輯方式放上的？

不論你的連結是否出現在網頁，你應該詢問自己：

「此連結是否由編輯方式放上去的？」

換句話說，是否有人將自己網站與你的網站連結，單純是因為他們認為你的網站很讚？

如果是的話，這就是一個編輯連結（editorial link）

或是你在一個隨機網站創造帳戶，並在那邊放下一個自己網站的反向連結？

這就不是編輯連結。

如你所料，Google 更加重視編輯連結。

:::info

引言自 Google

「以非編輯方式放上一個連結，或未經網站擁有人在網頁上的認證，又被稱為非自然連結。」

「它可以被視為違反我們的搜尋指南」

:::

連結錨點文字

錨點文字是一個可被點擊的文字連結區塊。

事實證明，Google 使用錨點文字作為排名訊號。

舉例來說，你取得一個連到你網站的錨點文字：原始人甜點

Google 看到該錨點文字，並說：

恩… 這個網站使用「原始人甜點」錨點文字，該連結導向的網頁一定是關於「原始人甜點」。

當然，如同其他 SEO 技巧，關鍵字豐富的錨點文字已經被濫用。

現今，建立一大堆準確描述的錨點文字，仍會被視為垃圾內容。

簡短來說，我不推薦透過關鍵字豐富的錨點文字，用以建立反向連結。

如果你是真的從錨點文字取得反向連結，還是值得慶祝。

連結共現

「共現」是指文字與片語共同出現在你的連結上。

Google 可能使用共線作為「子錨點文字」(baby anchor text)

如果你這樣思考，就能理解：

那些圍繞在連結上的文字，同樣提供該頁面的線索。

既然如此，Google 又有什麼理由何不去使用呢？

連結是否來自客作文章？

幾年前，Google 站出來說：

:::info

「有件事已經無法繼續下去了：客座文章已經結束，他已經變得太過低廉」

－Matt Cutts，前 Google 垃圾郵件團隊主管

:::

這是真的嗎？

恩…他取決於當下條件。

以下這一些紅旗舉動，會使客座文章變得沒有價值。

某人付費刊登文章
文章包含完全比對的錨點文字
該網站只為了發布客座文章單獨存在
該網站與你的網站不相關

但如果你在一個具權威性、關聯性的網站，發布一個令人驚艷的文章呢？

在我的經驗，該連結可以幫助你爭取排名

Nofollow vs Dofollow

「rel=“nofollow”」是一個連結標籤，用來告訴搜尋引擎：不要將此連結當成一個網站背書。

明顯地，當到了 SEO 領域，你會想要盡可能，取得一個正常「dofollow」連結。

現在，你可以知道如何衡量連結品質，是時候開始建立他們。

第 3 章：如何透過內容行銷，取得世界級的連結

內容是解鎖良好反向連結的關鍵，已經不是什麼秘密了。

但這樣說好了：

單純發布內容，並不會讓你取得任何連結。

事實證明，特定類型的內容最適合取得反向連結。

以下是四種內容類型，幫助你產生更多連結：

一、視覺資產

它是什麼

視覺資產是：

圖片
圖表
資訊圖
視覺導向的內容與圖表

它為什麼有用

視覺內容超級容易取得連結。

舉例來說，當你發布一個圖片在你的網站，任何人在他們的網站分享此圖，當會讓你取得反向連結。

這個強大的「當你分享我的圖片，請連結我的網站」關係，並不作用於任何文字基礎的內容。

實際例子

幾年前我在自己的網站，發布了一個關於 Google 點擊率的圖表。

直到現今，此圖已經被連結數十次（許多來自行銷領域的權威網站）

確實，即使我使用表格呈現，仍可能取得這些連結。

但這些連結的建立，有大部一部分（我預估 75%）是因為我以視覺方式呈現。

事實上，我的許多連結，來自人們直接將我的視覺圖表，張貼到他們的網站上（並作為來源連回我的網站）。

有趣的事，直到 2022 年的今天，每個月人們仍然連結此圖。

這就是創造視覺圖表的強大之處。

二、列點文章

它是什麼

一系列的方法、技術、原因、迷思或關於任何事情。

它為什麼有用

列點文章將大量的價值，包裝成一份份可一口咬下的內容。

事實上，當 BuzzSumo 分析一百萬篇文章時，他們發現這些列點文章，相較於其他形式的內容，產生更多反向連節。

它勝過測驗、影片，甚至是資訊化圖表。

實際例子

《2022 最新的 19 個 SEO 技巧》這個列表文章，是我最熱門的一個內容。

沒錯，它產生一大堆分享…

以及留言

但最重要的是，此貼文是一個連結磁鐵。

它擁有超過 4,000 條連結。

也因為此文章，擁有這麼多連結指向它，它取得關鍵字「SEO Techniques」的前 5 名。

三、原創的研究與數據

它是什麼

從產業報告、調查或原創研究中，揭露最新數據的內容。

它為什麼有用

研究與數據具有高度可連結性。

當某人引用你的數據，它會與你連結，這些連結增加得非常快。

實際例子

前些日子，我發布一篇大型 Google 排名因素調查。

不用說，此貼文滿載了大量原始數據。

這就是為什麼此貼文至今，可以累計 18,900 則反向連節，這個驚人的數字。

如我上述提及，這些連結大多數來自人們引用我們的研究：

四、深度完整的指南

它是什麼

一個關於某主題綜合性資源，其中包含所需要知道的一切事物。

它為什麼有用

終極指南將驚人數量的資訊集中在一處，並使你的指南，成為該資源的首選。

實際例子

我曾經從 email 收到人們詢問我，關於每日關鍵字研究的基本概念。

很不幸地，關於這個非常重要的主題，那時在我的部落格中，並沒有任何內容。

因此，我創造了一個：《SEO 關鍵字研究：終極指南》

因為這個多章節的指南，涵蓋了其他網路資源沒有的內容。

它已經被連結超過 37,700 次。

現在，你已經創造出一些值得連結的內容，是時候打造一些連結。

如何做？

透過非常經典的電子郵件推廣。

第 4 章：如何透過電子郵件推廣，打造強而有力的連結

如果你想要在 2022 年打造白帽連結，你需要使用電子郵件推廣。

問題是：

你的信件如何與部落客與記者們聯繫上，而非被丟進垃圾信件的資料夾中。

閱讀本章節，找出方法。

步驟一：找到「可能連結者」

如同名稱所述，可能連結者是一群可能會連結你網站的人。

我將會在第 6 章，向你展項找出「可能連結者」的一大堆技巧。

但現在，讓我們先使用簡單的策略，用來辨認出他們：反向工程。

首先，在 Google 搜尋你的關鍵字。

在第一頁搜尋結果頁，挑選一個網站連結，並放進連結分析工具（我使用Semrush 為例）

接著，點擊側攔的「反向連節分析」，再點「反向連節」。

這個網站會在下方，條列出全部的可能連結者。

(你如何知道哪個網站值得鎖定、哪個網站要忽略？去查看第二章的內容)

步驟二：找到他們的電子郵件地址

現在，你已經找出可能連結者，是時候挖出他們的電子郵件地址。

:::danger

進階技巧：僅在不得已的情況下，才去使用網站的聯繫表單，因為那一個黑洞

:::

以下是執行步驟：

使用 Hunter.io

Hunter.io 非常適合用於聯繫小型網站與個人部落格。

單純在工具中輸入網站

接著，他將會向你展現，與該網域關聯的電子郵件地址。

但如果你想要接觸大型網站呢？梳理這份清單將會非常痛苦。

這就是為什麼，針對這些情境，我推薦 VoilaNorbert

VoilaNorbert

藉由 VoilaNorvert.com ，你只要輸入某人的名字與工作的網域，就能成功運作，而不需輸入網址。

這樣，你就能接觸到那些可能連結者，並讓他們把你網站連結，放到他們頁面上的。

同時，它也會向你展現特定對象的電子郵件地址。

步驟三：寄給他們一個客製化的內容

如果你想使電子郵件推廣規模化，你將會需要使用模板。

使用模板的技巧在於，不要讓你的模板看起來像模板（下個步驟會解釋更多細節）

但現在，以下是我執行最好的電子郵件模板之一

:::info

嗨（名稱）。

我今天正尋找關於（某主題）的內容，偶然發現你的文章：（文章標題）

我發現它的內容非常好！其中，我特別喜歡（他們文章的特定內容）。

此外，我最近也在（你的主題）發布了一個新指南：（網址）。

作為一位在撰寫關於（某主題）的人，我認為你也會喜歡它。

我的指南同樣可能，成為你網頁上的一個不錯的延伸閱讀。

不論如何，希望你繼續在（對方網站）提供精彩的作品。

有空再聊。

:::

注意到這個範本，內含了許多客製化的資訊，卻不需花費許多力氣。

第 5 章：黑帽連結優化的真實情況

如果沒有關於黑帽 SEO 的章節，任何連結優化的指南都不完整。

黑帽連結優化非常容易被發現：

如果取得反向連節的方法，與 Google 的網站指南違背，它大概就是黑帽。

這就表示，你應該避免使用黑帽優化連結嗎？

這個選擇取決於你。

我個人不建議使用黑帽優化連結（風險與回報不成比例）。

話雖如此，不論你是一位白帽或黑帽 SEO，你都需要知道 Google 給予黑帽的懲罰。

因此，我們簡單統整它們：

Google 企鵝

它是什麼：

一個懲罰演算法，用來針對使用垃圾連結建立權重的特定網站。

例如，可疑的客座文章或文章留言處的垃圾訊息。

如何避免它：

只有建立白帽連結能避免。

有數據顯示，你可以藉由最小化完全匹克錨點文字，用以躲避企鵝演算法。

(我說過錨點文字是另一個內容了，但它的關鍵在於信任)

換句話說，躲避企鵝演算法最簡單的方式，就是避免使用可疑的連結（或錨點文字）

手動懲罰與非自然連結

它是什麼：

一位來自 Google 公司員工的手動懲罰。

它與企鵝演算法不同，Google 將會藉由 Google Search Console 寄給妳一封訊息。

如何避免它：

除了 Google 以外，沒人知道自己的網站為什麼被手動懲罰。

我的看法是有某個演算法，指出一個網站正在玩弄系統。

因此，他們將網站過濾出來並做手動檢驗。

可知，最好的避免方式是擁有一個非常乾淨的反向連結檔案。

此外，不像企鵝演算法，你可以透過「禁止連結指向網站」與「申請重新審查」從手動懲罰中恢復。

第 6 章：我最喜歡的 3 個連結優化策略（按步驟教學）

本章節不需要前言。

以下是我用實戰經驗驗證，取得世界級反向連結的 3 個策略。

資源頁面連結優化

首先，什麼是資源頁面？

資源頁面是指在特定主題中，整合擁有良好內容的連結。

以下是範例：

因為這些頁面存在的原因，是將使用者導向適合的地方。

因此，這是個絕佳的連結建立策略。

以下是具體步驟：

步驟 1：找到資源頁面

在 Google 使用這些搜尋字詞。

他們是專門設計用來挖掘資源頁面：

關鍵字 + inurl:links
關鍵字 + 「有幫助的資源」
關鍵字 + 「有用的資源」
關鍵字 + 「有用的連結」

步驟 2：檢視該頁面

以下是你需快速回答的問題：

「來自這個網頁的連結，值得努力爭取嗎？」

（提醒：使用第 2 章的技巧簡化此步驟）

舉例來說，這個資源頁擁有一個體面的 URL 分數：12，還不錯。

它同樣擁有一個具權威性的網站。

而我的連結，最後將會在此網頁的主體區塊，如同勝利者般。

步驟 3：找到最符合的內容

注意：

你可能擁有是世界上最好的內容，但如果它與資源頁的主題不相搭呢？

你將不會取得該連結。

因此此步驟的目的，是要找出與你內容相符的資源頁面。

依但你識別出內容，跳至第四步驟

步驟 4：寄送此封經測試的模板

以下是我建議的模板：

:::info

標題：關於（對方網站）的問題

–

嗨（名字）。

今早，我在 Google 搜尋關於（主題）的內容時，看到你的優質資源頁：（網址）

我只是想要跟你說：你的網頁幫了我很大的忙。

如果沒有此網頁，我將永遠不會找到（該網站連結的資源）。

有趣的事：我上個月剛發布了一個關於（主題）的指南，它是（簡短摘要）。

如果你想查看該內容，以下是連結：（）

此外，我的指南也可能是適合添加到你的網頁。

不論如何，謝謝你將相關資源條列整理。

祝你有個美好的一天！

期待回復。

（你的名字）

:::

:::danger

如同所有外部接觸的模板，確保此模板盡可能客製化。

你可以使用一個「看起來一點都不像模板」的模板。

:::

破損連結優化

「破損連結優化」一直是我最喜歡的優化策略。

為什麼？

透過破損連結優化，你可以替某人的網站提高價值，而非直接請求連結。

以下是執行步驟：

1. 安裝 Check My Links 或 LinkMiner

上述兩者工具，都能快速找到任何網頁的破損連結（透過你的 Chrome 瀏覽器）。

我將會在接下幾分鐘，線你展示如何使用它們。

2. 找到擁有許多外部連結的頁面

一個網頁越多連結，他們之中越有可能會產生破損連結。

資源頁非常適用於此情況。

因此，請盡情使用上文的搜尋字串，找出相應的資源頁。

4. 查看破損連結

以下，是你執行在步驟一安裝的外掛的地方。

它將會透漏該頁面的破損連結：

4. 寄送郵件給該網站管理員，告知關於破損連結的事情

最後，讓經營該網頁的人，知道該頁的破損連結，並作為交換，讓對方連結你的網站。

以下是我建議的模板：

:::info

標題：（對方網站名稱）的問題

–

你好(姓名)，請問你還有再更新你的網站嗎？

我在搜尋（主題）的內容時，發現你絕佳的網頁：（網頁標題或網址）

然而，我發現有幾則連結是否已失效：

（破損連結的網址）

此外，我最近發布（簡短的內容描述）。

它可能適合取代（指出特定的破損連結）。

不論如何，希望這有幫助到你。

謝謝

（你的名字）

:::

摩天大樓技術

這部影片將手把手，帶你走過全部流程。

{%youtube 263xIymvLl4 %}

一旦你觀看完此影片，就是時候進入下一章節：

非常棒的連結優化案例研究！

第 7 章：驚人的案例研究

現在，是時候向你展現連結優化實際的例子。

最棒的部分是，我之前從來沒有分享過這些內容。

案例一

Julie 如何使用摩天大樓技巧，增加 194.1% 的自然搜尋流量

Julie Adams 的部落格：我們美麗的星球，曾經非常掙扎。

確實，Julie　曾發布許多良好的內容，單在她的言詞中表示：不論我的內容有多棒，都沒有任何反向連結。

這就是她決定使用「摩天大樓技術」的時機點。

因此，她不再只是單純發布另一個良好內容，而是創造出驚人的事物。

以下是例子：

她使用電子郵件推廣去創立反向連結，而非單純創造好內容並等待被推廣。

這使她取得從自然領域的權威網站，取得滿手的連結。

這些白帽反向連結，使她自然搜尋增加了 194%。

為何「摩天大樓技術」運作得如此良好？

:::info

根據 Julie 所說：

「讓這件事如此成功的原因，在於建立反向連節就像與他人建立關係。」

「人們在知道你的網站存在前，不會連結你的內容。」

「此外，在你主動告訴他們以前，也不會知道你的網站存在。」

:::

說的非常好。

案例二

破損連結優化的回報

去年，我決定執行破損連結優化的行銷活動。

因此，我遵循在上一章節的流程。

首先，我使用搜尋字串，以找出含有許多外部連結的網頁。

接著，我使用 Check My Links 找出破損的連結。

之後，我寄信給負責該內容的人，並表示自己有發現的破損連結存在。

（仔細查看該信件有多麼客製化）

收到對方的回應後，我寄給他們那些失效的連結，以及來自 Backlinko 的一大堆內容，用以進行 1:1 替換。

而大多數的夥伴，都非常樂意增添我的連結：

案例三

Matt 如何優化它的電子商務連結

讓我們面對一個事實：

建立反向連結，對電商網站來說並不容易。

但他仍有可能，就如同 Matt Lawry 一樣。

如同多數電商網站擁有者，Matt 對於建立他電商網站的連結有麻煩（一個專注在禮物的澳洲網站）

畢竟，有誰想要連結到一個 100% 產品導向的頁面。

這讓 Matt 了解到，它可以使用內容為網站創造反向連結。

具體來說，Matt 在它的網站創造一篇「摩天大樓」內容：《澳洲琴酒：終極指南》

當然，Matt 並沒有坐下來並等待連結累積。

他透過電子郵件，主動推廣自己的內容。

因為 Matt 聯繫上正確的人（並寄給他們客製化的電子郵件），許多人願意提供連接給他的指南。

這些連結都加強了 Matt 的電商網站，在搜尋結果頁想要爭取的關鍵字：澳洲琴酒。

第 8 章：進階連結優化技巧

以下清單，是我為了挑選這幾年，一些進階連結優化的技巧。

從「連結回收」輕鬆取得反向連結

每當有人在文章中提及你的品牌，他們都會連結你對吧？

錯。

我的意思指，他們「應該」連結你，但並非總是會發生。

以下是我想表達的意思：

但藉由輕推一把，多數網站擁有人都非常樂意，將提及你的部分轉成一個連結。

你要如何發現些未含連結的提及呢？BuzzSumo 效果非常好。

透過反向圖片搜尋，取得「額外」連結

請問你是否發布視覺資產（如資訊圖表、示意圖）？

如果有，那現在可能有某些網站正使用你的圖片，卻沒有註明來源。

不要嚇到。事實上，你應該慶祝。

如同連結重新取得，一封友善的郵件可以將這些機會轉成連結。

你可以使用 Google 以圖搜尋，找到那些使用你圖片，卻沒有添加連結的人們 :

在下午寄送電子郵件

以下是我寄送上千封電子郵件後，從中學到的事情。

在下午（收件者本地時間）寄送你的推廣電子郵件。

為什麼？

當你在早上寄送你的訊息，它將會被收件者，與其他 93 封訊息混在一起處理。

但當你在下午寄送電子，收件夾就會少掉許多競爭者。

我推薦 Gmail 內建的時間排成功能，幫你規畫推廣信發送時間。

創造視覺化的概念、點子與策略

以下是來自 Backlinko 實際的作為：

不管你相不相信，許多人都因為這張簡單片與我連結：

為何它如此有效？

恩…我可以單純透過文字描述 APP 攻勢，但這將使我的內容比較不容易分享。

另一方面，當你創造一個視覺圖像，你將會擁有部落客樂於分享的內容（並連結你的網站）。

在結束前寄送試探郵件

你應該在第一封電子郵件推廣中，要求對方提供反向連結嗎？

簡短回答：可能可以。

你也可以透過兩階段流程，取得更好的結果。

（Backlinko 讀者 Mike 發現測試郵件的成效，輾壓直接要求連結的方式）

這個方法的另一個好處，可以減少你花費的時間。

與其花費時間，客製化一封沒人閱讀的訊息，先寄送簡短試探郵件更好。

之後，再針對你下一則訊息進行客製化。

獲得 Podcast 的訪談

沒錯，客座文章有他的重要地位存在

但有一個大問題：它需要花費很多時間撰寫！

進入　Podcast　的世界。

與其花費時間撰寫大綱、擬草稿、修改客座文章，不如單純出現在 Podcast 節目，並談論你所知道的內容。

蹦！你就取得了反向連結。

最好的地方是什麼？

每個領域都有 Podcast 節目。

以下反向連節，就是我出現在 Podcast 後建立的。

使用「連結交集」找出可能連結者

如果某人連結給你的競爭者，他們可能也會提供連結給你對吧？

沒錯。

如果某人連結你的 2 位競爭者，他甚至更有可能提供連結給你。

你如何找到這些，連結超過 1 位以上競爭者的網站。

Semrush Backlink Gap tool

只要列出 2 到 3 位你最大的網站競爭者。

這個絕佳的工具，將會向你顯示哪些人與他們連結。

使用「預先策畫」的連結目標清單

不能否認：找到高品質的反向連結非常困難。

這是個壞消息。

好消息是，有些人已經為你預先策畫好，這些高品質的網站…

…以「最佳部落格」清單的形式。

以下是範例：

更不用說，如果你再經營一個烘焙部落格，每一個網站清單的頁面，都將會是一個反向連結的好機會。

你可以透過以下搜尋字詞，找到這些清單：

最好的「主題」部落格
「主題」部落格清單。

結論

以上這就是我的 2022 連結優化指南。

從今天的指南中，你最想要優先嘗試哪個策略呢？或你對於某件事有疑問。

不論如何，在底下留言讓我知道。

SEO on Wayne's blog | 偉恩的部落格 | 技術博客

將網頁變成Progressive Web Application(PWA)，漸進式的網頁應用程式

將網頁變成Progressive Web Application(PWA)

Step1：下載 Chrome 擴充套件

Step2：檢查網頁

Step3：建立 manifest.json

manifest.json

Step4：html 加入 manifest.json

Step5：打開開發人員工具檢查 manifest.json 的設定

Step6：加入 serviceWorker 語法

Step7：建立 service-worker.js 檔案

service-worker.js

Step8：確認 Service Workers 是否正常

Step9：安裝「頁面」

Step10：安裝

manifest.json 介紹

manifest.json是做什麼用的？

manifest.json 成員

theme_color

background_color

icons

name

short_name

lang

description

dir

display

orientation

prefer_related_applications

related_applications

start_url

scope

manifest.json 基本檔案內容

manifest.json

關於「Chrome 主動提示加入主畫面」

manifest 觀摩

Service Worker 介紹

sw.js

Add to home screen banner

用 Firebase 做 Web Push

用到的資源

取得 FCM 金鑰

新增 manifest.json、Firebase Config

manifest.json

Firebase Config

fcm-web-push-firebase-config.html

取得使用者的 token

新增 sw.js

fcm-web-push-sw1.js

註冊 sw.js、存 Cookies、存 Firebase

fcm-web-push-get-token.js

發送 Web Push

fcm-web-push-trigger.js

接收 Web Push

使用者正開啟官網頁面

fcm-web-push-notification.js

使用者沒有開啟官網頁面

fcm-web-push-sw2.js

補充資源

SEO 反向連結建立：終極指南(2022)

第 1 章：連結優化基礎

什麼是連結建立？

為什麼連結這麼重要？

第 2 章：如何找到高品質的連結

頁面權重

網站權重

網站相關性

頁面上連結的位置

連結是否由編輯方式放上的？

連結錨點文字

連結共現

連結是否來自客作文章？

Nofollow vs Dofollow

第 3 章：如何透過內容行銷，取得世界級的連結

一、視覺資產

它是什麼

它為什麼有用

實際例子

二、列點文章

它是什麼

Step6：加入 `serviceWorker` 語法

Step7：建立 `service-worker.js` 檔案