Shopify 性能优化探索与落地

一、背景介绍

2023 年 9 月，飞书深诺集团公司前端小伙伴们配合运维团队，在公司内用较低的成本，对一些特定网站做了海外访问性能优化，完成后得知旗下子品牌 Meet Experience 团队（下文称 ME），在对客户 Shopify 网站做性能优化时，遇到了一些瓶颈，希望前端团队能帮忙解决。

提高 Shopify 网站性能，提升加载速度，有助于带给客户更好的体验，提升转化率，并改善 SEO 排名及自然流量，从而给客户带来更多流量，这也是我们希望做这件事情的主要原因。

预调研

接到 ME 需求后，我们先对公司内 Shopify 网站性能优化整体进行了一次预调研，调研内容主要集中在两个方面：

现有 Shopify 网站性能优化的整个工作流程是什么样的，技术介入的时机以及解决的问题是什么？
性能优化的指标如何检测和衡量，现有网站优化是怎么具体实施（修改代码的流程）的？

预调研结果如下：

整个商务工作的一般流程，简要概括下，如下图所示：

由流程图可以看到，网站性能诊断需求一般只占客户需求的很小一部分，而技术可以发力的地方有两点：

1）在售前诊断阶段 - 提供更专业的性能诊断

2）在实施执行阶段 - 提供更专业的优化方法

关于 Shopify 网站性能优化技术方面的调研信息如下：

1）Shopify 网站框架现状

一般情况下，前端开发的技术栈一般是主流框架（React、Vue），而 Shopify的技术栈是 Liquid。目前存在 Shopify 1.0(Liquid)、Shopify 2.0(Liquid)、Shopify hydrogen(Remix) 三个版本，其中，1.0 和 2.0 都是基于 Liquid，场景类似 Wordpress 建站，hydrogen 则是 Shopify 2021年下半年推出的的无头电商系统框架，前端基于 React。

当下市场，客户网站主流仍是 Shopify 2.0，约占总需求的 90% 左右。

2）Shopify 网站性能指标

如果衡量网站指标，绕不开 CWVs(Core Web Vitals) 指标三兄弟 - LCP、FID、CLS，其中 LCP 能代表网站性能的核心指标。

对于公开网站，Google 提供了网站诊断工具 PSI (PageSpeed Insights)，诊断结果的核心指标也是这三个；
对于非公开网站，Google 提供了类 PSI 的本地网站诊断工具 Lighthouse，安装 Chrome 插件即可使用。

回到客户上来，客户要求性能优化的 Shopify 网站，业内交付的指标也是以 PSI 测试分数为主，网站性能优化前，PC 站测试分数一般为 50～70 分，Mobile 站一般为 30～50 分。优化后，PC 站测试分数一般能提到 8、90 分左右，Mobile 站在原有基础上，一般也能多提升20～40分不等。

3）Shopify 网站性能优化

Shopify 框架自身已经在性能优化做了很多工作，比如使用全球 CDN、建立了快速的服务器响应，以及Http 使用 2.0 或者 3.0 协议。根据 Shopify 自身测算，从 2021 年以后，无论是基于 Liquid 的 Shopify 2.0 框架，还是 hydrogen 框架，性能测试均居各框架前列，见官方报告：liquid-vs-headless-a-look-at-real-user-web-performance。

总体来说，在 Shopify 2.0 框架下，能做的优化范围已经非常少了。但是，在这有限的范围内也不能忽视网站性能，如果做了一些比较挫的方式，比如网站商品图片使用的是未被压缩的原始图片、比如安装有问题插件导致js运行时消耗时间过长，Shopify 框架自身的优越性，依然救不了网站。

二、快速上手

1. 如何诊断 Shopify 网站性能

目前主要靠 PSI 诊断，PSI 也会给出一些优化建议，比如按需加载、启用文本压缩、使用缓存策略等

检测主要数据指标示例如下：

其中性能和 SEO 分数一般是客户最关注的。

2. 如何优雅开发 Shopify 网站

1）作为 Shopify Partner 获取客户授权

Shopify Partner 是 Shopify 生态中不可或缺的一环，组成群体主要是设计师、开发者以及营销人员，来有偿帮助商户做网站搭建、主题开发、数据分析等等。

为了帮助客户网站做性能优化，需要两点：

公司具有 Shopify Partner 资质
个人账号加入到公司所在的组

于是我们首先申请了 Shopify 账号，并加入到了公司组内，并看到了客户授权的网站，以及网站副本（一般开发交付用副本，防止误操作对线上造成影响）。

2）网站代码关联 Github

Shopify 2.0 开发有两种方式，一种是类似 Wordpress 的可视化界面搭建，另一种是直接修改源码。前者对开发小白比较友好，后者适用于专业网站开发者。

这里主要介绍后一种直接修改源码的开发方式：即先将网站与 Github 做关联，再进行网站源码开发。

具体步骤在官方文档中也做了详细介绍，简要来说，核心有 2 步：

Shopify 网站与 Github 组织或账号做关联
Shopify 网站与具体的 branch 做关联

做完关联后，就能获得双向的代码同步：当修改代码，并将新代码推送到 Github 后，Shopify 网站会同步发生改变；同样，当在 Shopify 网站编辑代码后，Github 中代码也会同步发生改变。

3）上手开发

Shopify 2.0 的源码示例如下：

做过 Wordpress 开发，或者经历过主流框架之前的 html 模版开发如 Pug（原 Jade）、EJS 的小伙伴们，对这一套模版预发应该比较熟悉。本质上就是用模版语法，实现数据动态注入，熟悉规则即可上手。

三、进阶玩法

1. 性能诊断作弊预防

上文提到，Shopify 网站性能诊断，主要靠 PSI，那么就有这么一小撮人在这方面打起了主意，不好好做性能优化，却欺骗 PSI 以获取较高分数，然后糊弄客户，实现交付。

我们在接到客户网站性能优化需求时，时而会看到不良第三方遗留在客户网站上的作弊代码，下面以两个典型例子，说明作弊代码的原理，大家可以小心此类套路。

1）典型作弊示例一

javascript 复制代码

let _0xd8f3ee = "ZG9jdW1lbnQub3BXXXXXXX...(过长略过)";Function(window["\x61\x74\x6F\x62"](_0xd8f3ee))();

解码后，发现这段代码做了以下事情：

针对 PSI 运行环境，插入一个宽高为 99999px 的 Base64 的 SVG 图片，最大宽高设置为整屏的 90%

这样 PSI 测试时，第一时间就会将这个 dom 元素渲染出来，根据 LCP 检测规则，因为渲染时间较早，性能分数就会很好看。而用户打开时，因为运行环境与PSI 运行环境不同，并不会渲染此元素，所以不会受到任何影响。

2）典型作弊示例二

html 复制代码

<img 
    alt="website" 
    width="99999" 
    height="99999" 
    style="pointer-events: none; position: absolute; top: 0; left: 0; width: 99vw; height: 99vh; max-width: 99vw; max-height: 99vh;"
    src="data:image/svg+xml;base64,PHN2ZXXXXXXX...(过长略过)"
>

这段代码做了以下事情：

在 html 最顶层，插入一个宽度 99999px，高度 99999px 的 Base64 的透明 SVG 图片，并且设置了 Click 和 Touch 等事件穿透

这个也是钻了 LCP 检测规则的空子，而且因为图片透明且事件穿透，所以用户也无感知。

3）作弊预防

既然不良第三方利用 LCP 检测规则钻空子，我们也可以针对 LCP 检测规则，揪出不良第三方。

应对原理很简单，需要检测 LCP 的最大内容块的 Dom 元素是什么，该 Dom 元素是否是有效元素，如果不是有效元素即为作弊。

网站性能优化是个系统工程，最终的目的是通过提高用户体验、增加网站转化率，进而帮助客户获益，这样整个生态才能健康向上，我们强烈反对这种只赚一次性快钱的作弊行为。

2. 网站性能优化实施

在 Shopify 2.0 框架下，虽然能做的性能优化比较少，但我们还是系统性总结了一些可以优化的点

综合优先级	影响因素	影响子因素	解决方案	成效	风险	解决成本
1	图片	图片未压缩，或未配置从而使用了默认Size较大的产品详情图	图片压缩，一般使用 Tiny	高	低	低
		图片未使用 webp 等新一代图片格式	使用新格式替代，Shopify 自身有一套降级方案	高	低	低
		图片未根据设备，设置适配的合适宽高	响应式加载适配宽高的图片	高	低	低
		图片宽高不明确，导致加载抖动（cls）	图片设置合适宽高	高	低	低
2	代码压缩	外联的 js / css 文件未压缩	压缩后替代	高	低	低
3	渲染/运行阻塞	未使用 prefetch，在空闲时加载非首页资源	根据实际场景，使用相关属性	中~高	低	低
		未使用 preload	根据实际场景，使用相关属性	中~高	低	低
		未使用 preconnect	根据实际场景，使用相关属性	中~高	低	低
		使用了不合理的懒加载（用 js 异步加载图片）	根据实际场景，使用相关属性	中~高	低	低
		该使用懒加载时未使用	根据实际场景，使用相关属性	中~高	低	低
		其他 - 如服务器请求较多	视情况处理	低~中	低	低~中
4	css 相关	使用 Sass	使用转化后的 css 文件	中~高	中	中
		在header 引用了大文件的 css 样式，但是在首页中只用了极小的一部分	转成 css 内联标签，并将 style 文件放body下	低	中
5	应用插件	安装已使用，对性能影响较大	只能将信息告诉客户，供其决策	-	-	-
		安装未使用，对性能有影响	与客户确认后卸载	中	中~高	中
		卸载后有残留	一般发生在Shopify 1.0框架中，需要尝试去除	低	中~高	中
6	js 相关	冗余js	尝试去除	低	中~高	中

四、再进阶一下玩法

1. 性能诊断指标体系化

从 PSI 网站诊断结果中，我们可以看到一些性能指标数据，但数据不多，只包含 LCP、FCP 等少量核心指标，ME 在和客户沟通时，会显得比较单薄。

我们首先做的，是帮 ME 扩充了原有的性能检测指标，用一套更系统性的指标来全面反映网站综合性能。

新的性能指标体系主要分为三个部分：

1）主要性能指标

包括能直接反映性能的指标，如 LCP、FCP、Full loaded 等

2）辅助性能指标

包括间接影响性能的的指标，如页面大小（Page Weight）相关明细、页面请求（Page Request）相关明细、以及 Prefetch、Preconnect、懒加载的一些检测情况

3）作弊情况

如果在我们接手客户网站代码之前，客户有被其他不良第三方欺骗过，并在网站中留下了作弊代码，针对不同的作弊代码，我们也会有一套检测措施

更详细的指标体系情况，因为涉及到 ME 对客策略，在此就不详细展开了

2. 诊断、实施流程自动化

成功体系化建设诊断指标后，使诊断流程标准化也有了可行性。

如果每一个客户进入，都需要人工将整个流程走一遍，其实是比较傻的行为。所以技术介入的另外一个优势是，实现工具的自动化。

目前整个自动化的工作流程正在价值论证中，后续我们会逐渐将一些经过多数客户验证过的流程，通过提供技术工具的方式，辅助 ME 小伙伴们进行实施。

五、性能优化服务技术 SOP

综上所述，网站性能优化只是对客户整体服务的一环，当 ME 接到客户需要对 Shopify 网站进行诊断和优化的需求时，会拆解出网站性能优化部分，在技术上会按以下 SOP 进行实施：

扫描检查网站作弊情况，根据特征代码，找出客户网站中不健康的欺骗代码。
按照新的性能指标体系，对现有网站数据做全面诊断，获取网站现有性能数据。
将网站性能诊断报告告知客户，并给出专业建议，等待客户进行下一步的决策。
如果签单进入了实施环节，则首先剔除网站作弊代码，并且按照诊断报告，对图片、代码以及应用插件进行全面优化。
实施完成后，重新诊断网站数据，并进行内部验收。
对客交付。

六、对客经历 & 写在最后

在帮助 ME 设计完性能诊断指标体系后，ME 迎来了被这套新工作范式下服务的第一个客户，对客经过颇有点跌宕起伏：

首先是客户需求经商务转至 ME 后，ME 小伙伴们先是比较兴奋：这次有了更全的一套评估体系，预估效果会很好；
但是在对客沟通时，客户说他们刚让第三方公司对网站做了性能优化，所以这部分可以略过了；
ME 的小伙伴比较失望，但是又不甘心，和客户安利了下我们性能优化的一些优势，开始了尽力的争取，客户也好奇起来，说，要不也给我们网站诊断一下试试？
于是 ME 用新的诊断指标体系，帮客户做了全套诊断，并邀请我们前端技术小伙伴帮忙诊断了一下网站是否有作弊行为；
不出意外，最大的意外发生了，上家帮客户做性能优化的第三方公司，是个无良奸商，用了典型作弊示例二的方式，欺骗了客户。
后面我们将作弊行为告知了客户，客户对我们的服务能力和质量有了全新的认识

到这里，这段经历差不多告一段落，此时我脑海里又浮现出一句话：技术需要为业务服务，创造价值，要不然没有意义；随着职业经历的丰富，我对这句话有越来越深的理解，虽然纯解决技术问题虽然有它的乐趣，但是看到自己的技术真正能解决问题，创造价值会带来更多的成就感，而这段经历也可以作为我对这个理念的一个注脚。

作者

马宗皓（飞书深诺架构与平台技术，资深前端研发工程师）