深圳網站制作網頁加載前端性能思路
前端性能優化23條
Web應用的性能優化思路
網頁加載效果實現

前端性能優化23條
 1. 減少HTTP請求次數

盡量合并圖片、CSS、JS。比如加載一個頁面，如果有5個css文件的話，那么會發出5次http請求，這樣會讓用戶第一次訪問你的頁面的時候會長時間等待。而如果把這個5個文件合成一個的話，就只需要發出一次http請求，節省網絡請求時間，加快頁面的加載。
2. 使用CDN

網站上靜態資源即css、js全都使用cdn分發，圖片亦然。
3. 避免空的src和href

當link標簽的href屬性為空、script標簽的src屬性為空的時候，瀏覽器渲染的時候會把當前頁面的URL作為它們的屬性值，從而把頁面的內容加載進來作為它們的值。所以要避免犯這樣的疏忽。
4. 為文件頭指定Expires

ExiPRes是用來設置文件的過期時間的，一般對css、js、圖片資源有效。 他可以使內容具有緩存性，這樣下回再訪問同樣的資源時就通過瀏覽器緩存區讀取，不需要再發出http請求。

5. 使用gzip壓縮內容

gzip能夠壓縮任何一個文本類型的響應，包括html，xml，json。大大縮小請求返回的數據量。
6. 把CSS放到頂部

網頁上的資源加載時從上網下順序加載的，所以css放在頁面的頂部能夠優先渲染頁面，讓用戶感覺頁面加載很快。
7. 把JS放到底部

加載js時會對后續的資源造成阻塞，必須得等js加載完才去加載后續的文件 ，所以就把js放在頁面底部最后加載。
8. 避免使用CSS表達式

舉個css表達式的例子
font-color:expression((new Date()).getHours()%3 ? "#fff" : "#aaa");1

這個表達式會持續的在頁面上計算樣式，影響頁面的性能。并且css表達式只被IE支持。

9. 將CSS和JS放到外部文件中

目的是緩存文件，可以參考原則4。 但有時候為了減少請求，也會直接寫到頁面里，需根據PV和IP的比例權衡。
10. 權衡DNS查找次數

減少主機名可以節省響應時間。但同時，需要注意，減少主機會減少頁面中并行下載的數量。IE瀏覽器在同一時刻只能從同一域名下載兩個文件。當在一個頁面顯示多張圖片時，IE 用戶的圖片下載速度就會受到影響。所以新浪會搞N個二級域名來放圖片。

11精簡CSS和JS

這里就涉及到css和js的壓縮了。比如下面的新浪的一個css文件，把空格回車全部去掉，減少文件的大小。現在的壓縮工具有很多，基本主流的前端構建工具都能進行css和js文件的壓縮，如grunt，glup等。

web前端培訓

12. 避免跳轉

有種現象會比較坑爹，看起來沒什么差別，其實多次了一次頁面跳轉。比如當URL本該有斜杠（/）卻被忽略掉時。例如，當我們要訪問 http:// baidu.com 時，實際上返回的是一個包含301代碼的跳轉，它指向的是 http:// baidu.com/ （注意末尾的斜杠）。在nginx服務器可以使用rewrite；Apache服務器中可以使用Alias 或者 mod_rewrite或者the DirectorySlash來避免。  另一種是不用域名之間的跳轉， 比如訪問 http:// baidu.com/bbs 跳轉到 http:// bbs.baidu.com/ 。那么可以通過使用Alias或者mod_rewirte建立CNAME（保存一個域名和另外一個域名之間關系的DNS記錄）來替代。
13. 刪除重復的JS和CSS

重復調用腳本，除了增加額外的HTTP請求外，多次運算也會浪費時間。在IE和Firefox中不管腳本是否可緩存，它們都存在重復運算javaScript的問題。
14. 配置ETags

它用來判斷瀏覽器緩存里的元素是否和原來服務器上的一致。比last-modified date更具有彈性，例如某個文件在1秒內修改了10次，Etag可以綜合Inode(文件的索引節點(inode)數)，MTime(修改時間)和Size來精準的進行判斷，避開UNIX記錄MTime只能精確到秒的問題。 服務器集群使用，可取后兩個參數。使用ETags減少Web應用帶寬和負載
15. 可緩存的Ajax

異步請求同樣的造成用戶等待，所以使用ajax請求時，要主動告訴瀏覽器如果該請求有緩存就去請求緩存內容。如下代碼片段, cache:true就是顯式的要求如果當前請求有緩存的話，直接使用緩存
$.ajax({ url : 'url', dataType : "json", cache: true, success : function(son, status){}, error : function(){} })1234567
16. 使用GET來完成AJAX請求

當使用xmlhttpRequest時，瀏覽器中的POST方法是一個“兩步走”的過程：首先發送文件頭，然后才發送數據。因此使用GET獲取數據時更加有意義。
17. 減少DOM元素數量

這是一門大學問，這里可以引申出一堆優化的細節。想要具體研究的可以看后面推薦書籍。總之大原則減少DOM數量，就會減少瀏覽器的解析負擔。
18. 避免404

比如外鏈的css、js文件出現問題返回404時，會破壞瀏覽器的并行加載。

19. 減少Cookie的大小

Cookie里面別塞那么多東西，因為每個請求都得帶著他跑。
20. 使用無cookie的域

比如CSS、js、圖片等，客戶端請求靜態文件的時候，減少了 Cookie 的反復傳輸對主域名的影響。

21. 不要使用濾鏡

IE獨有屬性AlphaImageLoader用于修正7.0以下版本中顯示PNG圖片的半透明效果。這個濾鏡的問題在于瀏覽器加載圖片時它會終止內容的呈現并且凍結瀏覽器。在每一個元素（不僅僅是圖片）它都會運算一次，增加了內存開支，因此它的問題是多方面的。  完全避免使用AlphaImageLoader的最好方法就是使用PNG8格式來代替，這種格式能在IE中很好地工作。如果你確實需要使用AlphaImageLoader，請使用下劃線_filter又使之對IE7以上版本的用戶無效。
22. 不要在HTML中縮放圖片

比如你需要的圖片尺寸是50* 50，那就不用用一張500*500的大尺寸圖片，影響加載（說到這里可能有朋友會說了，后臺上傳的圖片我也沒辦法控制他上傳的尺寸啊，這里只是說的最開始做靜態頁面的時候的一些注意事項，至于后面怎么去操作，那就看網編怎么辦了，盡可能把自己能做的做到最好就行了）
23. 縮小favicon.ico并緩存

以上是Yslow的23個優化原則，基本可以涵蓋現在前端大部分的性能優化原則了，很多更加geek和精細優化方法都是從這些原則里面延伸出來的。

前端優化是條漫長的路，不是說一天兩天就能全部做完的。我們可以參考上面的準則去把我們目前能做的都給優化了，剩下的更加小的一些細節點不用太過著急，畢竟也是要考慮優化性價比的。比如為了減小一個文件幾個字節花上個把月根本不值得。這些優化的東西都可以在我們的工作中慢慢去通過積累，去通過google解決。

網頁加載效果實現
<style>
/*opacity是設置遮罩透明度的，可以自己調節*/
#loading{position:fixed;top:0;left:0;width:100%;height:100%;background:#f8f8f8;opacity:1;z-index:15000;}
#loading img{position:absolute;top:46%;left:46%;width:150px;height:150px;margin-top:-15px;margin-left:-15px;}
</style>

<div id="loading">
    <img alt="" src="__PUBLIC__/img/timg.gif"><br>
</div>
<script>
document.onreadystatechange = completeLoading;
     
     //加載狀態為complete時移除loading效果
    function completeLoading() {
      if (document.readyState == "complete") {
        $("#loading").hide();
      }

Web應用的性能優化思路
 一個Web應用，不管是何種語言開發，粗略的結構無非是三層：

1. 頁面模板

可以是jsp、asp、php等頁面技術，根據數據生成最終的HTML頁面，性能關鍵指標只有一個，頁面的渲染速度。綜合各種頁面技術而言，渲染速度相差不會太大，10倍以內。

2. 業務邏輯

用于根據業務需要將數據庫中的數據讀取到內存中，以便通過頁面模板渲染成HTML頁面。這里面可能還包括緩存、連接池等技術。

3. 數據庫

就是數據庫，負責執行SQL查詢并返回查詢結果。

我們假設用戶訪問一個頁面，也就是請求一個URL地址，然后得到內容，所需要的時間是3秒鐘。其中大部分時間可能用在網絡傳輸上，而真正頁面執行并生成HTML內容所需的時間是很小的，這里假設需要100毫秒。

相當于用戶花了兩秒多鐘在傳輸數據上，這部分時間如果能縮減，可以大大提升訪問的速度，但是這部分一般也難以提升了，因為取決于用戶本身的網絡情況，服務器的網絡情況以及中間整個路由的情況。對于一個網站來說，能做的就是盡可能的提升服務器的帶寬，或者使用CDN來減少中間路由環節，很不幸的是，這個成本很高。

好吧，前面提到的更多是非技術因素，假設你已經耗費巨資解決了這個問題，然后突然發現網絡太快了，可是服務器頂不住了，生成一個頁面居然要100毫秒，才幾十個并發用戶就差點要把服務器搞崩潰了。

于是來到了本文的重點部分——找出應用的性能瓶頸。

前面我們提到的結構中的三層：頁面模板，業務邏輯和數據庫，根據經驗值，在這100毫秒中，三個部分占用的時間差不多為：頁面模板(5%)、業務邏輯+數據庫(95%)。

幾個準則：

1. 沒必要去優化頁面模板，這都是一些很成熟的技術，就算你好不容易提升了10%的性能，這10%在整個頁面的執行過程中只占了0.5%的比例，微乎其微，等于是前面例子中的4車道變8車道的傻瓜，我們不要去充當傻瓜。

2. 一般瓶頸所在以及相應處理辦法
數據庫連接：使用連接池來減少連接次數重復的數據庫查詢：使用緩存來避免重復的數據庫查詢慢查詢：使用索引來提升查詢速度，使用連接查詢替換子查詢等

簡簡單單的三條，里面卻包含了很深的功夫，特別是在數據庫查詢優化上。

你必須在充分解決了這些應用程序所屬的性能瓶頸之后，再去考慮系統級別的優化。

深圳制作網站

一些常用系統級別優化包括：

1. 靜態文件和動態頁面分開處理 2. 應用服務器的集群 3. 數據庫的集群

不要本末倒置，一個性能很差的應用程序，你就算集群了100個節點，也不會有什么效果。

所以Web網站優化三部曲：應用程序優化、