9
在开发模式下，Next 需要 26 秒以上的时间来为我构建一个页面。
DONE Compiled successfully in 26253ms
每次我更改代码时，这都成为开发过程中的一大痛苦。
我认为这是因为我有很多 npm 包 (48)，或者它们很大/很复杂。
其他人有这样的经历吗？
除了删除软件包之外，还能采取什么措施来加快速度吗？
Q
[vercel/next.js]慢速>构建页面：”
A
回答
3
使用 webpack 分析器查看应用程序中的包：https://github.com/zeit/next.js/tree/v3-beta/examples/with-webpack-bundle-analyzer
您可能正在使用一些服务器端 NPM 模块或一些不需要的模块。尝试摆脱它们。
0
@arunoda 谢谢。
知道增量 webpack 编译是否即将到来吗？
0
@tashburn 我们已经这样做了。我们只编译您正在查看的页面。
顺便说一句：仔细检查您是否使用的是最新版本的 Next.js
1
@tashburn 我也有同样的问题。我今天刚刚开始故障排除过程。
8
如果你们中的任何人可以将存储库发送给我，我可以看一下。
1
@brentmclark 超级，谢谢！
6
嘿@arunoda 想向您发送一个（精简的）存储库，展示我们公司（@brentmclark 和我自己）正在经历的事情：存储库
我想指出的部分是：运行 ( yarn run dev:start) 时，您将登陆到一个具有第二页链接的页面。这就是我们优化的链接。但是，在第二页上，如果单击根（已构建的页面）或“第三页”（未构建的页面），则两者都需要几秒钟的时间来构建。
现在这些都是非常轻的页面，我们真正的应用程序有超过 600kb 的样式，每个页面还有大量的组件等，将构建页面时间缩短到 5-10 秒。然而，事实上这些精简的页面仍然需要几秒钟的时间来加载，这对我来说是个问题。
有什么想法吗？
3
@tashburn，FWIW @chaffeqa 发现了一个我们正在尝试的配置设置以及适量的预取。 24 小时可能是错误的时间长度；我们正在不断进行微调。
将其放入next.config.js（或修改现有的）。 onDemandEntries是该财产的同级webpack。
module.exports = {
onDemandEntries: {
// on dev, since our pages are so expensive, lets keep them for 24 hours
maxInactiveAge: 1000 * 60 * 60 * 24,
},
}增加maxInactiveAge实际上只能解决症状，而不是根本问题。然而，它对我们的开发人员体验产生了相当大的影响。
yarn install而且，我们也有一段时间没有跑步了。当我运行一个时，我发现我们的几个依赖项有较小的和/或补丁更新。运行后rm -rf ./node_modules && rm yarn.lock && yarn install我的编译时间下降了大约 50%。
这些事情纯粹是轶事，但如果它们能给你带来类似的结果那就太好了！
5
@chaffeqa 应用程序构建时间对我来说似乎相当标准。看：
我检查了捆绑包，似乎您可以删除一些标记为红色的模块。 （我假设它们是仅服务器模块）
无论如何，尝试通过动态导入将这些模块加载为按需模块。
作为长期解决方案，我们希望使用 autodll 插件（https://github.com/zeit/next.js/pull/2433）或其他一些缓存机制来缩短开发重新构建时间。
0
顺便说一句：Apollo 客户端似乎也很大。
9
这是我们近期路线图的一部分，旨在显着提高开发和生产的编译性能。其中很大一部分是减少工作量。
3
（例如：每次启动时，webpack 都会从头开始重做整个项目。那里有很多时间可以保存）
7
@brentmclark 感谢您的建议。该onDemandEntries设置只会阻止 24 小时内卸载页面，是吗？如果是这样，那肯定会对一些人有所帮助。
我尝试更新到 Next 的最新版本，并根据您的建议重新安装了所有模块（谢谢）。我的开发构建时间并没有真正改变——启动仍然是 6-9 秒（每当我更改服务器代码时就会发生这种情况），而我的一个关键页面需要 9-29 秒。不知道为什么所花费的时间有如此大的变化。
@arunoda 我使用了 Webpack Bundle Analyzer，并且能够删除大约 10% 的模块。略有改善。
@rauchg 说这是我们近期路线图的一部分，旨在显着提高开发和生产的编译性能。爱它！这将产生巨大的影响。
4
我的开发构建时间并没有真正改变——启动仍然是 6-9 秒（每当我更改服务器代码时就会发生这种情况），而我的一个关键页面需要 9-29 秒。
我假设这里发生的事情是 webpack 从头开始重新启动。
0
感谢@arunoda 的关注！因此，该存储库是我们实际项目的副本，但是我删除了所有实际组件（页面），而是制作了这些 x3“模拟路由”（我这样做是为了不泄露业务数据）。我保留了我们使用的所有依赖项，并导入了它们，只是为了帮助演示这些依赖项的性能。
不幸的是，大部分依赖项在common块中都是必需的，因为它们被 redux 消耗，这显然是每个页面都需要的。
因此，您对编译时间“正常”的看法是正确的，但是我提到的“示例”应用程序的主要问题是：尝试从 开始http://localhost:8000，然后单击Route Two，然后单击Root。您将看到 404 页面 1 秒，然后页面加载。没有重建。
> Building page: /route-one
DONE Compiled successfully in 4414ms 04:48:05
GET / 200 5202.810 ms - 3329
GET / 200 9.402 ms - 3328
WAIT Compiling... 04:48:06
> Building page: /route-two
DONE Compiled successfully in 1820ms 04:48:08
GET / 200 137.186 ms - 3328
Client pings, but there's no entry for page: /
GET / 200 9.760 ms - 3329
GET / 200 10.049 ms - 3328
Client pings, but there's no entry for page: /
GET / 200 6.781 ms - 3329
GET / 200 10.076 ms - 3328我认为这是一个根本路由问题（路由匹配？）。
第二个是：从那里返回Route Two并单击Route Three（尚未构建）。单击约 3 秒后会挂起，然后渲染页面。这是我们都提到的正常缓慢，可能由 DLL 显着修复。
我实际上在本周早些时候看到了 DLL 拉取请求，并为此感到兴奋，这可能是开发体验的胜利。我确实想联系并提及我使用 DLL 插件的经验是它有棘手的边缘情况需要处理（很像热重新加载器）。所以我建议做类似于react-boilerplate所做的事情，并使其可以选择退出。主要是为了你自己的 github 问题理智吗？
我想在想法中提到的最后一件事是：有可能next-routes成为next.js.我这么说是因为我们能够使用它以及优化preload来dev-prebuild制作一种性能更高、标准的路由器（@tashburn，您可能想针对您的开发问题研究一下这个），更不用说这个redirectUrl选项是一个巨大的用户体验win，我们在我们的<Link />组件中使用了它）。
PS 请随意使用该存储库进行任何想法/性能测试
4
@tashburn 是的，这一onDemandEntries更改只会在 24 小时内阻止页面卸载。
1
我们的两分钱 - 现在我们已经完全迁移到下一个，我们看到了类似于 @chaffeqa 的问题 - 特别是因为我们的 mobx 存储，每个页面都需要我们的大部分 JS（就像上面描述的 redux 一样）。
此外，我们每天至少会遇到 #282 中描述的内存故障几次（对于计算机功能较弱的团队成员来说更是如此）。
我们从基本的 webpack + dll 插件迁移过来，它没有任何这些问题。启动成本较长（60 秒），但后续页面不必重建，并且我们没有遇到内存泄漏。恕我直言，这是一个更好的开发体验，因为我们实际上只需要每天进行一次或两次冷启动，但我们不断地导航页面。
问题1：有没有办法在服务器启动时编译所有页面（以禁用按需页面获取）？
问题2：有什么我们可以尝试帮助这种情况并加快我们的发展吗？ DDL 插件听起来很有前途（并且之前对我们有帮助） - 特别是因为我们加载了大量依赖项，例如https://github.com/codemirror/CodeMirror、https://github.com/jpuri/react-draft-wysiwyg和https:// /github.com/Semantic-Org/Semantic-UI-React。
除了上面的抱怨之外，感谢接下来所做的所有辛勤工作 - 这是一个很棒的库:)。
1
这方面有什么进展吗？
我自己刚从下一个开始，注意到了同样的模式。
初始加载很长（以及后续路线的任何加载），但之后导航到之前已加载的任何路线都非常快。
如果您在网站上闲置了一段时间，这种模式就会重演。
7
@tashburn @chaffeqa @brentmclark 我想我已经将范围缩小到postcss-import瓶颈postcss-easy-import。
你能尝试删除它并告诉我它是否更快吗？
7
也许，我很难判断它是否快得多，但有可能！
1
@pruhstal我没有使用postcss
5
@tashburn @chaffeqa 这对我来说是一个转移注意力的事情。此时，它几乎无法使用。
2
我们将在 Next v5 中集成 webpack dll
8
我正在忍受长时间的全页面刷新。结果是 OSX 和 IPv6 以及主机文件中解析地址的问题。
问题在于用作.local我的……本地……机器上的扩展。 DNS 解析器将在 20 秒以上超时。与.local操作系统保留有关。
最近，当我的本地 Next.js 站点从本地托管的 API 中提取数据时，这让我深受打击。
这是我的主机文件的第一部分。添加条目到::1队列中消除了漫长的等待。
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost example.local
fe80::1%lo0 localhost
127.0.0.1 example.local