這個標題看起來很高級 XD。
優化，涉及到不同面向，例如空間，速度，安全性，外觀，功能性，乃至於移植性，可變性等等。
但筆者僅是整理一些搜尋到的優化的方法，並無新意。
而我們在前文章，安裝 NGINX，當中提到安裝 wordpress wp super cache 的外掛，便是存取速度的優化，在此主題下當然要提一下；請逕至參考，以下不再贅述。
因此，此關於優化的主題之內容將會持續追加。

網站測試之連結

• https://www.webpagetest.org/
• https://developers.google.com/speed/pagespeed/insights/
• https://www.ssllabs.com/ssltest/
• https://www.cloudways.com/blog/wordpress-stress-test/

使用 CDN

• 參考連結
  https://geekflare.com/free-cdn-list/
  https://www.cloudflare.com/zh-tw/
• 我們可以到 cloudflare 的官網看一下它的介紹，筆者就不再贅述（因為看不太懂 XD）
• 簡單講，使用者存取我們自己建立的網站網頁，一定就是連接到我們的實體主機或虛擬（雲端）主機。不過，網頁內容當中某些部份，是可以使用外部的 links 的。即，例如一些 images，videos，icons，css，scripts 都可以由 internet 上的其他 CDN 所提供。當然前提是這些內容是安全的，自由免費的或合法散佈的。
• 這最大的好處，便是可以分散我們的有限頻寬的佔用以容納更多實時使用者。並且既有的豐富資源可供取用。
• 最大的缺點是，萬一資料不再可觸及例如該網點掛了，移動了等等，那麼我們的網頁內容便有缺陷。並且無法自訂修改資料。及速度問題便非我們能預期的了。
• 接下來就可談到下一點，
  https://www.freeimages.com/tw
  此網站有大量的免費圖片可供使用。我們的 links 便可指向該處。
• 不過，還有一個更適切的地方存放 images，
  https://postimages.org/
• 當我們上傳一張 image 後（最好先經過轉換成適合 wordpress 適用的），它會産生如下的結果頁面
  

• 而圖片的網址，就是圖中的第二行，圖片鏈接。wordpress 的上傳圖片中的使用 URL，就是使用這個網址。
• 請務必記下來這個結果頁面網址；我們可以在此 wordpress 圖片的說明或備註欄中記錄下來這個網址，以供日後我們利用。
  題外話，若我經營這個網站，我會請使用者貼上引用者的網址，若該引用者不存在了，便可刪除此圖片以節省空間。
• 其他連結，例如向量圖片，tile patterns，textures 等等請自行搜尋。
  https://all-free-download.com/
  https://www.freepik.com/
  https://3dtextures.me/category/tiles/
  https://www.textures.com/
• 關於如何將 media files 轉移至並更新本地端連結，請參考此外掛。
  wp offload media lite
  https://deliciousbrains.com/wp-offload-media/doc/developer-guide/
  https://yungke.me/wp-offload-s3-lite-wordpress-media-library/
  https://www.webnots.com/move-wordpress-images-folder-to-subdomain/
  http://www.dezzain.com/wordpress-tutorials/how-to-move-wordpress-uploads-path-to-subdomain/
  https://wpmudev.com/blog/image-optimization-guide/
• 接下來，殺出了個程咬金，我們延伸這個話題，將 media files 放在雲端的話，我們評估一下花費。
  筆者看過了 google cloud，但真的是因為太強大，資訊太豐富，反而不得其門而入。使用者初試啼聲時關注的是各類雲端平台所提供的免費內容及付費內容。故我們拿 amazon s3 來評估。https://aws.amazon.com/tw/s3/
  

AWS S3

• 頁面內容不太難懂就不再贅述，而真不懂的，哈，很可能代表著我們也用不上。倒是先附帶一提，Lambda 是雲端應用程式運算，若有運算需求便可使用它並予以搭配 S3 的運算之需求儲存空間。
  雲端，所有可以分割獨立出來的資源，都是要計費的，不過更優的是全都有基本費免費。即，用超過才會開始計費。而上圖並不包含免費的計算，即，用超過才會如上計費。
• 假設，每分鐘有 20 個人正在存取網頁。
  註：在 media files 放在雲端的前提下我們可以擴展預估每秒鐘有 1 個人正在存取網頁，即 60 人 1 分鐘，網頁不會過慢才被讀取完成，當從我們的商業微型網站（瓶頸是上傳頻寬）。再論，我們可以向 ISP 加購上傳頻寬若有得買的話；不過，跟雲端相比，便懂取決。
• 那麼，20 x 60 x 24（多慮了，取 8）x 31 x 10（若每張網頁有 10 個 get requests to cloud）= 2976000
• 除非我們的網站真的很熱門，不然，放一百個心，筆者取 2 百萬就夠了，如上圖計算。而 post 的部份取 10 萬，即我們上傳的次數。至於資料呑吐量，則隨便抓個數字了畢竟從圖片大小開始預估，就作罷了。
• 因此一個月約 NT$ 100 元。了不起 200 元都還比向 ISP 買頻寬便宜。
• （反觀若我們投放廣告 [ 筆者完全沒認知，純假想 ]，20 x 60 x 8 x 2 [ 每人獲權重 2 點 ] x 31 = 595200，
  595200 / 1000 [ 使用者去點擊廣告的機率取千分之一 ] x 0.01 [ 美金，使用者點擊廣告所獲得的 ] x 28.5 [ 匯率 ] = NT$ 170 > 100。
  此金額並非代表我們真能賺 170 這麼多錢，而是對比於花了錢使用了雲端，在投放廣告的前提下，我們絕不會賠錢。
  [ 事實上以上這兩點計算下來再比較變得很不準確，一來一往的計算下拉大誤差。但各位可比照此法精算看看 ] ）
• 此主題就先醬了。使用 offload media & image optimizer 就恰可用在 aws s3 上。
• 參考資料
  https://bhattaraipradip66.medium.com/how-to-extract-zip-files-in-s3-b5dfea807b44
  https://medium.com/@johnpaulhayes/how-extract-a-huge-zip-file-in-an-amazon-s3-bucket-by-using-aws-lambda-and-python-e32c6cf58f06

圖片優化外掛

• 在作網站測試時，請參考一開頭的連結，測試的結果有缺點說明，圖片並不是 progressive jpeg，相對地，progressive 可讓網站有較好的效能。因此我們可以安裝 EWWW Image Optimizer 外掛，其針對 wordpress on-site 的 images 及正在上傳的 images 作優化。筆者還在摸索中。
• 不過實際測試下，效能略減。原因筆者猜測是，jpeg 本就已是壓縮檔，要再壓縮投報率極低。並且 wordpress processing 都還要再經過 ewww 的程式碼，所以一來一往，效能不增反減。若是每篇文章都有大量的圖片，或許才會有所謂效能的優化吧。因此測試網站拿 progressive jpeg 為測項，權重應低點才是。這外掛筆者還是會使用，理論上可行的，都可使用。

bandwidth 4MBytes.

** SIEGE 4.0.4
** Preparing 150 concurrent users for battle.
The server is now under siege...
Lifting the server siege...
Transactions:		       10849 hits
Availability:		      100.00 %
Elapsed time:		      599.38 secs
Data transferred:	     2156.15 MB
Response time:		        7.94 secs
Transaction rate:	       18.10 trans/sec
Throughput:		        3.60 MB/sec
Concurrency:		      143.80
Successful transactions:       10849
Failed transactions:	           0
Longest transaction:	      233.29
Shortest transaction:	        0.07

當前結論

• 筆者註冊啟用了 Aws S3。
• Aws 最好是先建立一個 admin 帳號以別於 root，來日常管理。
• 若有多個網站，建立多個 IAM 帳號其只擁有 S3 完整權限，並關聯於各自的 buckets。
• 於 buckets 底下建立 wordpress 的 uploads folders。
• 上傳壓縮檔及解開請見前述連結。筆者是不壓直接上傳了 XD
• 因前述是使用 wp offload media lite + EWWW 兩支外掛實現 offload。
• （＊）若不使用外掛，前述連結文章也有直接修改 upload 的路徑，但前提是必須建立 access S3 via URL 這樣的函式功能，
  這或許是可行的但需對 wordpress 及 its plugin 有更深入的了解才能實作 php 來 hook upload。這目前筆者沒能力。
• 筆者是先裝 EWWW，故面臨既存的 media files 的問題，按前述連結文章確定可解決，故；
• （20231210 補充，很重要，因筆者又將某網站搬家了／從一台主機移到另一台主機。結果呈現該是遠端的連結全變回本地端了。而至於如何解筆者尚無認知，但，所以至少記得，搬家前的複製備份，務必先將 EWWW 及 offload-pgi 全都停用試試；停用前先將 EWWW 之媒體庫做過一次 optimize；並請再閱讀此以下的描述多點參考。[ok, 後來在此失誤的前題下，即在新主機上，筆者嘗試先停用二者後再啟用，接著再將 EWWW 的 images 重新 optimize 一次，那麼，遠端連結回來了，不過注意，此 re-optimize 將會重新演繹所有 images 並將其重新上傳至遠端，故注意一下每天的免費使用量。故事後補救此舉不建議。]）
• 若是新裝的 wordpress，便可先將 wp offload media lite & ewww 先裝好設定好，就沒有上述問題；
• 否則，記得先將 ewww 的所有快取與記錄全部清除，並停用之（但檔案已全優化好了）。再設定配置好相關的 offload。之後才啟用 ewww 那麼既存的 media files 的連結才會從本地端更新成遠端。
• wp offload media lite，在此簡稱 offload-pgi，只有付費版本才支援 aws cloudfront，其自帶支援 SSL。而若不使用 cloudfront，aws 建議存取 s3 使用 virtual host 的方式，不過一來 virtual host 方式無法使用本地端的 SSL，再來是 offload-pgi 並不提供可手動修改遠端連結，故我們便無法改成 virtual host，只能使用一般連結的方式，不過有支援 SSL（s3.domain/bucket-name/）。因此要有較佳的解法，應是使用（＊）這一方式了，而 SSL 或許只是 virtual host 還未支援？。
• 附帶一提，既存檔案，筆者是修改成 vhost 的連結，不過實際啟用，仍是顯示傳統遠端連結，這便有點耐人尋味了。故回文，手動修改連結就使用傳統連結即可才有一致性。其次，就算修改既存檔案的連結成遠端，ewww 仍 hook 成本地端，除非加上啟用 offload-pgi，這造成給人邏輯上的出入。故衍生出三個想法。一來，或許如此，當停用此二外掛，那麼才能再索引回本地檔案而不致出錯，故不存在此二外掛的前提下 wordpress 的任何設定應是 intact 才合理，表其實純是此二外掛做的手腳。再來，或許根本不需修改既存檔案的連結，只要上傳到 S3 即可，但如此仍有邏輯出入，故，可以嘗試可能的解決方式是，停用 ewww，再做單純上傳 S3 後安裝 offload-pgi，再重啟用 ewww，若沒問題，就全 consistency 了。哥再來，既存檔案已全由 ewww 優化，接著上傳至 S3 並更改路徑成遠端。由於若停用 ewww 後仍可於存取到既存檔案於本地端的連結而非我們改過的新連結，這便是我說的出入的地方。而新檔，將是本地端一份，遠端一份，並且 ewww & offload-pgi 全停用皆無妨（將索引回至本地端）。若要在此狀態下繼續使用例如已不再租用 aws，則我們只要做回復一步將之前改的連結改回來即可（不做亦可）。
• 附帶二提的是，筆者觀察到，新加入（遠端）的檔案，會被存放在所設定的目錄下，再新增一編號（timestamp）的子目錄的底下。而既存檔案也會比照辦理。這違反 offload-pgi 的說明，不處置舊檔。但筆者猜測，或許同一年月份，就會被處理，而更舊的便忽略。而這真正的原因是 offload-pgi 設定所致，Object Versioning，請搜尋此項目說明。筆者認為，我們就將它關閉吧畢竟路徑已跟本地端不一樣了。
• 綜合以上附帶的，別實驗了，我們還是乖乖修改舊的檔案連結吧（始終順序要對，先裝 ewww 優化再裝 offload-pgi）。
• 接下來，使用 offload-pgi 還會有一個問題待解且已解且未完全解：
• 網頁中關於 media files 將會是連結到 S3 的 raw URL，並不美觀，修改的方法之一是使用 DNS 的 CNAME，來對應到此 raw URL，但此時不再是使用 raw URL，而是使用 vhost URL；raw URL: s3.[area].amazonaws.com/[bucket-name]，vhost URL: [bucket-name].s3.[area].amazonaws.com，前者支援 SSL，後者不支援。而現用的 offload-pgi 2.5.5 版是可被修改使用 custom domain，於 [設定] -> [offload media lite] -> [delivery] -> [provider] -> [change] -> [another cdn] -> [other] -> 自定義名稱。儲存後返回後，便出現可設定 CNAME 此一項目。而這個 CNAME 便可向 dns provider 註冊一個以對應到 vhost。關鍵是，此 CNAME 必須是 bucket-name，aws 才能正確索引到；故，先新增出 CNAME，才創建同名 bucket。如此問題便解決了。但結果不然，offload-pgi 使用此 custom domain 以 https 的形式（故透過它存取時將被禁止），但此 CNAME 我們又無法申請 TLS，vhost 亦只使用 http（造成的結果是可以直接以 http & CNAME 的方式存取到），而就算 vhost 使用 https，CNAME 只能 http 亦不相容（解法將是，aws 有提供幫我們的 CNAME 申請 TLS 的功能？）。其次若 offload-pgi 使用 http，很可能網頁上亦因安全性而不讓顯示。故，應是 dead end。最終解法是只能使用 cloudfront 或使用 raw URL。（註：aws 可支援有 TLS 是 name.s3.*，name 是不能帶點號的。故只要有 domain 不帶點號便解了）
  https://aws.amazon.com/tw/blogs/aws/amazon-s3-path-deprecation-plan-the-rest-of-the-story/
  https://deliciousbrains.com/webp-wp-offload-media-ewww/
• 補註：
• offload 後，EWWW 必須重新 re-optimize，舊文章的連結才會真正更新，否則結果是成功或失敗都無法確定。（也因為如此，筆者就沒機會試不改舊文章連結這一步驟）
• 於主機端媒體庫中刪除 image file 會同步到遠端 S3／亦被刪除。但在文章中刪除 image file，不影響儲存性。當然於文章中或媒體庫中上傳檔案亦會兩地同步更新。
• 關於 S3 storage 給網站的權限的設定，原則上設定 AmazonS3FullAccess 的權限界限（上界），但擁有如此權限的任一個 IAM user 都可完全存取與建立刪除 buckets 及其內容物，故我們需要設定內嵌政策綁定某 IAM user，讓某特定 IAM user 只能有有限權限存取某特定 bucket。權限細分為操作及資源等個別細項批准，如下圖（非標準，筆者自訂僅供參考）。
• 而這樣的使用者，登入主控台的路徑只能透過 URL 來前往，
  https://s3.console.aws.amazon.com/s3/buckets/EXAMPLE-BUCKET/
  https://s3.console.aws.amazon.com/s3/buckets/EXAMPLE-BUCKET/folder1/folder2/
  https://aws.amazon.com/tw/premiumsupport/knowledge-center/s3-console-access-certain-bucket/
  https://aws.amazon.com/tw/blogs/compute/deploying-a-highly-available-wordpress-site-on-amazon-lightsail-part-2-using-amazon-s3-with-wordpress-to-securely-deliver-media-files/
  https://deliciousbrains.com/wp-offload-media/doc/custom-iam-policy-for-amazon-s3/
• 要讓 EWWW 的 Webp 能夠被套用，在 nginx 的設定要修改追加如下連結文章。
  https://docs.ewww.io/article/119-webp-delivery
  https://talk.plesk.com/threads/ewww-image-optimizer-webp-format-nginx-and-plesk.345980/
  https://github.com/uhop/grunt-tight-sprite/wiki/Recipe:-serve-WebP-with-nginx-conditionally

番外篇

• 事實上本文編排會很雜，因為做最佳化並不侷限於某一面向。
• 筆者使用 siege，測果速度明顯不符合預期，已抓到原因了。因為筆者在 urls.txt 中使用了不止一個網站；即，最好是讓受測者單純點為佳。故，筆者專注於本網站後，請比照上面那段測果，速度增加超過四倍。因原先的那另個網站中放有大量圖片所致。
  並將前後的幾次結果也列出。
• 請注意，所有列出之測果都是已使用 wp super cache & ewww。而這二者開或關幾乎不影響測果。

bandwidth 4MBytes.

** SIEGE 4.0.4
** Preparing 150 concurrent users for battle.
The server is now under siege...
Lifting the server siege...
Transactions:		       48072 hits
Availability:		      100.00 %
Elapsed time:		      599.85 secs
Data transferred:	     1447.62 MB
Response time:		        1.85 secs
Transaction rate:	       80.14 trans/sec
Throughput:		        2.41 MB/sec
Concurrency:		      148.52
Successful transactions:       47116
Failed transactions:	           0
Longest transaction:	      102.60
Shortest transaction:	        0.05

        Date & Time,  Trans,  Elap Time,  Data Trans,  Resp Time,  Trans Rate,  Throughput,  Concurrent,    OKAY,   Failed
2021-10-16 18:35:23,  10810,     599.12,        2162,       7.89,       18.04,        3.61,      142.30,   10810,       0
2021-10-21 19:15:36,  10750,     599.20,        2123,       7.92,       17.94,        3.54,      142.02,   10750,       0
2021-10-21 20:11:35,  10727,     599.74,        2135,       7.91,       17.89,        3.56,      141.44,   10727,       0
2021-10-22 08:14:56,  10729,     599.63,        2149,       7.86,       17.89,        3.58,      140.66,   10729,       0
2021-10-22 08:50:33,  10792,     599.77,        2148,       7.94,       17.99,        3.58,      142.94,   10792,       0
2021-10-23 17:04:38,  46577,     599.32,        1404,       1.91,       77.72,        2.34,      148.13,   45623,       3
2021-10-23 17:17:31,  47697,     599.40,        1433,       1.87,       79.57,        2.39,      148.41,   46734,       1
2021-10-23 17:41:35,  49341,     599.93,        1474,       1.81,       82.24,        2.46,      148.59,   48365,       0
2021-10-24 08:43:02,  48727,     599.13,        1459,       1.82,       81.33,        2.44,      148.00,   47747,       4
2021-10-24 09:13:22,  48072,     599.85,        1447,       1.85,       80.14,        2.41,      148.52,   47116,       0

• 接著，就會移至新主機再測一次；從 J1800 到 i5。
• 再下一步就是使用 AWS S3。
• 不過，筆者後來想一想，還未決定，
• i5 比較快，更適合同時有多人在線，本網站應是放於此主機最合適，還包含筆者建的其他網站已全塞於此。原本的 J1800 將變成閒置。所以網站分配到哪台主機是個問題。但主要取決的很可能會是，一秉初衷，讓此網站仍使用 noip 動態 ip 功能，延用 ddns name，使用 i5，使用 aws。而其他網站，已全在 i5 了，再移回 J1800。故就本網站而言，依舊除了付有線寬頻費，電費，還有新增的 aws 超額費用，就沒了。而筆者的其他網站，也只多花了租 domain name 的錢而已，一支年租 NT$ 800。
• 應是這樣了。
• 好了，現在這行開始，就是已將本網站從 J1800 移至 i5 了。
• 題外話，像這樣搬家的舉措，要做的事也不會太多，也不會太少，若讀者，從筆者的第一篇文章跟著做起，相信您此刻，我不敢說揮洒自如，但也會運用地順遂，甚至於每篇文章的啟發後您再補補其他資料，定會比業餘的筆者高明很多很多更接近專業的網管員了。
• 底下是 siege 的測果，看出效能真有增長不少（hits，第二欄位）。但，筆者認為，最能拿來評斷的數據首當 throughput 了。即，每秒只有 1.88 MB 的流量出來。輸於於 J1800（Caddy）上面的數據最高到 2.46(3.6) MB/s。（以 hits 來看，一萬多的是兩個網站於 J1800 上一起測，四萬多與五萬多是一個網站分別於 J1800 & i5 上測）。
• hits 表示達到某程度的響應，故可看出 i5（Nginx）上響應速度快，但欲傳輸出去的，卻一直在等待被服務。因此我們看到錯誤率提高了。
• 故，看來，caddy 的能力優於 nginx。

        Date & Time,  Trans,  Elap Time,  Data Trans,  Resp Time,  Trans Rate,  Throughput,  Concurrent,    OKAY,   Failed
2021-10-25 17:28:10,  54079,     599.56,        1126,       1.58,       90.20,        1.88,      142.58,   53098,      19
2021-10-25 17:52:33,  53971,     599.44,        1120,       1.56,       90.04,        1.87,      140.26,   52994,      29
2021-10-25 18:12:12,  53623,     599.86,        1130,       1.61,       89.39,        1.88,      143.64,   52639,      21
2021-10-25 18:23:45,  54376,     599.91,        1134,       1.58,       90.64,        1.89,      143.60,   53403,      19

• 附上筆者自始至今的 log，來看看演化過程。除了 php 版本的每版更新，及當中將 30 人改為 150 人，還有就是主機的更換（最後幾行），及後期加上了 wp super cache & EWWW。
• 再來，就是將 media files 上傳至 s3 做 offload 優化。不過，因筆者這台新主機放了五個網站了，因此，將會先試一次 threading 的 nginx。才接著 offload。

2021-10-26 09:52:58,  53880,     600.07,        1130,       1.61,       89.79,        1.88,      144.59,   52902,      18
2021-10-26 10:04:38,  53430,     599.31,        1125,       1.62,       89.15,        1.88,      144.22,   52454,      21

• 這兩行是開啟 threading 的測試，結果看不出有何差異。故 nginx 本身的優化，仍需再研究看看。
• 不過值得一提的是，測試的主機端，與受測者是共享頻寬 4MB/s。我也嘗試過使用手機網路於主機端但因其網路速度更慢故無參考價值。簡單講當頻寬不再是瓶頸時，才是最準確的測果。
• 此外，caddy & nginx 的比較如上述，當需再考量真實層面的使用者體驗。nginx hits 高，throughput 低，但或許（同時間更多地）使用者體驗優於 caddy 也說不定。
• 最後，就是 offload 了。底下，先放上當前的網頁測試分數。

• 接著，完成 offload 之後的測試結果如下，
• 先看 siege，成果不如預期，hits 只增加約 4000 筆。而錯誤率，即 timeout 的筆數增加很多。

2021-10-28 19:52:30,  57666,     599.18,        1165,       1.37,       96.24,        1.94,      132.15,   56635,     293
2021-10-28 21:22:25,  57960,     599.01,        1160,       1.33,       96.76,        1.94,      129.15,   56937,     292
2021-10-28 21:56:09,  58370,     599.21,        1176,       1.32,       97.41,        1.96,      129.00,   57311,     318

• 而當然還是要強調，當前是主機端及受測端共用頻寬，假如將其分開的話，測果應會提升，
• 不過這是單就 siege 而言。外部測試網站所測得的成果跟 offload 前相去不大。
• 因此，後續應可就其所建議的缺點來加以優化才是。

20220109 update