ClipCrafter砍掉6條API路由，瀏覽器竟能扛起視頻渲染

去年此時，ClipCrafter的用戶點擊"導出"后，平均要盯著轉圈動畫看47秒。這47秒里，他們的視頻正在穿越三層服務器、兩套隊列系統，最后在一臺裝著Chromium的Docker容器里被Remotion慢慢嚼碎。

上周，這家公司把整個后端渲染棧刪干凈了。不是優化，是連根拔起——6條API路由、Inngest后臺任務、Deno運行時層，全部進回收站。替代方案是一個叫framewebworker的庫，大小不到100KB，跑在用戶的瀏覽器標簽頁里。

從"服務器嚼碎"到"瀏覽器現炒"，這場遷移的代碼變更記錄在第214號PR里，是ClipCrafter本季度最大的一次提交。

被刪除的，不只是一堆代碼

舊架構像一條精心設計的流水線：用戶上傳片段→觸發Inngest任務→排隊等待→服務器渲染→輪詢狀態→最終下載。ClipCrafter團隊為此維護了狀態追蹤、失敗重試、進度輪詢整整三類服務器狀態。

新架構只有一個React鉤子：useClientStitch。視頻片段、字幕疊加層、時間軸數據，直接送進瀏覽器的Web Worker。主線程保持響應，渲染在后臺線程里跑，做完直接吐成MP4。

代碼對比很能說明問題。之前調用渲染要POST到/api/render，然后進入"輪詢地獄"——每隔幾秒問一次服務器"好了嗎"。現在await render(segments)直接返回，onProgress回調實時更新UI。

「我們刪除了一整個服務器狀態類別，」ClipCrafter工程師在PR描述里寫道，「不用再跟蹤渲染任務、不用再輪詢完成狀態、不用處理后端渲染失敗。」

進度條終于說人話了

服務器渲染時代，ClipCrafter能給用戶的最好反饋是"處理中..."，附帶一個每秒跳動幾下的百分比數字。這個數字不是算出來的，是猜的——根據歷史平均耗時，線性插值到一個假進度條上。

瀏覽器本地渲染改變了游戲規則。第216號PR引入了RenderStatusPanel：每個片段有自己的轉圈/對勾圖標，總進度條帶基于已耗時間的ETA計算，RichProgress數據暴露到每一幀的粒度。

用戶從看一個"假裝在動"的動畫，變成看一份"正在發生什么、還剩多久"的實時報告。這個變化聽起來很小，但對視頻編輯這種動輒幾十秒等待的場景，焦慮感是指數級下降的。

遷移是漸進式，不是大爆炸

第214號PR只是起點。接下來的217號PR把framewebworker升到v0.1.1，接入了真實的RichProgress類型，刪掉了本地模擬進度的 hack 代碼。218號PR更進一步，從stitch() API遷移到新的render()函數——后者只加載一次視頻，而不是每個片段重新加載。

這個優化引入了buildVideoSegments()函數，負責把ClipCrafter的剪輯映射到framewebworker的段格式。映射邏輯本身不復雜，但暴露了客戶端渲染的一個真實約束：瀏覽器內存。

服務器渲染時，ClipCrafter可以假設有16GB內存和無限硬盤臨時空間。瀏覽器里，每個視頻幀都是ImageBitmap對象，大項目可能吃掉幾百MB。團隊在第218號PR里加了分段渲染策略，長視頻切成多塊處理，做完一塊釋放一塊。

「我們以為Web Worker是瓶頸，結果發現是主線程的GC（垃圾回收），」一位工程師在內部復盤時提到，「ImageBitmap不手動close，Chrome會憋到內存壓力閾值才動手，那時候UI已經卡了。」

省下的不只是服務器錢

成本賬很直觀。之前每臺渲染服務器月費幾百美元，隨著用戶增長還要水平擴容?，F在這些預算可以砍掉，或者轉投到真正需要服務器的地方——比如AI字幕生成這種確實算不動的東西。

但更隱蔽的收益是開發速度。服務器渲染的調試是一場噩夢：本地復現需要搭完整環境，生產問題要看分布式日志，一個渲染失敗可能涉及四個服務的接力排查?？蛻舳虽秩镜腷ug，打開Chrome DevTools就能單步跟進去。

ClipCrafter團隊現在可以大膽做實時預覽功能——以前想都不敢想，因為每次預覽都要觸發服務器渲染。現在用戶在時間軸上拖動滑塊，Web Worker里同步生成低分辨率預覽幀，延遲控制在100毫秒內。

不是萬能藥，但邊界在移動

framewebworker有自己的天花板。4K渲染、復雜調色、多軌道合成，這些場景瀏覽器 still 吃力。ClipCrafter的定位是"社交短視頻剪輯"，單軌、1080p、字幕+貼紙的組合，剛好卡在瀏覽器舒適區內。

「我們不是在證明服務器渲染已死，」ClipCrafter的工程師在HN評論里補充，「是在標記一條移動的邊界線。三年前這個方案不可行，現在可以了，三年后可能4K也能本地跑?！?/p>

這條邊界線的移動速度，比大多數人預期的快。WebCodecs API的普及、WebGPU的逐步落地、SharedArrayBuffer的廣泛支持，都在把"瀏覽器能做什么"的圍欄往外推。

ClipCrafter的第219號PR已經在實驗WebGPU加速的濾鏡管線。如果跑通，原本需要服務器GPU的實時特效，也能搬進用戶筆記本的集成顯卡里。

當瀏覽器能做的事情越來越多，"先傳服務器"的默認假設是不是該重新檢討了？