基于监控宝的跨境电商网站性能优化实战科技频道

据国家统计局数据，2015 年全国网上零售额达 38773 亿元，同比增长 33.3%。其中阿里占比 76.1%，京东占比 11.9%。2016 年 3 月 4 日，美国知名调查公司 Forrester 发布的亚太电商数据报告显示，2015 年中国电商市场规模超越美国，成为全球第一大电商市场。在此背景下，跨境电商为抢占中国市场、追逐利润，纷纷采取多种策略，而电商网站性能优化是重要一环。

那么什么是网站性能呢？当用户输入网站域名后，经 DNS 解析找到目标服务器 IP，请求数据通过互联网到达目标服务器，服务器处理后，将响应数据经互联网返回用户浏览器，浏览器计算渲染后呈现给用户。这个复杂过程涉及网站可用性、正确率、打开速度、首屏时间等指标，这些数据综合起来就是网站性能的完整定义，不过在用户看来，就是网页能否打开这么简单。

网站性能与互联网企业的业务和利润密切相关。从 Google、Amazon、雅虎等世界著名网站的性能数据统计来看：Google 网站访问速度每慢 400ms，用户搜索请求就会下降 0.59%；Amazon 表示，网站延迟增加 100ms 会使其收入降低 1%；雅虎网站若有 400ms 延迟，流量会下降 5 - 9%。

某著名跨境电商企业在行业内经过多番比较，最终选择了云智慧的监控宝服务。起初客户需求比较模糊，经多次沟通，并结合其业务发展状况和网站架构，确定了如下监控方案：

一、通过监控宝进行网站监控

二、通过监控宝的 API 监控

对其微信公众号的 API 进行业务流程监控，客户自定义告警阈值，运行中触发阈值时要能及时告警。在监控过程中曾遇到问题，按照客户说明配置后，获取到 token 并加密，但访问购物 API 接口一直失败，而 Postman 测试却顺利通过。经检查对比，发现登录成功后的响应头有相应 cookie 值，重新修改监控任务，将获取的 cookie 赋给事先定义的变量，作为购物 API 接口请求头的 Set - Cookie 值再次测试后顺利通过。

三、通过监控宝网页性能监控

准确采集全球不同地区用户的网站打开速度、首屏时间等用户体验数据。

四、通过监控宝对同行业 4 家电商网站进行对比监控

五、通过网站监控、API 监控、网页性能监控、行业内数据对比，找出网站性能问题及根本原因，并提供解决方案和优化建议。

监控方案确定后便开始正式监控，为保证数据客观准确，采用一周的数据进行分析。

网站可用性

电商行业平均可用率为 99.99%，但该客户在中国大陆的平均可用率仅 95%，安徽只有 89.13%，北京为 90.27%；其中 MobileWeb 平均可用率 96%，北京仅 88.59%，可用率最差。

通过历史快照追踪，403Forbidden错误是客户网站平均可用率低的主因。其主机分布在常州电信、佛山电信、天津联通、西安电信、新乡电信和太原联通等多个区域。客户联系 CDN 服务商后解决了问题。

其次，HTTP/1.1503 服务不可用也是值得关注的错误类型，错误主机分布区域主要为：南昌电信、天津电信、武汉电信、郑州联通、徐州电信、佛山电信、镇江电信和上海电信等。分析原因，主要是请求是动态的，回到源站后，Jetty 处理请求过多，导致本次服务不可用。建议客户将此请求按频次生成静态页面。

最后分析客户官网的元素加载错误，发现部分资源出现 401、404 以及首屏渲染超时等错误。648 错误主要是因为 Downloadingtime 下载时间过长，导致系统整体性能下降。首屏时间与元素下载速度直接相关，当元素下载超时，首屏时间必然超时，页面优化建议后文统一给出。

业务流程监控

传统 IT 监控基于技术，关注 IT 基础设施可用性，但业务系统故障不只是 IT 故障导致，单纯的 IT 监控往往难以满足企业业务需求。业务流程监控是云智慧针对企业业务视角推出的特色功能，通过应用接口调用模拟用户使用过程，以可量化、可视化、自动化手段，测量业务系统服务的响应性能，准确感知终端用户体验和整体业务质量。针对此跨境电商客户的业务状况，提出多个监控流程，以购物流程为例：

登录，获取 token；

对获取的 token 重新进行 MD5 算法加密，生成新字符串；

购物，将新字符串作为头参数传入；

退出。

创建 API 监控任务，获取登录后生成的 token 信息存入已创建的 token 变量中，对该变量值重新进行 MD5 加密，生成新字符串，并作为头参数传递到下一步接口。

网页性能和用户体验

行业对比横坐标是基础文档下载的字节数，即页面基础文档元素大小，单位是 KB；纵坐标是首屏用时，单位是 s。这两类值越大，网站速度越慢，用户体验越差。小球体积代表页面开始浏览到接收最后一个数据包的时间差，数据越大，页面整体性能越差。黑色代表我们的客户，其他三个颜色分别代表同行业其他三个客户。这里出现一个问题，为何客户的基础文档元素最小，但首屏用时和响应用时却最大、用户体验最差呢？

原因剖析通过对这几个网站进一步分析，有以下因素：

代码层面：客户首页代码行数、JS 数、不同域名请求数过多，部分 JS 未压缩、部分无用，这是页面性能差、用户体验不好的重要因素。同时，客户页面中 JS 同时有外连和内嵌，且分布在页面上部和中间，这也是首屏加载慢的重要原因。因为浏览器执行 JavaScript 代码时不能同时处理其他事务，script 每次出现都会使页面等待脚本解析和执行，脚本执行完才继续渲染页面。此外，客户代码元素中内嵌 6 个 iframe，其中 4 个为空；div 嵌套过深且有很多空元素；部分代码没有缩进。

针对代码层面问题，优化建议如下：A. 优化布局 div 的层次，减少嵌套；B. JS 尽量外连，并合理控制引入位置，最好放在页面底部，提升网站加载速度；C. 合理控制 JS 和 CSS 文件的大小和数量，压缩合并，减少浏览器请求数量；D. 元素请求合并：一个页面有很多子元素，若单独请求，每个请求都回源调用，会占用大量时间。元素请求合并就是将所有请求合并为一个，统一提供给服务方，再由服务端分发、合并后返回。E. 尽量不在代码中出现无意义的空标签；F. 合理使用 iframe，去掉空的 iframe。

网络层面：分析这几个网站可知，客户源站在国外且大陆无镜像站点，这是页面性能和用户体验差的重要因素。建议客户联系 CDN 服务商优化，同时推荐采用某云的动态加速优化方案：优化前，用户动态请求都在源站，请求链路是：用户 —— 运营商 —— 源站，全球用户都要从源站获取数据，请求链路长且耗时。优化后，尽量将动态数据推到边缘节点，这些边缘节点无需去源站请求，可直接在边缘节点操作。另外，请求可同步或异步，可同时并行请求页面内多个元素，整体动态回源过程就是对内容的动态加速。动态加速是一系列优化方案，包括内容压缩等。