場景是大屏頁面一張深色背景, 裡面一些文字元素以及圖表展示.
結果在ie下發現載入異常緩慢, 還有部分人員反饋頁面卡死.
預設處理邏輯是, imageio讀取原圖, 轉成byte, base64編碼後, 放到dom裡.
這樣越大, 後台轉的byte陣列越大也越卡, 那麼改進思路自然是壓縮, 以及去除imageio讀取.
使用thumbnailator, 對超過1mb的進行壓縮, 一般10mb的深色,
壓縮率用75%, 壓縮後也就幾百kb. 然後把base64編碼寫在dom裡的實現方式改成了css載入src.
改完之後, 後台已經完全不涉及到讀寫卡頓問題了.
但是前台依然會空白很久, 然後出現載入圖示, 最後才開始各個元件載入渲染. 那麼這個空白跟背景有沒有關係呢?
答案是no, 不過會占用伺服器頻寬, 所以需要壓縮下原圖或者直接放到cdn上.
關於渲染是否影響內容載入可以做個很簡單的實驗, 將chrome控制台調整到network,
選擇fast3g網路模式, 可以模擬乙個低速網路.
訪問一張帶背景圖的表單, 可以看到內容是先渲染出來的, 然後是載入.
是一段一段的載入的, 並不會影響內容主體渲染, 也不是導致初始頁面空白的元凶.
如果覺得分段載入效果不好的話, 可以把改成漸進式載入. 效果如下:
如何生成漸進式呢?只需要在photoshop編輯的時候, 選擇交錯儲存png.
也可以用**處理, 設定progressivemode即可.
重複一下, 漸進式和分段式, 只是提公升互動體驗, 載入速度並沒有變化.
如果不是導致的載入慢, 為什麼很多小夥伴反饋大屏慢呢? ie以及edge似乎更卡一點.
我們用chrome訪問一張大屏模板, 對比下ie訪問模板的響應時間. 兩者都預先清理快取.
訪問大屏位址
截圖一看清楚了, ie裡看上去gzip就沒起作用, 實實在在的載入原js. 用了4s才載入完.
看下**中gzip的處理, 直接把 ie全家 列到不支援gzip的列表裡了.
1實際上高版本ie早就支援gzip了, 因為ie11裡http的響應頭已經寫了accept-encoding: gzip, deflate.public
boolean
supportgzip() 45
public
boolean
isie()
找了早期的ie9看了下, 也是支援gzip壓縮的.
因為是線上環境, 我們本地沒還原客戶那邊的卡頓很久空白的情況, 猜測跟網速有關係.
需要用乙個軟體來模擬低速網路環境,. 首選自然是fiddler, 只需要一步設定即可.
重複上述訪問entry操作, 等得的快炸的時候, 頁面終於載入出來了.
低速網路下, 兩個js累計載入耗時561s!!!
開啟gzip後, 跟chrome速度一樣了, 兩個js累計114s, 越是低速網路, gzip效果越明顯.
頁面載入慢的原因
1.後端的原因,伺服器不好,請求耗時長 2.前端傳送請求太多 解決 減少傳送請求 3.網路問題 4.過大 前端解決方法 減少http請求,使用精靈圖,把公共部分存再sessionstorage中,請求過就不在請求 sessionstorage localstorage cookie的區別 cooki...
WebKit之頁面載入
website webkit在渲染一張頁面之前,首先,需要從網路上載入頁面資料,以及頁面中所使用到的 指令碼 css等資源。然後,通過布局引擎將獲取的資源資訊布局。最後,渲染引擎將資料渲染到瀏覽器的檢視中。那麼,網頁資料資源在webkit中是如何被載入的,以及載入過程中涉及了那些元件模組呢?在web...
ie8載入js太慢 js ie8 慢
re請教ap6214f2r版主一些問題 引用第ap6214f2r於2012 09 10 14 08發表的 樓主,關於你說的慢,我去看了下 你 響應速度非常快 attachment 26863 這個請求是計算簽名,跳轉到oss的。您可以再測試一下嗎?還有就是請教一下您測試用的那個多少多少毫秒的是什麼工...