Tag Archives: loading

針對 JavaScript 時代調整網頁的效能評估指標

早期網頁的效能評估指標都沒有考慮 JavaScript 的情況,大多都是 TTFB (Time to First Byte) 或是網頁大小以及 DOMContentLoaded 或是 load 這類 DOM event 為主,但因為 Goodhart's law,現代的網頁設計會故意將許多 JavaScript 要做的事情搬到 load 以後開始做,以降低 load 被延遲的問題,讓前端的「KPI」比較好看:

When a measure becomes a target, it ceases to be a good measure.

但在 load 之後整個網站還是不能用,使用者的體驗其實很差,這個評估方式的價值變低不少。所以「Measuring Jank and UX」這篇就再找出一些新的指標,來評估 JavaScript 造成的問題。

可以看到文章裡面評估了很多關於 CPU loading 與操作時間的指標,也許這一兩年還會有用,不過我覺得還是會遇到 Goodhart's law 描述的問題... XD

Chrome 對各種 JavaScript 的優先順序

前陣子看到「JavaScript Loading Priorities in Chrome」這篇,在分析 Google Chrome 對各種 JavaScript 的優先順序。

優先順序分成讀取的「Loading priority (network/Blink)」與執行的「Execution priority」,另外文章裡也有整理建議「Where should this be used?」。

看起來 <script defer> at the end of <body> 是全部裡面最低的,建議是給 Load "Related articles" 或是 "Give feedback" 這類功能,不過應該沒什麼人真的這樣用...

然後要注意的是,這邊分析的對象是 Google Chrome,實際在設計時應該要先考慮一般性的定義,再考慮對各瀏覽器的最佳化... (雖然以現在市占率來說沒什麼人想管其他瀏覽器...)

用 link="preload" 提高下載的優先度

除了讓 browser 自己決定優先權外,在「Preload Scripts」這邊看到的技巧,可以跟 browser 說明哪些資源比較重要,請儘快先下載:

<link rel="preload" href="main.js" as="script">

Link rel=preload is useful for downloading any important resource more quickly, such as stylesheets that contain critical CSS, fonts that are used in important design elements, and hero images. It's especially important for scripts because they block page content from rendering and consume the most CPU during page load.

以作者的想法,這個技巧應該用在會卡住頁面呈現的部分,確保這些資源可以優先下載。

另外作者也提到了可以直接把這個資訊放到 HTTP header 裡面,理論上會更快:

Link: <main.js>; rel="preload"; as="script"

尤其是 sync script 應該會有幫助,建議可以跑 A/B test 看看效果:

We know that synchronous scripts block rendering, which makes the user experience feel slow. And we know that most scripts today are downloaded synchronously (rather than async). And yet only 1% of sites are using link rel=preload to download their scripts. If your site has any synchronous scripts, do an A/B test adding link rel=preload for them. It's likely this will be a win and help you create a more joyous experience for your users.

Linux 下 RAID1 的 SSD 會有讀取不平均問題

在「Unbalanced reads from SSDs in software RAID mirrors in Linux」這邊看到作者看 S.M.A.R.T. 數據時發現兩顆 SSD 硬碟組成的 RAID1 有很明顯的讀取不平均的問題:

242 Total_LBAs_Read [...] 16838224623
242 Total_LBAs_Read [...] 1698394290

原因是因為 Linux 對 RAID1 的 SSD 有不一樣的演算法:

The current state of RAID1 read balancing is kind of complex, but the important thing here in all kernels since 2012 is that if you have SSDs and at least one disk is idle, the first idle disk will be chosen.

2016 時演算法就更激進了,變成非 SSD 會:

In kernels with the late 2016 change, this widens to if at least one disk is idle, the first idle disk will be chosen, even if all mirrors are HDs.

加上 SSD 很快,這造成 loading 幾乎都在第一顆上... 這對 SSD 應該是還好啦 (理論上 SSD 的讀取不傷壽命),不過還是有點怪就是了。

Facebook 用 PJPEG 的技巧

Facebook 在「Faster Photos in Facebook for iOS」這篇提到使用 PJPEG 降低流量並且提昇大圖的速度。

實際上我覺得有點詭異,依照說明,降低流量的部份是因為原來有縮圖與大圖:

而現在只要抓一張,所以綜合起來降低了:

但不是每一張都這樣吧?另外是降低了到一定品質所需 image loading 的時間,但這樣看起來用小縮圖應該會更好?雖然 Facebook 的人是以 A/B testing 驗證,但以目前 Facebook 提供的數據並不通,看不太懂他的邏輯...

先丟著吧...