HTTP/1.1 與 HTTP/2 的最佳化技巧

這篇在討論,無論是 HTTP/1.1 時代,或是 HTTP/2 時代下 (裡面還包括了 HTTP/2 的 Server Push),各種讓下載速度最佳化的技巧以及造成的複雜度:「Performance testing HTTP/1.1 vs HTTP/2 vs HTTP/2 + Server Push for REST APIs」。

文章裡其中一個提到的是各類「打包」的技巧,也就是 JavaScript 的 bundle,或是 CSS 的 Image sprites,甚至是 API 的合併,像是很多人會考慮的 GraphQL

雖然在 HTTP/2 年代我們常說可以省下來,但這並不代表「打包」在 HTTP/2 情境下沒有效果,只是改善的幅度比較少,所以這個最佳化的技巧比起 HTTP/1.1 年代,可以放到後面一點再做,先把人力放到其他地方。但如果團隊工具已經熟悉打包技巧的話 (可能是以前就已經做好了),其實繼續使用沒有太大問題...

另外是 Server Push 的情境,意外的反而可以提昇不少速度,看起來主要是少了請求的時間,所以快不少。

再來是跨網域時 CORS 的問題,在 Flash 的年代是一個 crossdomain.xml 解決,但現在的解法是多一個 OPTIONS request,反而造成很大的效能問題... 文章裡提到現在看起來有個 Draft 在發展與 Flash 類似的機制:「Origin Policy」。

作者在測試完後得到的結論其實跟蠻多「直覺」相反的:

  • If speed is the overriding requirement, keep using compound documents.
  • If a simpler, elegant API is the most important, having smaller-scoped, many endpoints is definitely viable.
  • Caching only makes a bit of difference.
  • Optimizations benefit the server more than the client.

cdnjs 轉移到 Cloudflare 負責維護

不確定是 cdnjs 還是 CDNJS,因為官方網站是小寫,但 GitHub 上是大寫...

Anyway,cdnjs 本來由社群維護更新 (實際上是透過 bot 更新,但 bot 本身也需要維護),因為人力時間的因素,轉移給 Cloudflare 負責了:「An Update on CDNJS」。

這次也更新了 cdnjs 的 daily request 數量,可以看到現在大約是每天六十億次:

本來 Cloudflare 是站在贊助頻寬的角色提供服務:

Within Cloudflare’s infrastructure there is a set of machines which are responsible for pulling the latest version of the repo periodically. Those machines then become the origin for cdnjs.cloudflare.com, with Cloudflare’s Global Load Balancer automatically handling failures. Cloudflare’s cache automatically stores copies of many of the projects making it possible for us to deliver them quickly from all 195 of our data centers.

但更新的 bot 本身掛了,而且維護者沒時間修:

Unfortunately approximately thirty days ago one of those bots stopped working, preventing updated projects from appearing in CDNJS. The bot's open-source maintainer was not able to invest the time necessary to keep the bot running. After several weeks we were asked by the community and the CDNJS founders to take over maintenance of the CDNJS repo itself.

所以現在則是 Cloudflare 接手維護了:

This means the Cloudflare engineering team is taking responsibility for keeping the contents of github.com/cdnjs/cdnjs up to date, in addition to ensuring it is correctly served on cdnjs.cloudflare.com.

不過裡面也提到了一個問題,就是現在瀏覽器為了安全性,對於不同的站台會有不同的 cache,本來 cdnjs 的設計目的之一被大幅削弱,現在只剩下省頻寬了:

The future value of CDNJS is now in doubt, as web browsers are beginning to use a separate cache for every website you visit. It is currently used on such a wide swath of the web, however, it is unlikely it will be disappearing any time soon.

改善內嵌 YouTube 影片的載入速度

YouTube 的 embed 會載入大量的元件,所以就有專案把對使用者沒有意義的元件都拔掉:「Lite YouTube Embed」。

從比較可以看出來 Lite YouTube Embed 下載的元件少很多:

當然在功能上有差異,不過基本的功能應該都沒問題...

雖然還是 JavaScript 實做,但可以看到實際的程式碼大概 40 行而已?(註解的行數大約是程式碼的兩倍):「lite-youtube-embed/src/lite-yt-embed.js」。

不過要注意的是,程式碼中用到 ES6 的 class 語法,所以如果要考慮到 IE11,應該是要打包轉換...

Google 搜尋無法使用 Lynx 或是 w3m 操作了

看到「No more google for console junkies」這篇,裡面提到了新版的 Google 沒辦法用 Lynx 操作了,拿 w3m 測了一下發現也不行了,可以搜到東西,但連結的操作已經是 JavaScript 化了,而這兩個瀏覽器都不支援 JavaScript,所以就卡住了...

是個從早年的 Unobtrusive JavaScript 概念,到現在沒有 JavaScript 就不會動的年代...

有翻到一些有支援 JavaScript 的 terminal web browser (LinksELinks),但都只是實驗品,連輸入中文都有問題... :/

Facebook 推出了 Hermes,為了 React Native 而生的 JS Engine

Facebook 提供了一個對 React Native 最佳化的 JS engine:「Hermes: An open source JavaScript engine optimized for mobile apps, starting with React Native」。

裡面有提到兩個比較重要的的部份是 No JIT 與 Garbage collector strategy,針對行動裝置的特性而設計:避免 JIT 產生的 overhead,以及降低記憶體使用量。

官方給的改善主要也都是偏這兩塊:

不過沒有提到 CPU usage 會上升多少,只是帶過去:

Notably, our primary metrics are relatively insensitive to the engine’s CPU usage when executing JavaScript code.

對於 Facebook 也許是可以接受的數量,但對於其他人就沒概念了... 要入坑的人自己衡量這部份的風險 XD

Slack 改善桌面應用程式的效能與記憶體用量

Slack 桌面版改版的消息,在「Slack’s new desktop app loads 33 percent faster and uses less RAM」與「Slack speeds up its web and desktop client」這邊都有提到這兩個數字,不過看了官方的「When a rewrite isn’t: rebuilding Slack on the desktop」這篇,好像沒提到這兩個數字... 但看引用的圖片似乎是官方的評估數字,不知道是從哪邊得到的。

這是一個堅持繼續使用 Electron 的前提下改善效能的過程。如果過個幾年他們決定寫 native application 也不意外就是了,要一直壓榨效能,最後大概都會走到這邊... 當然也有可能靠 Google 一直改善 V8 engine 的效能撐很久 (畢竟 Google 是真狂砸人改善),現在大家都在賭可以改善多少 XD

這一波最主要的記憶體用量改善是來自於現在使用的 workspace 當然要有完整資料,而其他 workspace 的頁面就只保留狀態 (透過 Redux):

從記憶體用量可以看出來:

也可以理解因為這樣就不需要在啟動時馬上處理所有 workspace 的資料,所以啟動時間也就下降了不少,但這邊的 trade-off 是切換時的速度就會變慢 (需要重新 render),不過大概是考慮到常見情境下的切換次數而決定這樣做,應該還算 ok...

Fabrice Bellard 的 QuickJS

Fabrice Bellard 跑去寫了一套 JavaScript engine 出來:「QuickJS」。

以 ES2019 當底實做的 JS engine:

Almost complete ES2019 support including modules, asynchronous generators and full Annex B support (legacy web compatibility).

測試的部份也過了:

Passes 100% of the ECMAScript Test Suite.

在大小的部份,比起其他的 engine (與 package) 來說的確是小很多,不過 190KB 這個大小對於 embedded system 來說還是有點微妙 (但對於想要包 JS engine 進去用的人應該是頗開心的):

Small and easily embeddable: just a few C files, no external dependency, 190 KiB of x86 code for a simple hello world program.

不愧是 Fabrice Bellard,搞出了 LZEXEFFmpegQEMU 後跑來搞 JS...

移除 Blog 上的 Google Analytics,改用 Matomo

跑了快一個月了,大概整理一下...

一直都有在規劃降低對 Google 服務的依賴性,最主要的是使用 DuckDuckGo 替代 Google Search (但搜尋的品質還是差一截,所以寫了一些工具幫助我在不滿意的時候可以快速切到 Google 搜尋:「在 DuckDuckGo 搜尋頁快速切換到 Google 的套件」)。

而最近在研究的另外一個服務是 Google Analytics,我只用很基本的功能 (像是熱門文章,作業系統與瀏覽器的比率這些很基本的資料),不需要對於觀看客群有了解 (這個需要像 Google Analytics 跨站蒐集資料),所以替代方案應該不難找...

憑著印象與一些關鍵字,找到了 Matomo,這是一套 open source 的 web analytics 服務,以前叫做 Piwik (參考「Piwik is now Matomo - Announcement」),整個系統用 PHP + MySQL 就可以打發 (反正量不大的東西不需要拿什麼神兵利器出來,MySQL 硬塞硬算就可以了),接著把本來 Google Analytics 的 js 換掉就行了...

跑了快一個月後感覺還 ok,基本的資訊都有...

JavaScript 的 sort 變成 stable

看到「Stable Array.prototype.sort」這篇在講 JavaScript 規格書裡的 sort...

本來 JavaScript 的規格書裡,各種 sort 都沒有保證 stable,而在「[Normative] Make Array.prototype.sort stable #1340」與「[Normative] Make %TypedArray%.prototype.sort stable #1433」這兩個地方則有了變化,提案在規格裡加入 stable 的要求,可以減少開發者因為不知道 unstable 而造成的問題...

Firefox 則是很久前就決定使用 Merge sort 了 (看了一下,當時還在從 Firebird 轉換名稱到 Firefox 的時期):「Array.sort isn't a stable sort (switch to MergeSort)」。

另外這篇也剛好提到了 V8 使用 Timsort 當作 stable sorting algorithm,之前就有看到但發現沒在 blog 上提過...

Timsort 是 1993 年發明出來的演算法,與 Merge sort 的情況類似,除了 stable 外,還可以保證最差的情境下的時間複雜度是 O(n*log(n))

Timsort is a hybrid stable sorting algorithm, derived from merge sort and insertion sort, designed to perform well on many kinds of real-world data.

這個演算法的重點是善用已經排好的子序列,藉此降低記憶體操作次數而提昇效能,符合真實環境裡常見到的資料:

The algorithm finds subsequences of the data that are already ordered, and uses that knowledge to sort the remainder more efficiently.

除了 V8 採用這個演算法以外,其他常見的包括了 PythonAndroid 上的 Java SE:

Timsort has been Python's standard sorting algorithm since version 2.3. It is also used to sort arrays of non-primitive type in Java SE 7, on the Android platform, in GNU Octave, and Google Chrome.

Salesforce 弄了一個新的玩意出來...

然後在 Hacker News 上被酸爆了:「Open-sourcing the Lightning Web Components framework (salesforce.com)」。引用的原文在「Introducing Lightning Web Components Open Source」這邊。

主要還是大家已經厭倦前端一直丟東西出來,但是速度一直都沒什麼改善... 用傳統的 server rendering 反而省了不少 client 端的 CPU resource。

話說回來,前幾天的伺服器爆炸好像沒看到什麼後續新聞... (參考「Salesforce enables modify all in all user profiles」、「Salesforce系統更新意外造成權限擴張,用戶服務被迫中斷」)。