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 站测试分数一般为 5070 分,Mobile 站一般为 3050 分。优化后,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
也会给出一些优化建议,比如按需加载、启用文本压缩、使用缓存策略等
检测主要数据指标示例如下:
PC 端
Mobile 端
其中性能和 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)典型作弊示例一
解码后,发现这段代码做了以下事情:
针对
PSI
运行环境,插入一个宽高为 99999px 的 Base64 的 SVG 图片,最大宽高设置为整屏的 90%
这样 PSI
测试时,第一时间就会将这个 dom 元素渲染出来,根据 LCP
检测规则,因为渲染时间较早,性能分数就会很好看。而用户打开时,因为运行环境与PSI
运行环境不同,并不会渲染此元素,所以不会受到任何影响。
2)典型作弊示例二
这段代码做了以下事情:
在 html 最顶层,插入一个宽度 99999px,高度 99999px 的 Base64 的透明 SVG 图片,并且设置了 Click 和 Touch 等事件穿透
这个也是钻了 LCP 检测规则的空子,而且因为图片透明且事件穿透,所以用户也无感知。
3)作弊预防
既然不良第三方利用 LCP 检测规则钻空子,我们也可以针对 LCP 检测规则,揪出不良第三方。
应对原理很简单,需要检测 LCP 的最大内容块的 Dom 元素是什么,该 Dom 元素是否是有效元素,如果不是有效元素即为作弊。
网站性能优化是个系统工程,最终的目的是通过提高用户体验、增加网站转化率,进而帮助客户获益,这样整个生态才能健康向上,我们强烈反对这种只赚一次性快钱的作弊行为。
2. 网站性能优化实施
在 Shopify 2.0 框架下,虽然能做的性能优化比较少,但我们还是系统性总结了一些可以优化的点
四、再进阶一下玩法
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 用新的诊断指标体系,帮客户做了全套诊断,并邀请我们前端技术小伙伴帮忙诊断了一下网站是否有作弊行为;
不出意外,最大的意外发生了,上家帮客户做性能优化的第三方公司,是个无良奸商,用了典型作弊示例二的方式,欺骗了客户。
后面我们将作弊行为告知了客户,客户对我们的服务能力和质量有了全新的认识
到这里,这段经历差不多告一段落,此时我脑海里又浮现出一句话:技术需要为业务服务,创造价值,要不然没有意义;随着职业经历的丰富,我对这句话有越来越深的理解,虽然纯解决技术问题虽然有它的乐趣,但是看到自己的技术真正能解决问题,创造价值会带来更多的成就感,而这段经历也可以作为我对这个理念的一个注脚。
作者
马宗皓 (飞书深诺架构与平台技术,资深前端研发工程师)
评论