為**：具體看位址
yahoo提高**效能34條最佳實踐一
對於前台後台程式設計師 下面這些都應該是大家在工作要注意的
減少http請求
一種減少資源數量的方法是簡化頁面的設計（- - ||真是個好主意）。但有沒有方法在獲取快速響應的前提下有乙個豐富內容的頁面呢？這裡有一些能夠在不減少頁面內容的前提下減少http請求數的技術。
合併檔案是一種通過把所有指令碼合併到乙個指令碼中來達到減少http請求數目地的方法，同樣也適用於css。在不同頁面需要不同指令碼和樣式表的情況下要合併檔案顯的更為困難，但是把這個做為你發布工程的一部分來改善響應時間。
css sprites是乙個很好的減少請求數的技巧。把你的背景圖合併到一張中，使用css的background-image和background-position屬性去顯示需要的部分。
image maps把多張合併到一張上。整體的尺寸幾乎相同，但是因為減少了http請求數而加速了頁面的顯示。image maps僅僅在連續使用的下才能起作用，如導航條。制定image maps的座標是一件枯燥，容易出錯的工作。使用image maps的導航條也不易於訪問，所以這個不被推薦。
inline images 使用data: url scheme來將資料嵌入到實際頁面中。這樣做會增加html文件的體積。把inline images合併到你的樣式表中能夠在避免頁面體積增大的前提下減少http請求。inline images目前還被所有主流瀏覽器支援。
為你的頁面減少http請求數是第一步。這是改善初次訪客體驗的最重要的原則。正如tenni theurer的部落格文章browser cache usage - exposed!中描述的那樣，40-60%的**日常訪客都是以乙個空快取的狀態進入的。因此為那些初次訪客（事實上是空快取使用者）優化是獲得乙個良好使用者體驗的關鍵。
使用cdn（content delivery network）
按地域布置**內容的第一步並不是要嘗試重新架構你的**讓他們在分發伺服器上正常執行。根據應用的需求來改變**結構，這可能會包括一些比較複雜的任務，如在伺服器間同步session狀態和合併資料庫更新等。要想縮短使用者和內容伺服器的距離，這些架構步驟可能是不可避免的。
內容分發網路（content delivery network，cdn）是由一系列分散到各個不同地理位置上的web伺服器組成的，它提高了**內容的傳輸速度。用於向使用者傳輸內容的伺服器主要是根據和使用者在網路上的靠近程度來指定的。例如，擁有最少網路跳數（network hops）和響應速度最快的伺服器會被選定。
一些大型的網路公司擁有自己的cdn，但是使用像akamai technologies，mirror image internet， 或者limelight networks這樣的cdn服務成本卻非常高。對於剛剛起步的企業和個人**來說，可能沒有使用cdn的成本預算，但是隨著目標使用者群的不斷擴大和更加全球化，cdn就是實現快速響應所必需的了。以yahoo來說，他們轉移到cdn上的**程式靜態內容節省了終端使用者20%以上的響應時間。使用cdn是乙個只需要相對簡單地修改**實現顯著改善**訪問速度的方法。
新增乙個expire或者快取控制的頭部
在這個規則中有兩個要點：
對於靜態的資源：通過設定超長的過期頭部實行「永不過期」策略
對於動態的資源：使用乙個合適的快取控制頭部來幫助瀏覽器處理有條件的請求。
網頁設計得越來越豐富多彩，這意味著更多的指令碼，樣式表，和flash存在於網頁上。乙個網頁的初次訪客需要傳送一些 http請求，通過設定過期頭部你可以快取這些資源。從而在使用者訪問接下來的頁面時避免了不必要的http請求。過期頭部常用於，實際上應該對所有資源應用過期頭部包括指令碼，樣式表和flash等。
瀏覽器（和**）使用乙個快取來減少ｈｔｔｐ請求的數量和尺寸，使得網頁載入得更快。乙個伺服器在http響應中使用過期頭部來告訴客戶端乙個資源能夠被快取多久。下面是乙個超長的過期頭部，告訴瀏覽器這個資源在2023年4月15前不會過期。
expires: thu, 15 apr 2010 20:00:00 gmt
如果你伺服器是apache，使用exiresdefault設定乙個過期時間。這是乙個把過期時間設定到10年以後的例子。
expiresdefault 「access plus 10 years」
記得，如果你使用乙個超長的過期頭部，你如果想改動資源就必須改資源的名稱。在yahoo!我們常常把這個做為發布過程中的一部分：乙個版本號被做為資源名稱的組成部分，例如，yahoo_2.0.6.js
使用乙個超長的過期頭部只在使用者已經訪問你的**以後產生影響。當乙個初次訪問，空快取的使用者來到你的**時它是不起作用的。
把資源gzip
網路傳輸中的http請求和應答時間可以通過前端機制得到顯著改善。的確，終端使用者的頻寬、網際網路提供者、與對等交換點的靠近程度等都不是**開發者所能決定的。但是還有其他因素影響著響應時間。通過減小http響應的大小可以節省http響應時間。
從http/1.1開始，web客戶端都預設支援http請求中有accept-encoding檔案頭的壓縮格式：
accept-encoding: gzip, deflate
如果web伺服器在請求的檔案頭中檢測到上面的**，就會以客戶端列出的方式壓縮響應內容。web伺服器把壓縮方式通過響應檔案頭中的content-encoding來返回給瀏覽器。
content-encoding: gzip
gzip是目前最流行也是最有效的壓縮方式。這是由gnu專案開發並通過rfc 1952來標準化的。另外僅有的乙個壓縮格式是deflate，但是它的使用範圍有限效果也稍稍遜色。
gzip大概可以減少70%的響應規模。目前大約有90%通過瀏覽器傳輸的網際網路交換支援gzip格式。如果你使用的是apache，gzip模組配置和你的版本有關：apache 1.3使用mod_zip，而apache 2.x使用moflate。
瀏覽器和**都會存在這樣的問題：瀏覽器期望收到的和實際接收到的內容會存在不匹配的現象。幸好，這種特殊情況隨著舊式瀏覽器使用量的減少在減少。apache模組會通過自動新增適當的vary響應檔案頭來避免這種狀況的出現。
伺服器根據檔案型別來選擇需要進行gzip壓縮的檔案，但是這過於限制了可壓縮的檔案。大多數web伺服器會壓縮html文件。對指令碼和樣式表進行壓縮同樣也是值得做的事情，但是很多web伺服器都沒有這個功能。實際上，壓縮任何乙個文字型別的響應，包括xml和json，都值得的。影象和pdf檔案由於已經壓縮過了所以不能再進行gzip壓縮。如果試圖gizp壓縮這些檔案的話不但會浪費cpu資源還會增加檔案的大小。
gzip壓縮所有可能的檔案型別是減少檔案體積增加使用者體驗的簡單方法。
把樣式表放在頂端
注重效能的前端伺服器往往希望頁面有秩序地載入。同時，我們也希望瀏覽器把已經接收到內容盡可能顯示出來。這對於擁有較多內容的頁面和網速較慢的使用者來說特別重要。向使用者返回視覺化的反饋，比如程序指標，已經有了較好的研究並形成了正式文件。在我們的研究中html頁面就是程序指標。當瀏覽器有序地載入檔案頭、導航欄、頂部的logo等對於等待頁面載入的使用者來說都可以作為視覺化的反饋。這從整體上改善了使用者體驗。
把樣式表放在文件底部的問題是在包括internet explorer在內的很多瀏覽器中這會中止內容的有序呈現。瀏覽器中止呈現是為了避免樣式改變引起的頁面元素重繪。使用者不得不面對乙個空白頁面。
html規範清楚指出樣式表要放包含在頁面的區域內：「和不同，只能出現在文件的區域內，儘管它可以多次使用它」。無論是引起白屏還是出現沒有樣式化的內容都不值得去嘗試。最好的方案就是按照html規範在文件內載入你的樣式表。
優化建議 儲存效能優化。
在 應用中，海量的資料讀寫對磁碟訪問造成巨大壓力，雖然可以通過cache解決一部分資料讀壓力，但是很多時候，磁碟仍然是系統最嚴重的瓶頸。而且磁碟中儲存的資料是 最重要的資產，磁碟的可用性和容錯性也至關重要。機械硬碟是目前最常用的一種硬碟，通過馬達驅動磁頭臂，帶動磁頭到指定的磁碟位置訪問資料，由於每次...
React Native 效能優化建議
react native 雖然一直標榜媲美native的體驗，但實際使用下來，其渲染性還是非常低效，基於scrollview和listview兩大容器，在渲染上，相當於web端的table布局，需要等整個大table渲染完成才顯示頁面，也就是說，當容器內有大量的子元素，其白屏時間會非常長。如何讓re...
Android效能優化建議
android效能優化主要從卡頓 記憶體洩漏和崩潰 質量和邏輯 安裝包過大四方面入手。在使用時避免出現卡頓，響應速度快，減少使用者等待的時間，滿足使用者期望 同時減低 crash 率和 anr 率，不要在使用者使用過程中崩潰和無響應 節省流量和耗電，減少使用者使用成本，避免使用時導致手機發燙 安裝包...