-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
yakim-shu 網站優化成果 #7
Comments
原來是這樣XDD 話說你這篇我給你 100 分...把優化過程寫得有夠清楚,清楚到我都覺得搞不好可以放上履歷當作作品集之一了(認真)。而且這篇其實改一改就可以變一篇優質的部落格文章了,你可以考慮一下,標題可以叫什麼「網頁優化實戰:以 lazy hackathon 為例」之類的。 基本上可以做的優化都已經做了,如果還想要再更進一步的話,就是把 jQuery 整個拿掉之類的,然後改用自己手寫的,把原本用到 jQuery 的地方自己寫出來。 總之能做到這樣已經很棒了,我覺得這成果非常好 💯 |
哈哈哈哈標題都幫我想好,非常貼心! 其實我當初也有抱著這種心情寫,想說履歷如果有提到網頁優化,就直接貼這篇連結,但內容的確要修飾( 廢話太多老症頭 ),也想隱藏 sprite 圖是手工製作的事實,我怕會被工程師鄙視 🤣 寫到後面有點無力了,做紀錄比實際優化還難啊,可能再補個 before & after 的 CRP 分析。 |
@yakim-shu 已跪⋯⋯不管是優化後的載入速度,或者記錄過程的詳細程度都很驚人!覺得可以寫成部落格文章發布 +1 |
@yakim-shu 很厲害,跪拜。但我對《先把圖片尺寸調整到正常、但不失真的狀態》這裏有點疑問,為什麼“ 考慮到 retina 螢幕解析度為兩倍的情況” 為什麼要*2呢?把設計稿的存尺復現到網頁上,應該注意什麼?請指教 |
@objcxiaobai 雖然還沒實作過但試著回答看看兩倍的問題,我的理解是這樣: 圖片解析度在網頁上並不是永遠固定的,例如 ppi/dpi 這些值瀏覽器會忽略,因為在網頁上是由圖片的「寬、高」決定解析度。舉例來說,圖片高度自動的情況下:
假如說今天在網頁放一張寬 1400px * 700px、HTML/CSS 也設定 1400px * 700px 的圖片,這樣給一般螢幕瀏覽沒問題,但換成 Retina 螢幕看就會顯得模糊失真。因此通常為了顧及有 Retina 螢幕的裝置瀏覽體驗,會存一張寬高兩倍、在這個例子就是 2800px * 1400px 的圖片備用。 |
@mingjunlu 非常感謝回答,我有點理解苗頭了。請問還原設計稿到屏幕上需要注意什麼? |
@objcxiaobai 我目前缺乏實戰經驗,對此無法提供什麼具體建議,不好意思 😅 |
@mingjunlu 非常感謝。這是很好的建議,感謝指出 |
跪拜大神~太詳細了啊! 簡直就是網站速度優化之神啊! |
網站優化心得
🍡 優化後網址
https://yakim-shu.github.io/lazy-hackathon-yakim/dist/
WebPageTest 報告網址
🤢 原始報告
Google PageSpeed Insights
WebPageTest

🎯 優化後報告
Google PageSpeed Insights
WebPageTest

你做了哪些優化?
開始優化前的預期目標
接下來的優化步驟,盡可能完成一個小階段就去跑測試,看每種優化手段的實際效果各是多少,開始吧!
事前準備
因為網站是自己切版的,所以在做的時候就有些想法,再看完 Web Performance 影片後,更多了某些收穫(以粗體字顯示):
media
分割不同裝置的 CSS => 🤔 沒做,太搞工defer
載入所有 JSasync
=> 🤔 沒有 GA☞ 最簡單的步驟: 刪掉所有來亂的 code
material-icons.css
angular
,vue
先砍掉index.js
裡面有許多鬧場又難刪的 code🎯 階段性結果: 刪掉胡鬧 code
☞ 先計算現在的 CRP 資源、總大小、來回長度
此階段想要效仿優化影片內的教學,先觀察網頁的 HTML,來計算此網站的 CRP 資料:
CRP Resources:
10
10
個檔案,字形檔看起來不在裡面1
4
5
CRP Bytes: 約
822 KB
( 大略估計 )20 KB
style.css
:20 KB
slick-theme.css
:4 KB
slick.css
:4 KB
bootstrap.css
:193 KB
=> 肥 🥩🥩index.js
:4 KB
slick.js
:90 KB
=> 肥 🥩typed.js
:41 KB
bootstrap.js
:135 KB
=> 肥 🥩jquery-3.4.1.js
:311 KB
=> 肥爆 🥩🥩🥩CRP Length:
2
or10
( round trip )2
之後優化的目標
defer
屬性,可以從10
降至 =>5
822 KB
降至 =>400 KB
以下☞ 初步壓縮檔案( HTML、CSS、Javascript )
以下都是利用 gulp 套件來壓縮檔案
壓縮後檔案大小:
822 KB
=>420 KB
( 約壓縮一半 )HTML:
gulp-htmlmin
12 KB
=> 改善 60%CSS:
gulp-cssnano
gulp-postcss、autoprefixer
mask
語法會出錯style.css
:16 KB
slick-theme.css
:1 KB
slick.css
:784 B
bootstrap.css
:156 KB
=> 改善了 20%,但還是很肥JS:
babel - minify
index-min.js
:4 KB
slick-min.js
:45 KB
typed-min.js
:12 KB
bootstrap-min.js
:67 KB
=> 壓縮約 50%jquery-3.4.1-min.js
:90 KB
=> 壓縮為 30%🎯 階段性結果: 初步壓縮 HTML、CSS、JS
DOMInteractive
的時間,恩有點想撞牆,才快了 100 毫秒是怎樣!! 🤢☞ 壓縮圖片
因為圖片很多又大,預計是麻煩但最有成效的步驟。
🍡 1. 先把圖片尺寸調整到正常、但不失真的狀態
3840px
,大的連開啟網頁都有困難...最大寬度 * 2 (px)
實現手段:
我猜應該有更方便的工具,但個人是用習慣的 photoshop 步驟記錄 可以批次處理,全程應該不用 10 分鐘、還算滿方便的。
圖片區
350px
800px
700px
750px
1920px
1500px
125px
800px
250px
icon 區
20px
x20px
128px
40px
80px
x80px
512px
160px
30px
x30px
128px
60px
🍡 2. 大圖如果是 png 就轉成 jpg
背景大圖有些是 png 檔,先不進行壓縮、光只是轉成 jpg 就變得小許多,因為 jpg 本身就是會損畫質的一種圖片格式,例如:
bg_footer.png
這張原本有3.6 MB
bg_footer.jpg
變成變成930 KB
( 效果顯著 😮 )正常的圖片大小成果:
image
資料夾:33 MB
=>22 MB
3840px
🎯 階段性結果: 處理圖片成適當大小
55
變成32.6
,還不錯!🍡 3. 重頭戲: 壓縮圖片
gulp-imagemin
的效果會不會更好? 不如兩個都試看看吧!開始實驗
image
資料夾總大小:22.8 MB
👑 經過
gulp-imagemin
壓縮:16.8 MB
↓ 130%👑 經過
gulp-tinypng-compress
:4 MB
↓ 570%🎯 階段性結果: 壓縮圖片
7
秒以內( 純粹許願,不具任何客觀評估 )32.6
變成10
秒 🎉 🎉 🎉 🎉🍡 4. 延遲載入圖片 Lazy Load
需求:
評估 plugin:
lazy load 的套件也很多,觀察了一下
jQuery.Lazy()
vanilla-lazyload 有支援 Placeholder image,但文件有詳細說明不建議使用的原因:
實現手段
其實還滿簡單的,就是引入 js,幫圖片加上
lazy
的 class,路徑改用data-src
載入就可以了。倒是背景圖片的有點麻煩,在研究怎麼讓背景圖可以 fade in 花很多時間 QQ
大圖除了 header 的背景圖 跟 slider 目錄圖(會出錯)之外都加上了。
🎯 階段性結果: Lazy load
10
秒大幅提升到4
秒,非常優秀!🍡 5. 圖片改成 Webp
前景圖使用 webp 步驟:
imagemin-webp
套件跑一次就 OK ,前面用的 lazy load 套件vanilla-lazyload
也有無痛支援 webp 格式,只差要改 HTML 比較麻煩html 的
<picture>
格式:( 要同時 lazyload 的話,改成
data-srcset
&data-src
,再加上 class 就搞定 )背景圖使用 webp 步驟:
script
判斷瀏覽器有沒有支援script
,如果瀏覽器有支援的話,<html>
就會加上一個 Class.webp
實際在 CSS 用
.webp
:( 搞半天其實全部只有用一張背景圖
bg_header
是寫在 CSS 裡面... )🎯 階段性結果: 圖片改成 webp
3
秒內3
秒出頭,不錯不錯!☞ 減少 CSS 大小 & request
3.xx
版本,把頁面有用到的勾一勾,載進來還是爆掉bootstrap.min.css
有150 KB
,清掉變成16 KB
😍gulp-concat
將所有 CSS 打包成一支!style.css
大小剩下33 KB
,效果顯著🎯 階段性結果: 圖片改成 webp
DOMInteractive
的時間應該可以縮滿多的!2
秒了~DOMInteractive
的時間並沒有縮短2x
分,一把 CSS 縮小跟減少 request 之後,居然躍升成94
分 😂☞ 減少 JS 大小 & request
more tools
才有 )實際做了什麼?
6
個 request,縮減成3
個,把<script>
都加上defer
jQuery
跟lazyload
還是獨立出來🎯 階段性結果: defer Javascript
3
個 request,且script
改成defer
就不會 block parsing,載入的空白期應該可以短很多!1.7
秒!-
DOMInteractive
剩0.5
秒~~~☞ CSS sprite
mask-image
,這樣的寫法會讓 sprite 圖的製作變很麻煩mask-image
主要是拿來做遮罩用,但因為 icon 想要有換色效果、但又不想用 svg,所以都是用 CSS 的新語法mask-image
實現,而不是background-image
,原本就有預感做 sprite 圖會有困難postcss-sprites 生成 sprite 圖
background-position
改成mask-position
就可以了,試試看!回頭土法煉鋼
3
張 sprite 圖 ( 用 photoshop )mask-position
完工參考資料:
小結論:
🧐 突發問題: webp 跟 jpg 怎麼都載進來了?
突然發現一個很笨的問題,現在網頁上的圖片確是用
.webp
沒錯,但原先的 SCSS 寫法.jpg
是預設圖片,只是用.webp
的 Class 蓋過去了,所以.jpg
還是載入進來了啊開什麼玩笑!看到一些套件: webp-in-css 是會生成兩個 class:
.webp
&.no-webp
但我之前的引入的那段 script ,只會在
<html>
標籤上加上webp
,沒有.no-webp
的 class 可以用,所以我改用:not()
規則修改 SCSS ,變成以下:(
<html>
有.webp
會套用到下面的規則、沒有則會套用到上面的 )成果:
從 DevTools 可以看出來只載入了 webp 檔,是有點陽春但堪用的做法!
😬 發現事有蹊蹺
從 DevTools 的 Network 中發現還是載入有載入 png 檔案,這邊我卡了很久,之後向大師請教才得到啟發
🎯 階段性結果: defer Javascript
11
個圖片 request,應該可以減少全部的載入時間👏 找到同時載入兩張圖的問題來源了
剛剛實在太困惑,乾脆求救問 Huli 大大,得到以下回答:
難怪網路上的教學大多都是使用兩種 class,而不是像我在那裡假會,用
:not()
判斷的寫法,所以照著此教學換掉判斷支援 webp 與否的<script>
:使用 WebP 格式減少圖片載入時間有了
.no-webp
&.webp
2 種 Class 之後,SCSS 寫法改成:換成兩種 class 分別載入不同圖檔,確保不會因為 JS 執行順序而有問題
🎯 階段性結果: 刪掉多餘 request
Document Complete
剩下0.8
秒,開心得有點想哭。黔驢技窮,結束優化之旅
比較可惜的地方有幾點:
slim.min
版本了還是很肥,上網查unused code
還是沒頭緒。其他檢測工具
檢測結果: 恩。不是很好
心得
其實優化的過程比想像中還難,以前對於優化的概念大概就是知道有哪些手段,壓縮檔案、減少 request、script 用
async | defer
載入...,經過這次的優化作業中,學到最多的應該是針對性地優化哪個部分,有了更清楚的認知,歸功於這些方便的檢測工具。但就算沒有這些工具可以用,上過 Website Performance Optimization 這堂課之後,多少也可以從 HTML 看出網頁上的問題在哪裡,如何優化、預期表現等等...
過程中在處理 webp 跟 CSS sprite 跟 lazyload 的路上非常坎坷,基本上我覺得跟圖片牽扯到的都比較麻煩,尤其是當所有優化手段集中在一起的時候,會有很多問題要處理。
總之感謝有這個機會,很多模糊的概念在實踐中都變得很清晰許多,真的是獲益良多!
The text was updated successfully, but these errors were encountered: