-
Notifications
You must be signed in to change notification settings - Fork 509
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
天猫双11前端分享系列(一):活动页面的性能优化 #25
Comments
好赞 |
Open
谢谢分享 有你们的分享才能带动整个国内水平哦 |
thx to learn more about react |
现在不是可以 (愚见) =》
可以在Falcor中针对不同的UA,给出不同的数据源给业务JS,不同的终端根据业务JS获取不同的交互结果。 |
统计方法不同,得到的数据不同,不知道天猫是通过什么方法得到的数据?js埋点吗? |
赞赞!! |
这久写了几个页面了解了一下前端才发现这些重要。以前一直做的事安卓,所以对前端不是那么的了解。 |
Open
我会关注这个的。 |
厉害啊 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
数据结果
无线优先从去年开始推行,今年更是全面无线化,双11无线业务成交拿到了不错的结果,性能也迈出了一大步,对比去年双十一页面整体load时间提升了2s秒左右,秒开率达到了70%;
去年双11活动会场埋点几个页面的性能,onload均值在4.7s左右(实际情况应该在3-4秒),导致跳失率非常高。
今年双十一后的数据情况:
做了什么
体积优化
请求优化
渲染优化
为什么这么做
体积优化价值
对比去年双11和以往活动提升最明显的地方在于,针对所有图片均作了裁剪压缩处理,由于活动业务的特殊性,和目前在源头没能控制住图片的大小,往往一张页头图片或运营从detail页提取的商品图片就能达到300k,整体页面体积能超过1M(首屏600k左右),而现在通过CDN的裁剪压缩后一张图片大小能缩小70%左右,针对所有图片处理后页面整体体积和效率缩减至少一半,以一个简单双十一页面为例:
预加载是这次手淘新发起的解决方案,将页面中静态资源预加载到手淘客户端,减少这些静态资源请求,这套方案也正好解决了,天猫目前繁杂的业务下诞生的一些固定大资源的问题。详细会在相关文章中再详细介绍
请求优化重点
空白请求也会耗费时间。
优化中的痛点
关于体会
目前天猫的页面基本上都还在基于KISSY搭建,原来的目的是为了保持PC/Mobile端技术的一致性和简单性,提高工作效率和工程化能力。而这在全面无线化的今天,已经成为一个瓶颈,这也是天猫后续技术发展需要解决的一个非常重要的问题。
性能这块活动目前做的远远不够,看向手淘,还有太多太多的东西要做,相比繁杂的业务压力,确实需要缓缓,放慢手中的业务,将性能和品质提升上去。
天猫前端团队招聘
如果你看了这篇文章,对加入天猫前端团队有意向的,可以发简历到[email protected],招聘要求见:https://job.alibaba.com/zhaopin/position_detail.htm?positionId=3504
The text was updated successfully, but these errors were encountered: