讓你的網站打開的更快

這張圖是賣萌的

不知道從何時開始,無論是寫獨立博客,仍是網絡應用,甚至寫託管博客的人都會朝着「大」網站看齊,去追求網站的響應速度,通俗點說,就是白屏時間,由於據各類報告說,網站打開速度更快一些,帶來的用戶體驗就更好一些,從而帶來更多的附加利益。可是對於用戶來講,快,並非簡簡單單請求數目儘量少,和服務器吞吐能力盡量大。那麼,怎麼快?php

因爲本人水平有限,內容可能有誤,歡迎拍磚斧正,和幫助補充。css

談到速度(參考物和例子稍後一塊兒提),咱們首先能想到的事物有:html

  • 服務器機器性能
  • 服務器機房帶寬資源
  • 服務器軟件性能
  • DNS查詢速度
  • 頁面資源壓縮(服務端+客戶端)
  • 頁面提供資源數量
  • 頁面資源加載時機
  • 用戶終端某時刻性能
  • 用戶終端瀏覽器性能
  • 用戶直觀感覺
  • [附加]異常流量狀況

若是有興趣,不妨和我一塊兒逐一聊聊吧:前端

服務器性能

說到服務器性能,可能多數人會停留在幾核幾G幾百G這種概念上,可是對於網站服務器,咱們關注的應該是單機/VPS的數字運算能力和IO讀寫能力,若是不是單機服務器,那麼請關注本身實際能使用的資源數量,尤爲是高峯時刻,具體請參考VPS虛擬化常見方案:OpenVZ/Xen/KVM/VMWare/Hyper-V等方案在其餘實例佔用CPU太高的時候,對其餘實例的影響(部分虛擬化方案,會由於某些實例鎖死時間片而使用太高影響其餘實例)。node

就博客/網站主來講,咱們應該使用盡量更好的資源,可是非土豪的話,資源好到什麼程度呢,答曰:夠用。mysql

夠用是什麼程度呢,知足最大的調用程度,且有餘力。nginx

這個「有餘力」是你對網站/應用的訪問量有評估後,並進行壓測,觀察機器負載獲得的。web

若是你的網站有大量文件IO/數據庫讀寫操做,那麼爲了保證最佳性能,不妨嘗試使用SSD,或者進行內存緩存等操做,一旦你使用內存緩存,那麼總體的性能瓶頸多數狀況下會從機器總體性能變爲網卡/帶寬,是否是可喜可賀。ajax

在正確設置服務器軟件配置以知足本身需求場景後,若是你對運行程序優化得當,那麼最佳體驗應該是內存有30%cache,swap佔用極少,或不佔用,負載0.5如下。(以防突發流量)redis

說到壓測,不得不繼續說下面的話題了。

機房帶寬資源

帶寬資源或許是除了高端存儲設備外,價格最貴的資源之一了。因此,評估帶寬是否知足你的站點,是特別重要的事情。

通常來講小站點,1~2M的帶寬絕對夠用。若是不知道你的機器的帶寬能力,不妨登陸機器後臺觀察流量圖峯值,或者機器安裝speedtest-cli,來進行數據收集。

諸如我用過的機器,突發情況下能力爲:

Testing from Linode (X.X.X.X)...
Selecting best server based on latency...
Hosted by T-Mobile (West Norriton, PA) [104.63 km]: 79.475 ms
Testing download speed........................................
Download: 53.68 Mbits/s
Testing upload speed..................................................
Upload: 32.51 Mbits/s
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from HengTian HK DataCenter (X.X.X.X)...
Selecting best server based on latency...
Hosted by FPT Telecom (Hong Kong) [5.98 km]: 28.453 ms
Testing download speed........................................
Download: 77.30 Mbits/s
Testing upload speed..................................................
Upload: 4.45 Mbits/s

觀察二者,會發現前者上傳比較大,嗯,沒錯,服務器的上行帶寬,便是咱們常說的網站帶寬,通常而言,此數值越大,提供的訪問能力就越強。

可是,綜合現實因素,諸如政策和地理位置的緣由,網站響應速度和機房有重大關係,好比,BGP機房線路智能負載後的響應時間能夠達到10ms甚至如下,或者你能夠嘗試ping一下本身的本地服務器,響應時間感人,可是在祖國大地,若是你直接訪問一些美帝國或者歐洲大陸機房則可能速度會增大幾十到幾百倍,甚至出現訪問不能的情況。

基於這個情況,若是你的網站的受衆包括國外友人,那麼你的選擇:

  • 國內無所謂,本身能訪問就好,國外快快的:

  • 美帝機房/加拿大機房/日本機房/韓國機房/歐洲機房

  • 國內國外速度相對快的機房

  • 港澳臺機房/日本機房/韓國機房/歐洲機房

  • 國內快速,國外可能訪問不了的機房

  • 各省市機房/學校機房/港澳臺機房

固然,你也能夠根據本身狀況選擇CDN加速方案:

  • 國內機房+國內外CDN
  • 國外機房+國內外CDN

固然,若是你和個人網站同樣,是一個本身的無事寫幾筆的小站,那麼選擇國內的阿里雲,或者香港機房都是不錯的選擇。

硬件說完了,咱們聊聊第一節中提到的軟件。

服務器軟件性能

「尺有所短,寸有所長」,軟件也是同樣,小站點,資源有限的狀況下:

  • 若是你之前使用apache,且沒有使用一些三方模塊,或者不須要使用apache軟件套裝裏的高級功能,或者沒有軟件必須依賴apache,以及三方模塊能在nginx中找到替代的,能夠考慮替換爲nginx。
  • 若是你的程序容許實現數據庫緩存/站點內容緩存,可是沒有使用緩存的,請開啓緩存功能。
  • 若是你的程序使用了文件緩存,在內存資源有富裕的狀況下,請使用內存緩存(本身考慮緩存策略)。
  • 若是你的程序原來的運行環境執行速度不夠快,那麼請考慮升級或運行環境,諸如php5.2->php.5.6+,或者php5.6->hhvm 3.x,asp/php->nodejs。
  • 若是你的程序中多數功能你用不到,考慮使用更輕便的小程序。
  • 若是你啓用了緩存,且數據庫(關係數據庫)讀取熱數據頻率高於冷數據,且訪問量不是特別大,不須要考慮數據庫效率,不然須要考慮數據庫進行分庫分表和創建適當的索引,以提升數據庫吞吐能力。
  • 根據本身狀況適當調整nginx/mysql/redis/memcache等軟件的數據分塊大小。
  • 優化程序關鍵邏輯的流程,儘量讓程序始終遵循最短路徑結束任務。
  • 儘量讓TCP連接重用,或者適當調整持久連接的時間和數量(Keep-Alive),以及考慮使用SPDY。
  • 防火牆/服務器代理軟件/程序對訪客限制流量。
  • 過濾或者禁止能力範圍內的異常流量。

DNS查詢速度

DNS對於站點首次打開速度相當重要,因此請儘量選擇靠譜的DNS提供商來解決DNS查詢問題。

國內有兩家DNS提供商比較不錯:

  • DNSPOD
  • DNSLA

除此以外,對於webkit支持DNS預緩存的瀏覽器,能夠在頁面頭部盡少和盡合理的添加要緩存的DNS,以加快頁面展現速度。

好比,個人頁面中可能存在資源域名和附件域名。若是頁面在加載的時候,同時進行這兩個域名的DNS緩存操做,接下來請求這兩個域名的資源的速度會更加的快。

<link rel="dns-prefetch" href="//attachment.soulteary.com">
<link rel="dns-prefetch" href="//assets.soulteary.com">

可是是否分離域名,請根據本身狀況來。由於分離域名以後,不能否認的是,會帶來額外的查詢操做(查詢本地緩存也算)。可是分離資源,可使得程序更容易維護,以及對於程序總體安全性帶來提升。

解釋一下最後一句話,當初還在新浪的時候,翻看如今已然是大boss的ppt,其中提過這麼一句話「執行不可寫,可寫不執行」。若是你的目錄容許上傳,那麼上傳目錄的文件必定要限定不可執行,以及能夠執行的目錄,不能夠進行寫入操做,以避免網頁木馬的上傳,提升系統安全性。

另外,若是你將網站數據分離,那麼網站的遷移操做,將會變的十分簡單。好比,我將網站在國內國外遷移了若干次,只是須要先同步附件和頁面資源域名,而後改變這兩個域名的指向,而後同步程序文件,改版域名指向便可。

接下來,咱們說說節約帶寬和提升速度的一個大殺器:壓縮。

頁面資源壓縮(服務端+客戶端)

提到壓縮,正經常使用戶會想到的是rar/zip/7z,媒體愛好者想到的會是ABR/CBR/VBR/H.264,咱們這類代碼愛好者恐怕是gzip,若是你也是前端,可能你還會想到js compressor

  • 服務器根據CPU能力,儘量輸出gzip後的資源。

爲何是儘量輸出gzip呢,由於可能你的頁面須要支持古老手機端瀏覽器,一些古老的MID或者性能不太好的MID設備,或者是古老的IE6?若是不須要,那麼請一概輸出GZIP後的頁面。

  • 替換或者提升壓縮算法和策略。

若是你有特別的客戶端,能夠考慮使用自定義的更高壓縮比的壓縮方式,這個作手機應用的童鞋或許接觸過,和十年前你們壓縮MP3以及作軟件壓縮包同樣,使用本身軟件算法和策略替代市面上已有的算法和策略。若是沒有特別的客戶端,那麼咱們不妨對圖片和視頻使用更好的壓縮格式,好比webpwebm,以及適當狀況下的gif替代png等。

  • 對靜態資源內容適當排序。

如對最後生成的css文件進行排序能夠提升gzip壓縮比。

  • 適當添加頁面額外內容,提升壓縮比。

能夠將頁面的通用樣式或者腳本混合在頁面裏,提升頁面壓縮比。

  • 使用腳本去掉多餘的空格和換行。

雖然對於gzip效果甚微,可是對於緩存讀取和寫入有特別大的差別。

  • 使用縮略圖/響應式圖片來替代頁面中展現的原始圖片。

傳統模式下,咱們可使用服務端腳本thumb類庫/CDN提供的圖片縮略服務來進行資源的縮略圖,來替換原始圖片,並增長一些交互文本,對用戶實現降級訪問。若是用戶瀏覽器支持CSS3,那麼咱們可使用Media Queries特性來對內容圖片進行切換。若是用戶瀏覽器支持HTML5,咱們可使用image-set標籤來進行圖片響應式輸出。

接下來咱們來講說另一種變相的數據壓縮,減小請求。

頁面提供資源數量

  • 儘量減小同一時間的資源請求數量。

對於靜態樣式和腳本,使用合併策略。針對單頁面程序,你能夠將全部樣式或者腳本都合併爲一個單獨的文件。可是針對多頁面,以及帶有皮膚策略的站點,則考慮抽象基礎的Base內容和額外的內容,並經過先後端腳本進行策略加載。對於圖片和視頻資源,在交互容許的狀況下,使用延時加載,跨屏預加載必定數量,來取代頁面文檔加載完成後就加載所有的策略。

  • 對不一樣瀏覽器使用不一樣的腳本。

差別對待瀏覽器,對古老瀏覽器不使用一些功能,以及差別對待瀏覽器使用的基礎腳本庫。若是你使用下一節提到的JS加載器,那麼這個很容易作到。

  • 頁面增量更新。

若是你的內容支持異步增量更新,那麼使用接口更新增量內容的模式,來替換打開新頁面的模式。曾幾什麼時候,這個被稱做ajax頁面局部刷新

  • 客戶端緩存

此處深坑,稍後留寫一篇詳敘,簡單的說,儘量給全部資源使用最長時間的緩存,對於不支持200 cache的客戶端提供304 Modified緩存(前者不須要額外HTTP請求)。

  • 客戶端本地緩存。

對於變化不大的站點,配合腳本,對支持使用本地緩存的客戶端進行適當的數據緩存,這個是深坑,且有必定的安全風險,稍後寫篇具體的內容來描述。

上面提到的內容,多數屬於,如今咱們來聊聊

頁面資源加載時機

作網站時間比較久的童鞋或許還記得yahoo slow總結出的幾條「規則」:

  • 把css放在文檔頂部。
  • 把js放在文檔底部。
  • 減小inline腳本的存在。

這裏或許應該爲:

  • 將頁面主要樣式儘量放在文檔頂部。
  • 將三方不可合併腳本儘量放置頁面底部。
  • 將頁面inline腳本儘量替換爲配置內容。

將基礎樣式放置於文檔頂部,可讓頁面渲染基礎內容更快,若是前幾點你都作到了,或者作到大多數,項目複雜度不高的話,那麼把全部的樣式打包合併放在此處也無關係。

將三方不可合併的內容放在頁面底部,一方面是出於維護的考慮,一方面是由於咱們要使用JS加載器來控制資源的加載(這裏須要將本來頁面中的腳本替換爲具體執行腳本所須要的inline腳本配置)。

作到如此,頁面將會首屏渲染極快,以及頁面卡頓大幅減小(大量動畫狀況另說)。

用戶終端某時刻性能

這個不是咱們所能控制的,由於受限於客戶端宿主機性能以宿主機網絡環境。和最開始提到的服務器性能同樣,CPU時間片被其餘程序佔用時,或者硬件古老,以及網絡被其餘程序佔用的時候,會帶來瀏覽的不順暢。

若是你對網站的通常訪問速度有信心(經過收集到的數據的反饋),且網站屬於內容展現類的,能夠在適當的位置加諸如如下的提示(程序打底提示):

  • 頁面加載過慢,不妨檢查網絡環境是否有其餘軟件佔用(下載工具/在線視頻),並刷新頁面。
  • 資源加載失敗,請刷新重試。

待頁面加載完成,幹掉以上提示。可是請權衡此內容的存儲位置和腳本執行時機,考慮搜索引擎將提示和內容都緩存的狀況。

用戶終端瀏覽器性能

若是你的用戶使用者古老的瀏覽器,軟件性能成爲頁面數據下載和渲染瓶頸,那麼不妨給其一個提示,或者強制其使用新版本的瀏覽器進行訪問:

  • 請更新瀏覽器以得到更加體驗。
  • 本站僅支持新的瀏覽器:A,B,C。
  • 爲了您的訪問速度和安全考慮,咱們推薦您安裝:X,Y,Z。
  • 您是否是打開太多頁面了,請考慮關閉無用的頁面,加快本頁面打開速度(這招請考慮道德問題)。

固然,在頁面資源數量一節中,有提到一些,這裏補充一條,對於支持HTML5video標籤的客戶端,不妨使用其來替換flash,減小客戶端CPU使用率。

用戶直觀感覺

終於寫到這裏了,本節內容,其實上面的小節都有提到一些。

一句話以蔽之,用上面的方法,不要放過任何能夠加快數據展現的方法,給用戶儘量最快的體驗。

固然,這裏有個偷懶的方式,你只須要儘量打敗同類型網站就好。

[附加]異常流量狀況

異常流量可能存在如下情況:

  • 搜索引擎蜘蛛不約而同的來採集你的網站內容。

適當幹掉一些你不喜歡和須要的蜘蛛,諸如俄羅斯的一堆等,或者小衆瀏覽器搜索引擎。在sitemap中增長訪問時間間隔,或者考慮對不一樣蜘蛛輸出不一樣時間。內容添加緩存。

  • 內容引起熱點,真實訪問量大增。

內容確實有趣/有爭議/有實用價值,用戶訪問量增長,若是你是盈利的,那麼加機器吧,若是你是非盈利的,興趣驅動,無廣告的,諸如我這類小博客的,加緩存,或者加免費CDN,或者使用DNS進行多機負載。

  • 三方無聊的惡做劇/利益相關的惡意攻擊/錯誤的域名指向

無聊的惡做劇,包括掃描,這個避免不了,可是你能夠在fail2ban、iptables、nginx/apache過濾掉一些機器人和惡做劇。

若是是SYN的話,瓶頸在帶寬資源/機器資源/機器流量限制,能夠考慮切換DNS(前提是有備份機器)。

若是是最近的錯誤域名指向的問題,好比國外最大視頻站點忽然IP指向到你的機器,那麼請絕不猶豫的去換IP吧。

若是是惡意攻擊的話,這裏區分兩種情況:

  • 你是盈利的,對用戶承諾SLA,那麼請考慮加硬件,加CDN,過濾IP。
  • 你是非盈利的,諸如我這類blog,加內容緩存就行了,本身實測,壓滿了帶寬,機器負載仍是0.5如下,固然若是帶寬大的話,那麼機器估計壓掛。若是你有備份機器,那麼切換下DNS,或者除了當前域名外,使用三方託管頁面進行博客備份,諸如Github Page/Issue、新浪博客之類的BSP。

原文出處:http://www.soulteary.com/2015/01/10/give-me-better-feeling-when-i-visite-your-website.html

相關文章
相關標籤/搜索