Next.js应用变慢的8个原因及解决办法
作者：周尛先森
引言
Next.js 应用变慢的情况比你想象的更常见。过长的加载时间会让用户感到沮丧，降低参与度。但大多数性能问题都可以归结为几个常见原因 —— 从繁重的数据获取、路由延迟到过大的包体积、缓存错误和未优化的图像。
在本文中，我将指出 Next.js 应用中 8 个常见的性能问题，并分享清晰、实用的解决办法，帮助你打造更快、更流畅的用户体验，让用户切实感受到差异。
我假设你已经基本掌握 React 组件、useState 和 useEffect 等钩子，以及 Next.js 路由和数据获取的基础知识。你还应该熟悉使用浏览器开发者工具和在命令行中运行构建命令。如果这些听起来不熟悉，你可能需要先复习一下，不过我会尽量把解释写得简单明了。
快速说明一下 —— 我会在示例中使用 getServerSideProps，因为许多现有项目仍然依赖 Pages Router，而且性能问题并非 Next.js 特定版本所独有。即使语法略有变化，这些优化原则同样适用于使用较新的 App Router 的情况。我们的目标是专注于最重要的解决办法，无论你的项目配置如何。
1. 感知性能不足
我们来谈谈感知性能 —— 即应用给用户的感觉有多快，而不仅仅是它实际有多快。Jakob Nielsen 在他 1993 年的《可用性工程》一书中，为用户耐心设定了一些经典基准：
- 0.1 秒 —— 系统感觉 “即时响应” 的极限。在此范围内，用户不会察觉到延迟。
- 1.0 秒 —— 保持用户思维流畅的上限，尽管他们会注意到延迟。
- 10 秒 —— 用户完全失去注意力之前的最长时间。
如果你的 Next.js 应用显示内容的时间超过 1 秒，对用户来说它就正式 “变慢” 了，即使数据实际上正在后台加载。而等待 10 秒？那几乎是数字时代的永恒，足以让用户彻底失去兴趣。
但这里有个关键点：你的应用真的慢吗？还是只是 “感觉” 慢？
Reddit 上有个讨论：“为什么大多数 Next.js 应用都这么慢？”
用户说：“每次我访问一个网站，点击链接要等 2 秒，我就会想‘这肯定是个 Next 应用’，查看代码后发现确实如此。我猜是服务器组件在等待数据获取，但初始加载真的很慢（之后就好了）。我见过一些优化得很好的 Next 应用，初始加载很快，但 90% 我遇到的都有加载慢的问题。是新手开发者的问题还是框架本身的问题？”
这就是感知性能不足的体现。有时候，无论数据获取需要多长时间，你处理等待的方式都会产生巨大差异。
解决办法：使用加载状态和 React Suspense
关键在于立即向用户展示一些内容 —— 即使不是最终内容。设计良好的加载状态可以让 2 秒的等待感觉比盯着空白屏幕 1 秒更快。
React Suspense 让在 Next.js 中实现这一点变得容易。你可以这样包裹组件，在内容加载时显示占位符：
import { Suspense } from 'react';
export default function Dashboard () {
return (
<div>
<h1>Dashboard</h1>
<Suspense fallback={<DashboardSkeleton />}>
<DashboardContent />
</Suspense>
<Suspense fallback={<ChartSkeleton />}>
<AnalyticsChart />
</Suspense>
</div>
);
}
当用户重新加载页面时，他们会立即看到占位符，让他们知道系统正在处理：
（ Dashboard 重新加载演示：Next.js Suspense + 骨架屏加载演示）
（展示内容：John Doe 的仪表盘，包含用户信息、总用户数、收入、最近活动等，加载时显示骨架屏）
2. Next.js 混合渲染拖慢速度
说完了感知性能，我们来看看一些实际的性能问题。如你所知，Next.js 不仅是关于服务器端渲染 —— 也不纯粹是单页应用。它是一个混合框架，兼顾两者的优点。但有时，也会带来两者的缺点。
这种混合模式很强大。它让你的应用可以为 SEO 和快速初始加载提供完全渲染的页面，然后切换到 SPA 行为以实现流畅的客户端导航。但这也意味着你要同时处理两种不同的性能特征 —— 这正是问题可能出现的地方。
理解两种模式
首次加载时，你的 Next.js 应用表现得像传统的服务器渲染网站。它在服务器上获取数据，渲染完整的 HTML，然后发送到浏览器。这对 SEO 和快速显示有意义的内容非常有利：
// 首次访问：服务器承担所有繁重工作
export async function getServerSideProps() {
// 这在服务器上运行，会阻塞响应
const userData = await fetchUser();
const dashboardData = await fetchDashboard(userData.id);
const notifications = await fetchNotifications(userData.id);
return {
props: {
userData,
dashboardData,
notifications
}
};
}
但一旦初始页面加载完成，React 接管后，Next.js 就会切换到 SPA 模式。点击操作会触发客户端导航，无需整页重新加载 —— 就像 React Router 一样：
// 后续导航：纯 SPA 行为
function Dashboard({ userData }) {
const router = useRouter();
const goToProfile = () => {
// 不访问服务器——纯客户端导航
router.push('/profile');
};
return (
<div>
<h1>Welcome, {userData.name}</h1>
<button onClick={goToProfile}>View Profile</button>
</div>
);
}
性能问题出现的地方
棘手之处在于，你实际上在运行两个应用：
- 处理初始请求的服务器渲染应用
- 处理导航和交互的客户端 SPA
每个都有自己的性能特征，如果没有适当优化，每个都可能拖慢整个应用：
- 在服务器上，缓慢的数据库查询或阻塞操作会延迟 HTML 响应
- 在客户端，过大的 JavaScript 包或低效的 API 调用会阻碍流畅的导航
更糟的是，这些问题会相互叠加。假设用户访问你的主页（服务器渲染），然后点击进入仪表盘（客户端）。这个仪表盘需要一个 2MB 的 JavaScript 包 —— 而且还没有缓存。那么用户就必须等待包加载和客户端数据获取：
// 性能陷阱：繁重的客户端页面
import HeavyChart from './HeavyChart'; // 500KB
import ComplexTable from './ComplexTable'; // 300KB
import RichEditor from './RichEditor'; // 400KB
export default function Dashboard () {
const [data, setData] = useState(null);
useEffect(() => {
// 导航后在客户端获取数据
fetchDashboardData().then(setData);
}, []);
// 用户需要等待包加载 + 数据加载
if (!data) return <div>Loading...</div>;
return (
<div>
<HeavyChart data={data.charts} />
<ComplexTable data={data.tables} />
<RichEditor content={data.content} />
</div>
);
}
解决办法：同时优化两种模式
当服务器和客户端都经过优化时，你就能获得两者的最佳效果 —— 快速的初始加载、良好的 SEO，以及流畅的、类应用的导航。但如果忽视任何一方，整个体验都会变得迟缓。
现在我们已经了解了混合渲染如何引入隐藏的性能成本，接下来让我们聚焦服务器端一个最大的罪魁祸首 —— 缓慢的、顺序的数据获取。
3. 数据获取过慢且按顺序执行
你点击应用中的某个东西，然后…… 什么都没有。没有反馈，没有内容。十有八九，问题在于同步数据获取。这是指应用 “礼貌地” 一次加载一条数据。以下是典型 Next.js 配置中的情况：
// 慢方法——每个请求都要等前一个完成
export async function getServerSideProps({ req }) {
// 步骤 1：获取用户（300ms）
const user = await fetchUser(req.session.userId);
// 步骤 2：等用户数据，再获取个人资料（400ms）
const profile = await fetchUserProfile(user.id);
// 步骤 3：等个人资料，再获取仪表盘数据（600ms）
const dashboardData = await fetchDashboardData(user.id, profile.preferences);
// 步骤 4：等仪表盘数据，再获取通知（200ms）
const notifications = await fetchNotifications(user.id);
// 总时间：300 + 400 + 600 + 200 = 1500ms（1.5 秒！）
return {
props: {
user,
profile,
dashboardData,
notifications
}
};
}
这种方法把本可以 4800ms 的页面加载变成了 1.5 秒的加载。每个 await 都在说 ——“暂停所有操作 —— 在这个完成之前我们不继续。” 但这些请求真的需要一个接一个地进行吗？
解决办法：使用 Promise.all ()
如果你的请求彼此不依赖，就没有理由不能同时运行。这就是 Promise.all () 的用武之地：
export async function getServerSideProps({ req }) {
// 步骤 1：先获取用户（仍然是其他请求所需要的）
const user = await fetchUser(req.session.userId);
// 步骤 2：并行获取其他所有数据
const [profile, dashboardData, notifications] = await Promise.all([
fetchUserProfile(user.id), // 400ms
fetchDashboardData(user.id), // 600ms
fetchNotifications(user.id) // 200ms
]);
// 总时间：300ms（用户） + 600ms（最长的并行请求） = 900ms
// 我们节省了 600ms！
return {
props: {
user,
profile,
dashboardData,
notifications
}
};
}
这个简单的改变就减少了 600ms—— 而且这只是一次页面加载。
额外解决办法：全局数据的并行获取
你可以更进一步。如果某些数据不依赖于用户，比如系统范围的设置或服务器状态，你可以在获取用户数据的同时获取这些数据：
export async function getServerSideProps({ req }) {
// 并行获取与用户无关的数据和用户数据
const [user, globalSettings, systemStatus] = await Promise.all([
fetchUser(req.session.userId),
fetchGlobalSettings(), // 不需要用户数据
fetchSystemStatus() // 不需要用户数据
]);
// 现在并行获取依赖于用户的数据
const [profile, dashboardData, notifications] = await Promise.all([
fetchUserProfile(user.id),
fetchDashboardData(user.id),
fetchNotifications(user.id)
]);
return {
props: {
user,
profile,
dashboardData,
notifications,
globalSettings,
systemStatus
}
};
}
通过更智能的并行化，你可以减少加载时间，提高响应速度 —— 不需要复杂的工具或库。只需要更好地使用 JavaScript。
即使数据获取更快，你的应用可能仍然感觉不流畅。为什么？因为你的路由行为可能在进行不必要的完整服务器往返。让我们接下来看看这个问题。
4. 路由触发不必要的服务器往返
使用 Next.js App Router 时，每次导航都可能触发服务器端渲染 —— 即使是本可以（也应该）在客户端处理的路由。这不仅低效，而且肯定会让快速的应用感觉变慢。
假设你有一个用户在浏览产品目录。在传统的 SPA 中，在产品页面之间点击应该是即时的。JavaScript 处理状态更新，URL 变化而无需重新加载页面。
但如果 Next.js App Router 配置不当，每次点击都可能往返服务器。情况如下：
// app/products/[id]/page.js
// 每次访问产品页面时，这都会在服务器上运行
export default async function ProductPage({ params }) {
// 每次导航都向服务器发起网络请求
const product = await fetchProduct(params.id);
const reviews = await fetchReviews(params.id);
const recommendations = await fetchRecommendations(params.id);
return (
<div>
<ProductDetails product={product} />
<ReviewsList reviews={reviews} />
<RecommendationGrid recommendations={recommendations} />
</div>
);
}
在这种设置下，每次点击都要经过同样缓慢的流程：
- 点击产品链接
- 浏览器向服务器发出请求
- 服务器获取产品数据（数据库调用）
- 服务器渲染 HTML
- 服务器将 HTML 发送到浏览器
- 浏览器显示页面
这有六个步骤，每个都可能有延迟。乘以十次产品浏览，就有十次服务器请求 —— 而不是十次即时的页面转换。
解决办法：转向客户端路由
为避免这些往返，尽可能将路由转移到客户端。方法如下：
// app/products/[id]/page.js
'use client'; // 这使其成为客户端渲染
import { useEffect, useState } from 'react';
import { useParams } from 'next/navigation';
export default function ProductPage () {
const params = useParams();
const [product, setProduct] = useState(null);
const [reviews, setReviews] = useState(null);
useEffect(() => {
// 在客户端获取数据——没有服务器往返
Promise.all([
fetch(`/api/products/${params.id}`).then(res => res.json()),
fetch(`/api/reviews/${params.id}`).then(res => res.json())
]).then(([productData, reviewsData]) => {
setProduct(productData);
setReviews(reviewsData);
});
}, [params.id]);
if (!product) return <ProductSkeleton />;
return (
<div>
<ProductDetails product={product} />
<ReviewsList reviews={reviews} />
</div>
);
}
这样，产品页面之间的导航会立即发生 —— 数据在后台加载，无需在服务器上重新渲染整个页面。
何时使用服务器端 vs 客户端渲染
快速指南：
使用服务器端渲染（SSR）当：
- SEO 至关重要（产品页面、博客文章）
- 你要显示用户特定的敏感数据
- 初始页面加载速度比导航速度更重要
- 内容不经常变化
使用客户端渲染（CSR）当：
- 用户频繁在相似页面之间导航
- 你可以有效地缓存数据
- SEO 不是优先事项（用户仪表盘、管理面板）
- 你想要即时的、类应用的导航
额外解决办法：混合渲染
有时，你需要 SSR 用于初始页面加载，但希望后续交互受益于 CSR。Next.js App Router 允许你结合两者：
// app/products/[id]/page.js
// 为 SEO 进行服务器渲染初始页面
export default async function ProductPage({ params }) {
const initialProduct = await fetchProduct(params.id);
return (
<div>
<ProductClient initialData={initialProduct} productId={params.id} />
</div>
);
}
// components/ProductClient.js
'use client';
export default function ProductClient({ initialData, productId }) {
const [product, setProduct] = useState(initialData);
// 后续导航在客户端进行
const router = useRouter();
const navigateToProduct = async (newId) => {
// 立即更新 URL（感觉是即时的）
router.push(`/products/${newId}`);
// 在后台获取新数据
const newProduct = await fetch(`/api/products/${newId}`).then(res => res.json());
setProduct(newProduct);
};
return (
<div>
<ProductDetails product={product} />
<RelatedProducts onProductClick={navigateToProduct} />
</div>
);
}
但即使有智能路由和优化的数据获取，如果应用拖着过大的 JavaScript 包，仍然会感觉迟缓。让我们谈谈为什么会出现这个问题 —— 以及如何解决。
5. JavaScript 包体积过大
我曾在一个黑客马拉松期间加入一个 Next.js 项目，当时主 JavaScript 包的大小是 2.3 MB。之前的开发者为了使用几个函数就导入了整个库。没有代码分割。没有动态导入。只是把一个巨大的负载丢给每个用户。
JavaScript 包体积直接影响你的交互时间（TTI）—— 衡量页面何时完全可用的指标。包越大，用户盯着加载 spinner 的时间就越长。
以下是经常导致包膨胀的原因：
// 第一个包膨胀器：导入整个库
import _ from 'lodash'; // 导入整个 70KB 的库
import * as dateFns from 'date-fns'; // 另一个大型导入
// 第二个包膨胀器：在各处导入重型组件
import { DataVisualization } from './DataVisualization'; // 500KB 组件
import { VideoPlayer } from './VideoPlayer'; // 300KB 组件
import { RichTextEditor } from './RichTextEditor'; // 400KB 组件
export default function HomePage () {
return (
<div>
<h1>Welcome</h1>
{/* 这些组件可能在初始加载时甚至不可见 */}
<DataVisualization />
<VideoPlayer />
<RichTextEditor />
</div>
);
}
这种方法会向每个用户加载所有内容 —— 即使他们从未与这些组件交互。幸运的是，有更好的方法。
解决办法：代码分割和动态导入
Next.js 默认支持智能代码分割。但要充分利用它，你需要使用动态导入来仅在需要时加载代码。
基于路由的代码分割
默认情况下，Next.js 按路由分割代码。但你可以使用 next/dynamic 进一步优化：
// pages/dashboard.js - 仅当用户访问 /dashboard 时加载
import dynamic from 'next/dynamic';
// 仅在需要时加载重型组件
const AnalyticsChart = dynamic(() => import('../components/AnalyticsChart'), {
loading: () => <ChartSkeleton />,
ssr: false // 对仅客户端组件跳过服务器端渲染
});
const DataExporter = dynamic(() => import('../components/DataExporter'), {
loading: () => <p>Loading exporter...</p>
});
export default function Dashboard() {
const [showAnalytics, setShowAnalytics] = useState(false);
const [showExporter, setShowExporter] = useState(false);
return (
<div>
<h1>Dashboard</h1>
<button onClick={() => setShowAnalytics(true)}>
View Analytics
</button>
{showAnalytics && <AnalyticsChart />}
<button onClick={() => setShowExporter(true)}>
Export Data
</button>
{showExporter && <DataExporter />}
</div>
);
}
通过这种模式，用户只在请求时才下载图表或导出逻辑，而不是之前。
基于组件的代码分割
如果你有在路由之间共享但仅在特定情况下需要的组件，也可以延迟加载它们：
// components/ConditionalFeatures.js
import dynamic from 'next/dynamic';
// 仅当用户有高级订阅时加载
const PremiumChart = dynamic(() => import('./PremiumChart'), {
loading: () => <div>Loading premium features...</div>
});
// 仅当用户点击“高级设置”时加载
const AdvancedSettings = dynamic(() => import('./AdvancedSettings'));
export function ConditionalFeatures({ user, showAdvanced }) {
return (
<div>
{user.isPremium && <PremiumChart />}
{showAdvanced && <AdvancedSettings />}
</div>
);
}
这确保你的用户不会为他们甚至无法访问的功能付出性能代价。
额外解决办法：使用 @next/bundle-analyzer 分析包
要查看是什么占用了你的包体积，使用官方的包分析器：
// next.config.js
const withBundleAnalyzer = require('@next/bundle-analyzer')({
enabled: process.env.ANALYZE === 'true'
});
module.exports = withBundleAnalyzer({
// 你的 Next.js 配置
});
运行 ANALYZE=true npm run build 查看 JavaScript 的可视化地图 —— 每个过大的库、每个庞大的组件。这就像性能问题的 X 光片。
通过动态导入、条件加载和包分析，你可以毫不费力地将初始包缩小 50-70%。
6. React hydration（水合）也可能是问题所在
即使你小心处理 JavaScript 包，React 应用中还有一个性能杀手 —— 水合。服务器向浏览器发送 HTML 后，React 需要 “水合” 它，即附加事件监听器，并使虚拟 DOM 与服务器渲染的标记协调。这个过程可能会阻塞交互性，影响性能。
问题是这样的：
// 传统 Next.js 页面，存在水合瓶颈
export default function ProductPage({ products }) {
return (
<div>
<Header /> {/* 必须先水合，用户才能交互 */}
<ProductGrid products={products} /> {/* 大型组件树 */}
<FilterSidebar /> {/* 复杂的交互组件 */}
<Footer /> {/* 不需要 JS 的静态内容 */}
{/* 所有内容同时水合，阻塞交互性 */}
</div>
);
}
在水合期间，浏览器的主线程会被阻塞，而 React 处理整个组件树。对于复杂页面，这在低端设备上可能需要数百毫秒甚至几秒，造成用户能看到 UI 但无法交互的令人沮丧的延迟。
解决办法：使用 React 服务器组件和部分水合
Next.js App Router 带来了 React 服务器组件，从根本上改变了这种动态，让你可以选择应用的哪些部分需要客户端 JavaScript：
// app/products/page.js - 服务器组件（不向客户端发送 JS）
import { ProductGrid } from './components/ProductGrid';
import { ClientSideFilter } from './components/ClientSideFilter';
// 这个组件在服务器上运行，只发送 HTML
export default async function ProductPage () {
// 数据获取在服务器上进行
const products = await fetchProducts();
return (
<div>
<h1>Products</h1>
{/* 静态部分仅作为 HTML 存在 */}
<ProductGrid products={products} />
{/* 仅交互部分需要水合 */}
<ClientSideFilter products={products} />
</div>
);
}
// components/ClientSideFilter.js
'use client'; // 标记为需要水合
export function ClientSideFilter({ products }) {
const [filters, setFilters] = useState({});
// 交互组件逻辑...
}
这种方法带来几个主要性能优势：
- 默认零 JavaScript—— 服务器组件只向浏览器发送 HTML，除非用 'use client' 明确标记
- 选择性水合 —— 只有交互组件消耗客户端 JavaScript
- 流式渲染 —— 页面的各个部分可以独立加载并变得可交互
- 减小包体积 —— 服务器组件的代码永远不会发送到客户端
实施智能水合技术是个好开始，但如果你的应用不断重新获取相同的数据，就像失忆了一样，用户仍然会感到延迟。让我们谈谈缓存。
7. 没有在请求间有效缓存数据
缓存就像给你的应用一个好记性。它防止应用每次都要重新获取信息。但我见过很多 Next.js 应用把每个请求都当作第一次处理 —— 特别是对于权限、用户数据或博客文章等内容。
糟糕的缓存不仅会减慢应用速度 —— 还会浪费服务器资源。最常见的缓存错误往往很基础：
重复获取相同数据：
export default function UserProfile({ userId }) {
const [user, setUser] = useState(null);
// 每次组件挂载时运行——没有缓存！
useEffect(() => {
fetch(`/api/users/${userId}`).then(res => res.json()).then(setUser);
}, [userId]);
return user ? <div>{user.name}</div> : <div>Loading...</div>;
}
每次页面加载都拉取新数据：
export async function getServerSideProps({ params }) {
// 每次请求都访问数据库
const posts = await db.posts.findMany({
where: { published: true },
orderBy: { createdAt: 'desc' }
});
return { props: { posts } };
}
这就是我所说的 “系统失忆症”—— 应用在用户刷新或点击离开时就忘记了所有学到的东西。
解决办法：尽可能使用 SSG 和 SWR
有效的缓存在不同层面发挥作用：API 路由、页面渲染，甚至数据库查询。让我们看看如何让它为你工作：
使用 ISR 进行服务器端缓存
如果你的数据不是每秒都变化，就不要每秒都重新获取。使用增量静态再生（ISR）来提供预构建的页面，并偶尔刷新它们：
// pages/blog/[slug].js
export async function getStaticProps({ params }) {
const post = await fetchPost(params.slug);
return {
props: { post },
revalidate: 3600, // 最多每小时再生一次
};
}
export async function getStaticPaths() {
// 为热门帖子生成路径
const popularPosts = await fetchPopularPosts();
return {
paths: popularPosts.map((post) => ({
params: { slug: post.slug }
})),
fallback: 'blocking' // 按需生成其他页面
};
}
这能保持内容新鲜和快速，同时最小化服务器负载。
额外解决办法：在 API 上应用智能缓存控制头
对于消耗大的 API 操作，使用 unstable_cache 缓存服务器端逻辑：
// pages/api/posts.js
import { unstable_cache } from 'next/cache';
const getCachedPosts = unstable_cache(
async () => {
// 消耗大的数据库查询
return await db.posts.findMany({
include: {
author: true,
comments: { take: 5 },
tags: true
},
orderBy: { createdAt: 'desc' }
});
},
['posts-list'],
{
revalidate: 300, // 缓存 5 分钟
tags: ['posts']
}
);
export default async function handler(req, res) {
const posts = await getCachedPosts();
res.setHeader('Cache-Control', 'public, s-maxage=300, stale-while-revalidate=600');
res.json(posts);
}
现在你的服务器不必为相同的查询过度工作，用户也能获得更快的体验。
如果缓存得当，你的应用会感觉像提前知道了用户的下一步行动。但即使有完美的缓存，还有一个陷阱会拖慢一切 —— 未优化的图像。
8. 媒体资源拖慢应用
我曾审计过一个 Next.js 应用，其中单个英雄图像有 4.2MB—— 而且在每个页面上都加载。为了让你有概念，这比大多数完整应用的整个 JavaScript 包还要大。
问题不仅仅是文件大小。处理不当的图像会导致布局偏移、延迟页面渲染、在解码时阻塞主线程，并使最大内容绘制（LCP）远远超出可接受范围。这就像看电影时视频不断缓冲 —— 技术上能看，但体验很糟糕。
我经常看到的错误是这样的：
使用原始 标签：
export default function ProductCard({ product }) {
return (
<div className="product-card">
{/* 没有优化，没有懒加载，导致布局偏移 */}
<img src={product.imageUrl} alt={product.name} />
<h3>{product.name}</h3>
<p>${product.price}</p>
</div>
);
}
急切加载所有内容：
export default function Gallery({ images }) {
return (
<div className="gallery">
{images.map((image, index) => (
// 所有 50 张图像同时加载，即使用户只看到 6 张
<img key={index} src={image.url} alt={image.caption} />
))}
</div>
);
}
这种策略向用户交付了远超他们实际需要的内容，破坏了性能和用户体验。
解决办法：使用 next/image 和响应式尺寸
Next.js 提供了一个图像组件，处理响应式尺寸、懒加载和格式转换（如 WebP/AVIF）。它更快、更易访问，并节省大量带宽。以下是有效使用它的方法：
基本优化
// components/ProductCard.js
import Image from 'next/image';
export default function ProductCard({ product }) {
return (
<div className="product-card">
<Image
src={product.imageUrl}
alt={product.name}
width={300}
height={200}
priority={product.featured} // 立即加载精选产品
placeholder="blur"
blurDataURL="data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcUFhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAARCAAIAAoDASIAAhEBAxEB/8QAFQABAQAAAAAAAAAAAAAAAAAAAAv/xAAhEAACAQMDBQAAAAAAAAAAAAABAgMABAUGIWGRkqGx0f/EABUBAQEAAAAAAAAAAAAAAAAAAAMF/8QAGhEAAgIDAAAAAAAAAAAAAAAAAAECEgMRkf/aAAwDAQACEQMRAD8AltJagyeH0AthI5xdrLcNM91BF5pX2HaH9bcfaSXWGaRmknyJckliyjqTzSlT54b6bk+h0R//2Q=="
className="rounded-lg object-cover"
/>
<h3>{product.name}</h3>
<p>${product.price}</p>
</div>
);
}
这本身就能改善 LCP、防止布局偏移，并帮助用户更快开始交互。
响应式英雄图像
对于在不同屏幕上显示不同尺寸的图像：
// components/HeroSection.js
import Image from 'next/image';
export default function HeroSection () {
return (
<div className="hero relative h-screen">
<Image
src="/hero-image.jpg"
alt="Hero image"
fill
priority
sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"
className="object-cover"
/>
<div className="absolute inset-0 flex items-center justify-center">
<h1 className="text-white text-6xl font-bold">Welcome</h1>
</div>
</div>
);
}
sizes 属性确保浏览器为每个屏幕尺寸选择最佳版本，在小设备上节省带宽。
带懒加载的智能画廊
对于图像画廊，实现渐进式加载：
// components/ImageGallery.js
import Image from 'next/image';
import { useState } from 'react';
export default function ImageGallery({ images }) {
const [visibleCount, setVisibleCount] = useState(6);
const loadMore = () => {
setVisibleCount(prev => Math.min(prev + 6, images.length));
};
return (
<div className="gallery">
<div className="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-4">
{images.slice(0, visibleCount).map((image, index) => (
<div key={image.id} className="aspect-square relative">
<Image
src={image.url}
alt={image.caption}
fill
sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"
className="object-cover rounded-lg"
priority={index < 6} // 优先加载前 6 张图像
/>
</div>
))}
</div>
{visibleCount < images.length && (
<button
onClick={loadMore}
className="mt-8 px-6 py-3 bg-blue-600 text-white rounded-lg"
>
Load More ({images.length - visibleCount} remaining)
</button>
)}
</div>
);
}
这样，用户只下载他们看到的内容 —— 提高性能并减少移动设备上的内存使用。
总而言之 —— 如果你在 Next.js 项目中不使用 组件，你就错过了巨大的性能提升。优化你的图像，用户会立即感受到差异。
为什么在移动设备上优化更为重要
性能问题影响所有人 —— 但移动用户受到的影响最严重。这就是为什么你的 Next.js 应用需要特别友好的移动体验：
- 网络速度慢 —— 许多移动用户仍然使用 3G 或不稳定的 4G 网络。在宽带下 200ms 加载完的 500KB JavaScript 包，在移动网络上可能需要超过 2 秒。
- CPU 较弱 —— 移动设备的处理能力远低于桌面。在你的 MacBook 上 300ms 运行完的 JavaScript，在廉价安卓手机上可能需要 1.5 秒 —— 只是为了水合一个页面。
- 内存限制严格 —— 移动浏览器更容易崩溃和频繁垃圾回收，特别是当你的应用依赖大的包或重型图像时。
这对你的 Next.js 性能策略意味着：
- 最小化包体积 —— 这不是奢侈品，而是必需品
- 优化图像 —— 臃肿的英雄图像不仅减慢页面速度，还可能消耗用户的实际流量
- 使用智能加载状态 —— 在较慢的网络上，感知性能更重要
专业提示 —— 如果你的应用在廉价手机上通过 3G 网络运行良好，那么在其他地方都会流畅运行。
衡量关键指标：如何优化性能
Next.js 中的性能优化不是选择一个解决方案 —— 而是识别问题所在，并有条不紊地解决。事实是，性能工作不是一个勾选框，而是开发速度和用户体验之间持续的平衡。
每个新功能、每个额外的依赖项、每个在截止日期压力下走的捷径，都可能慢慢侵蚀你已经取得的进展。最好的方法是不要把性能当作事后才考虑的事情。从一开始就考虑它。
不要盲目优化。使用以下工具：
- Next.js 内置分析，用于核心网络指标
- Lighthouse CI，用于 CI/CD 管道中的自动化性能测试
- 真实用户监控（RUM），了解实际用户体验
- 包分析器，及早发现依赖膨胀
我们在本指南中涵盖的大部分内容 —— 缓存、图像、代码分割和 SSR 策略 —— 可以解决大约 80% 的 Next.js 性能问题。剩下的 20% 通常涉及更复杂的优化，如边缘渲染、CDN 策略、查询优化，有时甚至是全面的架构调整。
但不要从边缘情况开始。先关注大的改进点。
结论
性能的棘手之处在于：应用实际有多快和用户感觉它有多快之间存在差距。你的应用可能在技术上 2 秒内加载完成 —— 但如果用户在 1.8 秒内都盯着空白屏幕，那感觉会非常慢。感知和指标同样重要。
记住这一点。如果感觉快，那就是快 —— 至少对用户来说是这样。
所以要牢记这一点进行开发。添加加载状态，显示占位符，给用户视觉反馈。这样，当有人访问你的应用时，他们不仅会看到速度 —— 还会感受到速度。
LogRocket：全面监控生产环境中的 Next.js 应用
调试 Next 应用可能很困难，特别是当用户遇到难以重现的问题时。如果你有兴趣监控和跟踪状态、自动显示 JavaScript 错误、跟踪缓慢的网络请求和组件加载时间，可以试试 LogRocket。
以上就是Next.js应用变慢的8个原因及解决办法的详细内容，更多关于Next.js应用变慢的原因及解决的资料请关注脚本之家其它相关文章！