.png?v=1647475200)
.jpg?v=1697597433)
【Google-pagespeed】google-pagespeed-如何縮短初始伺服器回應時間
問題：請縮短初始伺服器回應時間
請確保伺服器能快速回應主要文件，因為這會影響到所有其他要求的回應時間。
案例圖片：
解答：
前略：一般來說，回應時間的解釋為 TTFB（Time To First Byte)
用比較白話的說法，就是伺服器生成html頁的前置時間，也就是俗稱TTFB
TTFB 與 Loading Times 兩者是不同的。雖然都是跟網頁載入時間有關。
要如何縮短TTFB的時間，其實這跟後端程式碼及伺服器還有頻寬有直接的關係。
基本有其下原則
-
使用者傳送請求到主機的時間
也就是說，第一步要先處理的是，發送的資料值。
但就一般網頁連結來說，在不傳送GET或是POST的情況下，這個問題是可以忽略的
-
主機接收請求抓取資料的時間
這多數而言是與後端程式有關係，其中包含了演算、資料庫讀取的時間。
一般要先確定的是資料庫的讀取時間。
如資料庫的讀取時間過久，則需要重新改寫資料庫的取資料的方式
如
- 取得的數量值是否過大
- 資料庫索引是否有建立好
- 資料的取得資料容量值是否太大
再來就是程式碼的寫碼問題。這一般只要注意廻圈的部份就好。像是PHP的for或foreach..等等。檢查是否廻圈次數過多。(例如幾10萬次)
最後就是負載的問題了。一般這就考量WEB SERVER的負符能力值。能承受多大的請求數。評斷是否需要更換較高階級的主機等等問題。
-
主機回傳資料給使用者的時間
其實當瀏覽器收到伺服器的傳送資料時，其還需要做最後一個動作。
也就是將相關畫面給與秀出顯示出來到使用者。
這期間其會有相關javascript的運行處理。
不過一般來說，這已經是在客戶端的機器上跑了。少了傳送的等待。速度是會很快的。
TTFB的改良優化，基本源頭還是得要從程式及資料庫處理。
而是否有其冥優化的方式。
其實還是有的。
就目前的WEB SERVER來說。常見到的是APACHE NGINX 。
其兩者是有其優缺點的。
就正常來說，APACHE在上手比較容易許多，畢竟它是很早期就出來的一套SERVER系統。
且也是第一個採用主從式架構原理的伺服器。並有非常良好的擴展性。
但在於 2004 後多個WEB SERVER的崛起。比較具代表性的不外乎就是 NGINX 。
NGINX 首次推出就捨棄了APACHE看來容易使用的可調式設定變動檔(.htaccess)
所以 NGINX 可以更為有效的運行網頁運算。效能而言來說，遠遠比過APACHE
所以如想要有更好的TFFB。選對WEB SERVER也是很有幫助的。
最後就是SERVER的設定值應用了。一般來說依照主機等級來計算。需要注意的有以下幾點
-
最大進程數
-
最大連接值
-
最大記憶體用量
-
單線記憶體用量
用以下表格來區分各自不同的規劃
|
最大進程數 |
最大連接值 |
MAX記憶體 |
USE記憶體 |
|
|
1C 1G |
30 |
50 |
256M |
2M |
|
1C 2G |
30 |
50 |
512M |
8M |
|
2C 2G |
50~80 |
150 |
1024M |
32M |
|
2C 4G |
80 |
150 |
2048M |
128M |
|
4C 8G |
150 |
300 |
4096M |
256~1024M |
基本來說，連程數跟連接數，會先依照核心計算。再考量記憶體容量的容許值來做調整
最大記憶體一般不要超過本身主機的最大值一半以上的容量。
使用記憶體一般維持在容許的傳送值就可以。設定太高了。有時就得要調整連接線值。
這些調整只是大略的參考性。最佳的方式是直接依照專案的需求性而調整設定。
最後，如上面所說的，一般TTFB的運行都是來自於伺服器的運算後呈現出來的畫面。
如果這些資料畫面值，是不常變動性的。一般就會考量是否要將其給緩存下來。
緩存的方式有很多種。就大約舉個比較常用的。如CDN 、 靜態頁緩存
其中CDN來說，則是利用了另一個伺服器來幫你記錄頁面資料。
客戶端收到的都是單純的靜態頁面輸出。自然就沒有運算這一回事。
這是將緩存相關的技術交由另一台機器處理。
目前比較有名類似的服務廠商為 CloudFlare
不過 ，要使用CDN或是緩存機制的情況下，要注意不適合使用在常變動數據的頁面上。
因為有可能會有時間差的資料不同步。
就正常來說。如果資料同步率可以超過30分以上不會變動的情況。我就會建議使用緩存頁的機制及技術處理。
以上是相關TFFB優化需要處理及相關事項