web效能優化
1.到底什麼是頁面速度？
網頁的速度基本上是指在網頁或媒體內容從網站託管伺服器下載並顯示到請求的Web瀏覽器的時間長度。頁面載入時間是點選連結並顯示請求瀏覽器上網頁的全部內容的時間。
在使用者體驗和網站效能方面，有三個核心方面需要理解頁面速度：
- 將所需材料以及伴隨的HTML內容交付給瀏覽器所花費的時間。
- 瀏覽器響應頁面載入請求。
- 終端使用者視為所請求的網頁在瀏覽器上呈現 - 這是頁面載入速度的最終經驗衡量。
對於網站開發人員設計高度敏感和速度優化的移動網站的企業主來說，應該在以下三個移動網站解剖要素中尋求改進：
- 流體網格
- 靈活的影象
- 媒體查詢
並且設計側重於以下移動網站元素：
- Masterhead
- 圖片庫
- 產品描述
- 輔助資訊
- 頁尾
2. 造成網站效能地下，載入時間變慢可能有一下原因：
- 不合格的虛擬主機服務
- 分配不均的頻寬
- 太多的廣告和外部服務
- 臃腫的介面設計和不相容的多媒體，包括圖片、視訊等等
- 過多的表格和表單
- 重定向過多
3. 測試頁面的載入時間，包括初始頁面速度、整頁載入時間 、不同地理位置的載入時間、網頁負載、Web伺服器CPU負載、網站資料庫效能
4.如何提高網站速度？
1）.影象優化
作為一般的經驗法則，較大的檔案比較小的檔案需要更長的時間下載。網頁下載時間（也稱為頁面載入時間）取決於從主機伺服器下載到請求瀏覽器的內容資源的總大小。高質量龐大的影象是網頁大小的最大貢獻者，降低了頁面速度，並激動地等待網頁載入的訪問者。
根據HTTP Archive，截至2017年12月，影象平均佔網頁總重量的66％。以下影象優化最佳做法可大大減少影象對網站速度的負面影響：
- 格式選擇：質量高的時候使用JPG格式，上傳之前不需要修改圖片。在影象質量急劇下降之前，JPG可以進行有限的處理和修改。對於帶有圖示，徽標，插圖，標誌和文字的影象，請使用PNG格式。使用GIF僅適用於較小或簡單的影象，並避免BMP或TIFF。
- 正確的大小：儲存有價值的影象有效載荷的位元組，並匹配您的網頁模板的尺寸（寬度）。使用瀏覽器大小調整功能，通過設定固定寬度和自動高度指令來使影象響應。
- 壓縮：影象壓縮應該是影象尺寸和質量之間的一個周到的折中。對於JPG，60-70％的壓縮產生了良好的平衡。對於視網膜螢幕，將影象尺寸（JPG）增加150-200％，壓縮30-40％，然後根據需要的尺寸重新縮小。
- 更少的影象：保持影象的數量絕對最低。
2）.優化CSS程式碼和交付
不久之前，30 KB被認為是理想的網頁大小。這包括製作整個頁面的影象，內容，圖形和程式碼。CSS和JavaScript的受歡迎程度在30 KB頁面大小的上限中提供了豐富的網站使用者體驗。
然而，以CSS編碼的現代網站更好地從託管伺服器向請求的瀏覽器下載內容。因此，優化並不是關於縮小檔案大小。以下最佳實踐確保了速度優化的CSS傳遞：
- 速記編碼：使用較少的宣告和運算子來縮減程式碼的大小。更少的程式碼行意味著更少的處理週期和有效的網站檔案交付給請求的瀏覽器。
- 斧頭瀏覽器特定的CSS黑客：由於瀏覽器特定的黑客攻擊（或稱為懲罰性宣告），CSS處於危險之中，從而給CSS指令碼檔案增加了不必要的重量。速度優化的CSS程式碼對於伺服器高效處理來說既簡單又簡單。
- 縮小CSS：幾乎所有的網站速度監測工具都提供了一個減少CSS程式碼重量以提高速度的共同建議。輕量級和緊湊的程式碼加速了下載，解析和執行，大大縮短了頁面載入時間。
- 程式碼定位：在本體的<head>和JavaScript內部載入CSS程式碼，因為在本部分之外引用CSS可以防止Web瀏覽器在下載後立即顯示CSS內容。
- CSS交付最佳實踐：
- 不要使用@import呼叫。
- 刪除未使用的CSS。
- 不要在HTML中使用CSS，例如H1和DIV標籤。
- 使用內嵌的小CSS。
3).減少- JavaScript，CSS，HTML
事實上，速度優化不僅僅是縮小頁面大小。減少向Web瀏覽器提供網站內容的客戶端 - 伺服器請求的數量是網站速度優化的一個組成部分。網站管理員可以通過不使用CSS，HTML和JavaScript請求做太多的人來實現這一點。雖然請求的數量不如以前那樣重要，這要歸功於HTTP / 2的改進。也就是說，優化，縮小和壓縮所有不必要和可壓縮的程式碼行。
對於嵌入式JavaScript和未快取的外部檔案，縮小比例尤為重要。Google建議縮小超過4096位元組大小的所有JavaScript檔案，並削減至少25個位元組，以使頁面載入時間產生明顯的差異。
設計速度優化的網站的一個嚴格的方法將強烈消除程式碼中不必要的位元組。利用所有可用的編碼空間，刪除多餘的空格，縮排和行空格，同時保持程式碼的可讀性，減少網站核心和前端檔案的整體大小。而對於已經沒有這個策略的開發者來說，將多個伺服器請求（對於HTML，JavaScript和CSS）組合成單個請求，從頁面載入時間中有效地縮減了相當大的塊。
但是，HTML Minification的過度放縱可能會導致網站程式碼保真度的丟失，而使用者代理會花費過多的記憶體週期和CPU來“猜測”解析HTLM檔案所需的缺失資源。監視頁面載入效能的變化，以響應實施每個縮小過程，確保只有不必要的程式碼和空間被刪除。
CSS，JavaScript和HTML的縮小具有共同的優點：減少網路延遲，減少HTML請求，增強壓縮，更快的瀏覽器下載和執行，最終提高網頁速度，並在網站測速工具上獲得更高的分數。
4).外掛 - 少即是多！
外掛的其他網站功能的價格是：效能下降。不幸的是，網站管理員部署了大量的外掛來新增吸引人的，但通常不必要的功能，如gravatar，配置檔案工具，網站統計和字型工具 - 有些甚至使用10個不同的外掛進行社交媒體整合。這裡唯一的好處是成功地避免了手動編碼。
許多受歡迎的網站帶有多達80個外掛。然而，如果安裝的外掛開發良好，以避免複雜的操作和昂貴的伺服器處理，這個數字並不完全是一個問題。
在選擇高質量外掛的四個主要領域：
- 它執行復雜的操作嗎？
- 它是否載入了許多內容資產和指令碼？
- 它是否增加了對每個頁面請求的資料庫查詢的數量？
- 它是否對外部API執行請求？
如果回答所有這些問題是YES，你有問題的外掛反應應該是一個巨大的NO！
現在到了一個大問題，有多少外掛太多了？
雖然這個問題沒有全面的答案，但是每個網站和外掛的限制都是獨一無二的。很多WordPress專家建議不要使用太多的外掛。但是許多執行良好的網站託管了80多個外掛，直到他們安裝了一個低質量的外掛，在頁面載入時間上增加了半秒。
同樣的，對於簡單和獨特的任務，使用10個外掛比部署一個外掛來完成所有複雜任務要好得多。例外包括可靠的開發人員的高品質的外掛，如Yoast的WordPress搜尋引擎優化外掛，所有在一個搜尋引擎優化包等。
5).優化資料庫
WordPress CMS將文章，評論，頁面和其他形式的文字和加密資料儲存在一個數據庫中 - 除了儲存在“wp_content”資料夾中的影象和視訊之外。隨著時間的推移，這個資料庫變得擁擠，不僅有不必要的內容和文章修訂，而且還有垃圾資料。
垃圾內容包括：
- 垃圾郵件佇列中的評論
- 未經批准的評論
- 釋出修訂
- 刪除了帖子和頁面等專案
資料庫優化圍繞著擺脫混亂的資料庫中的垃圾資料和無用內容，縮小它們的大小，並使網站託管伺服器能夠在最短的處理週期內有效地獲取請求的內容。這也可能涉及確保您正在使用InnoDB作為您的MySQL資料庫表，而不是MyISAM。瞭解如何將myISAM轉換為InnoDB。
當涉及到整體的WordPress和資料庫效能時，wp_options表也經常被忽略。特別是在大型網站上，由於第三方外掛和主題留下的自動載入資料，這可能是導致網站查詢速度緩慢的罪魁禍首。
6)壓縮
根據Google的說法，網路世界每天都會看到由於未壓縮的網頁內容而浪費了99年的時間。儘管大多數最新的Web瀏覽器都支援內容壓縮功能，但並不是每個網站都提供壓縮內容。這些佔用頻寬的網站的訪問者經歷了與Web頁面的瘋狂緩慢互動。這種不利的（而且大多是無意的）網站行為的主要原因包括配置錯誤的託管伺服器，Web代理，舊的或多錯的瀏覽器和防病毒軟體。
未經壓縮的內容會損害受到頻寬限制的使用者在長時間的頁面載入時間內收到Web內容。以下是提供未壓縮內容的通用瀏覽器 - 伺服器通訊的記錄：
瀏覽器：嘿，讓我/HeavyWeightChampion.html！
伺服器：在這上面！*伺服器瀏覽伺服器並找到檔案*
伺服器：你去，250 KB的響應程式碼。
瀏覽器：哎呀！*終端使用者流汗，最終在幾十秒內收到請求的內容*。（好吧，客戶端 - 伺服器通訊可能比上面的敘述更正式一些，也不那麼戲劇化）。
大部分問題在於HTML世界中客戶端 - 伺服器通訊的方式。HTML檔案（幾乎使整個Web內容）包含多個冗餘程式碼例項。<Tags>，<Alts>，<HTML>等等都是一樣的東西。
Google建議採用以下壓縮策略來高效地傳送網站內容：
- 縮小JavaScript，HTML和CSS
- 使用以下技術確保CSS和HTML程式碼的一致性：
- 一致的外殼 - 大部分是小寫的。
- HTML標籤屬性的一致引用。
- 以相同的順序指定HTML屬性。
- 按字母順序指定CSS鍵值對。
- 啟用GZIP壓縮。GZIP查詢類似的字串和程式碼例項，用較短的字元替換它們。瀏覽器解壓縮gzip檔案，使他們回到原來的形狀。
請注意幾句：
- 不要GZIP（已壓縮）的影象，PDF或其他二進位制資料。
- GZIP資料只能在150-1000位元組的範圍內。壓縮速度必須快於傳送未壓縮內容所用的時間。
- 不要為舊瀏覽器壓縮內容。
由於壓縮和解壓縮的開銷，不遵循上述建議實際上會增加檔案大小和頁面載入時間。
解決方案：
- 使用W3 Total Cache外掛啟用GZIP壓縮。
- 啟用GZIP壓縮的最佳方式是在Apache或Nginx的伺服器級別。看看我們的GZIP壓縮指南。
7)快取記憶體
開發人員渴望網站設計程式碼的簡單性。網站程式碼更容易建立，閱讀和維護導致高效的網站開發過程。這包括經常使用可用的程式碼功能來縮短特定網站功能的廣泛編碼。
但是，新增太多的無關迴圈和不必要的程式碼行會使頁面渲染時間縮短几毫秒。湧入網站流量的洪流，並毫秒複合降低頁面速度遠低於可接受的標準。
網站管理員可以通過提供所請求內容的快取副本來減少這些響應時間，而不是為了響應每個使用者請求對其伺服器的請求而重複呈現。Web快取是臨時儲存Web內容副本的機制，以滿足滿足特定條件時來自快取資料庫的後續使用者請求。此過程減少了將（靜態）網站內容傳送到請求的瀏覽器時所採用的客戶端 - 伺服器往返次數。
託管服務提供商不提供伺服器端快取時，網站所有者可以使用以下附件和配置啟用快取：
- W3總快取
- 快取記憶體啟動器
- WP Rocket
- 用於Nginx和Drupal伺服器的FastCGI Cache。
除了靜態可快取內容之外，網站還託管包含每個終端使用者定期更改的獨特屬性的動態資訊。因此，儲存非可重用動態內容的快取副本是沒有意義的，即使呈現非快取內容是一個非常緩慢的過程。
8).片段快取
這是快取不可快取的動態網站內容的較小元素的藝術。當載入包含靜態和/或動態內容的網頁時，託管伺服器處理PHP程式碼並查詢MySQL資料庫以獲取請求的內容。通過提供儲存為快取副本的所需輸出來規避這些時間和資源消耗過程。
片段快取儲存了一些程式碼塊的輸出，這些程式碼塊在不同版本的動態內容中保持不變。當代碼執行並達到快取預定時間的程式碼塊時，伺服器將查詢並傳遞此程式碼的快取輸出，而不是重複執行，直到達到時間限制。
最終結果是快取優化網站內容的最大頁面速度，即使是電子商務和基於會員的網站處理強烈的動態內容。Kinsta實際上提供了四種不同型別的快取，所有這些都是在軟體或伺服器級自動完成的。所以沒有必要混淆第三方外掛。
9).CDN
CDN是快取優化的擴充套件，旨在增強網站效能，專門針對全球分散的網路流量。CDN由承載網頁快取副本的伺服器網路組成。請求這些資訊的網際網路訪問者根據他們的地理位置被定向到這個網路內最近的伺服器。CDN的傳統優勢包括效能提升，高可用性和頁面排名，共同提升業務底線。看看你應該使用CDN的所有原因。Kinsta為所有客戶提供免費的HTTP / 2 CDN！
10).使用PHP 7
隨著PHP 7的釋出帶來了巨大的效能收益！以下基準測試顯示了PHP 7在以前的迭代中顯著的效能提升。與PHP 5.6相比，PHP 7允許系統執行每秒兩倍的請求，幾乎可以延遲一半的時間。
PHP Fluent Talk的Rasmus Lerdorf的PHP基準測試
去年，我們也使用PHP 5.6和PHP 7比較HHVM來執行我們自己的效能基準測試。與上面的基準類似，我們看到PHP 7的執行速度幾乎是PHP 5.6的三倍。
- PHP 7.0基準測試結果：306.24trans / sec
- PHP 5.6.16基準測試結果：106.45trans / sec
PHP 5.6和更高版本的PHP之間的效能差距是顯而易見的，這就是為什麼Kinsta總是提供最新的穩定版本。PHP 7.2已於11月30日正式釋出。我們還為需求更多的人提供HHVM。
轉載於:https://my.oschina.net/Shinsg/blog/1590836