弱网下的动效预算

动效做得好不好，在本地千兆网里看不出来，在地铁里的 4G 上才见分晓。境外节点 + 晚高峰的组合意味着：你无法假设用户能顺畅地下载 1MB 的 JS。

三条硬规则

1. 动效库不进首屏包。 three.js 和 GSAP 都用动态 import()，只有真正需要时才下载。首屏只留 CSS 动画和几十行原生 JS。
2. 降级不是可选项。 prefers-reduced-motion: reduce 的用户不但看不到动画，连动效库的请求都不会发出——脚本在判断之后才会被 import。
3. 给最坏情况留路。 WebGL 创建失败、GSAP 加载超时、音频解码失败，每一种都有静态兜底：CSS 渐变背景、普通纵向列表、纯播放器无频谱。

体积账

资源	是否首屏	体积（gzip/br 后）
HTML + 内联 CSS	是	~14 KB
原生交互脚本	是	~2 KB
three.js 分包	否，进入视口后	~150 KB
GSAP + ScrollTrigger	否，滚动到该节	~45 KB
音频	否，点击播放后	按需 Range

首屏没有一张大图：海报图是构建期生成的 AVIF，且只作为 WebGL 的兜底垫底。

测量方式

别只看 Lighthouse 的实验室数据。用 Chrome DevTools 的 Network 面板把速度限制到 Slow 4G，再把 CPU 降速 4 倍，然后刷新——这才是国内移动网络的真实体感。目标：LCP < 2.5s，首屏总量 < 300KB。