優化TTFB

打開 Chrome 瀏覽器的 Network 標籤，點擊最後的 Waterfall 就能夠看到相應的內容：

從圖中，咱們就能夠看到影響加載速度的主要因素是：

• Waiting (TTFB)。TTFB，即Time To First Byte，指的是：請求發出後，到收到響應的第一個字節所花費的時間。
• Content Download。即下載內容所須要的時間。

用戶下載內容所須要的時間，受限於服務器的資源、資源的大小以及用戶的網絡速度。所以，咱們暫時不討論這方面的內容。

咱們能夠看到這裏的主要限制因素是，TTFB。而要對 TTFB 優化的話，就須要關心兩部分：

• 服務器。好比：若是有複雜的防火牆規則或路由問題，則TTFB時間可能很大。又或者是你的服務器性能很差，可是你啓用了 GZIP 壓縮，那麼它也將增長 TTFB 所須要的時間。
• 應用程序。比較簡單的做法是和我同樣，交這部分交給 New Relic 去處理，咱們就能夠知道應用中哪些地方比較佔用資源。

TTFB 優化

 

而對於早期個人博客來講，還有一個主要的限制因素是 DNS 查詢所須要的時間——即查詢這個域名對應的服務器地址的時間。這主要是受限於域名服務器提供的 DNS 服務器比較慢，做一個比較簡單的對比：

經過使用 traceroute 工具，咱們就能夠發現通過不一樣網關所須要的時間了：

而這仍是在我採用了 DNSPod 這樣的工具以後的結果，原先的域名服務器則須要更長的時間。惋惜，我這麼窮已經不能付錢給更好的 DNS 服務提供商了。

服務器優化

後來，我發現個人博客還有一個瓶頸是在服務器上。因而，我使用 APM 工具 NewRelic 發現了另一個性能瓶頸，服務器默認使用的 Python 版本是 2.6。

對於如我博客這樣性能的服務器來講，應用的一個很大的瓶頸就是：大量的數據查詢。如當用戶訪問博客的列表頁時，大概須要 400+ ms 左右的時間，而一篇詳情頁則差很少是 100ms+。對於數據查詢來講，除了使用更多、更好的服務器，還可讀減小對數據的查詢——即緩存數據結果。

而在當時，我並無注意博客對於緩存的控制，主要是由於使用的靜態資源比較少。這一點直到我實習的時候才發現。

項目優化經驗：緩存優化

當我試用了 PageSpeed 以及 YSlow 以後， 我發現光只使用 Nginx 來啓用壓縮 JS 和 CSS 是不夠的，咱們還須要：

• CSS和JavaScript壓縮、合併、級聯、內聯等等
• 設置資源的緩存時間。將資源緩存到服務器裏，減小瀏覽器對資源的請求。
• 對圖片進行優化。轉化圖片的格式爲 JPG 或者 WEBP 等等的格式，下降圖片的大小，以加快請求的速度。
• 對 HTML 重寫、壓縮空格、去除註釋等。減小 HTML 大小，加快速度。
• 緩存 HTML 結果。緩存請求過的內容，能夠減小應用計算的時間。
• 等等

對於 CSS 和 JS 壓縮這部分來講，咱們能夠從工程上來實現，也可使用諸如 Nginx Pagespeed 這樣的工做來實現。可是我想使用工程手段更容易進行控制，而且不依賴於 HTTP 服務器。

設置資源的緩存時間就比較簡單了，弄清楚 Last-Modified / Etag / Expires / Cache-Control 幾種緩存機制，再依據本身的上線策略作一些調整便可。

至於緩存 HTML 結果來講，比較簡單的作法就是採用諸如 Squid 和 Varnish 這樣的緩存服務器。

固然了，還有一些極其有意思的方法，如將 JavaScript 存儲在 LocalStorage 中。