2024 年 JavaScript 的臃腫狀況

I was a bit out of touch with modern front-end development. I also remembered articles about web bloat, how the average web page size was approaching several megabytes!

我有點與現代前端開發脫節了。記得以前看過一些講 Web 臃腫的文章，說平均網頁大小都快接近好幾 MB 了！

So all this time I was living under impression that, for example, if the average web page size is 3 MB, then JavaScript bundle should be around 1 MB. Surely content should still take the majority, no?

所以我一直以為是這樣：比如平均網頁大小要是 3MB，那 JavaScript 包大小估計也就 1MB 左右。內容肯定還是佔大頭，對吧？

Well, the only way to find out is to fuck around. Let’s do a reality check!

好吧，唯一能搞清楚的方法就是親自動手摺騰一番。我們來看看實際情況！

I’m writing this in 2024, so maybe do a sequel in a few years?

我現在是在 2024 年寫的這篇文章，所以也許幾年後再寫個後續？

閣下可能在使用不支援 CSS 的瀏覽器或閱讀器。使用現代瀏覽器訪問該文章，可檢視單/雙語、漢/漢語、橫/直排版本。

Method#

測試方法#

• Firefox on macOS (but should be the same in any browser)
• macOS 上的 Firefox（但在任何瀏覽器中結果應該都一樣）
• Not incognito (I want to see numbers inside the app, and there’s a better chance it will resemble actual everyday experience)
• 非隱身模式（我想看看應用實際執行時的載入資料，這樣更接近真實的日常使用體驗）
• All extensions disabled
• 所有擴充禁用
• JavaScript only
• 僅統計 JavaScript
• Uncompressed
• 未壓縮大小
• Service Workers enabled (again, more real-life)
• Service Workers 啟用（同樣，為了更貼近真實使用場景）
• All caching disabled (cold load)
• 所有快取禁用（即冷載入）

Why only JavaScript? Content varies a lot from site to site (surely videos on YouTube are heavier than text messages on Slack), but JavaScript is a universal metric for “complexity of interactions”.

為什麼只看 JavaScript？不同網站的內容差異很大（YouTube 上的影片肯定比 Slack 上的文字訊息更佔地方），但 JavaScript 是衡量「互動複雜度」的通用指標。

The main goal is to evaluate how much work the browser has to do to parse and execute code.

主要目標是評估瀏覽器為了解析和執行這些程式碼需要做多少工作。

To set some baseline, let’s start with this blog:

為了設定一個基準，我們從本部落格¹開始：

The number here would be 0.004 MB. I also highlighted all the important bits you need to set if you decide to reproduce this at home.

這裡的資料是 0.004 MB。我還高亮了所有重要的設定項，如果你想自己動手復現這個過程的話。

Landings#

著陸頁#

Okay, let’s start with something simple, like landing pages/non-interactive apps.

好吧，讓我們從一些簡單的東西開始，比如著陸頁或基本沒什麼互動的應用。

A normal slightly interactive page looks like this — Wikipedia, 0.2 MB:

一個正常的、略帶互動的頁面大概是這樣——維基百科，0.2 MB：

Slightly bloated — like this — Linear, 3 MB:

稍微有點臃腫的——比如這個——Linear，3 MB：

Remember: that’s without images, or videos, or even styles! Just JS code.

記住：這還不包括圖片、影片，甚至樣式！僅僅是 JS 程式碼。

A bad landing page looks like this — Zoom, 6 MB:

一個糟糕的著陸頁大概是這樣——Zoom，6 MB：

or like Vercel, 6 MB:

或者像 Vercel，6 MB：

Yes, this is just a landing page. No app, no functionality, no calls. 6 MB of JavaScript just for that.

是的，這僅僅是一個著陸頁。沒有應用本身，沒有實際功能，也沒有後臺呼叫。就為了這個，要 6 MB 的 JavaScript。

You can do a lot worse, though — Gitlab, 13 MB:

不過，還有更離譜的——Gitlab，13 MB：

Still just the landing.

這也僅僅是個著陸頁。

Mostly static websites#

大部分是靜態內容的網站#

Nothing simpler than showing a static wall of text. Medium needs 3 MB just to do that:

沒什麼比顯示滿螢幕的靜態文字更簡單了吧。Medium 就為了這個需要 3 MB：

Substack needs 4 MB:

Substack 需要 4 MB：

Progress?

有進步嗎？

Quora, 4.5 MB:

Quora，4.5 MB：

Pinterest, 10 MB:

Pinterest，10 MB：

Patreon, 11 MB:

Patreon，11 MB：

And all this could’ve been a static page...

而所有這些，本可以只是一個靜態頁面……

Search#

搜尋功能#

When your app’s interactivity is limited to mostly search. Type the query — show the list of results. How heavy is that?

當你的應用互動主要就是搜尋。輸入查詢語句——顯示結果列表。這種的需要多重？

StackOverflow, 3.5 MB:

StackOverflow，3.5 MB：

NPM, 4 MB:

NPM，4 MB：

Airbnb, 7 MB:

愛彼迎，7 MB：

Booking.com, 12 MB:

Booking.com，12 MB：

But Niki, booking is complicated! Look at all this UI! All these filters. All these popups about people near you stealing your vacation!

但是，Tonsky，訂票頁面很複雜啊！看看這滿屏的 UI！這麼多篩選器！還有那些告訴你手慢無的煩人彈窗！

Okay, okay. Something simpler then. Google. How about Google? One text field, list of links. Right?

好吧，好吧。那來個簡單點的。谷歌。谷歌搜尋怎麼樣？一個輸入框，然後一個連結列表。對吧？

Well, it’ll cost you whooping 9 MB:

嗯，這就要你足足 9 MB：

Just to show a list of links.

僅僅是為了顯示一個連結列表。

Simple one-interaction apps#

簡單互動型應用#

Google Translate is just two text boxes. For that, you need 2.5 MB:

谷歌翻譯就倆文字框。就這個，你需要 2.5 MB：

ChatGPT is one text box. 7 MB:

ChatGPT 就一個文字框。7 MB：

I mean, surely, ChatGPT is complex. But on the server, not in the browser!

我的意思是，誠然，ChatGPT 本身很複雜。但複雜的是後端，不是前端啊！

Videos#

影片網站#

Loom — 7 MB:

Loom — 7 MB：

YouTube — 12 MB:

YouTube — 12 MB：

Compare it to people who really care about performance — Pornhub, 1.4 MB:

跟那些真正關心效能的網站比比——Pornhub，1.4 MB：

Audio#

音訊網站#

I guess audio just requires 12 MB no matter what:

我猜音訊網站起步價橫豎是 12 MB：

SoundCloud:

SoundCloud：

Spotify:

Spotify：

Email#

郵箱#

Okay, video and audio are probably heavy stuff (even though we are not measuring content, just JS, remember!). Let’s move to simpler office tasks.

好吧，影片和音訊可能確實是大傢伙（但是還是想強調，我們測量的可不是內容，只是 JS 程式碼！）。讓我們轉向更簡單的辦公任務。

Google Mail is just (just!) 20 MB:

谷歌郵箱只有（僅僅只有！）20 MB：

It’s a freaking mailbox!!! How on earth is it almost as big as Figma, who ships entire custom C++/OpenGL rendering for their app?

這特喵的是個郵箱！！！它到底是怎麼做到幾乎和 Figma 一樣大的？Figma 可是內建了一整套定製的 C++/OpenGL 渲染引擎的啊！

And if you are thinking: mail is complicated, too. Lots of UI, lots of interactivity. Maybe 20 MB is okay?

如果你在想：郵箱也很複雜啊，那麼多介面，那麼多互動。也許 20MB 也還行？

No!

不！

Just no. See, FastMail, same deal, but only 2 MB. 10× less!

絕不可能。看，FastMail，幹著同樣的活兒，但只有 2 MB。少了整整 10 倍！

Productivity#

生產力工具#

Okay, maybe e-mail is too complicated? How about something even simpler? Like a TODO list?

好吧，也許郵箱還是太複雜了？那來點更簡單的怎麼樣？比如一個待辦事項清單？

Well, meet Todoist, 9 MB:

那麼，來看看 Todoist，9 MB：

Showing you a list of files in folders requires 10 MB in Dropbox:

在 Dropbox 中顯示資料夾裡的檔案列表，需要 10 MB：

List of passwords? That’ll be 13 MB on 1Password:

密碼列表？1Password 上需要 13 MB：

Cards? Add 0.5 MB more, up to 13.5 MB. Trello:

一些卡片？再加 0.5 MB，高達 13.5 MB。說的是 Trello：

Okay, maybe TODO lists are too complex, too? How about chatting?

好吧，也許待辦事項清單也太複雜了？那聊天軟體呢？

Well, Discord needs 21 MB to do that:

嗯，Discord 需要 21 MB 來實現聊天功能：

Document editing#

文件編輯#

Okay, document editing is hard, right? You have to implement cursor movement, synchronization, etc.

好吧，文件編輯是挺難的，對吧？你必須實現游標移動、內容同步等等。

Google Docs, 13.5 MB:

谷歌文件（Google Docs），13.5 MB：

Something simpler? Notion, 16 MB:

功能簡單點的？Notion，16 MB：

Social Networks#

社交網路#

The typical size of code that social networks need for like buttons to go brrr is 12 MB.

社交網路為了讓點贊量咻咻咻地漲起來，通常需要 12 MB 的程式碼。

Twitter, 11 MB:

Twitter (X)，11 MB：

Facebook, 12 MB:

Facebook，12 MB：

TikTok, 12.5 MB:

TikTok，12.5 MB：

Instagram is somehow bigger than Facebook, despite having like 10× less functions. 16 MB:

Instagram 不知怎麼的比 Facebook 還大，儘管功能少了大概 10 倍。16 MB：

LinkedIn. Is it a blog? A platform? It has search, it has messaging, it has social functions. Anyways, that’ll be 31 MB:

領英。它算部落格？還是平臺？它有搜尋，有訊息，還有社交功能。不管怎麼說，這是 31 MB：

By the way, I'd like to add you to my professional network on LinkedIn.

順便說一句，我想在領英上加您為好友來拓展我的人脈圈。

Elephants — its own category#

大象級應用——自成一檔#

Sometimes websites are so stupidly, absurdly large that they deserve their own category.

有些網站大到愚蠢、荒謬的程度，簡直應該單獨給它們分一類。

Here, Jira, a task management software. Almost 50 MB!

比如，Jira，一個任務管理軟體。差不多 50 MB！

Do they ship the entire Electron compiled WASM or what?

他們是把整個 Electron 編譯的 WASM 都給打包進來了，還是怎麼了？

But that’s not the limit! Slack adds 5 more MB, up to 55 MB:

但這還不是極限！Slack 又多了 5 MB，高達 55 MB：

Yes, it’s a chat. You know, list of users, messages, reactions. Stuff we did on raw HTML, even before JS was invented?

是的，它就是個聊天軟體。你想想，使用者列表、訊息、表情回應。這些玩意兒，我們以前用純 HTML 都能實現，甚至在 JavaScript 發明之前就可以！

That’s 55 MB in today’s world. It’s almost like they are trying to see how much more bullshit can they put in a browser before it breaks.

在今天這個時代要 55 MB。簡直就像是他們在想試試看到底能往瀏覽器裡塞多少垃圾程式碼才會讓它崩潰。

Finally, this blew my mind. Somehow react.dev starts with a modest 2 MB but as you scroll back and forth, it grows indefinitely. Just for fun, I got it to 100 MB (of JavaScript!), but you can go as far as you like:

最後，這個操作驚掉我的下巴。不知怎的 react.dev 網站一開始只有區區 2 MB，但當你來回滾動頁面時，它的大小會無限增長。純粹為了好玩，我把它搞到了 100 MB（的 JavaScript！），但你想搞多大就能搞多大：

What is going on there? Even if it unloads and downloads parts of that blog post, how is it growing so quickly? The text itself is probably only 50 KB (0.05 MB).

這到底是什麼鬼？就算它會解除安裝並重新載入博文的某些部分，它怎麼能增長得這麼快？文章本身的文字可能也就 50 KB（0.05 MB）。

UPD: It has been brought to my attention that this behavior is not, in fact, representative of normal user experience. Normally embedded code editors will be cached after first load and subsequent loads will be served from disk cache. So as you scroll, you will see no network traffic, but these 100 MB of JS will still be parsed, evaluated and initialized over and over as you scroll.

更新：有人提醒我，這種行為實際上並不代表典型的使用者體驗。通常情況下，嵌入式程式碼編輯器在首次載入後會被快取，後續載入會從磁碟快取中讀取。所以當你滾動時，你不會看到網路流量，但這 100MB 的 JS 仍然會在你滾動時一遍又一遍地被解析、求值和初始化。

How fast are we degrading?#

我們這是在以多快的速度開倒車？#

Look how cute! In 2015 average web page size was approaching shareware version of Doom 1 (2.5 MB):

瞧瞧這個，多可愛啊！2015 年的時候，平均網頁大小快趕上《毀滅戰士Ⅰ》共享版的大小了（2.5 MB）：

Source

Well, in 2024, Slack pulls up 55 MB, the size of the original Quake 1 with all the resources. But now it’s just in JavaScript alone.

好吧，到了 2024 年，Slack 一個應用就幹到了 55 MB，這都趕上初代《雷神之錘》完整版的大小了。但現在，這僅僅是 JavaScript 程式碼的大小。

For a chat app!

單就為一個聊天應用！

How big is 10 MB anyway?#

10 MB 到底有多大？#

To be honest, after typing all these numbers, 10 MB doesn’t even feel that big or special. Seems like shipping 10 MB of code is normal now.

講真，在敲了這麼多數字之後，10 MB 感覺已經不那麼大或者特別了。現在看來，動不動就上 10 MB 的程式碼體積，似乎是家常便飯了。

If we assume that the average code line is about 65 characters, that would mean we are shipping ~150,000 lines of code. With every website! Sometimes just to show static content!

如果我們假設平均每行程式碼大約 65 個字元，那就意味著我們給每個網站都塞了約 15 萬行程式碼。每個網站都這樣！有時僅僅是為了顯示一些靜態內容！

And that code is minified already. So it’s more like 300K+ LoC just for one website.

而且那些程式碼已經是壓縮過的了。所以一個網站實際的程式碼行數更可能超過 30 萬行。

But are modern websites really that complex? The poster child of SPAs, Google Maps, is quite modest by modern standards — is still just 4.5 MB:

但是，現代網站真的有那麼複雜嗎？作為單頁應用（SPA）的標杆，谷歌地圖按現在的標準來看算是相當剋制的了——仍然只有 4.5 MB：

Somebody at Google is seriously falling behind. Written with modern front-end technologies, it should be at least 20 MB.

谷歌的人可真是嚴重掉隊了。要是用現代前端技術來寫，它至少也得 20 MB 起步。

And if you, like me, thought that “Figma is a really complex front-end app, so it must have a huge javascript download size”, well, that’s correct, but then Gmail is about as complex as Figma, LinkedIn is 1.5× more complex and Slack is 2.5× more ¯\_(ツ)_/¯

如果你和我一樣，曾以為「Figma 是個非常複雜的前端應用，所以它的 JavaScript 下載體積肯定很大」，嗯，這想法沒錯。但照這麼說，Gmail 跟 Figma 差不多複雜，領英比它複雜 1.5 倍，Slack 則複雜 2.5 倍 ¯\_(ツ)_/¯

Conclusion#

結論#

It’s not just about download sizes. I welcome high-speed internet as much as the next guy. But code — JavaScript — is something that your browser has to parse, keep in memory, execute. It’s not free. And these people talk about performance and battery life...

這不僅僅是下載大小的問題。我和其他人一樣擁抱高速網際網路。但是程式碼——JavaScript——是你的瀏覽器必須解析、駐留記憶體、然後執行的東西。這些都不是零成本的。而那些傢伙們還在大談特談效能和電池續航……

Call me old-fashioned, but I firmly believe content should outweigh code size. If you are writing a blog post for 10K characters, you don’t need 1000× more JavaScript to render it.

你可以罵我老古董，但我堅信內容本身應該比程式碼體積重要得多。如果你寫的是一篇萬字博文，你並不需要用比內容多一千倍的 JavaScript 來渲染它。

This site is doing it right:

這個網站就做對了：

That’s 0.1 MB. And that’s enough!

這才 0.1 MB。這就夠了！

And yet, on the same internet, in the same timeline, Gitlab needs 13 MB of code, 500K+ LoC of JS, just to display a static landing page.

然而，在同一個網際網路上，在同一個時代背景下，Gitlab 僅僅為了顯示一個靜態著陸頁，就需要 13 MB 的程式碼，超過 50 萬行的 JS 程式碼。

Fuck me.

日了狗了。