北京
一支團隊滿懷期待地把項目升級到 Next.js 15 和 React 19，并開啟了 React 編譯器。他們以為 Lighthouse 評分會像施了魔法一樣自動躥升。
事實狠狠澆了盆冷水。移動端的最大內容繪制（LCP）仍舊懸在 3 秒以上，每當用戶操作篩選器，交互到下次繪制（INP）就急劇飆升，整個頁面的水合（hydration）過程依然黏滯到令人發慌。技術棧是最新的，性能表現卻原地踏步。
在排查了多個生產環境應用后，我發現這種模式反復出現：僅僅升級框架并不會讓那些運行時的瓶頸自行消失。主線程照樣要跑水合，客戶端組件照樣要執行 JavaScript，頁面布局抖動照樣在侵蝕核心網頁指標。下面就是我為這類問題診斷和修復的真實過程。
很多研發者有一種慣性思維，覺得只要換成最新版技術棧，性能問題就會迎刃而解。Next.js 15 和 React 19 固然帶來了令人興奮的改進，但它們無法憑空變走這些常客——水合期間發生的布局偏移、過多的客戶端 JavaScript、龐大的客戶端組件樹、不必要的重渲染，以及被推遲的事件處理器。
構建成功與應用“感覺很快”之間的距離，恰好是所有性能難題棲身的地帶。我的第一步不是跑 Lighthouse，而是同時打開 Chrome 性能面板、React Profiler、布局偏移疊加層以及網頁核心指標監控，因為 Lighthouse 表面尚可的分數并不代表真實用戶的感受。
第一項修復：斬斷水合期的布局抖動
排查時發現，充當最大內容繪制元素的儀表板圖表就是罪魁禍首。服務器渲染時先吐出一個占位容器，等客戶端圖表組件掛載完成就重新調整尺寸，瞬間把整個布局擠得七零八落。累積布局偏移（CLS）于是升高，LCP 也被嚴重拖慢。
在 Chrome 開發者工具的性能面板中點擊錄制，并開啟“體驗”分組下的布局偏移區域，那些紫色疊層可以毫不留情地把作亂元素標出來。隨即我就開始動手，思路很簡單：在水合開始之前就鎖定空間。
針對頁面文件，改成在服務端獲取圖表數據，只傳遞可序列化的屬性，并用固定高度的容器包裹住圖表插槽。示例結構大致是這樣：
export default async function DashboardPage() {const stats = await getDashboardStats();return ({stats.title}}接著再為圖表組件設置懶加載，并始終維持容器尺寸不變。這一套組合拳下來，原本由圖表掛載引發的視覺跳動基本被根除，測試環境里的布局偏移區域不再頻繁高亮。
第二項修復：打破 React 19 的水合滯后與交互延遲
INP 衡量的是用戶交互后頁面給出反饋的迅捷程度。在應用路由（App Router）場景里，一個常見現象是：用戶點擊篩選器時水合尚未結束，React 被迫推遲處理交互，INP 隨之沖高。根源在于，過濾器、表格、分頁全部擠在一個龐大的客戶端組件內部，只有把整棵組件樹都水合完，交互才能恢復靈敏。
面對這種巨型客戶端組件，我把水合邊界拆分開來。原先的結構是“use client”標識下同時塞進了過濾器、表格和分頁邏輯；改造后，FilterBar 和 DataTable 被剝離為獨立組件，頁面文件只負責編排它們的順序，確保優先水合過濾器部分，表格可以稍后流式傳入。
為了讓交互狀態更輕，我還把參數移入 URL 搜索參數，篩選后的結果重新交回服務端渲染，同時利用空閑回調來推遲分析腳本的加載。這樣一來，水合任務的粒度變細，用戶的點擊不再被一個臃腫的組件樹堵在隊列里。改造完成后，篩選器的響應速度明顯提升，交互延遲指標也從之前的尖峰區域回落到可接受范圍。
整個診斷過程反復印證了一點：新一代框架提供的是更好的基座，但把基座變成真正順滑的體驗，仍然需要主動去修剪客戶端的包袱。只要水合還在主線程運行、客戶端組件還在執行重量級邏輯，桌面和移動端的核心網頁指標就依然有被拖垮的風險。與其盼著一次升級解決所有煩惱，不如摸準性能面板里那些紫色疊層和高亮水合區塊，再一點點把它們削平。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
