改善 Wikipedia 的 JavaScript,減少 300ms 的 blocking time

Hacker News 首頁上看到「300ms Faster: Reducing Wikipedia's Total Blocking Time」這篇,作者 Nicholas RayWikimedia Foundation 的工程師,雖然是貼在自己的 blog 上,但算是半官方性質了... 文章裡面提到了兩個改善都是跟前端 JavaScript 有關的。

作者是透過瀏覽器端的 profiling 產生火焰圖,判讀裡面哪塊是大塊的問題,然後看看有沒有機會改善。

先看最後的成果,可以看到第一個 fix 讓 blocking time 少了 200ms 左右,第二個 fix 則是少了 80ms 左右:

第一個改善是從火焰圖發現 l._enable 吃掉很多 blocking time:

作者發現是因為 find() 找出所有的連結後 (a 元素),跑去每一個連結上面綁定事件造成的效能問題:

The .on("click") call attached a click event listener to nearly every link in the content so that the corresponding section would open if the clicked link contained a hash fragment. For short articles with few links, the performance impact was negligible. But long articles like ”United States” included over 4,000 links, leading to over 200ms of execution time on low-end devices.

但這其實是 redundant code,在其他地方已經有處理了,所以解法就比較簡單,拔掉後直接少了 200ms:

Worse yet, this behavior was unnecessary. The downstream code that listened to the hashchange event already called the same method that the click event listener called. Unless the window’s location already pointed at the link’s destination, clicking a link called the checkHash method twice — once for the link click event handler and once more for the hashchange handler.

第二個改善是 initMediaViewer 吃掉的 blocking time,從 code 也可以看到問題也類似,跑一個 loop 把事件掛到所有符合條件的元素上面:

這邊的解法是 event delegation,把事件掛到上層的元素,就只需要掛一個,然後多加上檢查事件觸發的起點是不是符合條件就可以了,這樣可以大幅降低「掛」事件的成本。

這點算是常用技巧,像是 table 裡面有事件要掛到很多個 td 的時候,會改成把一個事件掛到 table 上面,另外加上判斷條件。

算是蠻標準的 profiling 過程,直接拉出真實數據來看,然後調有重大影響的部分。

維基基金會 (包括維基百科) 的官方服務狀態頁

看到「Announcing www.wikimediastatus.net」這個,維基基金會相關服務的官方狀態頁:「www.wikimediastatus.net」。

從頁面下面的「Powered by Atlassian Statuspage」這邊可以看出來是使用 Statuspage 這個服務。

看起來當 server error 狂噴的時候這邊應該有機會看到 (剛好前陣子好像有發生),另外 Total request volume 這個指標也透漏了目前整個維基基金會服務尖峰會有 150Kreqs/sec 的量,可以預期大多數應該都是維基百科相關的服務...

不過大多數的量應該都是從 cache server 吐出去,不知道有沒有後端 PHP loading 的數字...

維基基金會對中國大陸維基人用戶組的行動 (WMCUG)

在『維基媒體基金會出手清除多名「中國大陸維基人用戶組」成員。包括封禁其在全球所有維基媒體基金會項目的帳號,或是拔除在中文維基百科的管理員權限。』這邊看到的消息,看起來目前都還在進行中,所以這幾天還可以繼續等看看消息。

中文版維基百科的管理群裡面被中國政府以及共青團伸手進來的事情是眾所皆知,只是先前維基基金會一直都是抱持沒有確切證據不處理的態度。

這次官方的正式聲明是由 Maggie Dennis 署名 (法務部門 VP),可以參考「Office actions/September 2021 statement」(英文版) 與「基金會行動/2021年9月聲明」(中文翻譯版本)。

相關的拔權記錄可以在「Special:Log/WMFOffice」這邊看到,這邊的時間應該是 UTC,可以看到還有陸陸續續在拔。另外在「Wikipedia:2021年基金會針對中文維基百科的行動」這邊也有一些記錄。

看到連 Outlookxp 都被拔了,總算是出手了啊...

另外補充一下在 mailing list 上看到的資料,原始的 Twitter 已經刪除,但 Internet Archive 上面還有備份:

https://web.archive.org/web/20210914024812/https://twitter.com/Philip_Tzou/status/1437543054043275265

Blockchain 的使用時機

這兩則可以一起看,首先是 Jimmy Wales 對於提議用 blockchain 記錄維基百科的回應:

另外一個是 xkcd 最近的酸圖:

腦袋裡又瞬間冒出「詐騙集團」這個詞彙 XDDD

維基百科的 Vital articles

Hacker News Daily 這邊看到,英文版維基百科有一套列表,整理出「重要」的條目:「Wikipedia:Vital articles」。

目前的列表有五個層級,從 Level 1 到 Level 5,後面的 Level 包含了前面 Level 的文章:

  • Level 1 只有 10 篇。
  • Level 2 有 100 篇 (包含 Level 1 的 10 篇,以下類推)。
  • Level 3 有 1000 篇。
  • Level 4 有 10000 篇。
  • Level 5 有 50000 篇。

看到的第一個問題就是這些列表怎麼產生的,這點在 Wikipedia talk:Vital articles/Frequently Asked Questions 裡面有提到列表的歷史:這是 2004 年由 David Gerard 發起,之後擴大到社群並且分不同等級。而這也說明了這些列表示人工選擇的,而不是透過演算法推薦的:

The English Wikipedia Vital Articles list was originally created in August 2004 by David Gerard as an adaptation of the metawiki List of articles every Wikipedia should have. Since then, the Vital Articles list has undergone numerous revisions by multiple editors, and has expanded to include 5 different levels of vitalness.

然後選擇的標準是「要了解這個領域不可或缺的條目」:

A vital article is one considered essential to the subjects listed. For example, it would be difficult to discuss Science without the scientific method, History without World War II, Language without Grammar, Earth science without Geology, or Civics without Democracy. Individuals within the People section represent the pinnacles of their field, such as Albert Einstein in "Inventors and scientists" or William Shakespeare in "Authors". In sections such as those pertaining to People, History or Geography, weight is given to some articles to produce a more diverse, global list.

這些列表其中一種用法是「想要了解某個領域」,但剛剛翻了一下 Level 1 與 Level 2 可以發現似乎太少,看起來 Level 3 的資料算是個還不錯的起點...

維基百科各語言與各地區的綜合資訊

維基百科推出了新版的介面:「Just how many people are reading Wikipedia in your country, and what language are they using?」。

We recently released a new interactive visualization of Wikipedia traffic by country and language. Called WiViVi, which stands for Wikipedia Views Visualized, the new visualization shows the geographic distribution of pageviews to any or all Wikipedias from two different perspectives[.]

這個介面可以看到每個版本在每個地區佔的比率,像是中文維基百科的情況:

不過翻牆 VPN 的不知道怎麼算...

收 Wikimedia (包括維基百科) 的 Recent Changes

所以有新的 streaming protocol 取代本來的 RCStream:「Get live updates to Wikimedia projects with EventStreams」。

這次新的 protocol 是走標準協定:

EventStreams is built on the w3c standard Server Sent Events (SSE). SSE is simply a streaming HTTP connection with event data in a particular text format. Client libraries, usually called EventSource, assist with building responsive tools, but because SSE is really just HTTP, you can use any HTTP client (even curl!) to consume it.

直接用瀏覽器打開也可以看到一直冒出來新的訊息...

V8 對 for-in 的最佳化

V8 引擎的人對 for-in 的最佳化寫了一篇解釋「Fast For-In in V8」,比較直接的結果就是維基百科Facebook 都變快了:

For example, in early 2016 Facebook spent roughly 7% of its total JavaScript time during startup in the implementation of for-in itself. On Wikipedia this number was even higher at around 8%.

可以看得出來是挑比較大的來改,而下一版的 Google Chrome (57) 將會對 for-in 會到另外一個極致:

The most important for-in helpers are at position 5 and 17, accounting for an average of 0.7% percent of the total time spent in scripting on a website. In Chrome 57 ForInEnumerate has dropped to 0.2% of the total time and ForInFilter is below the measuring threshold due to a fast path written in assembler.

主要是因為 spec 對 for-in 的定義寫得很模糊,所以就有很多實作的空間可以調整:

When we look at the spec-text of for-in, it’s written in an unexpectedly fuzzy way,which is observable across different implementations.