周三下午，我打開Vercel的部署日志，盯著上面的Core Web Vitals評分發呆。一個內容還不錯的項目，LCP（最大內容繪制）卻一直在2.8秒徘徊，移動端CLS（累計布局偏移）更是飆到了0.25。對于靠搜索流量吃飯的站點，這點差距就是用戶直接關掉頁簽和讀完文章的區別。更要命的是，Google明確把Core Web Vitals當作排名信號，而用戶不等頁面畫完就已經離開了。那之后，我花了兩個下午，把一份自己反復使用的性能清單在Next.js構建流程里又從頭到尾跑了一遍。效果立竿見影——不是靠換一個更快的服務器，也不是刪掉什么神奇的功能，就是一串有點無聊但每次都有效的工程習慣。

　　下面就是這份清單里真正起作用的部分，按回報最高的順序排列。每一點都不新奇，但合在一起，就能把“看起來挺快”變成“刷一下就出來”。

　　第一步：給客戶端少送點JavaScript
React站點變慢，絕大多數時候不是因為React本身渲染慢，而是因為客戶端被灌進了太多根本沒用上的代碼。一個簡單的數據展示頁面，整整400KB的JavaScript，從第三方包到很久沒點開的模態框邏輯，全都一口氣塞給瀏覽器。用戶打開頁面只是想看幾行文字，卻要先下載、解析、執行一個龐大的SaaS后臺。

　　我的第一刀總是切在“是不是真的需要客戶端組件”上。在Next.js App Router里，默認所有組件都是Server Component，只有真正用到狀態、事件或者瀏覽器API的部分，才值得加上'use client'標記。而且這個標記要盡量往下推，別圖省事在頁面頂層就打上客戶端標簽，只因為底部有一個需要交互的按鈕。讓客戶端真正負責的，就是那一個按鈕自己，而不是整棵組件樹。

　　對于那些體積大、首屏又看不見的東西——圖表、重型編輯器、3D場景、點擊后才彈出的對話框——next/dynamic是最直接的解藥。我通常這么寫：

　　const GalaxyScene = dynamic(() => import('@/components/GalaxyScene').then((m) => m.GalaxyScene),{ ssr: false, loading: () => null },

　　這串代碼把GalaxyScene的加載完全推遲到它真正需要渲染的時候，同時不觸發服務端渲染，loading狀態干脆什么都不顯示，用戶根本沒機會注意到這個組件是后來才加載出來的。削減JavaScript不是在功能上讓步，而是把有限的網絡和CPU預算用在用戶第一眼看到的東西上。第一眼沒看到的東西，完全可以排在后面。

　　第二步：別讓布局突然跳起來
CLS是Core Web Vitals里最容易破壞用戶感受的指標，也是最好修復的。頁面剛出來，用戶正要點擊一個按鈕，廣告加載了，或者一張圖片突然撐開了容器，手指就點到了別的地方。這種體驗比加載慢還要讓人煩躁，因為它打斷了已經開始的閱讀或操作。

　　解決CLS的核心思路很直白：為所有還沒出現的內容提前預留好空間。圖片是最常見的“罪魁禍首”。next/image組件只要給它顯式的width和height，瀏覽器就能在渲染之前算出圖片會占據多少空間，不會等圖片下載完才重新排版。如果想讓它填滿某個容器，就用fill屬性搭配一個明確尺寸的父容器，同樣能達到預留空間的效果。

　　對于廣告、嵌入內容、橫幅等按需加載的模塊，哪怕后端接口返回得再快，也要提前在占位元素上設置好寬高，或者至少給一個合理的min-height。字體加載也會引起類似的問題，本地回退字體和網絡字體字寬不同，文本就會在切換瞬間抖動一下。用next/font加載字體，并且把display設置為swap，可以在保證文字立即可見的同時，減少字體交換帶來的重排。比如：

　　import { Inter } from 'next/font/google';const inter = Inter({ subsets: ['latin'], display: 'swap' });

　　這樣一來，文字不會因為網絡字體遲遲不到而空白一片，也不會因為字體度量差異而讓整段文字突然移動。布局穩定之后，用戶看到的頁面更像一個印刷好的稿子，而不是還在搭建中的腳手架。

　　第三步：把圖片當成頁面上最重的資源來對待
在很多站點上，圖片占整個頁面體積的60%以上。我們經常無意識地讓一張4000像素寬的照片塞在一個400像素的卡片槽里，浪費的字節比整個頁面文字還多出十倍。Next.js內置的next/image組件幾乎把圖片優化該做的事都打包好了：自動生成AVIF和WebP格式，根據屏幕實際顯示尺寸提供合適的源文件，默認開啟懶加載，只要不用到第一屏關鍵圖片，它就乖乖地等。

　　首屏的主視覺圖是個例外。如果這張圖恰好在用戶第一眼看到的地方，懶加載反而會拖慢它出現的時間。這時候一定要加上priority標記，告訴Next.js這張圖片需要提前加載，不應該被延遲。其余的圖片，包括列表里成排的頭像、文章配圖、圖庫內容，全都交給默認的懶加載就好。還有一個容易被忽略的細節：始終確保提供的圖片尺寸跟它在頁面上實際渲染的尺寸接近。這并不需要手動一個個去裁圖，next/image的尺寸控制結合CDN的圖像處理能力，就能在請求時自動裁出接近顯示區域的大小，從根本上杜絕浪費。

　　這些做法堆在一起，能直接讓圖片帶來的帶寬消耗降到原來的幾分之一，同時肉眼幾乎看不出畫質差異。尤其在移動網絡下，這種削減就是頁面從等三秒鐘到秒開之間的差距。

　　第四步：盡可能在服務端渲染完，并把結果緩存起來
Next.js給了我們幾種渲染策略，對于不依賴實時用戶數據的內容，靜態生成或增量靜態再生成是最直接有效的選擇。一個預渲染好的頁面，從CDN邊緣節點直接推給瀏覽器，幾乎不需要服務端計算時間，首字節時間能做到幾十毫秒。與每次請求都現場拼組件、拉數據、渲染HTML相比，這個差距不是一點半點。

　　如果一定要在服務端取數據，也別在每個請求上都重新抓一遍。Next.js擴展的fetch API支持緩存和重新驗證策略。比如可以設置revalidate，讓同一個請求在指定時間內復用已緩存的結果，而不是重復調取遠端API。這在不影響內容新鮮度的前提下，能極大減少數據層的壓力，也讓后續請求的響應時間幾乎變成常量。

　　第三方腳本也是個常見的性能陷阱。分析工具、在線客服、視頻嵌入，這類腳本的加載方式如果不加限制，會霸道地搶占主線程，把頁面的可交互時間硬生生往后推。next/script組件的strategy="lazyOnload"可以輕松解決這個問題。把這些不緊急的腳本推遲到頁面上所有關鍵元素都加載完畢之后才運行，主線程就不會在早期被它們堵塞。用戶仍然可以在頁面完全可交互之后繼續正常使用那些工具，但首頁加載時的體感已經不再是他們埋單。

　　第五步：在真正用戶的設備上測量，別被自己的開發機騙了
光纖直連、i7處理器、32GB內存的開發機器上跑Lighthouse，分數漂亮得不像話，但這跟真實用戶隔著層層移動信號看到的東西完全是兩個世界。我強制自己養成一個習慣：只在模擬慢速移動設備的Lighthouse模式里看分數，而且更多是參考Search Console里基于真實用戶的CrUX數據。Google的排名看的是真實用戶數據，不是自己本地跑出來的實驗室數據。

　　還有一個讓團隊持續受益的做法是設定一個性能預算，比如首次加載JavaScript總量不超過150KB。把這個限制加到CI流程里，一旦某個PR讓它超標，構建直接報錯。這種硬約束把速度退化擋在合并代碼之前，也讓所有人從最開始就意識到自己引入的每一個依賴都在預算里記賬。看起來嚴格，實際效果卻像是自動剎車，把緩慢降級扼殺在搖籃里。

　　到這里會發現，這些動作沒有一個是需要額外學習什么革命性技術。server組件、動態導入、圖片優化、緩存策略、預算監控，都是Next.js生態里已經準備好的工具。真正能帶來差異的，是執行這些“無聊的事”的連貫性。一個頁面走完這五步，可能看不出任何花哨的地方，但那種一觸即達的加載感，會用評論區更長的停留時間、更低的跳出率，以及逐漸上漲的自然搜索流量，默默兌現回報。

　　對我自己來說，這份清單已經變成了每次做Next.js項目時的默認配置——不是等到性能報警了再沖去救火，而是從一開始就把速度寫進構建流水線里。后來看到別人在同樣的問題上反復踩坑，我才把這些步驟總結成可復用的檢查項。如果你也在琢磨自己的Next.js項目為什么沒有想象中那么快，可以先別急著研究什么黑科技，把這幾步老老實實走一遍，也許答案就已經出來了。