針對 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

Netflix 對 Landing Page 的效能改善計畫...

幹掉 React (噗):

官方帳號丟戰文出來... 後面就有人開始亂 XDDD

不過先拉回來看... 依照說明,其他頁面都還是跑 React,只有 Landing Page 被改寫,看起來 Landing Page 的 TTI (Time to Interactive) 是他們的 KPI,所以就被拿出來另外處理了...

當然也有可能有其他的陰謀論 (而且我覺得可能性是在的):因為之前 React 的專利問題,變成之後 Facebook 如果真的出手提出告訴,會以惡意侵權來告 (因為鬧這麼大以後,沒有理由裝作不知道了)。這次只換 Landing Page 可以當作是試水溫練功 (累積 migration 的經驗),後續再換內頁...

在教育領域用 KPI 制度的結果

這邊提到在教育領域所設計的制度所期望帶來的效果,與實際帶來的效果的差異:「Every attempt to manage academia makes it worse」。


出自「Academic Research in the 21st Century: Maintaining Scientific Integrity in a Climate of Perverse Incentives and Hypercompetition」這篇論文。

這邊左邊的 Incentive 都是可被量化的方式,而中間有預期的效果,右邊則是實際發生的效果。跟台灣校園裡看到的情況很接近。

可以看出來,你對用腦吃飯的人設計 KPI 制度,大概都是這樣的下場 XDDD