基于WEB 的圖片加載優化技術研究

李蘭蘭，宋永鵬

（1.山東省氣象服務中心，山東濟南 250031；2.山東省氣象信息中心，山東濟南 250031）

HTTP Archive 統計顯示，圖片內容已經占到了互聯網內容總量的62%，也就是說超過一半的流量和時間都用來下載圖片。從性能優化的角度看，圖片也是優化的重點和熱點之一，Google PageSpeed 優化規則把圖片優化作為重要的優化手段。傳統的圖片加載方式是通過Url 或者Src 屬性加載圖片地址，向服務器提出Http 請求[1]后下載圖片至瀏覽器，圖片站點的開發過程中，加載的圖片過多會增加向服務器請求的次數而導致請求時間過長，對服務器和本地網絡資源是極大的浪費；圖片體積過大會使瀏覽器從上到下逐步顯示圖片直到圖片完整呈現，這種從空白區域到完全加載的過程顯得比較突兀會使用戶體驗較差[2]。基于Javascript 的懶加載和預加載是目前流行的圖片優化技術，能夠從頁面前端的角度優化加載速度[3]；Base64 轉碼和圖像壓縮在后端和系統架構方面為圖片站點的優化提供技術支持。該文的硬件測試環境是4G 內存的DELL 一體機，軟件測試環境為Win7 操作系統、山東省氣象部門圖片資料云平臺和Google Chrome。

1 Base64轉碼

Base64 是網絡中常見的用于傳輸8 Bit 字節代碼的編碼方式，Base64 編碼可用于在Http 環境下傳遞較長的標識信息，具有不可讀性，即編碼的數據無法直接查看，通過Html 的Img 圖片標簽的Src 屬性和CSS 背景圖片的Url 屬性傳遞[4]。頁面中的每一個圖片需要先向服務器遞交一個Http 請求，再進行圖片的下載與顯示，圖片過多會導致Http 請求時間過長，而Base64 轉碼技術將圖片在服務器中的保存地址通過編碼表轉換成一串字符，隨著頁面的Html 代碼下載到本地，避免了向服務器進行Http 請求的時間消耗和網絡資源的浪費。

1.1 Base64轉碼的兩種運用

Base64 轉碼技術在圖片站點中的應用有（圖1所示，包含傳統圖片加載方式）兩種方式：1）對用戶上傳的圖片進行轉碼，將轉碼后圖片的編碼存儲于服務器的數據庫或文件中，用戶訪問圖片時，前端瀏覽器會下載內聯有Base64 編碼字符串的Html 以顯示圖片；2）前端用戶將圖片上傳至服務器后，后端應用將圖片進行格式化存儲，并將圖片在服務器中的相對地址保存于數據庫或文件中，前端用戶對圖片有Http 請求的時候，應用將圖片的存儲相對地址轉換成Base64 編碼字符串隨Html 進行下載并加載至瀏覽器[5]。二者區別在于圖片在服務器中的存儲方式和前端的顯示方式，前者保存、加載的是圖片的編碼，后者保存圖片本身及其相對地址，加載的同樣僅是相對地址的轉碼數據流。

圖1 傳統圖片加載和Base64轉碼實現方式

上述程序實現Base64 轉碼的核心功能，代碼將名為Source 的圖片變量賦值給另一變量fp，目標變量經過函數Base64_encode 的轉碼后生成Base64 格式的數據流，之后將該數據流分配至圖片標簽img的Src 屬性，通過img 標簽加載至用戶前端并顯示，此時瀏覽器加載的字符串是圖片儲存相對地址的轉碼流或是圖片本身的轉碼流，而不是圖片存儲于服務器中的相對地址[6]。

1.2 Base64轉碼的優勢

由于測試環境平臺已經上線運行，數據庫中已儲存了大量用戶上傳圖片的相對地址，所以該文采取第二種Base64 轉碼方式并和傳統圖片加載方式進行性能對比。將數據庫中存儲的圖片在服務器中的相對地址轉碼后，將編碼返回前端由Url 或Src 加載并顯示。利用Google Chrome 的開發者工具，對兩種加載方式下的同一頁面圖片加載時間進行對比分析，如表1 所示。原始圖片大小在200 kB 左右時，傳統方式加載和Base64 轉碼方式加載的時間分別為281 ms 和4 ms，瀏覽器加載速度相差70 倍，圖片大小在500 kB 時，Base64 轉碼方式的加載速度較傳統方式提升20 余倍，圖片大小在5 MB 左右時，提升16倍，性能提升的同時也大大提高了用戶體驗度。

1.3 Base64轉碼的不足

隨著圖片大小的增大，它的Base64 編碼字符串長度增長更明顯，4 kB 大小的圖片轉碼后的數據流足足有5 000 個字符，2 M 以上的圖片轉碼后的數據流更是長達200 行以上，當頁面中的一個Html 元素的CSS 樣式超過200 行，整個CSS 的體積會變得異常龐大，繼而影響頁面的渲染[7]。經測試，在表1 的頁面中加載的圖片超過200 kB 時，接近40%的概率出現頁面崩潰，90%以上的概率出現一張或數張圖片空白的情況。綜上，Base64 轉碼技術的應用局限在能夠嚴格控制圖片大小在200 kB 以下的站點中[8]。

表1 Base64對比傳統加載方式的性能優勢

2 基于PHP GD庫的圖像壓縮

一張1 920*1 080 像素的圖片，在每個像素4 字節大小的情況下，圖片大小將超過8 M，對存儲和傳輸會造成極大的浪費。圖像數據能夠被壓縮的理論基礎是圖像數據的冗余性，并且允許一定程度的失真。假設該圖片第一行像素的亮度值是[100 100…100（1 920個）]，那么第一行的大小就是4字節*1 920，將第一行重復數據壓縮成[100,1 920]表示1 920 個100亮度值的像素，那么第一行的大小就變成4字節*2，上述基于圖像空間冗余性的壓縮是目前的主流圖像壓縮原理[9]。主流的Web 開發語言都有優秀的圖片壓縮類庫，例如Java 的Thumb nailator、C#的Drawing和PHP 的GD（Graphic Device 圖像處理擴展），出于對高壓縮比的追求，它們支持的多是有失真即允許一定程度的有損壓縮[10]。由于測試平臺由PHP 開發，筆者基于GD 類庫進行程序的改編對壓縮前后的圖片進行采樣對比。

2.1 基于GD庫的圖像壓縮流程

利用GD 庫壓縮圖片的流程如圖2 所示，依據不同的圖片格式調用格式相應的圖像加載函數，亦或是根據圖片的Ur（lUniform resource locator）圖像加載函數（文中方式），之后創建新畫布以載入原始圖片的圖像資源，在新畫布中完成對圖像資源的壓縮操作，通過壓縮比的調整對圖像資源的大小和清晰度，進而生成壓縮后圖片[11]。

圖2 壓縮流程

上述程序實現基于GD 庫圖像壓縮Jpg 格式圖片的基本功能，代碼讀取代表圖像的變量Source，調整壓縮比，即改變Quality 的數值，調用圖像壓縮函數Imagejpeg 生成變量名為destination 所代表的壓縮后圖片，Gif 和Png 格式的圖片壓縮有各自相似的處理函數。值得注意的是第一行代碼ini_set(′memory_limit′,′256 M′)，擴大了PHP默認的內存限制至256 M字節，經多次測試，當壓縮的圖片大小在10 M 以上時，過小的內存限制會有一定幾率導致應用程序的崩潰[12]。

2.2 圖像壓縮的優勢

經過對不同大小的圖片進行不同壓縮比的壓縮，對比壓縮前后圖片，得出如下結論（見表2）：在壓縮比為50 的條件下壓縮后得到的圖片能較好地兼顧清晰度和大小的要求，并且隨著圖片大小的增大，原始圖片與壓縮圖片的大小比例遞增。其余的壓縮比數值的壓縮較難實現二者的兼顧，25 壓縮比的壓縮雖然滿足較小圖片的要求，但是清晰度失真較為嚴重反而影響圖片內容的辨識；同理，75 壓縮比生成的圖片雖然保留了大部分原始圖片的像素但是失去了壓縮的意義：圖片大小無明顯變化。

表2 50壓縮比條件下壓縮前后圖片大小

對一張測試平臺中1.2 MB 大小的圖片進行壓縮前后采樣對比發現，壓縮后圖片大小約400 kB，較原始圖片大小縮小了3 倍多，在色彩和清晰度方面有輕微的失真不會致使讀者對圖片表達的原始信息產生誤解，而3 倍的大小差距體現在瀏覽器的加載性能上將會對用戶體驗造成巨大的影響。

將表1 中對比Base64 轉碼和傳統加載方式應用到的圖片壓縮后重新上傳入庫，利用Google Chrome開發者工具測試頁面加載時間，結果如表3 所示，原始圖片大小在200 kB 左右時，傳統方式加載和圖片壓縮方式加載的時間分別是281 ms和4 ms，瀏覽器加載速度相差70倍，圖片大小在500 kB 時，Base64轉碼方式的加載速度較傳統方式提升20余倍，圖片大小在5M左右時，提升2.44倍，圖片大小越大時，對比Base64轉碼方式，圖像壓縮方式的加載時間優勢越小。

表3 圖像壓縮技術的性能優勢

2.3 圖像壓縮的不足和解決方案

根據表3 所示對比內容，顯而易見，圖像壓縮技術的不足之處在于因壓縮導致像素丟失造成的失真，這種程度的失真作為大圖顯示時會造成肉眼可見的差異，可是作為列表圖片或者縮略圖時，這種差異是能夠忽略不計的[13]。綜上，解決方案是用戶上傳原始圖片時，后臺同時生成壓縮圖片一并儲存至服務器，在進行列表圖或縮略圖加載時使用壓縮圖片，進行大圖顯示時加載原始圖片。由此在頁面加載大量列表圖時，不會由于過多大體積圖片的Http請求而造成頁面卡頓，而且在加載單一大圖時，單一的Http 請求又能夠緩解大體積圖片的下載壓力[14]。

3 懶加載和HTTP2協議

懶加載就是延時加載，用戶有瀏覽需求時手動進行加載圖片操作，例如淘寶京東此類購物網站，眾多商品圖片需要集中在一個頁面顯示，1 MB 大小的圖片如果同時有1 000 人訪問，達到的1 000 并發量就會產生1G 的帶寬壓力，基于前端的懶加載是解決此類問題的較流行的優化技術[15]，類似山東省氣象部門圖片資料云平臺這種屏幕可以完全顯示當前頁所需圖片的站點，能通過分頁功能展示搜索結果集中的其他圖片，沒有需要懶加載的內容，在加載頁面的同時就能夠加載全部圖片，因此懶加載技術適用于頁面高度超過屏幕且頁面下方仍有待加載的圖片的站點。

HTTP2 協議能夠解決瀏覽器連接請求的限制問題。目前主流的瀏覽器，如IE 各版本和筆者測試用的Google Chrome，最大Http 連接數限制在6 個，瀏覽器的一次Http 請求能夠同時加載6 張圖片，如果頁面待加載圖片過多則會進行多次的連接請求從而拖累整個頁面的加載速度[16]。而HTTP2 協議一個站點只有一個連接，每個請求是一個流數據，被分為多個二進制幀，不同流中的幀可以交錯地發送，實現多路復用，從而解決連接數限制問題，通過上述論述能夠看出，HTTP2 協議適用于頁面包含海量圖片的站點。

4 結束語

懶加載和HTTP2 協議技術同樣能夠優化圖片站點的加載速度，由于不適用于該文測試平臺，筆者不再進行相關的實驗測試。經筆者驗證的基于系統架構和后端開發的Base64 轉碼和圖像壓縮是能夠大幅提高頁面加載速度和用戶體驗并且適用范圍更加廣泛的圖片加載優化技術，是合格Web 開發人員的必備技能。