Nginx的PageSpeed安裝失敗記錄 / Install NGINX PageSpeed Module failed
結論是放棄了。
NGINX作為暫存伺服器 / NGINX as a cache server
(圖片來源：NGINX)
反向代理伺服器(reverse proxy)一直是NGINX的一種主要用法。有一臺好用的反向代理伺服器，不僅可以減少後端伺服器(backend)被攻擊的機會，還能藉由暫存、壓縮等機制提升網頁服務的效率。
https://shazi.info/nginx-%E5%B0%88%E6%B3%A8%E6%96%BC-cdn-%E7%9A%84-pagespeed-module/
後來我從MR. 沙先生寫的「Nginx 專注於 CDN 的 PageSpeed module」發現到Google有為NGINX推出PageSpeed模組，此模組後來轉移到Apache的孵化專案裡了。
PageSpeed模組 / PageSpeed Module
PageSpeed模組可以自動化地提升網頁服務的效率。根據過濾器的說明，它包括了：
- 快取機制最佳化：將JavaScript函式庫改為連線速度更快的伺服器(主要是Google伺服器)、擴大快取的檔案類型、使用HTML5的LocalStorage進行快取、將寫在HTML上的CSS跟JavaScript分離為另外的檔案(outline CSS and JavaScript)。
- 減少讀取時間：將多個CSS跟JS合併為一個、將JavaScript跟CSS寫入到HTML上(inline CSS and JavaScript)、合併圖片(Sprtie images，好懷念，我也做過耶)
- 降低請求開銷：主要是域名的調整。
- 縮小檔案：刪除多餘空格、縮小JavaScript跟CSS、縮短網址。
- 瀏覽體驗最佳化：延後載入圖片、將CSS移至開頭等等。
看起來PageSpeed模組做了很多一般會被認為網頁開發都應該要做的最佳化功能。如果我們能在NGINX安裝PageSpeed模組，讓它自動為後端伺服器完成這些最佳化處理，那就算不具備網頁最佳化知識的開發者也能作出適合的網頁了，不是嗎？
Docker
https://rupokify.com/tutorials/how-to-install-pagespeed-on-nginx-docker/
PageSpeed模組的安裝並不容易。它需要從NGINX原始碼搭配PageSpeed的檔案進行編譯。而為了編譯，我們還需要安裝很多必要的套件。
看到這裡，我就直接轉向找尋合適的Docker映像檔了。不過試了大概五個左右的Docker映像檔，結果都不盡理想。
https://stackoverflow.com/a/64205695
部分映像檔無法安裝我需要的NGINX Headers More模組。部分映像檔無法執行在/docker-entrypoint.d裡面的腳本，而這是NGNIX 1.19之後才有的功能。
手動安裝 / Install
https://www.modpagespeed.com/doc/build_ngx_pagespeed_from_source
Apache PageSpeed也提供了直接用指令安裝的方法。看起來用一行指令，執行一個腳本就可以了，但編譯到一半就卡住了，我也不確定是什麼原因。
仔細看下面的作業系統版本，它還在Ubuntu 12.05、CentOS 5。我才驚覺PageSpeed模組似乎很久沒有更新了。
https://www.modpagespeed.com/doc/release_notes
仔細一看，Googe PageSpeed是2010年提出的概念。目前最後釋出的版本是2020年七月的1.14.36.1，後來就沒有下文了。
https://www.ithome.com.tw/news/141582
附帶一提，CentOS也已經在2021年停止更新。最後的版本是CentOS Linux 8而已。在這裡看到CentOS 5，真有種年代感。
反思 / Do I need the PageSpeed Module?
Docker不行、手動安裝也不行，我打算放棄PageSpeed模組了。
不過這時候我才在思考，我真的需要PageSpeed模組嗎？
從PageSpeed的功能介紹來看，它的調整其實非常激進。被PageSpeed模組調整過的網頁，應該會跟開發者預想的結果有很大的差異。而近年來網頁技術還是有在不斷更新調整，瀏覽器的資安限制也有所變動，再加上使用者瀏覽網頁的載具越來越多元，這都使得「網頁最佳化」變得無比困難。
就我的經驗來說，以前我做過在發佈之前自動最小化(minify)與合併JavaScript跟CSS的工具，但效果非常差。先別說過大的程式碼會導致最小化效率變差，只要JavaScript或CSS有寫錯的地方，很容易就導致最小化過程失敗，最後也就無法發佈。
https://ithelp.ithome.com.tw/articles/10248245
後來改到了Vue跟Webpack陣營，Webpack的打包就比我自己做的好上非常多，再搭配Source Map功能，可以在確保壓縮效率的同時，能夠回頭查看原始碼的位置。開發起來真的流暢很多。然而，Webpack也是出了名的難以駕馭，並不是一位剛入門的開發者能夠輕易上手的程度。
這樣一想，既然連人都難以上手了，那還停在2020年的PageSpeed模組，能夠幫我做好那些Webpack能做的事情嗎？顯然是不能的。
https://serverfault.com/a/361802
除了PageSpeed模組之外，也有很多人嘗試用PHP或PERL來處理JavaScript和CSS的最小化。不過2012年的petermolnar的建議是，放棄最小化，改用gzip壓縮吧。
的確，也許單純的壓縮這些檔案，可能會比PageSpeed模組大刀闊斧地修改，還要更讓人安心吧。
最後是本篇的小問題：你有聽過哪些網頁最佳化的技術嗎？
歡迎下面留言喔！
