问题所在
你花了好几周压缩商品图片、精简 CSS、开启懒加载、选了轻量主题。PageSpeed 终于达到85–90分。然后你安装了一个新的菜单应用——分数直接跌到55。
这是非常常见的场景。市场上很多菜单应用使用沉重的 JavaScript 框架、加载额外字体、在页面加载时就注入脚本执行，并且不支持正确的懒加载。一个优化不佳的菜单应用可能给页面加载时间增加1–2秒——这就足够让 Google 降低排名，让顾客在页面加载完成前就离开了。
"我试装了一款知名 mega menu 应用——我的移动端 PageSpeed 一夜之间从82降到48。卸载就回升，安装就下降。只能另找更轻的。"
— Navi+ 用户
一个沉重菜单应用能抹掉你所有的优化成果
页面速度不只影响用户体验——它直接影响营收和搜索排名。Google 使用 Core Web Vitals（LCP、FID/INP、CLS）作为排名因素。而顾客不会等待——根据多项研究，每多一秒延迟会降低约7%的转化率。
菜单应用通常会造成以下速度问题：
- 渲染阻塞 JavaScript——应用脚本在页面显示内容之前执行，导致 LCP（最大内容渲染时间）增加
- 多余 CSS，未经 tree-shaking 处理——应用加载完整样式表，包括你用不到的部分
- 独立字体未预加载——导致字体替换时的布局偏移（CLS）
- 无法懒加载——菜单在页面加载时就全部加载，即使顾客还没打开菜单
- 多余 HTTP 请求——每个额外请求都增加延迟，对网速慢的顾客尤其明显
你做的每件事都是对的——只是菜单应用没有被正确构建。
Navi+ 如何保持轻量？
Navi+ 从设计之初就将速度作为第一优先级——而不是事后补充。所有 JavaScript 都以延迟加载和懒加载方式执行，CSS 经过优化只加载必要部分，菜单面板只在顾客真正交互时才渲染。结果是安装 Navi+ 后 PageSpeed 几乎没有变化。
| 速度标准 | 普通菜单应用 | Navi+ Menu Builder |
|---|---|---|
| 页面加载时阻塞 JavaScript | 有——导致 LCP 增加 | ✓ 延迟加载，不阻塞渲染 |
| 菜单面板懒加载 | ✗ 立即全部加载 | ✓ 仅在需要时渲染 |
| CSS tree-shaking | ✗ 加载完整样式表 | ✓ 只加载正在使用的样式 |
| 额外字体 | 通常加载独立字体 | ✓ 使用主题字体，无额外加载 |
| 对移动端 PageSpeed 的影响 | 降低15–30分是常见情况 | ✓ 影响极小（<3分） |
| 安装后的 Core Web Vitals | LCP 增加，可能出现 CLS | ✓ 无明显变化 |
如何检测并切换
安装 Navi+ 前，运行 PageSpeed Insights（pagespeed.web.dev）获取店铺基准分数。安装配置完成后，重新运行并对比。大多数商家看不到明显变化——这就是目标。
如果你正在使用其他菜单应用并怀疑它在拖慢店铺，试着临时卸载（或禁用），然后运行 PageSpeed 确认。如果卸载后分数明显提升——你找到原因了。安装 Navi+ 替代，再次运行对比。
从旧菜单应用迁移到 Navi+ 的完整过程——导入菜单结构、自定义样式、在桌面端和移动端测试——通常需要15–30分钟。