AirJD 焦点
AirJD

没有录音文件
00:00/00:00
加收藏

手机百度速度优化 by 三水清

发布者 noder
发布于 1433082743793  浏览 4769 关键词 JavaScript, 移动开发 
分享到

第1页

手机百度速度优化

@三水清



第2页

自我介绍

王永青 网名: @三水清 手机百度前端运营组负责人 招聘邮箱

- wangyongqing01#baidu.com - 有妹子,有水果机



第3页

目录

项目背景 整个搜索流程和项目分工 以真实用户体验为标准 怎样和客户端一起做速度项目



第4页

项目背景

2013年7月:搜索速度需要与移动搜索速度持平 - 目标:3G+wifi用户,绝大多数可以在1s内看到首屏

2013年11月:做搜索最快的客户端 - 目标:搜索速度超越竞品



第5页

整个搜索流程



第6页

流程对应的架构



第7页

流程决定分工



第8页

整个项目划分

监控:知己知彼 优化:核心工作 准入:防止退化



第9页

以真实用户体验为标准

怎样收集用户整个搜索体验时间? 究竟我们和竞品的差距在哪里? js打点得到的数据是用户的真实体验吗? 用户的使用习惯真的是我们想象的吗? 要解答上面问题,就需要利用监控系统来做数据分析!



第10页

收集完整搜索体验时间

客户端时间=客户端打点 服务器处理=logid标注 页面渲染时间=js埋点 网络时间=首字节-客户端loadUrl-服务器处理



第11页

现状&竞品数据



手机百度



竞品



数据测算方 法



解决方法



点击搜索到首屏展 2497ms 示



1222ms



上下游统计 --



客户端耗时



882ms



N/A



客户端RD测 精简动画/框架 算



网络+服务器耗时



内核/网 878ms+300ms 608+360ms 请求log日志

络/HHVM/chunked



首屏渲染



437ms



254ms



js埋点



内核/差异化模板



P.S:wifi环境,15日均值

客户端:网络:页面=2:2:1



第12页

js打点能体现用户真实的体验?



第13页

js打点能体现用户真实的体验?



第14页

结论

js打点方式要早于UI展现 两者走势是match的 有内核反而更差,为什么?

- 从“切片”到<paint>标签



第15页

用户的使用习惯真的是我们想象的吗?

用户输入搜索词时间:10s~14s 空sug比例:20% 用户很关注进度条 底部搜索框使用情况:<5‰



第16页

基于用户使用习惯我们做了什么?

利用用户输入搜索词时间:DNS预连接 sug:空sug不发请求,sug预充 体验优化



第17页

用户很关注进度条:强迫症吗?



第18页

通过实验验证方案

AA实验 AB实验



第19页

底部框sug去除实验



第20页

底部框去除后数据



A:保留搜索框



B:去除搜索框



页面大小



125K



104K



首屏时间







十条结果







用户可操作







总下载时间







结论:因为代码在非首屏,并不会对首屏造成影响,但是因为代码量的减 少,会缩短domready之后的时间



第21页

准入:防止退化,保护成果

利用 Python+adb+monkey 脚本



第22页

准入:防止退化,保护成果



第23页

结果:高速摄像头测试数据

冷启动时间(优化后)

手机百度5.0>竞品1>竞品2>竞品3



第24页

结果:高速摄像头测试数据

搜索结果(优化后)

手机百度在稳定性和速度上都超过竞品



第25页

速度项目怎么做?

监控+分析:

- 从全局抓,从大头抓 - 数据支持理论,不要想当然 优化开展:

- 多团队合作 - 做好效果评估和原因分析 准入系统:

- 确立标准 - 防止退化



第26页

Q&A



<ThankYou!>



第27页

PoweredBynodePPTv0.9.8-3



支持文件格式:*.pdf
上传最后阶段需要进行在线转换,可能需要1~2分钟,请耐心等待。