Skip to content
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

Open
yakim-shu opened this issue Sep 6, 2019 · 9 comments
Open

yakim-shu 網站優化成果 #7

yakim-shu opened this issue Sep 6, 2019 · 9 comments

Comments

@yakim-shu
Copy link
Collaborator

yakim-shu commented Sep 6, 2019

網站優化心得

🍡 優化後網址

https://yakim-shu.github.io/lazy-hackathon-yakim/dist/

WebPageTest 報告網址

🤢 原始報告

Google PageSpeed Insights

  • 行動版: 9 分
  • 電腦版: 52 分

WebPageTest
螢幕快照 2019-09-04 下午2.07.56

🎯 優化後報告

Google PageSpeed Insights

  • 行動版: 97 分
  • 電腦版: 100 分

WebPageTest
螢幕快照 2019-09-06 下午7.59.55


你做了哪些優化?

開始優化前的預期目標

接下來的優化步驟,盡可能完成一個小階段就去跑測試,看每種優化手段的實際效果各是多少,開始吧!

事前準備

因為網站是自己切版的,所以在做的時候就有些想法,再看完 Web Performance 影片後,更多了某些收穫(以粗體字顯示):

  1. 刪掉不必要的字元( HTML、CSS、Javascript )
  2. 先計算現在的 CRP 資源、總大小、來回長度
  3. Minify, Compress( HTML、CSS、Javascript )
    • 去除註解 & 空白
    • 研究 GZIP => 🤔 沒做,好像是 Server 端的事情
  4. 圖片最佳化:
    • 先用工具壓縮到適當大小
    • Webp 或 DataURL 則一
    • CSS sprite
  5. 圖片最佳化: 使用 lazy load
  6. CSS 最佳化:
    • media 分割不同裝置的 CSS => 🤔 沒做,太搞工
    • Bootstrap 改用 customize 版本 => 🤔 嘗試過,失敗收場
  7. JS 最佳化:
    • 改成 defer 載入所有 JS
    • 如果有 GA 就用 async => 🤔 沒有 GA
  8. 處理 Cache
    • 外部資源都用成 cdn ( CSS、Javascript ) => 🤔 後來都壓縮成一支,所以沒用

☞ 最簡單的步驟: 刪掉所有來亂的 code

  • HTML
    • 出師表掰掰
  • CSS
    • 刪掉 material-icons.css
  • JS
    • 網站技術很單純簡單,什麼複雜的 angular, vue 先砍掉
    • index.js 裡面有許多鬧場又難刪的 code

🎯 階段性結果: 刪掉胡鬧 code

  • 猜測結果
    • 差距應該很微小,因為頂多把 JS 砍掉後,圖片開始載入的時間會快一些
  • 真正結果
    • 快了... 一秒鐘哈哈哈哈哈
    • 觀察:比較奇妙的是圖片跟字形檔的載入順序有換

螢幕快照 2019-09-04 下午9.39.01


☞ 先計算現在的 CRP 資源、總大小、來回長度

此階段想要效仿優化影片內的教學,先觀察網頁的 HTML,來計算此網站的 CRP 資料:

CRP Resources: 10

  • 總共有 10 個檔案,字形檔看起來不在裡面
  • HTML: 1
  • CSS: 4
  <link rel="stylesheet" href="./css/bootstrap.css">
  <link rel="stylesheet" href="./js/slick/slick.css">
  <link rel="stylesheet" href="./js/slick/slick-theme.css">
  <link rel="stylesheet" href="./css/style.css">
  • JS : 5
<script src="./js/jquery-3.4.1.js"></script>
<script src="./js/bootstrap.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/typed.js/2.0.10/typed.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/slick-carousel/1.9.0/slick.js"></script>
<script src="./js/index.js"></script>

CRP Bytes: 約 822 KB( 大略估計 )

  • HTML: 20 KB
  • CSS
    • style.css : 20 KB
    • slick-theme.css : 4 KB
    • slick.css : 4 KB
    • bootstrap.css : 193 KB => 肥 🥩🥩
  • JS
    • 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 or 10 ( round trip )

  • 這項目我其實不太確定
  • 因為根據此教學說明: 16. Quiz 計算 CRP,CSS 跟 JS 可以並行下載,所以 CRP length 的 best case 應該是 2
  • 但根據影片 21. Quiz 又變成是分開計算,所以這題先持保留態度。

之後優化的目標

  • CRP Resources : 把所有 JS 都加上 defer 屬性,可以從 10 降至 => 5
  • CRP Bytes : 是一定可以藉由壓縮降低,目標至少從 822 KB 降至 => 400 KB 以下
  • CRP Length : 因為 Resources & Bytes 都有降低,照理說也會受到影響而降低,但因為牽扯到網路速度等其他因素,目前無法估計

☞ 初步壓縮檔案( HTML、CSS、Javascript )

以下都是利用 gulp 套件來壓縮檔案

壓縮後檔案大小: 822 KB => 420 KB ( 約壓縮一半 )

HTML:

  • 壓縮 gulp-htmlmin
  • 成果
    • 12 KB => 改善 60%

CSS:

  • 壓縮 gulp-cssnano
  • 前綴 gulp-postcss、autoprefixer
    • 要記得加上 SCSS 前綴,不然 CSS 的 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

  • 猜測結果
    • 整體秒數差距應該也很小,因為最肥大的圖片還沒動手
    • 改善的是 CRP Bytes 的壓縮,所以剛進入網頁時的空白等待期應該會縮小
    • 但使用者還是會感覺圖片 load 很慢,所以整體體驗應該還是很差
  • 真正結果
    • 非常令人失望,整體載入時間甚至比剛剛更慢,不知道怎麼回事
    • 那渲染網頁之前的等待期呢? 來看看觸發 DOMInteractive 的時間,恩有點想撞牆,才快了 100 毫秒是怎樣!! 🤢
    • 但再回頭看最原始的版本,需要等 2.674 秒,好吧有安慰一點~

螢幕快照 2019-09-04 下午9.31.45


☞ 壓縮圖片

因為圖片很多又大,預計是麻煩但最有成效的步驟。

🍡 1. 先把圖片尺寸調整到正常、但不失真的狀態

  • 因為圖片都是從圖庫網抓下來的,雖然 Huli 叫我不要縮小圖片,但其實我之前已有偷偷改過尺寸,不然每張圖片寬度都 3840px,大的連開啟網頁都有困難...
  • 考慮到 retina 螢幕解析度為兩倍的情況,不想要有像素失真的條件下,以網頁上的圖片最大寬度為基準,每張圖片寬度調整成 最大寬度 * 2 (px)

實現手段:

我猜應該有更方便的工具,但個人是用習慣的 photoshop 步驟記錄 可以批次處理,全程應該不用 10 分鐘、還算滿方便的。

圖片區

  • 參賽隊伍區的圖片,最大寬度是 350px
    • 原本寬度為 800px
    • 目標縮小為 700px
  • 評審介紹區的 slide 大圖,最大寬度是 750px
    • 原本寬度為 1920px
    • 目標縮小為 1500px
  • 評審介紹區的 slide 小圖,最大寬度是 125px
    • 原本寬度為 800px
    • 目標縮小為 250px

icon 區

  • 各標題旁邊的 icon 圖片,尺寸是 20px x 20px
    • 原本寬度為 128px
    • 目標縮小為 40px
  • 歷屆成績區的 icon 圖片,尺寸是 80px x 80px
    • 原本寬度為 512px
    • 目標縮小為 160px
  • 社群分享的 icon 圖片,尺寸是 30px x 30px
    • 原本寬度為 128px
    • 目標縮小為 60px

🍡 2. 大圖如果是 png 就轉成 jpg

背景大圖有些是 png 檔,先不進行壓縮、光只是轉成 jpg 就變得小許多,因為 jpg 本身就是會損畫質的一種圖片格式,例如:

  • bg_footer.png 這張原本有 3.6 MB
  • bg_footer.jpg 變成變成 930 KB( 效果顯著 😮

正常的圖片大小成果:

  • 整個 image 資料夾: 33 MB => 22 MB
  • 其實並沒有差很多,因為圖片主要是幾張背景大圖佔的比例最高。
    • 如果是橫幅滿版的圖片,為了不要犧牲在 retina 螢幕下的畫質,還是維持寬度為 3840px

🎯 階段性結果: 處理圖片成適當大小

  • 猜測結果
    • 因為圖片大小減少了 1/3,整體秒數應該可以優化不少
  • 真正結果
    • 整體秒數從 55 變成 32.6,還不錯!
    • 每次測試都很像在開獎,有點緊張哈哈哈哈

螢幕快照 2019-09-04 下午10.53.30


🍡 3. 重頭戲: 壓縮圖片

  • 壓縮圖片感覺是一門學問,有太多不同工具可以研究
  • 以前很習慣用 tiny.png 跑過一遍,個人覺得經過這網站的壓縮,看得出來畫質有差,但還在接受範圍內,因為圖片大小差距非常可觀!
  • 但這次想實驗用工具 gulp-imagemin 的效果會不會更好? 不如兩個都試看看吧!
  • 有文章列出不同 gulp 壓縮圖片套件的比較,可以參考這裡:gulp 图片压缩

開始實驗

  • 原本的 image 資料夾總大小: 22.8 MB

👑 經過 gulp-imagemin 壓縮: 16.8 MB ↓ 130%

  • 畫質的損失肉眼看不出來,但此套件好像要自己寫參數,才可以發揮強大之處,我懶的研究,所以目前先這樣。

👑 經過 gulp-tinypng-compress4 MB ↓ 570%

  • 無話可說,整個就是大勝!!
  • 因為是基於 tiny.png 的套件,難怪這麼厲害
  • 流程有點麻煩,要先經過官網申請 API 的 key,且每個月限制圖片 500 張
    • 要很珍惜著用,跑一次套件就要花掉 10% 扣打,讓人很緊張
    • 所以如果圖片真的太多,還是得去官網壓縮

🎯 階段性結果: 壓縮圖片

  • 猜測結果
    • 非常期待,這應該是最有感的一個環節了~
    • 希望可以到 7 秒以內( 純粹許願,不具任何客觀評估 )
  • 真正結果
    • 打鼓預備備~~
    • 整體秒數從 32.6 變成 10🎉 🎉 🎉 🎉

螢幕快照 2019-09-04 下午11.57.15


🍡 4. 延遲載入圖片 Lazy Load

需求:

  • 支援 responsive-img
  • 支援 Placeholder image
    • low quality 替代圖
    • 或是直接用一個色塊當底圖

評估 plugin:

lazy load 的套件也很多,觀察了一下

  • jQuery.Lazy()
    • 看起來支援很廣,文件齊全,有很多參數可以改
  • lazysizes
    • 簡單使用,但沒有 placeholder 圖片
  • Lazy Load Remastered
    • 簡單使用,支援 placeholder,但我以為是程式產生,結果不是,原來要自己弄一張 🤢
  • 👉 vanilla-lazyload
    • 決定採用! 受歡迎、可調整參數多、文件詳細、demo 完整、支援 webp

vanilla-lazyload 有支援 Placeholder image,但文件有詳細說明不建議使用的原因:

Do NOT use placeholder images

  • For best perceived performance, leave the src and srcset attributes blank. Doing so, the image will be shown as soon as LazyLoad starts loading the image. See this video or this pen to test the difference (remember to disable the cache and to set a slower connection speed if you have a very fast one).
  • If you put anything in the src (like a transparent GIF), then LazyLoad starts loading the image but it won't be shown by browsers until the new image is loaded, leading to a worse perceived performance.

實現手段

其實還滿簡單的,就是引入 js,幫圖片加上 lazy 的 class,路徑改用 data-src 載入就可以了。

倒是背景圖片的有點麻煩,在研究怎麼讓背景圖可以 fade in 花很多時間 QQ

大圖除了 header 的背景圖 跟 slider 目錄圖(會出錯)之外都加上了。

🎯 階段性結果: Lazy load

  • 猜測結果
    • 雖然首屏的 request 大幅減少,但我猜應該在這測試沒什麼改變
    • 但可以看出來在 DevTool 的 rnetwork 面板內,往下滑才會增加 reuqest 數量,還是挺不錯的~
  • 真正結果
    • 好喔測驗證明我錯了,不過是好的那種,yeah 💃
    • 10 秒大幅提升到 4 秒,非常優秀!

螢幕快照 2019-09-05 下午5.18.30


🍡 5. 圖片改成 Webp

前景圖使用 webp 步驟:

  • Use WebP images 講得很清楚,直接動手做
  • 其實轉成 webp 還滿簡單的,imagemin-webp 套件跑一次就 OK ,前面用的 lazy load 套件 vanilla-lazyload 也有無痛支援 webp 格式,只差要改 HTML 比較麻煩

html 的 <picture> 格式:

<picture>
    <source type="image/webp" srcset="./webp/judge_h.webp">
    <source type="image/jpeg" srcset="./image/judge_h.jpg">
    <img class="" src="./image/judge_h.jpg">
</picture>

( 要同時 lazyload 的話,改成 data-srcset & data-src,再加上 class 就搞定 )

背景圖使用 webp 步驟:

  • 背景圖要在 CSS 裡面實現比較繁瑣
    1. 要先載入一段 script 判斷瀏覽器有沒有支援
      1. 看到滿多推薦 modernizr,但我只要判斷這項而已,載入一包不太理智
    2. 經過此 教學 看到有一段現成的 script,如果瀏覽器有支援的話,<html> 就會加上一個 Class .webp
    3. 接下來就只要寫兩段 CSS 就好,不難

實際在 CSS 用 .webp

  • 判斷瀏覽器是否支援:
<script>!function (e) { "use strict"; function s(s) { if (s) { var t = e.documentElement; t.classList ? t.classList.add("webp") : t.className += " webp", window.sessionStorage.setItem("webpSupport", !0) } } !function (e) { if (window.sessionStorage && window.sessionStorage.getItem("webpSupport")) s(!0); else { var t = new Image; t.onload = t.onerror = function () { e(2 === t.height) }, t.src = "data:image/webp;base64,UklGRi4AAABXRUJQVlA4TCEAAAAvAUAAEB8wAiMwAgSSNtse/cXjxyCCmrYNWPwmHRH9jwMA" } }(s) }(document);</script>
  • CSS mixin:
/* webp */ 
    @mixin bg-webp($url) {
    background-image: url('./../image/'+ $url + '.jpg');
    
    .webp & {
        background-image: url('./../webp/'+ $url + '.webp');
    }
}

/* 使用 */
.bg {
    @include bg-webp('bg_header');
}

( 搞半天其實全部只有用一張背景圖 bg_header 是寫在 CSS 裡面... )

🎯 階段性結果: 圖片改成 webp

  • 猜測結果
    • 看圖片大約都有減少一半大小,猜測可以 3 秒內
  • 真正結果
    • 3 秒出頭,不錯不錯!

螢幕快照 2019-09-05 下午9.34.30


☞ 減少 CSS 大小 & request

  • 使用 Bootstrap customize: 失敗
    • 只有支援到 3.xx 版本,把頁面有用到的勾一勾,載進來還是爆掉
  • 改試 gulp-uncss,原理是把頁面上沒用到的 CSS 移除,但看起來很久沒更新了,不是很穩定的樣子
    • 結果非常厲害,本來的 bootstrap.min.css150 KB,清掉變成 16 KB 😍
  • 利用 gulp-concat 將所有 CSS 打包成一支!
    • style.css 大小剩下 33 KB,效果顯著

🎯 階段性結果: 圖片改成 webp

  • 猜測結果
    • CSS 大幅縮小,DOMInteractive 的時間應該可以縮滿多的!
  • 真正結果
    • 2 秒了~
    • 但現階段 JS 的 request 還是一堆,所以 DOMInteractive 的時間並沒有縮短
  • PageSpeed
    • 在此優化之前,Google 的分數都超低,尤其是行動版,前個階段還是 2x 分,一把 CSS 縮小跟減少 request 之後,居然躍升成 94😂
    • 分數評量感覺 CSS 佔很大因素

螢幕快照 2019-09-05 下午11.10.01


☞ 減少 JS 大小 & request

  • 這邊的目標在於打包成一隻 JS 及如何對付萬惡的 jQuery
  • 先觀察冗碼在哪,Sources panel 裡面有個 Coverage( 要點開左邊的 more tools 才有 )
  • 滿滿的紅條就是龍馬本人,果然是 jQuery & bootstrap
  • 但找不到像剛剛 uncss 可以直接刪掉 JavaScript 程式碼的工具,找到的文章都是幫助你分析程式碼
  • 沒有方便的作法,因此我選擇放棄 😅

螢幕快照 2019-09-05 下午11.40.47

實際做了什麼?

  • 原本有 6 個 request,縮減成 3 個,把 <script> 都加上 defer
    • 全部打包成 1 隻 js 會爆掉,我猜是各自有相依關係,但打包順序無法控制
    • 所以 jQuerylazyload 還是獨立出來

🎯 階段性結果: defer Javascript

  • 猜測結果
    • CRP 路徑少了 3 個 request,且 script 改成 defer 就不會 block parsing,載入的空白期應該可以短很多!
  • 真正結果
    • 小幅減少成 1.7 秒!

螢幕快照 2019-09-06 上午1.05.53
- DOMInteractive0.5 秒~~~

螢幕快照 2019-09-06 上午1.06.16


☞ CSS sprite

  • 這是很不想面對的一環
  • 很想跟有做這優化的同學道歉,因為原本的 icon 是用 mask-image,這樣的寫法會讓 sprite 圖的製作變很麻煩
  • 其實 mask-image 主要是拿來做遮罩用,但因為 icon 想要有換色效果、但又不想用 svg,所以都是用 CSS 的新語法 mask-image 實現,而不是 background-image,原本就有預感做 sprite 圖會有困難
  • 上網找不到有關 mask-image sprite 的資料,要馬就轉成 svg 做成 svg sprite,但要重新找圖太累了,我決定採取土法煉鋼法,先用工具集合圖片!

postcss-sprites 生成 sprite 圖

  • 找到一線之光,postcss-sprites 看起來可以更改輸出參數,其實只要把 background-position 改成 mask-position 就可以了,試試看!
  • 結果:跑起來 log 出錯誤,說是與 postcss 版本衝突,總之失敗了,我連用工具匯成一張圖都搞不定... 😅

回頭土法煉鋼

  • 把同樣性質的 icon 轉成 3 張 sprite 圖 ( 用 photoshop )
  • 然後改一下 mask-position 完工
  • 因為此網頁還算簡單,可以手工製作,專案要是很多圖片就不要這樣虐待自己了。
.comments__icon {
    @include absolute($left: 0, $top: 0);
    @include size(70px);
    @include icon($color_main,
        'icon-comments');

    &.icon-strength {
        mask-position: 0 0;
    }

    &.icon-buddha {
        width: 80px;
        height: 80px;
        mask-position: 0 (100% / 3);
    }

    &.icon-sleep {
        mask-position: 0 (100% / 3 * 2);
    }

    &.icon-bao {
        mask-position: 0 100%;
    }
}

參考資料:

小結論:

  • 是可以達成目標,但這方法實在太不帥了很是苦惱
  • sprite 好煩人,而且後來才想到,為什麼不用 icon-font 就好了?!( 抱頭懊悔 )

🧐 突發問題: webp 跟 jpg 怎麼都載進來了?

突然發現一個很笨的問題,現在網頁上的圖片確是用 .webp 沒錯,但原先的 SCSS 寫法 .jpg 是預設圖片,只是用 .webp 的 Class 蓋過去了,所以 .jpg 還是載入進來了啊開什麼玩笑!

螢幕快照 2019-09-06 下午5.00.47

看到一些套件: webp-in-css 是會生成兩個 class: .webp & .no-webp

但我之前的引入的那段 script ,只會在 <html> 標籤上加上 webp,沒有 .no-webp 的 class 可以用,所以我改用 :not() 規則修改 SCSS ,變成以下:

/* webp */ 
@mixin bg-webp($url) {
    // background-image: url('./../image/'+ $url + '.jpg'); => 本來只有這樣,變成不管有沒有支援 web 都會載入 jpg
    html:not(.webp) & {
        background-image: url('./../image/'+ $url + '.jpg');
    }

    .webp & {
        background-image: url('./../webp/'+ $url + '.webp');
    }
}

<html>.webp 會套用到下面的規則、沒有則會套用到上面的 )

成果:

從 DevTools 可以看出來只載入了 webp 檔,是有點陽春但堪用的做法!

螢幕快照 2019-09-06 下午5.31.52

😬 發現事有蹊蹺

從 DevTools 的 Network 中發現還是載入有載入 png 檔案,這邊我卡了很久,之後向大師請教才得到啟發

螢幕快照 2019-09-06 下午5.37.35

🎯 階段性結果: defer Javascript

  • 猜測結果
    • 一陣兵荒馬亂之後要來揭曉成果,用 CSS sprite 處理 icon 之後,少了 11 個圖片 request,應該可以減少全部的載入時間
    • 不過雖然背景圖是 webp,但原格式還是載入了,這麼一來,等於同於載入兩個同樣的檔案,結果可能更糟 QQ
  • 真正結果
    • 果然幾乎沒變,甚至載入秒數多一點...

螢幕快照 2019-09-06 下午5.48.27

  • 倒是 dom 剩下 0.18 秒,棒棒的

螢幕快照 2019-09-06 下午7.02.37


👏 找到同時載入兩張圖的問題來源了

剛剛實在太困惑,乾脆求救問 Huli 大大,得到以下回答:

我大膽猜測可能是因為
你 .webp 是用 js 加的 class 吧?
css 的載入在 js 之前,所以就會先載入 jpg
順序:
1. 載入 css
2. dom build
3. 載入 css 裡面的 jpg
4. js 載入
5. js 執行
6. 加上 .webp
7. 載入 wep

恍然大悟! 😲😲😲😲

難怪網路上的教學大多都是使用兩種 class,而不是像我在那裡假會,用 :not() 判斷的寫法,所以照著此教學換掉判斷支援 webp 與否的 <script>使用 WebP 格式減少圖片載入時間

有了 .no-webp & .webp 2 種 Class 之後,SCSS 寫法改成:

換成兩種 class 分別載入不同圖檔,確保不會因為 JS 執行順序而有問題

/* webp */ 
@mixin bg-webp($url) {
    .no-webp & {
        background-image: url('./../image/'+ $url + '.jpg');
    }

    .webp & {
        background-image: url('./../webp/'+ $url + '.webp');
    }
}

🎯 階段性結果: 刪掉多餘 request

  • 猜測結果
    • 把來亂的 request 刪掉之後,有信心可以加快很多!
  • 真正結果
    • Document Complete 剩下 0.8 秒,開心得有點想哭。

螢幕快照 2019-09-06 下午7.59.55


黔驢技窮,結束優化之旅

比較可惜的地方有幾點:

  • 圖片應該可以再壓縮
    • 圖片應該還可以再壓縮,但怕再壓下去,損壞的程度會讓肉眼看出,所以就先保持這這樣。
  • 沒有全面用 webp
    • 主要是使用的 lazyload 套件無法在背景圖放 webp,找了很久還是沒有解法,就先放棄了。
  • JS 冗碼還是不少
    • 主要是 jQuery,但不知道怎樣再幫他瘦身,已經用 slim.min 版本了還是很肥,上網查 unused code 還是沒頭緒。
  • Cache
    • Github Page 能控制的不多,且自己對 Cache 還沒有太多研究,也是日後再來查資料。

其他檢測工具

  • lighthouse
    • 一個 Google 出品的 chrome 外掛,相較於 Goolge speed,檢查的更加全面

檢測結果: 恩。不是很好

螢幕快照 2019-09-06 下午9.52.32


心得

其實優化的過程比想像中還難,以前對於優化的概念大概就是知道有哪些手段,壓縮檔案、減少 request、script 用 async | defer 載入...,經過這次的優化作業中,學到最多的應該是針對性地優化哪個部分,有了更清楚的認知,歸功於這些方便的檢測工具。

但就算沒有這些工具可以用,上過 Website Performance Optimization 這堂課之後,多少也可以從 HTML 看出網頁上的問題在哪裡,如何優化、預期表現等等...

過程中在處理 webp 跟 CSS sprite 跟 lazyload 的路上非常坎坷,基本上我覺得跟圖片牽扯到的都比較麻煩,尤其是當所有優化手段集中在一起的時候,會有很多問題要處理。

總之感謝有這個機會,很多模糊的概念在實踐中都變得很清晰許多,真的是獲益良多!

@yakim-shu yakim-shu changed the title Yakim 網站優化成果 yakim-shu 網站優化成果 Sep 6, 2019
@aszx87410
Copy link
Member

aszx87410 commented Sep 6, 2019

因為圖片都是從圖庫網抓下來的,雖然 Huli 叫我不要縮小圖片,但其實我之前已有偷偷改過尺寸,不然每張圖片寬度都 3840px,大的連開啟網頁都有困難...

原來是這樣XDD

話說你這篇我給你 100 分...把優化過程寫得有夠清楚,清楚到我都覺得搞不好可以放上履歷當作作品集之一了(認真)。而且這篇其實改一改就可以變一篇優質的部落格文章了,你可以考慮一下,標題可以叫什麼「網頁優化實戰:以 lazy hackathon 為例」之類的。

基本上可以做的優化都已經做了,如果還想要再更進一步的話,就是把 jQuery 整個拿掉之類的,然後改用自己手寫的,把原本用到 jQuery 的地方自己寫出來。

總之能做到這樣已經很棒了,我覺得這成果非常好 💯

@yakim-shu
Copy link
Collaborator Author

yakim-shu commented Sep 7, 2019

哈哈哈哈標題都幫我想好,非常貼心!

其實我當初也有抱著這種心情寫,想說履歷如果有提到網頁優化,就直接貼這篇連結,但內容的確要修飾( 廢話太多老症頭 ),也想隱藏 sprite 圖是手工製作的事實,我怕會被工程師鄙視 🤣

寫到後面有點無力了,做紀錄比實際優化還難啊,可能再補個 before & after 的 CRP 分析。
至於 jQuery,全部應該也只有 carousel 是依賴於 jQuery,換個符合需求的 plugin 應該沒問題!

@mingjunlu
Copy link

mingjunlu commented Oct 31, 2019

@yakim-shu 已跪⋯⋯不管是優化後的載入速度,或者記錄過程的詳細程度都很驚人!覺得可以寫成部落格文章發布 +1

@objcxiaobai
Copy link

objcxiaobai commented Nov 20, 2019

@yakim-shu 很厲害,跪拜。但我對《先把圖片尺寸調整到正常、但不失真的狀態》這裏有點疑問,為什麼“ 考慮到 retina 螢幕解析度為兩倍的情況” 為什麼要*2呢?把設計稿的存尺復現到網頁上,應該注意什麼?請指教

@mingjunlu
Copy link

mingjunlu commented Nov 20, 2019

@objcxiaobai 雖然還沒實作過但試著回答看看兩倍的問題,我的理解是這樣:

圖片解析度在網頁上並不是永遠固定的,例如 ppi/dpi 這些值瀏覽器會忽略,因為在網頁上是由圖片的「寬、高」決定解析度。舉例來說,圖片高度自動的情況下:

  • 寬 1400px 的圖片,HTML/CSS 設定為寬 1400px ,解析度是 1x
  • 寬 2800px 的圖片,HTML/CSS 設定為寬 1400px,解析度是 2x

假如說今天在網頁放一張寬 1400px * 700px、HTML/CSS 也設定 1400px * 700px 的圖片,這樣給一般螢幕瀏覽沒問題,但換成 Retina 螢幕看就會顯得模糊失真。因此通常為了顧及有 Retina 螢幕的裝置瀏覽體驗,會存一張寬高兩倍、在這個例子就是 2800px * 1400px 的圖片備用。

@objcxiaobai
Copy link

objcxiaobai commented Nov 27, 2019

@mingjunlu 非常感謝回答,我有點理解苗頭了。請問還原設計稿到屏幕上需要注意什麼?

@mingjunlu
Copy link

mingjunlu commented Nov 27, 2019

@objcxiaobai 我目前缺乏實戰經驗,對此無法提供什麼具體建議,不好意思 😅
順帶一提,光問「要注意什麼」可能稍嫌廣泛、籠統,若能再聚焦問題點的話,應該會比較好回答,拙見供參考~

@objcxiaobai
Copy link

objcxiaobai commented Nov 29, 2019

@mingjunlu 非常感謝。這是很好的建議,感謝指出

@CHANG-CHING-CHUNG
Copy link

CHANG-CHING-CHUNG commented Oct 31, 2020

跪拜大神~太詳細了啊! 簡直就是網站速度優化之神啊!
已收錄在我的最愛

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants