你给店铺加的每一个应用，都会往页面里注入一小段代码。菜单应用是最早加载的东西之一，因为顾客在页面一打开的那一刻就需要看到导航。所以菜单应用与 Core Web Vitals 之间的关系，并不是什么遥远的技术问题——它直接关系到顾客的第一印象。
有一点很容易被忽略：一个加载缓慢的漂亮菜单，有时甚至比没有还要糟。顾客看不到代码；他们只看到一个卡顿的页面、跳来跳去的内容，或者点了却没反应的菜单。这篇文章汇集的是我自己经营店铺、反复测量之后学到的东西——不是要吓唬你「速度有多可怕」，而是让你在选菜单应用时有足够的依据，同时不必拿体验去交换。
- 菜单应用会影响用户最先接触的导航。
- Core Web Vitals 能显示加载慢、点击延迟和布局偏移。
- 不要只相信宣传，要在安装前后测量。
Core Web Vitals 是什么，为什么和你有关
Core Web Vitals 是 Google 用来衡量页面加载真实体验的三个指标。它们不是实验室里跑出来的分数，而是从你真实顾客那里采集来的数据。
这三个指标是：
- LCP（Largest Contentful Paint，最大内容绘制）——页面上最大的那块内容需要多久才出现。Google 认为 2.5 秒以内为好。
- INP（Interaction to Next Paint，交互到下一次绘制）——顾客点击或轻触时的延迟。低于 200 毫秒为好。
- CLS（Cumulative Layout Shift，累积布局偏移）——页面加载过程中内容跳动的幅度。低于 0.1 为好。
有一个细节常常被误解：Google 是按第 75 百分位来衡量的。也就是说，要有 75% 的访问都达到「好」，这个页面才算通过。如果四分之一的顾客体验糟糕，再漂亮的平均值也救不了你。
商家为什么要在意这个？有两个原因。第一，这是 Google 的排名信号之一，尽管不是分量最重的那个。第二，也是更重要的，它反映了顾客真实的感受。在漏斗顶端的每一点小小的摩擦——包括加载缓慢的页面——都会累积起来。
好消息是，你不需要懂任何代码就能读懂这三个数字。它们是公开的、免费的，而且解释得相当清楚。
深入了解阅读完整指南 → Core Web Vitals 是什么，为什么和你有关
菜单应用如何影响速度，以及怎么发现它
Shopify 上的大多数应用，都是通过向店铺前端注入 JavaScript 来工作的。菜单应用也不例外。这本身并不坏——问题在于这段代码是怎么加载的、什么时候运行的。
当一段脚本以渲染阻塞的方式加载时，浏览器必须先下载、读取并跑完它，才能去构建页面的其余部分。菜单应用正好属于那类容易出问题的东西，因为它需要很早就出现，就在页面最上方。
菜单应用拖慢速度或损害体验，有三种方式：
- 推高 LCP——当菜单是页面顶部很大一部分内容，又必须等脚本跑完才显示时。
- 抬高 INP——当每一次点击菜单都得等 JavaScript 处理，让人感觉迟钝时。
- 增大 CLS——当菜单（尤其是顶部栏或底部标签栏）出现得太晚，把其他内容挤得移了位时。
不用任何工具、肉眼就能看出的迹象：
- 菜单明显比页面正文晚出现。
- 菜单一出现，页面就抖一下或跳一下。
- 你点了菜单，要等一拍它才打开。
- 在手机上，底部标签栏在加载时闪烁或位置跳动。
看到这些迹象，并不意味着菜单应用就是唯一的元凶——但值得在移除它之前和之后各测一遍。
深入了解阅读完整指南 → 菜单应用如何影响速度，以及怎么发现它
一个好的菜单应用在速度上应该具备什么
一旦你明白了菜单应用是怎么影响这些指标的，选起来就容易多了。下面是我认为值得权衡的几条标准，大致按重要性排序。
加载轻量，不阻塞渲染。 应用应该用 defer 或 async 来加载代码，这样菜单就不会逼着页面去等。这一点你没法直接查看，但结果会体现在安装前后的速度分数上。
预留稳定空间，不造成布局偏移。 一个好的菜单应用应该提前给菜单留出位置，这样 CLS 才不会上升。这一点非常容易被忽略，尤其是固定标签栏和顶部的吸顶导航栏。
带有 Built for Shopify 徽章。 这是一个值得信赖的信号。按照 Shopify 公布的要求，一款应用要拿到 Built for Shopify 徽章，就不能让店铺前端的 Lighthouse 分数下降超过十分。这不保证它完美无缺，但说明这款应用在页面速度上已经过了一道最低门槛。
移动端和桌面端可分开配置。 一个轻量的菜单，用错了场景照样不好。能给移动端设标签栏、给桌面端设巨型菜单，意味着你不必把所有东西硬塞进同一套设计里。
更换主题时保持稳定。 如果菜单独立于主题保存，你就不必每次换设计都重建一遍——也能避免在切换过程中残留代码越积越多的风险。
下面是一个典型「沉重」菜单应用与一个经过优化的应用之间的简要对比：
| 方面 | 不在意速度的应用 | 为速度优化的应用 |
|---|---|---|
| 代码如何加载 | 渲染阻塞 | Defer / async |
| 对 CLS 的影响 | 经常引起布局偏移 | 预留稳定空间 |
| Built for Shopify | 通常没有 | 带有徽章 |
| 设备配置 | 一套共用设计 | 移动端与桌面端分开 |
Navi+ 正是按这些思路打造的：无需代码就能搭建菜单，移动端与桌面端分开配置，更换主题时菜单原地不动，而且这款应用持有 Built for Shopify 徽章。你可以去 naviplus.io 看看。即便如此，我仍然鼓励你在自己的店铺上亲自测量，而不是轻信营销话术——包括我们的。
深入了解阅读完整指南 → 一个好的菜单应用在速度上应该具备什么
安装任何菜单应用之前的一份清单
这一部分是一套实用的步骤，大约十五分钟就能做完，不需要任何技术功底。
- 先测好你的基准线。 打开 PageSpeed Insights，粘贴你的首页网址和一个商品页网址，把当前的 LCP、INP、CLS 记下来。这是你日后对比的参照点。
- 以试用模式安装菜单应用。 大多数应用都有试用期。按你真正打算使用的方式把菜单搭好——别敷衍了事地随便配一下。
- 再测一次同样的页面。 把三个指标和基准线对比。小差异是正常的；CLS 或 LCP 出现大差异，就是要回头再看一看的信号。
- 在真机上用肉眼检查。 如果可以，就在 4G 下加载页面。看看菜单是否出现得晚、是否引起布局偏移、点击时是否卡顿。
- 看徽章，也看评价。 优先选有 Built for Shopify、并且评价里具体提到速度的应用。
- 不留用的话，要干净地卸载。 如果你决定不留它，要确认应用把它注入的所有代码都移除了，然后再测一次，确认分数回到了基准线。
一个习惯上的提醒：不要为了对比而同时装好几个菜单应用。它们的代码可能互相重叠，扭曲你的测量结果。一个一个地试，测下一个之前先把上一个干净地卸掉。
关于导航，而不只是速度
速度很重要，但它服务于一个更大的目标：帮顾客找到他们需要的东西。一个把所有导航都藏起来的快菜单，什么也解决不了。
Nielsen Norman Group 针对 179 名用户做的一项研究发现，把导航藏起来会让可发现性几乎砍掉一半，同时还让顾客行动变慢、让找东西感觉更难。这个教训足够简单：如果不是非藏不可，就别藏。
这就是为什么在手机上，底部标签栏往往比单纯的汉堡菜单更好用——主要项目始终触手可及，不用打开什么就能看到。速度和好导航是相辅相成的；选一个菜单应用，意味着两者一起选。
从哪里开始
先测基准安装菜单应用前保存 PageSpeed 分数，设置后再对比同样页面。
速度并不只是开发者才需要操心的问题。作为商家，你完全有能力自己去检查，并做出有依据的判断。你不需要读一行代码，就能知道一个菜单应用是不是在拖慢你的店铺——你只需要知道该看哪里。
像 PageSpeed Insights 这样的免费工具，就足以让你上手。今天就测一测你店铺的分数，把它存为基准线，等你试用新的菜单应用之后再对比。这些数字会比任何营销说辞告诉你更多——包括写这篇文章的人说的话。
探索更多主题
本指南链接到一系列专题文章——逐一深入了解。