Next.js 13部署在Windows Server加载缓慢问题排查求助

我在Windows Server上部署了一个Next.js应用，通过URL重写反向代理将默认网站指向localhost:3000（应用使用npm run start启动）。执行npm run build后，构建文件大小显示正常：

Route (app)                                Size     First Load JS
┌ ○ /                                      3.83 kB         193 kB
├ ○ /page-1                                22.3 kB         200 kB
├ λ /page-2/[slug]                         18.6 kB         155 kB
├ ○ /favicon.ico                           0 B                0 B
├ ○ /industry                              402 B           143 kB
├ λ /page-3/[slug]                         3.59 kB         217 kB
├ ○ /search                                4.39 kB         218 kB
└ λ /page-4                                7.25 kB         173 kB
+ First Load JS shared by all              77.9 kB
  ├ chunks/698-9aeb085986fa3c35.js         25.3 kB
  ├ chunks/bce60fc1-4fb1d7d66adc126a.js    50.5 kB
  ├ chunks/main-app-81baf2622b02bba0.js    221 B
  └ chunks/webpack-9a9ff32ad7229fde.js     1.9 kB

Route (pages)                              Size     First Load JS
─ ○ /404                                   183 B          75.9 kB
+ First Load JS shared by all              75.7 kB
  ├ chunks/framework-43665103d101a22d.js   45.1 kB
  ├ chunks/main-35a40e64711e27bc.js        28.5 kB
  ├ chunks/pages/_app-4e72088c2da7d84b.js  198 B
  └ chunks/webpack-9a9ff32ad7229fde.js     1.9 kB

但实际访问网站时，加载数据显示异常：

116 requests
19.85 MB / 3.98 MB transferred
Finish: 42.20 s
DOMContentLoaded: 5.99 s
load: 20.71 s

其中layout.js达6.73MB，main-app.js达6.1MB，远大于构建时的体积。请问哪里操作有误，为何单页加载耗时长达42秒？

一、反向代理未启用静态资源压缩 #

Windows Server的IIS默认可能没开启Gzip/Brotli压缩，导致构建后的优化压缩文件以原始未压缩体积传输，直接造成文件体积暴涨。

• 检查IIS压缩设置：
  1. 打开IIS管理器，选中服务器节点，双击“压缩”功能
  2. 勾选启用静态内容压缩和启用动态内容压缩
• 配置反向代理的压缩支持：在URL重写规则的“服务器变量”中添加HTTP_ACCEPT_ENCODING，值设为gzip, deflate, br

二、Next.js启动流程错误 #

确认npm run start启动的是生产环境服务：

• 检查package.json的scripts配置：确保"build": "next build"、"start": "next start"
• 部署必须严格执行npm run build完成构建后，再执行npm run start，启动后查看控制台输出，确认显示“Production mode”

三、静态资源代理路径错误 #

反向代理规则可能未正确映射Next.js的静态资源路径（/_next/下的chunk文件），导致浏览器请求到未优化的原始文件或重复加载资源。

• 检查IIS的URL重写规则，确保所有/_next/*路径都代理到http://localhost:3000/_next/*
• 打开浏览器开发者工具的“网络”面板，查看layout.js和main-app.js的请求URL、响应头，确认是否获取到压缩后的文件（响应头应有Content-Encoding: gzip或br）

四、代码或依赖未按需加载 #

构建日志显示的是优化后的体积，但实际可能存在未被Tree Shaking的冗余代码，或第三方库引入了完整包而非按需模块。

• 用Next.js的包分析工具定位大体积模块：
  1. 安装依赖：npm install @next/bundle-analyzer --save-dev
  2. 在next.config.js中添加配置：

     const withBundleAnalyzer = require('@next/bundle-analyzer')({
       enabled: process.env.ANALYZE === 'true',
     })
     module.exports = withBundleAnalyzer({})
     

  3. 执行ANALYZE=true npm run build，打开生成的分析页面，查看layout.js和main-app.js内的大体积依赖

五、服务器资源或网络瓶颈 #

Windows Server的CPU、内存不足，或网络带宽受限，会导致文件传输缓慢，拉长加载时间。

• 打开任务管理器，查看CPU、内存占用率，排除资源耗尽问题
• 测试服务器到客户端的网络带宽，确认是否存在网络拥堵

内容的提问来源于stack exchange，提问作者Ivana Murray