Next.js性能升级与主线程减负：next/dynamic使用及移动端得分提升技术问询

一、next/dynamic的适用与不适用场景 #

适合通过动态导入拆分的场景 #

• 首屏可视区域外的非核心组件：比如页脚社交分享模块、评论区入口、回到顶部按钮、侧边栏非核心推荐位，这类组件用户滚动到对应位置前不会产生交互，拆分后完全不影响首屏渲染节奏
• 体积较大的非首屏交互组件：比如带复杂逻辑的富文本编辑器、数据图表看板、模态弹窗、带虚拟滚动的大型下拉选择器，这类组件对应依赖包体积超过10KB，拆分后可直接缩减主JS包体积
• 强依赖浏览器API的客户端专属组件：比如需要调用window/document的第三方组件，配合ssr: false参数使用，可省去手动做环境判断的冗余逻辑，同时降低服务端渲染的计算开销

不适合通过动态导入拆分的场景 #

• 承载核心首屏指标的组件：比如对应LCP指标的主图容器、核心标题块、首屏业务表单、全局导航栏组件，这类组件拆分后会触发额外的JS请求，需等chunk加载完成后才会渲染，直接拖慢FCP、LCP指标
• 体积小于3KB的轻量通用组件：这类组件拆分后生成的独立chunk本身，加上请求头的传输开销就已经超过组件本身的体积，拆分后的请求成本远高于收益
• 首屏即需交互的组件：比如首屏搜索框、Tab切换控件，这类组件拆分后会导致用户触发交互时仍在等待chunk加载，直接拉高INP指标，造成交互卡顿

二、过度滥用next/dynamic会导致性能反向下降 #

这是移动端性能优化最容易踩的负收益坑，核心影响体现在三点：

• 加剧请求数量超标问题：原本可合并到同一个主chunk的组件，被拆成多个独立的动态加载chunk后，在HTTP/1.1协议下浏览器同域名并发请求数仅为6个，大量零散的chunk请求会挤占并发通道，让首屏需要的核心资源排队等待加载，直接拉长资源加载总时长
• 触发串行加载瀑布：每个动态chunk都需要等主JS执行完成、识别到组件渲染需求后才会发起请求，这种串行加载流程会大幅推迟组件出现的时间，在移动端弱网环境下，延迟会被放大3-5倍
• 拉高主线程长任务耗时：原本可被浏览器一次性预解析、编译为字节码的整包JS，被拆成零散小chunk后，每个chunk的解析、编译操作都是零散触发的，反而会增加主线程的阻塞时间，拉低TBT指标

实操判断阈值：单页面通过动态加载拆分的chunk总数建议控制在3-5个，单个拆分chunk的体积不要小于5KB，超过这个范围基本都是负收益。

三、当前优化阶段完全没有必要引入AMP #

• 技术适配成本极高：Next.js官方在App Router架构中已经不再内置AMP支持，硬接入需要做大量路由适配、组件兼容改造，投入产出比极低
• 优化目标可通过常规手段实现：AMP的核心作用是强制限制第三方脚本加载、优化核心资源优先级，这些效果完全可以通过代码拆分、请求合并、核心资源预加载的方式达成，不需要受AMP规则的限制（比如AMP禁止自定义复杂JS逻辑、不支持深度交互组件，反而会损失业务功能）
• 排名加权效应已经消失：Google当前的搜索排序机制中，已经不再将AMP作为移动端页面的核心加权项，只要页面达到Core Web Vitals合格线，即可获得和AMP页面同等的排名权重。

针对当前移动端评分60-75分、请求总数105个的现状，优先把首屏外、单体积超5KB的组件做动态拆分，把总请求数压到50个以内的优化收益，远高于折腾AMP、无差别拆分组件的效果。

内容的提问来源于stack exchange，提问作者La pach'