国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

前端的性能優化(針對內容方面)

coordinate35 / 2262人閱讀

摘要:避免重定向重定向用和狀態碼,下面是一個有狀態碼的頭瀏覽器會自動跳轉到域指明的。除此之外還有別的跳轉方式元標簽和,但如果你必須得做重定向,最好用標準的狀態碼,主要是為了讓返回按鈕能正常使用。要提高性能,優化這些響應至關重要。

性能優化

減少Http請求:

1.盡量減少HTTP請求數   80%的終端用戶響應時間都花在了前端上,其中大部分時間都在下載頁面上的各種組件:圖片,樣式表,腳本,Flash等等。減少組件數必然能夠減少頁面提交的HTTP請求數。這是讓頁面更快的關鍵。

2.減少頁面組件數的一種方式是簡化頁面設計。但有沒有一種方法可以在構建復雜的頁面同時加快響應時間呢?嗯,確實有魚和熊掌兼得的辦法。

3.合并文件是通過把所有腳本放在一個文件中的方式來減少請求數的,當然,也可以合并所有的CSS。如果各個頁面的腳本和樣式不一樣的話,合并文件就是一項比較麻煩的工作了,但把這個作為站點發布過程的一部分確實可以提高響應時間。

4.CSS Sprites是減少圖片請求數量的首選方式。把背景圖片都整合到一張圖片中,然后用CSS的background-image和background-position屬性來定位要顯示的部分。

5.圖像映射可以把多張圖片合并成單張圖片,總大小是一樣的,但減少了請求數并加速了頁面加載。圖片映射只有在圖像在頁面中連續的時候才有用,比如導航條。給image map設置坐標的過程既無聊又容易出錯,用image map來做導航也不容易,所以不推薦用這種方式。

6.行內圖片(Base64編碼)用data: URL模式來把圖片嵌入頁面。這樣會增加HTML文件的大小,把行內圖片放在(緩存的)樣式表中是個好辦法,而且成功避免了頁面變“重”。但目前主流瀏覽器并不能很好地支持行內圖片。

7.減少頁面的HTTP請求數是個起點,這是提升站點首次訪問速度的重要指導原則。


減少DNS查找:

1.域名系統建立了主機名和IP地址間的映射,就像電話簿上人名和號碼的映射一樣。當你在瀏覽器輸入www.yahoo.com的時候,瀏覽器就會聯系DNS解析器返回服務器的IP地址。DNS是有成本的,它需要20到120毫秒去查找給定主機名的IP地址。在DNS查找完成之前,瀏覽器無法從主機名下載任何東西。

2.DNS查找被緩存起來更高效,由用戶的ISP(網絡服務提供商)或者本地網絡存在一個特殊的緩存服務器上,但還可以緩存在個人用戶的計算機上。DNS信息被保存在操作系統的DNS cache(微軟Windows上的”DNS客戶端服務”)里。大多數瀏覽器有獨立于操作系統的自己的cache。只要瀏覽器在自己的cache里還保留著這條記錄,它就不會向操作系統查詢DNS。

3.IE默認緩存DNS查找30分鐘,寫在DnsCacheTimeout注冊表設置中。Firefox緩存1分鐘,可以用network.dnsCacheExpiration配置項設置。(Fasterfox把緩存時間改成了1小時 P.S. Fasterfox是FF的一個提速插件)

4.如果客戶端的DNS cache是空的(包括瀏覽器的和操作系統的),DNS查找數等于頁面上不同的主機名數,包括頁面URL,圖片,腳本文件,樣式表,Flash對象等等組件中的主機名,減少不同的主機名就可以減少DNS查找。

5.減少不同主機名的數量同時也減少了頁面能夠并行下載的組件數量,避免DNS查找削減了響應時間,而減少并行下載數量卻增加了響應時間。我的原則是把組件分散在2到4個主機名下,這是同時減少DNS查找和允許高并發下載的折中方案。


避免重定向 重定向用301和302狀態碼,下面是一個有301狀態碼的HTTP頭:

1.HTTP/1.1 301 Moved Permanently Location: http://example.com/newuri Content-Type: text/html   瀏覽器會自動跳轉到Location域指明的URL。重定向需要的所有信息都在HTTP頭部,而響應體一般是空的。其實額外的HTTP頭,比如Expires和Cache-Control也表示重定向。除此之外還有別的跳轉方式:refresh元標簽和JavaScript,但如果你必須得做重定向,最好用標準的3xxHTTP狀態碼,主要是為了讓返回按鈕能正常使用。

2.牢記重定向會拖慢用戶體驗,在用戶和HTML文檔之間插入重定向會延遲頁面上的所有東西,頁面無法渲染,組件也無法開始下載,直到HTML文檔被送達瀏覽器。

3.有一種常見的極其浪費資源的重定向,而且web開發人員一般都意識不到這一點,就是URL尾部缺少一個斜線的時候。例如,跳轉到http://astrology.yahoo.com/as...://astrology.yahoo.com/astrology/的301響應(注意添在尾部的斜線)。在Apache中可以用Alias,mod_rewrite或者DirectorySlash指令來取消不必要的重定向。

4.重定向最常見的用途是把舊站點連接到新的站點,還可以連接同一站點的不同部分,針對用戶的不同情況(瀏覽器類型,用戶帳號類型等等)做一些處理。用重定向來連接兩個網站是最簡單的,只需要少量的額外代碼。雖然在這些時候使用重定向減少了開發人員的開發復雜度,但降低了用戶體驗。一種替代方案是用Alias和mod_rewrite,前提是兩個代碼路徑都在相同的服務器上。如果是因為域名變化而使用了重定向,就可以創建一條CNAME(創建一個指向另一個域名的DNS記錄作為別名)結合Alias或者mod_rewrite指令。


讓Ajax可緩存:

1.Ajax的一個好處是可以給用戶提供即時反饋,因為它能夠從后臺服務器異步請求信息。然而,用了Ajax就無法保證用戶在等待異步JavaScript和XML響應返回期間不會非常無聊。在很多應用程序中,用戶能夠一直等待取決于如何使用Ajax。例如,在基于web的電子郵件客戶端中,用戶為了尋找符合他們搜索標準的郵件消息,將會保持對Ajax請求返回結果的關注。重要的是,要記得“異步”并不意味著“即時”。

2.要提高性能,優化這些Ajax響應至關重要。最重要的提高Ajax性能的方法就是讓響應變得可緩存,就像在添上Expires或者Cache-Control HTTP頭中討論的一樣。下面適用于Ajax的其它規則:

3.Gzip組件 減少DNS查找 壓縮JavaScript 避免重定向 配置ETags   我們一起看看例子,一個Web 2.0的電子郵件客戶端用了Ajax來下載用戶的通訊錄,以便實現自動完成功能。如果用戶從上一次使用之后再沒有修改過她的通訊錄,而且Ajax響應是可緩存的,有尚未過期的Expires或者Cache-Control HTTP頭,那么之前的通訊錄就可以從緩存中讀出。必須通知瀏覽器,應該繼續使用之前緩存的通訊錄響應,還是去請求一個新的。可以通過給通訊錄的Ajax URL里添加一個表明用戶通訊錄最后修改時間的時間戳來實現,例如&t=1190241612。如果通訊錄從上一次下載之后再沒有被修改過,時間戳不變,通訊錄就將從瀏覽器緩存中直接讀出,從而避免一次額外的HTTP往返消耗。如果用戶已經修改了通訊錄,時間戳也可以確保新的URL不會匹配緩存的響應,瀏覽器將請求新的通訊錄條目。

4.即使Ajax響應是動態創建的,而且可能只適用于單用戶,它們也可以被緩存,而這樣會讓你的Web 2.0應用更快。


延遲加載組件:

可以湊近看看頁面并問自己:什么才是一開始渲染頁面所必須的?其余內容都可以等會兒。

1.JavaScript是分隔onload事件之前和之后的一個理想選擇。例如,如果有JavaScript代碼和支持拖放以及動畫的庫,這些都可以先等會兒,因為拖放元素是在頁面最初渲染之后的。其它可以延遲加載的部分包括隱藏內容(在某個交互動作之后才出現的內容)和折疊的圖片。

2.工具可幫你減輕工作量:YUI Image Loader可以延遲加載折疊的圖片,還有YUI Get utility是一種引入JS和CSS的簡單方法。Yahoo!主頁就是一個例子,可以打開Firebug的網絡面板仔細看看。

3.最好讓性能目標符合其它web開發最佳實踐,比如“漸進增強”。如果客戶端支持JavaScript,可以提高用戶體驗,但必須確保頁面在不支持JavaScript時也能正常工作。所以,在確定頁面運行正常之后,可以用一些延遲加載腳本增強它,以支持一些拖放和動畫之類的華麗效果。


預加載組件:

預加載可能看起來和延遲加載是相反的,但它其實有不同的目標。通過預加載組件可以充分利用瀏覽器空閑的時間來請求將來會用到的組件(圖片,樣式和腳本)。用戶訪問下一頁的時候,大部分組件都已經在緩存里了,所以在用戶看來頁面會加載得更快。

實際應用中有以下幾種預加載的類型:

1.無條件預加載——盡快開始加載,獲取一些額外的組件。google.com就是一個sprite圖片預加載的好例子,這個sprite圖片并不是google.com主頁需要的,而是搜索結果頁面上的內容。 條件性預加載——根據用戶操作猜測用戶將要跳轉到哪里并據此預加載。在search.yahoo.com的輸入框里鍵入內容后,可以看到那些額外組件是怎樣請求加載的。 提前預加載——在推出新設計之前預加載。經常在重新設計之后會聽到:“這個新網站不錯,但比以前更慢了”,一部分原因是用戶訪問先前的頁面都是有舊緩存的,但新的卻是一種空緩存狀態下的體驗。可以通過在將要推出新設計之前預加載一些組件來減輕這種負面影響,老站可以利用瀏覽器空閑的時間來請求那些新站需要的圖片和腳本。


減少DOM元素的數量:

一個復雜的頁面意味著要下載更多的字節,而且用JavaScript訪問DOM也會更慢。舉個例子,想要添加一個事件處理器的時候,循環遍歷頁面上的500個DOM元素和5000個DOM元素是有區別的。

1.大量的DOM元素是一種征兆——頁面上有些內容無關的標記需要清理。正在用嵌套表格來布局嗎?還是為了修復布局問題而添了一堆的

s?或許應該用更好的語義化標記。

2.YUI CSS utilities對布局有很大幫助:grids.css針對整體布局,fonts.css和reset.css可以用來去除瀏覽器的默認格式。這是個開始清理和思考標記的好機會,例如只在語義上有意義的時候使用

,而不是因為它能夠渲染一個新行。

3.DOM元素的數量很容易測試,只需要在Firebug的控制臺里輸入:

document.getElementsByTagName(‘*’).length

4.那么多少DOM元素才算是太多呢?可以參考其它類似的標記良好的頁面,例如Yahoo!主頁是一個相當繁忙的頁面,但只有不到700個元素(HTML標簽)。


跨域分離組件:

1.分離組件可以最大化并行下載,但要確保只用不超過2-4個域,因為存在DNS查找的代價。例如,可以把HTML和動態內容部署在www.example.org,而把靜態組件分離到static1.example.org和static2.example.org。

后續還會整理,目前對性能的優化先寫這么多........

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/54902.html

相關文章

  • 前端性能優化常用總結

    摘要:前言對于前端的性能話題,從來都沒有斷絕過。作為一個前端開發者,性能是我們關注的指標。前端發展以來,優化方式,琳瑯滿目,有雅虎軍規等。所以,接下來我會從三個方面就前端性能進行總結網絡方面操作及渲染方面數據方面。 前言 對于前端的性能話題,從來都沒有斷絕過。因為這個東西沒有最好,只有更好。而且往往也是業務的繁雜程度去決定優化程度的。作為一個前端開發者,性能是我們關注的指標。它直接影響著我們...

    oliverhuang 評論0 收藏0
  • 前端性能優化常用總結

    摘要:前言對于前端的性能話題,從來都沒有斷絕過。作為一個前端開發者,性能是我們關注的指標。前端發展以來,優化方式,琳瑯滿目,有雅虎軍規等。所以,接下來我會從三個方面就前端性能進行總結網絡方面操作及渲染方面數據方面。 前言 對于前端的性能話題,從來都沒有斷絕過。因為這個東西沒有最好,只有更好。而且往往也是業務的繁雜程度去決定優化程度的。作為一個前端開發者,性能是我們關注的指標。它直接影響著我們...

    walterrwu 評論0 收藏0
  • 前端性能優化常用總結

    摘要:前言對于前端的性能話題,從來都沒有斷絕過。作為一個前端開發者,性能是我們關注的指標。前端發展以來,優化方式,琳瑯滿目,有雅虎軍規等。所以,接下來我會從三個方面就前端性能進行總結網絡方面操作及渲染方面數據方面。 前言 對于前端的性能話題,從來都沒有斷絕過。因為這個東西沒有最好,只有更好。而且往往也是業務的繁雜程度去決定優化程度的。作為一個前端開發者,性能是我們關注的指標。它直接影響著我們...

    luzhuqun 評論0 收藏0
  • 前端性能優化從css說起

    摘要:放在中減少引起和接下來我們再來討論一下圖片與雪碧圖或精靈,在網頁中我們會用到很多圖標,如果每一個圖標是單獨的一張圖片,那網頁加載的時候,就會有多個請求去請求圖片,顯而易見會影響網頁性能,所以要采取方法對網頁中圖標使用進行優化處理。 ???????我們都知道性能對于一個網站來說相當重要,以至于很多公司都會專門招聘人員優化網站性能,網上關于探討網站性能優化的文章也非常多。性能是什么呢?簡單...

    KoreyLee 評論0 收藏0
  • 前端性能優化從css說起

    摘要:放在中減少引起和接下來我們再來討論一下圖片與雪碧圖或精靈,在網頁中我們會用到很多圖標,如果每一個圖標是單獨的一張圖片,那網頁加載的時候,就會有多個請求去請求圖片,顯而易見會影響網頁性能,所以要采取方法對網頁中圖標使用進行優化處理。 ???????我們都知道性能對于一個網站來說相當重要,以至于很多公司都會專門招聘人員優化網站性能,網上關于探討網站性能優化的文章也非常多。性能是什么呢?簡單...

    shiyang6017 評論0 收藏0

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<