線上 JSON 編輯器處理 20MB Base64 效能評測：為何會卡頓？

API 回應包含 20MB Base64 字串時，瀏覽器編輯器可能需要大量時間進行解析、高亮與排版。影響取決於編輯器、瀏覽器、裝置與測試資料，因此本文只比較三款具體工具。

這到底是怎麼回事？是硬體效能不足，還是瀏覽器在處理超長文字時有根本性的缺陷？我們決定用一台高規格開發機來做一次橫向評測，找出目前主流格式化工具在高壓下崩潰的確切原因，並提出解決方案。

20MB 基準測試：主流線上 JSON 編輯器橫向評測

為了排除硬體效能不足的干擾，我們直接在一台旗艦級開發機上進行測試：

• CPU: Intel Core i7-14700F
• 記憶體: 32GB RAM

我們撰寫了一支 Playwright 腳本，模擬將 1MB 到 20MB 的 JSON 資料貼入幾款主流格式化工具中。您可以從 GitHub Gist 取得該腳本來自行重現或修改測試。以下是實測結果，重點關注載入（Load）耗時（括號內為格式化與壓縮耗時）：

下載原始 CSV。測試腳本記錄了操作耗時與失敗資訊，但沒有記錄作業系統、Chromium、Playwright、網路條件及受測網站版本。結果應視為有日期的測試快照，而不是長期排名。

為什麼線上 JSON 編輯器面對超大 Base64 字串會卡死？

這種巨大的效能落差凸顯了傳統 Web 應用在處理語法高亮時的嚴重限制。當線上 JSON 編輯器在大型 Base64 資料上嚴重卡頓時，本質上是碰到了以下兩個主要瓶頸：

1. 單執行緒 CPU 瓶頸

許多編輯器操作仍在主執行緒執行，因此大型文件的解析或分詞可能拖慢互動。Worker 可以轉移部分工作，但不同編輯器實作不同，CPU 使用情況需要實測。

2. 超長單行文字的渲染瓶頸

在解析大型檔案時，語法高亮工具會將整段 Base64 字串包進一個 <span class="string"> 節點中。真正的瓶頸在於：這個節點包含了約 2,700 萬個字元，而且全部擠在同一行上、沒有任何換行符號。編輯器的核心引擎必須為這行「超級單行」逐字元量測寬度、計算可能的換行位置以及游標定位。對於如此巨大的連續字串，這些排版計算會導致災難性的記憶體暴增，直接鎖死瀏覽器的主執行緒（Main Thread）。

ViewJSON 的解法：媒體替換與無損剪貼簿

傳統編輯器卡死的根本原因，在於它們試圖把數千萬個字元硬生生渲染出來。但我們發現了一個核心事實：開發者在貼上 20MB 的 Base64 亂碼時，壓根不打算閱讀這段程式碼，而是想看它背後的實際圖片或媒體檔案。基於這個洞察，ViewJSON 放棄了硬撐瀏覽器的物理渲染極限，改從產品體驗層面進行底層架構設計：

• 媒體替換（而非單純截斷）: 當 ViewJSON 偵測到 Base64 字串時，會解碼魔術位元組（Magic Bytes），並直接用真實的行內媒體預覽（如圖片）取代那段無法閱讀的程式碼區塊。若使用者關閉預覽模式，也會對超長字串進行智慧截斷。無論哪種模式，都阻止了數以百萬計的字元進入編輯器的文字緩衝區，徹底釋放核心引擎與渲染執行緒的運算負擔。
• 無損剪貼簿復原: 隱藏原始文字通常會帶來一個致命問題：複製 JSON 時拿到的是殘缺資料。ViewJSON 透過自訂剪貼簿管理器解決了這個問題。無論畫面上顯示的是圖片預覽還是截斷後的文字，只要按下「複製」，編輯器就會在背景自動還原完整的原始 Base64 資料，確保複製出來的內容 100% 完好無損。

在這套測試設定下，ViewJSON 載入 20MB 情境約需 1.6 秒。更換資料、瀏覽器或裝置後，結果可能不同。