当一家店铺感觉很慢时，我们通常首先会怪罪沉重的图片或臃肿的主题。但有一个东西很少有人注意到：菜单应用是如何影响页面加载速度的。菜单就位于页面最顶部，所以它是浏览器最先需要处理的元素之一。一款没有用心打造的导航应用，可能会把整个店铺拖慢。
这篇文章分为两部分。第一部分讲机制：菜单应用为什么会拖慢速度。第二部分讲那些警示信号，让你能亲自检查自己的店铺，而不是靠猜。
菜单应用为何会影响店铺速度
表面上看，菜单应用不过是几个按钮。但在幕后，它通常会引入 JavaScript、字体、图标和图片。每一项都带有速度成本。下面是最常见的四种原因。
菜单出现之前必须先运行的沉重 JavaScript
许多菜单应用用 JavaScript 来构建界面。当顾客打开页面时，浏览器必须先下载文件、解析它，然后执行它——只有到这时菜单才会显示出来。
JavaScript 越重，这一步耗时越长。在性能强的电脑上你几乎察觉不到。但大多数购物者是用手机下单的，而中端手机处理 JavaScript 的速度要慢得多。一个几百 KB 的文件在桌面端只是一瞬间，但在一台廉价的安卓手机上可能要花整整一秒。
对店铺来说，那一秒就是顾客盯着一块没有任何菜单可点的空白屏幕、白白浪费掉的时间。
渲染阻塞：应用在等待菜单时拖住了整个页面
这一点常常被忽视。根据 Google 的文档，JavaScript 默认是会阻塞解析器的：当浏览器正在构建页面、遇到一个 script 标签时，它必须停下来，先把那段脚本运行完，然后才能继续构建页面。
这就叫渲染阻塞（render blocking）。一款把脚本放在错误位置、又没有使用 async 或 defer 属性的菜单应用，会阻塞整个页面的渲染，而不仅仅是菜单。
现实中的结果是：顾客点了一个商品链接，但页面卡住了一会儿，因为它在等菜单脚本跑完。这时他们还看不到图片、价格，什么都看不到。而真正需要快速加载的，是用来卖货的内容，而不是菜单栏。
每一个图标、字体和图片都是一次 HTTP 请求
一个漂亮的菜单往往会附带来自自定义字体的图标，有时甚至每一项都配一张背景图或 logo。每一个资源都是一次 HTTP 请求——浏览器向服务器请求发送一个文件的一次往返。
每次请求都需要时间来建立连接并等待响应。十个图标就意味着十次往返。如果再为菜单单独加一个自定义字体，这份清单还会更长。每一项都很小，但合在一起就累积起来了——尤其是对那些身处信号不佳地区、用着孱弱 3G/4G 连接的顾客。
一个精简的菜单，如果使用内联 SVG 图标或设备上已有的系统字体，就能砍掉相当一部分这类请求。
CLS：加载迟缓的菜单会让布局发生位移
CLS（Cumulative Layout Shift，累积布局偏移）是 Google Core Web Vitals 指标之一。它衡量界面在页面加载过程中位移的程度。根据 Google 的说法，良好的阈值是 CLS 低于 0.1。
同样根据 Google 的说法，CLS 常常发生在 JavaScript 较晚地把内容插入页面、把已有元素往下推的时候。一条在主内容加载之后才出现的菜单栏或导航横幅，就是一个典型的例子：它冒出来，占据空间，把下面的所有东西都往下挤。
你在购物时多半遇到过这种情况：你正要点”加入购物车”，恰好这时菜单弹了出来，布局发生位移，结果你点错了别的地方。这就是 CLS——既恼人，又是顾客离开的原因。
菜单正在拖慢店铺的信号
既然你已经理解了其中的机制，下面就是实操部分：如何判断你的菜单应用是否正在造成问题。你不需要深厚的技术功底，只要几个免费工具就够了。
运行 PageSpeed Insights
打开 pagespeed.web.dev，粘贴你的店铺网址，点击分析。这款 Google 工具会给你的页面打分，并把问题列在两个板块下：Opportunities（优化建议）和 Diagnostics（诊断）。
留意那些提到 render-blocking resources（渲染阻塞资源）或 reduce JavaScript execution time（减少 JavaScript 执行时间）的条目。如果某个文件名或描述里出现了 navigation、menu 或 drawer 之类的字眼，那么菜单应用很可能就是拖慢速度的一部分原因。
Mobile（移动端）和 Desktop（桌面端）两种模式都跑一遍。Mobile 的分数通常更低，也更接近你顾客的真实体验，因为他们大多数是用手机下单的。
使用 Chrome DevTools 的 Network 标签
在 Chrome 中打开你的店铺，按 F12 调出 DevTools，选择 Network 标签。重新加载页面，然后按 JS 类型筛选，只看 JavaScript 文件。
出现的表格会显示每个文件有多重、加载花了多长时间。找那些名字看起来像你的导航应用的文件。如果某个菜单文件有几百 KB、并且要花一段时间才加载完，那就是实打实的证据，而不是猜测了。
一个小提示：DevTools 提供了模拟慢速网络（throttling，限速）和弱 CPU 的选项。把它们打开，来模拟真实顾客的设备，你看到的数字就会比你自己机器上显示的更接近现实。
对比安装应用前后的分数
最诚实的做法是在前后各测一次。在安装新的菜单应用之前，先跑一遍 PageSpeed Insights，记下分数以及 LCP、INP 和 CLS 指标。等你装好应用、搭好菜单之后，再跑一遍并做对比。
根据 Google 的说法，良好的阈值是 LCP 低于 2.5 秒、INP 低于 200 毫秒、CLS 低于 0.1。如果在安装应用之后 LCP 升高了，或者 CLS 跳过了 0.1，那这款应用就在消耗你的速度。
这一点很重要，因为普通店铺安装的应用不止一个。根据很多来源引用的数据，一家典型的 Shopify 店铺大约安装了六个应用，有些店铺甚至用到三十个。每个应用都会增加一点拖累，合在一起就累积成一个不算小的数字。而速度又直接关系到有多少人离开页面——根据 Baymard Institute，平均购物车放弃率本就已经在 70% 左右，每多出一秒都可能让这个数字变得更糟。
选择一款在意速度的菜单应用
并不是每一款菜单应用都会拖慢速度。关键在于这款应用在打造时是否把速度放在了心上：精简的 JavaScript、没有渲染阻塞、几乎没有浪费的请求，以及为菜单预留好空间、让它不会让布局发生位移。
这正是我们打造 Navi+ 时的首要任务。Navi+ 为 Shopify 和任何网站无需写代码地构建菜单——Tab Bar、Mega Menu、Slide Menu、FAB、Grid Menu——支持移动端和桌面端分别配置，并经过优化，不会拖累你的 Core Web Vitals。你仍然应该按上面的步骤亲自测量，在安装前后各测一次；这是最可靠的验证方式。
总之，菜单应用是体验的一部分，但别让它悄悄拖慢你整个店铺。花几分钟跑一跑 PageSpeed Insights、看一看 Network 标签，就能给你一个清晰的答案。
本文是更大篇章《导航与页面加载速度——选择一款不损害 Core Web Vitals 的菜单应用》的一部分。