AMP 已死？現代網站有必要做 AMP 嗎？
#1 AMP 是什麼？
AMP（Accelerated Mobile Pages）顧名思義就是加速手機頁面的意思，這是由 Google 在 2015 年領導的一個開源專案計畫，目標是要解決當時期手機蓬勃發展，但多數網站過於肥大，導致使用手機瀏覽網頁速度極慢，用戶不舒服的問題。
從 2010 年開始，智慧型手機的使用率爆炸性的成長，但環境上網路仍在 3G 與 4G 交界期，如果手機沒有連上 WIFI，上網速度只能用感人形容，這讓用戶感到很不舒服，在這樣的大環境下，AMP 網頁的概念因此問世，其基本邏輯非常直觀：減少一切可刪減的資料來讓手機用戶提升網站使用速度。
#1-1 AMP 的開發方式與流行原因：
具體來說，AMP 最大的規則有兩條：
- CSS 檔案限制最大為 50KB，且不得使用任何外部 CSS。
- Javascrip 限制只能使用 AMP 提供的元件，常見的 jQuery、AngularJS 等資料庫都不支援。
在當時期，這樣的限制能大幅解決手機瀏覽速度問題，因為減少在前端上程式碼讀取與轉譯的時間，將大幅降低所需要的網路頻寬，提高手機使用速度，並且 AMP 網頁只在手機上加載，並不會影響一般電腦網站的使用，對當時期的經營者來說，這麼做並不影響桌上型設備的用戶，卻能帶給手機用戶更好的體驗，是相當不錯的。
再加上，那個時期 Google 正在大力推行手機用戶體驗（當時支援 AMP 的網頁在 SERP 上會有閃電符號，這個標誌已在 2021 年被 Google 廢除），因此對支援 AMP 的網站提供更好的手機排名，導致網站開發人員、SEO 行銷人員等各方的大力支持，造就了 AMP 網頁的流行。
現在你依然可以用 Google 的檢測工具來看看網站是否支援 AMP：https://search.google.com/test/amp?hl=zh-TW
#2 AMP 網頁為什麼不流行了？
AMP 技術曾經是 Google 大力推行的方案，市場上也有許多廠商以這個解決方案為核心，但為什麼最近卻很少聽到了呢？其實我們不難想像，AMP 本來就是一個過渡產物，根本沒有長期發展的意義，因為：
- 整體網路速度會隨著時代不斷提升：現今手機能應付的網站早已不是 2015 年可以想像的狀況了，這讓 AMP 技術顯得相當雞肋。的確，採用 AMP 技術依然可以提升網站速度，讓用戶打開網頁更快，但過去是從 5 秒變成 1 秒，用戶體驗會提升非常多，現在只是從 1 秒變成 0.5 秒，對多數用戶是無感的。畢竟，所謂的網路速度其實就是要讓用戶覺得舒服而已，無限制地追求快速沒有太多意義。
- 我們多了許多可以加速網站的方法，而且這些方法並沒有 AMP 限制多，例如：網頁圖片採用 ＷebP 等新技術、使用 CDN 加速、更好的快取、更合理的伺服器部署方式⋯⋯，幾乎每個環節我們都多了許多可以提升速度的手段，沒有必要採用一個特別麻煩的框架。
- 為了速度犧牲用戶體驗，其實不是好選擇：為了符合 AMP 的技術標準，需要限制各種 CSS 與 Javascript 的使用，這導致許多有用的功能只能被移除，即便可以很快速的加載網頁，缺少了這些功能，對用戶真的有比較好嗎？
- 開發 AMP 的成本很高，嚴格來說 AMP 的開發並不困難，因為都是刪除法，但維護卻非常麻煩，因為新增任何功能都要多考量一種版型的問題，這導致使用 AMP 的潛在成本很高。
#2-1 Google 其實已經表明 AMP 對 SEO 的態度了！
許多行銷人員仍然有錯誤的印象，認為 AMP 可以改善 SEO 排名，我可以直接說：這是錯的！AMP 對 SEO 沒用！
Google 不只一次在文件中表明：AMP 並不是排名因素，網站速度才是！（就連 Google 的AMP 說明文件也有這一段。）
另外，Google 本身也已經不是很推崇 AMP 技術了，這一點可以從 Google 將 AMP 的閃電標誌移除就可以發現，其實他們只是維護這個技術，卻早已不是很重視。所以，如果你是為了行銷排名想要做 AMP，那可以直接放棄了，不用浪費這個時間。
不過這並不代表 Google 不重視手機速度，Google 在 2018 年推出的演算法 Mobile Speed Update 就將網頁速度列為影響手機搜尋結果排名的因素，你可以在：Google 演算法更新紀錄這篇文章了解更多。
#3 你需要做 AMP 網頁嗎？
雖然 AMP 網頁不再是 Google 提倡的開發方式，而且多數網站經營也確實不需要使用這個技術，但仍然有一些狀況，採用 AMP 是不錯的選擇：
- 內容知識型網站：如果你經營的網站主體以內容為主，不太需要複雜的互動技術，那麼採用 AMP 開發的確可以讓網站重心放在內容上，透過 AMP 不單是將用戶的焦點聚集，同時也讓維運人員聚焦在內容品質，算是不錯的選擇。
- 非營利的新聞媒體：與內容型網站類似，扣除新聞媒體需要呈現大量廣告的狀況之外，這些網站的本質依然是以內容為主，不太需要複雜的互動。
- 以 WordPress 架設的內容部落格：這裡講的並不是官網、購物網這類型的網站，而是專門撰寫內容的 WordPress 部落格，這是因為 WordPress 有許多 AMP 外掛可以使用，既然可以一鍵完成 AMP 部署，那也算是不錯的選擇，不過要特別注意，一旦採用 AMP 的外掛，很多原本的功能都可能失靈，最好在測試環境中反覆確認，才啟用相關外掛。
#3-1 不做 AMP 要怎麼做？
即便不使用 AMP 技術，提升手機用戶對網站的使用舒適度依然是重要的思維，這裡我們可以分成兩個環節討論：
#3-2 手機排版的觀念
透過 AMP 網頁不只是解決了速度問題，同時也解決了手機排版的問題，因此，若不使用 AMP 技術，我們還是需要解決手機排版的問題，在現代開發環境中比較常見的作法有以下幾種：
- RWD 響應式排版：針對畫面大小而改變每個元素所佔的空間，進而取得不同裝置合適的排版方式，這是當前最主流的開發方法，你正在瀏覽的 Procrustes 網站也是透過 RWD 響應式排版技術開發而成的。
- AWD 自適應網站設計：與 RWD 技術類似，差別在於 RWD 會將所有的 CSS 與 Javascript 資源同時載入，再去判斷當前使用者的裝置大小，而 AWD 網站則是會在載入資源之前先判斷裝置大小，然後才讀取資源，好處就是速度會比 RWD 網站更快（因為不用讀取到當前裝置大小所不需要的資源），而缺點就是開發難度遽升，需要更多維運的成本，代表的例子有：Amazon。
- 手機版網頁：這也是正在被淘汰的技術，方法其實很土炮，就是直接把手機版當作是另一個網站來開發，因此可以在手機版上呈現完全不同的資料，再透過 Meta Data 提醒 Google 等搜尋引擎哪個網頁是手機版哪個是桌機版，最容易判斷網站是否採用這種寫法的方式就是：手機版網頁的網址與電腦版的網址不相同，例如：電腦版：https://www.momoshop.com.tw/ 對比手機版：https://m.momoshop.com.tw/。
網站設計 | 英文全名 | 開發成本 | 載入速度 | 特點 |
RWD 響應式網站設計 | Responsive Web Design | 3 | 3 | 開發難度與提升使用者體驗的性價比最高。 |
AWD 自適應網站設計 | Adaptive Web Design | 2 | 3 | 與 RWD 類似，但開發端的差異讓 AWD 較適合大型網站。 |
AMP 加速行動版頁面 | Accelerated Mobile Pages | 4 | 1 | 單純為了優化網站載入速度的做法，但犧牲了許多網站視覺。 |
行動版網站 | Mobile Website | 1 | 2 | 最不建議的做法，等於另外做一個網站，會影響網站的 SEO。 |
如果想了解更多手機版網站開發的知識，歡迎參考這篇文章：RWD 網頁是什麼？響應式網頁的設計要點
#3-3 如何提升網站速度
即便當前的網路環境遠比以往更好，開發者還有搞砸的方法，想要把網站變得很慢很難用，是相當容易做到的！因此以下幾點是我建議要特別注意的，別被開發人員坑了：
圖片：pagespeed
- 選一個好點的伺服器：這是個很簡單的問題，伺服器等級越高，網站資料端處理的速度就越快，想好好經營網路生意，這個錢省不了的！我們並沒有特別推薦哪一家伺服器廠商（只要不是台灣的就好，不是因為不愛國，而是因為台灣的伺服器 CP 值真的太低了⋯⋯）。
- 養成壓縮圖片、影音的好習慣：媒體資源是影響網站速度的重大因素，我們還不需要談到進階的優化技巧，如：採用新型 WebP 格式、針對不同裝置改來源大小⋯⋯。光是「壓縮」就能大幅改善一個網站的速度，而且絕對是所有人都有能力做好的，我們強烈建議，上架任何圖片或影音之前，一定要進行壓縮！（圖片壓縮軟體有很多，我們自己最常用：Squoosh。）另外，如果行有餘力，可以讓工程師開發上傳時自動壓縮的程序，以及新型的圖片格式技術。
- 不要用不實際（ㄏ一,ㄏㄨㄚ）的插件與功能：開發網站時很多人都對酷炫的功能感到興趣，好像巴不得把所有會動的、會閃閃發光的東西塞到網站上，這些都不會改善你的生意，但會拖累你的網站速度，華而不實的網站是不會吸引用戶的，請大家慎重考慮。
- 選擇輕量的開發架構：這是要提醒工程師的，不要為了方便就採用笨重的架構，因為更換網站架構是極其痛苦的過程，最好能一開始就選擇輕量的，不用在考量後續更換。補充：如果你用 WordPress 作為 CMS 管理系統，就要在選擇主題時慎重考量「輕量」這個概念，好用的主題並不少，我們也可以推薦你適合的（Procrustes 採用 Astra 的 Spectra 開發），不過不好用的我這裡直說：千萬別用 Elementor，你會哭出來！
除了以上這幾個大要點之外，表格內的項目都是可以提升速度的方法，你也可以參考這篇文章來了解更多：網站速度優化教學，改善 SEO 排名的重要因素
| 項目 | 指標分類 | 解決人員 | 項目重要度 |
|---|---|---|---|
| 避免鏈結關鍵要求 | FCP, LCP | 一般操作人員 | 低 |
| User Timing 標記和測量結果 | 前端工程師 | 低 | |
| 降低要求數量並減少傳輸大小 | 前端工程師 | 中 | |
| 最大內容繪製元素 | LCP | 前端工程師 | 中 |
| 缺少包含 width 或 initial-scale 的 標記找不到任何 `` 標記 | TBT | 前端工程師 | 高 |
| 避免長時間在主要執行緒上執行的工作 | TBT | 前端工程師 | 中 |
| 排除禁止轉譯的資源 | FCP, LCP | 前端工程師 | 高 |
| 使用合適的圖片大小 | 一般操作人員 | 高 | |
| 延後載入畫面外圖片 | 前端工程師 | 高 | |
| 壓縮 CSS | FCP, LCP | 前端工程師 | 中 |
| 壓縮 JavaScript | FCP, LCP | 前端工程師 | 中 |
| 減少無用的 CSS | FCP, LCP | 前端工程師 | 中 |
| 圖片編碼有效率 （壓縮圖片） | 一般操作人員 | 高 | |
| 提供 next-gen 格式的圖片 | 後端工程師 | 高 | |
| 啟用文字壓縮 | FCP, LCP | 伺服器管理者 | 中 |
| 預先連上必要來源 | FCP, LCP | 前端工程師 | 低 |
| 初始伺服器回應時間很短 | FCP, LCP | 伺服器管理者 | 高 |
| 避免進行多次頁面重新導向 | FCP, LCP | 前端工程師 | 高 |
| 預先載入重要要求 | FCP, LCP | 前端工程師 | 中 |
| 使用影片格式的動畫內容 | LCP | 一般操作人員 | 中 |
| 請移除 JavaScript 套件中重複的模組 | TBT | 前端工程師 | 低 |
| 避免將舊版 JavaScript 提供給新型瀏覽器 | TBT | 前端工程師 | 中 |
| 預先載入最大內容繪製圖片 | LCP | 前端工程師 | 中 |
| 避免耗用大量網路資源 | LCP | 前端工程師 | 中 |
| 使用有效的快取政策處理靜態資產 | 伺服器管理者 | 高 | |
| 避免 DOM 過大 | TBT | 後端工程師 | 高 |
| JavaScript 執行時間 | TBT | 前端工程師 | 中 |
| 將主要執行緒的工作降到最低 | TBT | 前、後端工程師 | 高 |
| 載入網站字型時沒有任何文字消失 | FCP, LCP | 前端工程師 | 低 |
| 盡量減少第三方程式碼的使用量 | TBT | 前、後端工程師 | 高 |
| 使用門面元件延遲載入第三方資源 | TBT | 前、後端工程師 | 中 |
| 未延遲載入最大內容繪製圖片 | LCP | 前端工程師 | 低 |
| 避免大量版面配置轉移 | CLS | 前端工程師 | 高 |
| 使用被動事件監聽器來提升捲動效能 | 前端工程師 | 低 | |
| 避免使用 document.write() | 前端工程師 | 中 | |
| 避免使用非合成的動畫 | CLS | 前端工程師 | 中 |
| 圖片元素具有明確的 width 和 height | CLS | 前端工程師 | 中 |
#4 結論：AMP 技術的未來
我得坦白說，我認為 AMP 技術是沒有未來的，這個過渡產品是時候被時代淘汰了，與其挖空心思要開發 AMP 網站，還不如把其他優化速度的方法做好（或者採用 AWD 技術來改善基礎框架），然後好好經營內容與使用者體驗。
如果想要提升 SEO 排名，多得是比採用 AMP 更重要的事情，例如：關鍵字規劃、內容加強、內外連加強⋯⋯，不要浪費時間在這個技術上了。（不過弔詭（好笑）的是，我花了時間寫一個過時技術的文章、而你花了時間閱讀它，就讓這篇文章成為 AMP 的墓誌銘吧～）
#4-1 AMP 技術常見問題總結
