比较 Healthcare.gov 和 JCrew.com 的表现

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / Java 学习路线 / 一对一提问 / 学习打卡/ 赠书活动

目前,正在 星球 内带小伙伴们做第一个项目:全栈前后端分离博客项目,采用技术栈 Spring Boot + Mybatis Plus + Vue 3.x + Vite 4手把手,前端 + 后端全栈开发,从 0 到 1 讲解每个功能点开发步骤,1v1 答疑,陪伴式直到项目上线,目前已更新了 204 小节,累计 32w+ 字,讲解图:1416 张,还在持续爆肝中,后续还会上新更多项目,目标是将 Java 领域典型的项目都整上,如秒杀系统、在线商城、IM 即时通讯、权限管理等等,已有 870+ 小伙伴加入,欢迎点击围观

每周,我们都会使用我们的浏览器综合监控(测试版)工具测量大约 30 个消费者网站的网站主页性能。 MobileStrategies360.com 每周都会发布包含每个站点的完整排名和数据的结果摘要。

看到这些站点如何随时间变化以及这些变化如何影响站点的性能是非常有趣的。本周的结果显示,HealthCare.gov 主页的性能改进与 JCrew.com 的性能下降之间的变化形成了有趣的对比。

几年前,当 HealthCare.gov 网站推出时,它理所当然地因网站整体表现不佳而受到很多批评。本周,至少主页有了显着改善,在每周排名中上升了 8 位,从第 18 位上升到第 10 位,速度得分有所提高,主要是通过优化大小将页面加载大小减少超过半兆字节(如见下图)。

平均加载的资源数量也略有减少 6 个(每个额外加载的资源都会对网站的性能产生明显的“资源税”)。页面加载大小的减少对视觉完成时间、首次渲染时间和页面整体速度得分的提高有直接影响(如下图所示)。

这代表了一种通过优化内容以使其尽可能紧凑以减少需要传输的数据量从而加快页面加载时间来提高站点性能的标准方法。

本周数据中第二个有趣的变化是,J.Crew 在 3G 中从第四位上升到第八位几乎完全是由于视觉完成时间从 8.1 秒增加到 9.7 秒。

该图显示了周中视觉完成时间的突然增加,而第一次渲染和速度得分保持相当一致。

尽管页面重量从 1.5 MB 减少到 0.89 MB,但性能还是出现了下降。加载的元素保持不变,首次渲染时间和速度得分分别保持在 5.1 和大约 5.6。下图显示了一周内页面重量的减少。

这个视觉效果代表了一个难题,因为您通常会期望相当合理地减少 600 KB 的总页面重量会导致性能提高。

如果我们进一步调查,检查之前和之后的各个快照,原因之一可能是服务器响应可用时间的增加。它包括服务器连接时间和服务器响应第一个数据字节所需的时间。

查看下面的两个时序图,我们可以看到 J.Crew 服务器可用响应时间有明显增加:

查看本周早些时候的快照,服务器响应可用时间大约为一秒。

本周晚些时候此快照中的服务器响应可用时间接近 12 秒。

同样,如果我们查看本周早些时候与本周晚些时候的单个资源时间,下面的两个图表显示创建 J.Crew index.jsp(Java 服务器)页面所需的时间大幅增加——主页内容的主要容器页面。

此资源瀑布时序图显示 index.jsp 页面的下载时间约为 1.7 秒。

此资源瀑布图显示了 J.Crew 主页的 index.jsp 大约需要 14 秒才能下载。

虽然这些特定的快照显示了一周内的极端变化,但它们通常表明了一周内发生的趋势,这种趋势导致视觉完整时间的增加,导致 J.Crew 在指数中下降。

如果不检测网站的后端,就无法知道是什么导致了创建 index.jsp 所需时间的增加。这可能是由于用于创建页面的逻辑发生变化或其他一些设计变化导致了变化。公司必须了解网站设计、架构或基础设施的变化如何影响其网站的性能,尤其是最终用户所感知的性能。