前端開發中,對圖片的優化技巧有哪些?

我目前知道的有設置緩存、壓縮圖片


謝邀。

按照先後順序有以下:

1. 去掉無意義的修飾。嗯,我會瞎說嗎?除了內容圖片,其他的圖片的作用是修飾,也就是對於傳達信息來說並非本質性的。最大的優化就是壓根不要圖片!所以在優化之前要做的,首先是確認設計,設計本身是否需要用那麼多圖片?還是說可以更簡潔?

2. 不用圖片。嗯,切圖是一件扯淡的事情!不要隔靴搔癢了少年,直接使用CSS替代圖片來實現修飾效果吧!如半透明、邊框、圓角、陰影、漸變等,在當前主流瀏覽器中都可以用CSS達成。將來CSS濾鏡得到廣泛支持後,還可以做到alpha混合、正片疊底等各種效果。

3. 使用矢量圖替代點陣圖。對於絕大多數圖案、圖標等,矢量圖更小,且可縮放而無需生成多套圖。現在主流瀏覽器都支持SVG了,所以可放心使用!

4. 使用恰當的圖片格式。我們常見的圖片格式有JPEG、GIF、PNG。基本上,內容圖片多為照片之類的,適用於JPEG。而修飾圖片通常更適合用無損壓縮的PNG。而GIF基本上除了GIF動畫外不要使用。且動畫的話,也更建議用video元素和視頻格式,或用SVG動畫取代。除了這些格式之外,Chrome、新版Opera、Android 4+支持WebP格式,IE 9+、IE mobile 10+支持JPEG XR。這兩個新格式都支持無損和有損壓縮,都具有更良好的壓縮比。當然這需要為不同的瀏覽器返回不同的圖片,增加了開發成本,也增加存儲成本。不過你省了流量或者相同流量下改善了圖片質量,提升了用戶體驗。你會如何取捨呢?對了,別忘了使用優秀的圖片編碼器及合適的參數。好的圖片編碼器,尤其是有損圖片格式的編碼器,能通過演算法或手動調整,獲得更高的壓縮比。

以下是普遍適用各種資源而不限於圖片的優化手段:

5. 使用data url。資源內嵌於CSS或HTML中,而不必單獨請求。注意,多個地方都要使用的資源不一定適合用此優化方式,因為圖片數據重複多了,增加流量。另外許多瀏覽器對data url有長度限制,注意資源的大小。

6. 按照HTTP協議設置合理的緩存。具體的緩存策略(如永久緩存+重命名)、部署策略(如反向代理、CDN等)這裡就不展開了。

7. 使用支持SPDY的伺服器。SPDY可認為是未來的HTTP 2.0的早期實現,Chrome、Firefox 13+、Opera 12+、IE 11+均已支持SPDY。SPDY和HTTP2可參考此中文演講:http://www.youtube.com/watch?v=r74RAcrc1ZA(請自備梯子),這裡就不展開了。

8. 資源的lazyload或postpone。(lazyload:延遲到其他資源下載完成後再載入,postpone:延遲到元素可見再載入。)目前基本上都要用腳本控制。未來HTML和CSS會增加相關的控制屬性,見:Resource Priorities。

9. 資源的prefetch。可用&,見http://www.whatwg.org/specs/web-apps/current-work/#link-type-prefetch。注意prefetch只是hint,Firefox會預取資源(如果網路空閑的話),而IE 9則是對該資源的hostname進行DNS預解析。如果你真的需要更強的控制,則得用腳本。注意:Chrome支持與prefetch相近但更進一步的&,另外SPDY加入了與prefetch相近但語義不同的subresource link支持,這兩個新特性我也沒用過,有興趣的可以嘗試。

圖片的其他優化技巧如字體圖標、CSS Sprites等,不過我不推薦。用字體圖標不如用SVG。使用了SPDY和data url後,CSS Sprites完全沒有必要用了。

再有各種特定的圖片問題,超出了一般優化的範疇。如許多手機瀏覽器有黑夜模式,其中有的瀏覽器允許定製黑夜模式;有的手機瀏覽器允許在用戶開啟不載入圖片選項的情況下讓開發者設置必須載入的圖片(有點繞);又如許多手機瀏覽器有所謂雲加速模式,即在伺服器端對圖片進行處理後再發送給客戶端,應該返回怎樣的圖片給這些伺服器有待研究和實踐。

10. 最後是responsive設計所需的圖片優化,可能要產生多套不同大小和解析度的圖片,配合media query、以及srcset屬性、picture元素、src-N等標準提案,這個話題比較大,尚未形成普遍認可的最佳實踐,這裡也不多展開了。

以上。


補充一個 mxhr,比較經典的自定義協議的實現,應用場景在 大量細小圖片載入的地方,比如照片牆或者瀑布流,尤其手機端,如果做的細緻一些,我個人覺得還是比較屌的。。

原理很簡單,xhr載入base64的圖片,自定義分隔符,利用xhr對象狀態為3的這個值,對文本內容做解析,再扔到頁面里,不僅僅用於載入圖片,你也可以拿它來載入js,html,css等資源。。

這個概念來源於 郵箱附件實現思路。


看了一下上面的答案,在座的各位都是大牛啊,這裡本小菜也補充一個:

JavaScript圖片的預載入優化。

1. 用CSS或JavaScript實現預載入

構造純CSS預載入圖片,再在需要的時候使用;也可以通過JavaScript代碼來配合生成:

```css

#fetch1 {

background: url(http://example.com/1.jpg) no-repeat -9999px -9999px;

}

```

2. 僅使用JavaScript預載入

基本原理如下代碼,適用於載入大量圖片:

```javascript

var images = new Array()

for (var i = 0; i &< 3; i++) {

images[i] = new Image()

images[i].src = `http://example.com/${i}.jpg`

}

```

純手打輸入,代碼過於簡單,莫噴;在這裡拋磚引玉,多多給贊!


轉雅虎前端優化的幾條軍規~~~有疑問歡迎討論

雅虎給出了優化網站載入速度的34條法則(包括Yslow規則22條) 詳細說明,下載轉發 ponytail 的譯文(來自帕蘭映像)。

1.Minimize HTTP Requests 減少HTTP請求

圖片、css、script、flash等等這些都會增加http請求數,減少這些元素的數量就能減少響應時間。把多個JS、CSS在可能的情況下寫進一個文件,頁面里直接寫入圖片也是不好的做法,應該寫進CSS里,利用 CSS sprites 將小圖拼合後利用background來定位。

2.Use a Content Delivery Network 利用CDN技術

CDN 確實是好東西,8過伺服器提供商的這項服務一般是要收費的,我以前買的國內空間是有這個的但是我當時根本不知道啥用,現在沒了。。。

3.Add an Expires or a Cache-Control Header 設置頭文件過期或者靜態緩存

瀏覽器會用緩存來減少http請求數來加快頁面載入的時間,如果頁面頭部加一個很長的過期時間,瀏覽器就會一直緩存頁面里的元素。不過這樣如果 頁面里的東西變動的話就要改名字了,否則用戶端不會主動刷新,看自己衡量了~ 這項可以通過修改.htaccess文件來實現。

4.Gzip Components Gzip壓縮

Gzip格式是一種很普遍的壓縮技術,幾乎所有的瀏覽器都有解壓Gzip格式的能力,而且它可以壓縮的比例非常大,一般壓縮率為85%。壓縮沒壓縮,可以到 這裡 做下測試。

5.Put Stylesheets at the Top 把CSS放頂部

讓瀏覽者能儘早的看到網站的完整樣式。

6.Put Scripts at the Bottom 把JS放底部

網站呈現完畢後再進行功能設置,當然這些JS要在你的載入過程中不影響內容表現。

7.Avoid CSS Expressions 避免CSS Expressions

CSS表達式很可怕,這個只被IE支持的東西執行時候的運算量非常大,你移動一下滑鼠它都要進行重計算的,但有時候為了做瀏覽器的兼容必須要用到這個||| IE6去死去死!~

8.Make JavaScript and CSS External 將JS和CSS外鏈

前面講到了緩存這個事情,一些較為公用的JS和CSS,我們可以使用外鏈的形式,譬如我就是從Google外鏈來的Jquery文件,如果我的瀏覽者在瀏覽別的使用了這個外鏈文件的網站時已經下載並緩存了這個文件,那麼他在瀏覽我的網站的時候就不需要再進行下載了!~

9.Reduce DNS Lookups 減少DNS查找

貌似是要減少網站從外部調用資源,我的Google分析和picasa的外鏈圖片都算在裡面了。

10.Minify JavaScript and CSS 減小JS和CSS的體積

寫JS和CSS都是有技巧的,用最少的代碼實現同樣的功能,減少空白,增強邏輯性,用縮寫方式等等,當然也有不少工具也能夠幫你實現這一點。

11. Avoid Redirects 避免重定向

再寫入鏈接時,雖然」http://www. today-s-ooxx. com」和」http://www. today-s-ooxx. com/」 僅有一個最後的」/」只差,但是結果是不同的,伺服器需要花時間把前者重定向為後者然後進行跳轉,這個要自己注意,也可以在Apache里用Alias 或者mod_rewrite或者DirectorySlash解決。

12. Remove Duplicate Scripts 刪除重複腳本

重複調用的代碼瀏覽器並不會識別忽略,而是會再次運算一遍,這當然是大大的浪費。

13. Configure ETags 配置ETags

搞不清楚咋回事,總之我是在. htaccess里把它刪除了。

14. Make Ajax Cacheable 緩存Ajax

Ajax是實時響應的,在瀏覽器接收到新的數據前,舊的數據被緩存,這樣能夠更好的提高效率。

15. Flush the Buffer Early 儘早的釋放緩衝

當用戶進行頁面請求時,伺服器端需要花費200到500毫秒時間來拼合HTML,將寫在head與body之間,釋放緩衝,這樣可以將文件頭先發送出去,然後再發送文件內容,提高效率。

16. Use GET for AJAX Requests 用GET方式進行AJAX請求

Get 方法和伺服器只有一次交互(發送數據),而 Post 要兩次(發送頭部再發送數據)。

17. Post-load Components 延遲載入組件

最先載入必須的組件進行頁面初始化,然後再載入其他,YUI Image Loader 是很好的例子。

18. Preload components 預載入組件

提前載入以後可能用到的東西,和延遲載入並不衝突,它的目的是為後續請求提供更快的響應,參見Google首頁上的CSS sprites應用。

19. Reduce the Number of DOM Elements 減少DOM元素數量

複雜的頁面結構意味著更長的下載及響應時間,更合理更高效的使用標籤來架構頁面,是好的前端的必備條件。

20. Split Components Across Domains 跨域分離組件

頁面組件多個來源可以增大你的平行下載量,但注意不要過多,超過2-4個域名會引起上面說到的DNS查找浪費。

21. Minimize the Number of iframes 減少iframe數量

需要更有效的利用 ifames。

iframe 優點:有利於下載緩慢的廣告等第三方內容,安全沙箱,並行下載腳本

iframe 缺點:即使為空也會有較大資源消耗,會阻止頁面的onload,非語義

22. No 404s 不要出現404頁面

站點本身里(非搜索結果)出現404頁面,無意義的404頁面會影響用戶體驗並且會消耗伺服器資源。

23. Reduce Cookie Size 減小Cookie

Cookie在伺服器及瀏覽器之間的通過文件頭進行交換,儘可能減小Cookie體積,設置合理的過期時間,能夠很好的提高效率。

24. Use Cookie-free Domains for Components 對組件使用無Cookie的域名

對靜態組件的Cookie讀取是一種浪費,使用另一個無Cookie的域名來存放你的靜態組件式一個好方法,或者也可以在Cookie中只存放帶www的域名。

25. Minimize DOM Access 減少DOM的訪問次數

JS訪問DOM是很慢的,盡量不要用JS來設置頁面布局。

26. Develop Smart Event Handlers 開發靈活的事件處理句柄

DOM樹上過多的元素被加入事件句柄的話,反應效率肯定會低,YUI事件工具有一個 onAvailable 方法可以幫助你靈活的設置DOM事件句柄

27. Choose over @import 使用而非 @import

在IE中使用@import就和在頁面底部用一樣,我們前面說要把放頂部的。

28. Avoid Filters 避免過濾器的使用

如果需要Alpha透明,不要使用AlphaImageLoader,它效率低下而且只對IE6及以下的版本適用,用PNG8圖片。如果你非要使用,加上_filter以免影響IE7+用戶。

29. Optimize Images 優化圖片

將你的GIF轉為PNG8會是個減小體積的好辦法,另外有很多方法處理你的JPG及PNG圖片以達到優化效果。

30. Optimize CSS Sprites 優化CSS Sprites

在CSS Sprites中豎直並盡量緊湊的排列圖片,盡量將顏色相似的圖片排在一起,會減小圖片本身的大小及提高頁面圖片顯示速度。

31. Don』t Scale Images in HTML 不要在HTML中縮放圖片

圖片要用多大的就用多大的,1000X1000的圖片被w=」100″ h=」100″以後,本身的KB數是不會減少的。

32. Make favicon. ico Small and Cacheable 縮小favicon. ico的大小並緩存它

站點的瀏覽器ICO應該不是經常換吧,那就長時間的緩存它,並且最好控制在1K以下。

33. Keep Components under 25K 保證組件在25K以下

iPhone不能緩存25K以上的組件,並且這還是要在被壓縮前。

34. Pack Components into a Multipart Document 將組件打包進一個多部分的文檔中


這裡就說下WebP圖片格式能給前端帶來的優化。WebP,谷歌2010年左右發布的開源圖片格式,支持無損、有損壓縮,動態、靜態圖片,壓縮比率優於GIF、JPEG、JPEG2000、PNG等格式,非常適合用於網路等圖片傳輸。

附:WebP效果體驗

大家可以體驗下WebP的壓縮效果,它能讓圖片平均大小減小70%,解決了流量消耗大,載入速度慢等一系列問題。

WebP 兼容性

說到 WebP,不得不提到一個比較令人煩惱的問題,那就是 WebP 客戶端兼容性。Google Chrome 和 Opera 瀏覽器以及許多其他工具和軟體庫都支持 WebP,但是當前並非所有瀏覽器都支持 WebP,支持的情況參見如下圖所示:

詳見 WebP 支持情況

如何解決 WebP 的兼容問題?

又拍雲 CDN 服務發布WebP 兼容功能,實現 WebP 自適應。這樣可以享受的好處就是:

1、WebP 格式的圖片可以提供更好的壓縮比和更小的文件大小,可以減少網路傳輸,使得網路傳輸的速度更快;

2、網路傳輸的流量減少了,可以節省 CDN 流量消耗,節省帶寬成本;

3、通過 CDN 層去判斷客戶端是否支持WebP格式。對於支持的客戶端,響應 WebP 格式的圖片;不支持的客戶端,響應原圖。從而實現無縫適配。

推薦閱讀:如何通過 WebP 兼容方案來減少圖片體積?


同意 @賀師俊。

補充一下兩點:

  1. 提升圖片的 DNS 解析時間不限於 prefetch,別看 DNS 時間不長但它的影響是全部的性能指標。

  2. 使用 data URI 需要十分小心,如果 CSS 還是放在 head 內,文件的增大必然導致性能(開始渲染時間、首屏)變差。


圖片延遲載入;

css可以直接base64編碼圖片;

小圖標可以合成大圖標,進行分割使用;

掌握一定切圖能力非常加分哦~


1、使用base64編碼代替圖片

適用於圖片小於2KB,頁面引用圖片不多的情況。將圖片轉換為base64編碼字元串inline到CSS或頁面中,減少http的請求次數。

2、合併圖片sprite(雪碧圖)

任何用到頁面圖片的場景。將多個頁面用到的北京圖片合併成一個大的圖片在頁面中引用,可以有效地減少請求個數。

3、使用canvas代替圖片

需要高性能的圖片或動畫,使用HTML5的canvas元素繪製圖片,頁面渲染性能較高。

4、響應式圖片

不同終端對同一圖片的需求不一樣,根據終端載入不同的圖片來節省不必要的流量。通過picture元素,picturefill或平台判斷來為不同終端平台輸出不同的圖片。減少沒必要的圖片載入,靈活控制。

5、圖片壓縮

在不得不載入圖片的前提下,進一步提高優化效果,通過有損或無損壓縮所見圖片的大小。減少圖片載入流量,效果明顯。

6、更好的圖片格式

webp、bpg、sharpP等新圖片格式具有更好的壓縮比


圖片使用獨立域名算嗎,每個域名同時連接數有限制,特別是單頁大量圖片還需使用多個域名分散式存儲


圖片本身的話:

1. 盡量少用圖片,特別是非內容性質的,能用CSS畫就盡量畫一下

2. 圖片尺寸合適,合適是指,比如以iphone 6s寬度下能清晰展示為標準,那麼就是實際顯示圖片尺寸*2差不多這樣

3. 格式合適,webp是個好的選擇,無線端win phone目前支持還有些問題,做好兼容處理。

4. 圖片體積控制,一般為了高dpi下圖片的清晰,本身圖片展示的時候就是縮小的,所以對原圖質量要求不會太高,也可以適當對圖片做多一些的壓縮


合理切圖。

什麼是合理切圖?

1.弄清楚切圖輸出格式,png和jpg的差異。

2.按顏色拆解圖層,由於png的特性,與尺寸關係不大,但與顏色數關係很大,以顏色來裁剪圖層能大大減少png的體積。

3.以主次關係來切圖,例如背景上的雲層、煙霧等虛幻模糊的元素,可以以jpg格式輸出並減少質量到60%甚至更低。

想做到精細化的圖片優化處理,設計圖不能再是一張平面圖,而必須是帶圖層的原文件,有命名有分組更好。

合理切圖,讓每一個素材都以最佳的姿態輸出組合,然後才是合雪碧、上極限壓縮工具、請求緩存管理等後話。

PS:更多的極限圖片優化玩法,請參考潘傑茂四五年前在WebRebuild上面分享的PPT


1.圖片描述

做法:1.圖片(有實質意義的圖片,即非背景圖片或者按鈕圖片等)名稱規範化,例如nokia-n95.jpg

2.添加圖片alt屬性,由於「搜索引擎不能識別圖片的內容--」,故此圖片需要添加描述,直接告訴「搜索引擎」該圖片所表達的內容。並且在設置alt屬性值的時候,應該以簡潔而有效地表達圖片內容為原則{而不是堆砌關鍵字}----如:諾基亞N95

3.周邊內容

圖片周邊內容是搜索引擎判斷圖片alt屬性值真實性的重要依據之一。如果圖片的alt屬性值與周邊的內容不相關,則搜索引擎就會對alt屬性值產生懷疑,甚至否定。

2.圖片壓縮

1.圖片壓縮的原理

圖像解析度常用「位/像素」表示。一般情況下,高解析度圖像每個像素由32位或者24位組成,而中解析度圖片每個像素由16位或者8位組成。不管用什麼工具對圖片進行壓縮,其原理就是降低組成圖片每個像素的位數。所以,圖片壓縮對圖片質量的影響在所難免。但是,我們不能為了片面的追求降低圖片體積,而忽略圖片質量。圖片優化的一個非常重要的原則就是:在保證圖片正常顯示的範圍內儘可能降低圖片的解析度,從而降低圖片的體積。

2.圖片的格式問題

在網頁中,常用的圖片格式有兩種:JPG和GIF .使用GIF格式或者JPG格式進行保存,所產生的體積是不一樣的。在實際中,如果圖片的色彩比較複雜,那麼用JPG格式進行保存可以節省更大的存儲空間。相反,如果圖片的色彩很單調,那麼使用GIF格式保存則可以節省更大的存儲空間。

JPG--&>當圖片質量(或者品質)調整到50~60時,顯示效果與體積大小都是比較合理的。

GIF--&>圖片調整至40~50位時,顯示效果與體積大小都是比較合理的。

3.圖片切割

對於大尺寸的圖片,可以通過縮小圖片尺寸(即降低圖片的解析度)的方發來降低圖片的體積。

3.圖片壓縮工具

1.Image Optimizer (http://www.xat.com/xatio.exe).

2.Photoshop

3.圖片在線壓縮工具 (在線圖片優化器)


想了解看看淘寶首頁就知道了,考慮兼容性的問題,還是要懶載入。如果用戶群體不需要考慮兼容性或者針對高級瀏覽器可以採用一樓的建議。


這裡可以參考 【前端】載入的圖片太多或者太大怎麼辦(上)


1:圖片上線前需要進行壓縮處理,可以使用sindresorhus/gulp-imagemin · GitHub

2:可以使用雪碧圖,把多個小圖合成一個,減少請求數量

3:使用cdn,例如七牛

4:瀏覽器對單個域名下的請求並發數是有限制的,如果是圖片量很多的頁面,需要考慮使用多域名。這個可以參考百度圖片

5:注意緩存,合理設置緩存過期時間

最好將上述操作可以通過項目構建工具實現自動化,當然不僅僅是圖片,其他靜態資源也類似

另外反對 @賀師俊 的一條

data url 在絕大多數情況是個糟糕的選擇,雖然可以減少一次請求,但是data url的性能奇差,尤其是在移動端,而且如果不使用本地緩存(LocalStorage)的話,還沒法緩存。當然除非這張圖片你要求儘快展現或者要求必須展現。如logo或者容錯圖。


icon font實現小圖標,圖片base64,保存圖片可以用png-4半透明就好。


補充一點:在搞基瀏覽器中藉助 XMLHttpRequest 和 FileReader 可以把圖片轉為 base64 存儲在 localStorage 中,二次載入可以直接讀取 localStorage


1.對圖片進行合併、拼接。

2.無損壓縮,基於後台演算法。(現在可行的不太清楚)

3.對圖片延遲載入。


然而設計師為了秀設計功底而設計,各種切圖,各種炫而無實質作用的切圖、特效,所以最直接還是換設計師


目前知道的也就有:

1、圖片緩存;2、素材圖片拼成一張圖片,使用CSS定位;3,、軟體壓縮圖片;4、GZIP;5、還有一種是圖片另存到一台空間內,就像螺絲站蘇州螺絲_螺母商派程序中商品圖片調用放在另外一台空間,類似遠程附件般;6、還有一種是圖片延遲載入,現在好多圖片瀑布流使用,百度圖片好像也是這種,首屏沒載入完,滾動條滾動至底,圖片再次載入一撥。


webp格式挺給力的,只是瀏覽器支持程度差了點…


同意@賀師俊,現代瀏覽器上大多數可以嘗試,不過考慮的ie6-8兼容的話,svg那條需要轉換後,用icon font實現,另外圖片也可以進一步壓縮後再上線。


推薦閱讀:

Google 的 HTML 代碼看著很亂,為什麼要寫成這樣呢?
網頁 head 標籤中的 JS 和 CSS,哪種文件放在前面,哪种放在後面比較好?
2016年前端技術將會呈現怎樣的局勢?全棧工程師是不是前端的一個趨勢?
web移動前端有哪些優化方案?

TAG:前端性能優化 |