升級Next.js 15后還卡？我實操兩步，修好了水合滯后和布局偏移

有個團隊做了件聽起來挺正確的事——把整個應用棧升到 Next.js 15 和 React 19，順手打開 React 編譯器，然后等著看 Lighthouse 分數自己起飛。結果呢？手機端最大內容繪制（LCP）還是卡在 3 秒以上，用戶點一下篩選按鈕，交互延遲（INP）就往上躥，頁面水合階段拖泥帶水的感覺一點兒沒變。他們的技術棧確實變新了，但用戶感受到的速度一點兒沒變快。

這個畫面熟悉嗎？我在好幾個生產環境里反復撞見同一種模式：把框架版本號往上挪，并不等于把運行時的瓶頸自動清零。水合依舊搶主線程，客戶端組件照樣要跑一堆 JavaScript，那些肉眼可見的布局跳動照樣拖累核心網頁指標。這些坑，靠一次升級根本填不平。

那怎么辦？先別看總分，得鉆進具體指標里把真正的罪犯揪出來。我養成的一個習慣是，不完全信任 Lighthouse 給出來的結論——它的分數看起來還行的時候，真實用戶的感受很可能完全是另一回事。所以，我的排查起點永遠是四樣東西：Chrome Performance Panel（性能面板）、React Profiler（組件性能分析器）、Layout Shift Overlay（布局偏移疊加層）和實打實的 Web Vitals 埋點數據。靠這些，連那些只閃一下的紫色偏移區域，都能給你標得明明白白。

順著這個思路，我鎖定了拖慢整個應用的元兇之一：水合剛開始那一瞬間，頁面上最大內容元素的占位符被真實圖表完全頂開，導致整個卡片往下猛跳，累積布局偏移（CLS）嗖一下就被拉高，連帶著 LCP 的時間也被頂得往后拖。打開 Chrome DevTools 里的 Performance 錄制，勾上 Experience 下面的 Layout Shift Regions，幾乎不用費力，那一閃而過的紫色疊加層就直接把圖表容器指出來了。

根因其實是服務器渲染時只丟出了一個空的占位區域，客戶端一掛載真實圖表庫，尺寸立刻變化，容器高度跟著被撐大，下方所有元素都得為它讓路。修起來并不復雜：在真實內容到來之前，給容器預留出足夠空間，并且讓這塊空間在客戶端水合前后保持固定尺寸。我把頁面里的儀表盤區塊改成了服務器組件，先在后端把統計數據拿到手，再用 min-h-[280px] 這種固定高度的容器把它包裹起來，同時給容器加上圓角、邊框和內邊距，讓視覺形態一開始就很穩定。圖表數據通過可序列化的屬性往下傳遞，圖表庫本身則用動態導入按需加載，絕不會在一開始就阻塞主線程。這樣服務器產出的 HTML 里就已經有了完整高度的容器，客戶端水合時哪怕圖表還沒渲染完，容器占位也不會再變了。

另一個吃響應速度的地方，是交互延遲 INP 突然飆高。INP 衡量的是用戶操作之后，頁面到底隔了多久才給出反饋。在一個典型 App Router 頁面里，開發者常常把篩選欄、數據表格和分頁組件一股腦塞進同一個龐大的客戶端組件里。用戶點一下篩選，水合還沒結束，React 只能先擱在那兒排隊等著，INP 自然就竄上去了。這個問題本質上是主線程被一個巨大水合任務堵死了，所有交互都得等它跑完才能執行。

解決的思路很直接：別讓一棵巨型客戶端組件樹同時水合。我把原來的單文件拆成了三個獨立的組件 FilterBar、DataTable 和 Page，各自負責一小塊交互。FilterBar 先水合，讓用戶能以最快速度開始篩選操作；DataTable 利用 App Router 的流式傳輸稍后抵達，不會跟篩選交互爭搶主線程；Page 作為整體布局把各部分串聯，但本身幾乎不含需要水合的邏輯。與此同時，我把篩選的狀態從組件內部移到了 URL 的 search params 里，讓服務端直接根據查詢參數渲染過濾后的結果，用戶刷新或分享鏈接也不會丟狀態。那些不急于執行的統計上報，就用空閑回調 defer 出去，不再跟初始水合擠在一起。

到這里，重點已經不在框架本身，而在架構上的兩個輕量調整。一個是讓容器在渲染過程中始終保持穩定的形態，另一個是讓水合任務從一整塊大石頭變成可以分步執行的小顆粒。這兩步改完，頁面在移動端的真實表現已經不是升級之前能比的了。當然，我沒有跑出一組“提升 42%”之類的精確基準數據，因為在多份生產環境里，瓶頸權重不同，最終收益因人而異。但可以確定的是，升級框架這動作，只能算是遞給你一套新工具，用這些工具把組件樹和水合邊界重新打理好，才是讓應用真正變快的唯一路徑。如果你的 Next.js 15 項目也正卡在“構建成功”和“用起來很快”之間，不妨試試從布局偏移疊加層和客戶端組件拆分這兩個角度查一遍，主線程會感謝你。