web性能優化

經常使用方法

壓縮源碼和圖片
　　JavaScript文件源代碼：能夠採用混淆壓縮的方式，CSS文件源代碼進行普通壓縮，JPG圖片能夠根據具體質量來壓縮爲50%到70%，PNG可 以使用一些開源壓縮軟件來壓縮，好比24色變成8色、去掉一些PNG格式信息等。
　　選擇合適的圖片格式：若是圖片顏色數較多就使用JPG格式，若是圖片顏色數較少就使用PNG格式，若是可以經過服務器端判斷瀏覽器支持WebP，那麼就使用WebP格式和 SVG格式。
合併靜態資源
　　包括CSS、JavaScript和小圖片，減小HTTP請求。
開啓服務器端的Gzip壓縮
　　這對文本資源很是有效，對圖片資源則沒那麼大的壓縮比率。
使用CDN 或者一些公開庫使用第三方提供的靜態資源地址
　　好比jQuery、normalize.css。一方面增長併發下載量，另外一方面可以和其餘網站共享緩存。
延長靜態資源緩存時間

　　頻繁訪問網站的訪客就可以更快地訪問。不過，這裏要經過修改文件名的方式，確保在資源更新的時候，用戶會拉取到最新的內容。

CSS引用放在頁面頭部，JavaScript引用放在頁面底部

　　這樣就不會阻塞頁面渲染，讓頁面出現長時間的空白。

前端工程師的性能優化

基本優化方法是：

• 儘可能減小同一域下的HTTP請求數
• 以及儘可能減小每個資源的體積

　　瀏覽器經常限定了對同一域名發起的併發鏈接數的上限。E6/7和Firefox2的設計規則是，同時只能對一個域名發起兩個併發鏈接。新版瀏覽器廣泛上限設定爲4至8個。

　 　把靜態資源放在非主域名下，這種作法除了能夠增長瀏覽器併發，還有一個好處是，減小HTTP請求中攜帶的沒必要要的cookie數據。cookie是某些 網站爲了辨別用戶身份而儲存在用戶瀏覽器中的數據。cookie的做用域是整個域名，也就是說若是某個cookie存放在google.com域名下，那 麼對於google.com域名下的全部HTTP請求頭都會帶上cookie數據。

　　若是Google把全部的資源都放在google.com下，那麼全部資源的請求都會帶上cookie數據。對於靜態資源來講，這是毫無必要的，由於這對帶寬和連接速度都形成了影響。
　 　前端工程師常常作的優化是合併同一域名下的資源，好比把多個CSS合併爲一個CSS，或者將圖片組合爲CSS貼圖，還有一些優化建議是省掉沒必要要的 HTTP請求，好比內嵌小型CSS、內嵌小型JavaScript、設置緩存，以及減小重定向。這些作法雖然各不相同，可是若是瞭解HTTP請求的過程， 就知道這些優化方法的最終目的都是最大化利用有限的請求數。
　　一個基礎題目是「經常使用的圖片格式有哪些，它們的使用場景是什麼」。對圖片的敏感性反映出工程師對帶寬和速度的不懈追求。比較大的文本資源，必須開啓gzip壓縮。
對於一個CSS資源的請求耗時（兩個細節）：
　　這個CSS資源請求的體積是36.4KB（這是gzip壓縮過的體積），解壓縮以後，CSS內容其實是263KB，能夠算出壓縮後體積是原來的13.8%。
　　整個鏈接的創建花費了30%的時間，發出請求到等待收到第一個字節回覆花費了20%的時間，下載CSS資源的內容花費了50%的時間。

後臺工程師的性能優化

　　對於HTTP的關注在於讓服務器儘快響應請求，以及減小請求對服務器的開銷
　　一、提升服務器的請求處理能力: Apache 經過模塊化的設計來適應各類環境，其中一個模塊叫作多處理模塊（MPM），專門用來處理多請求的狀況。Apache安裝在不一樣系統上的時候會調用不一樣的默 認MPM，咱們不用關心具體的細節，只須要了解Unix上默認的MPM是prefork。爲了優化，咱們能夠改爲worker模式。
　　 prefork和worker模式的最大區別就是：prefork 的一個進程維持一個鏈接，而worker的一個線程維持一個鏈接。因此prefork更穩定但內存消耗也更大，worker沒有那麼穩定，由於不少鏈接的 線程共享一個進程，當一個線程崩潰的時候，整個進程和全部線程一塊兒死掉。可是worker的內存使用要比prefork低得多，因此很適合用在高HTTP 請求的服務器上。

Apache和Nginx：
　　在高鏈接併發的狀況 下，Nginx是Apache服務器不錯的替代品或者補充：一方面是Nginx更加輕量級，佔用更少的資源和內存；另外一方面是Nginx 處理請求是異步非阻塞的，而Apache 則是阻塞型的，在高併發下Nginx 能保持低資源、低消耗和高性能。——因爲Apache和Nginx各有所長，因此常常的搭配是Nginx處理前端併發，Apache處理後臺請求。新秀 Node.js也是採用基於事件的異步非阻塞方式處理請求，因此在處理高併發請求上有自然的優點。
　　二、高性能網站的關鍵：緩存
　　在一個Web站點中，它的數據流從服務器端到瀏覽器端，哪些地方可使用緩存來優化：

• 服務器緩存
• 數據庫緩存

　　基本的數據庫查詢緩存——能夠開啓MySQL查詢緩存來提升速度，而且減小系統壓力

　　MySQL默認不開啓查詢緩存，但咱們能夠經過修改MySQL安 裝目錄中的my.ini來設置查詢緩存。設置的時候能夠根據實際狀況配置緩衝區大小、單個查詢的緩衝區大小等。

若是您但願優化MySQL服務器的查詢性能 和速度，能夠在MySQL配置中增長這兩項:

1. query_cache_size=SIZE SIZE是指爲查詢緩存開闢多大的空間。默認是0，也就是禁用查詢緩存。
2. query_cache_type=OPTION 設置查詢緩存的類型，可選的值有如下這三種。
   • 0：設置查詢緩存的類型，可選的值有如下這三種。
   • 1：全部的緩存結果都緩存起來，除非查詢命令以SELECT S_NO_CACHE開始。
   • 2：只緩存查詢命令以SELECT SQL_CACHE開始的查詢結果。

——問題是「緩存命中率不高」，因此配置緩存以後第一件事就是查詢命中率，若是命中率低，不如不作緩存。數據庫查詢緩存的一個設計原則：其緩存失效設計是很粗糙的——保證明時性可犧牲命中率??

　　擴展數據庫緩存：memcached　 　memcached應運而生，它是一個高性能分佈式內存對象緩存系統，用於減輕數據庫負載。它經過在內存中緩存數據和對象來減小讀取數據庫的次數，從而 提升動態、數據庫驅動網站的速度。memcached能夠與數據庫查詢緩存配合使用。memcached的設計原則是：時間過時，即只有設定的時間到了才 去更新數據，提升了命中率，但有多是」不新鮮的「。