手机百度速度优化

@三水清

自我介绍

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

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

目录

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

项目背景

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

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

整个搜索流程

流程对应的架构

流程决定分工

整个项目划分

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

以真实用户体验为标准

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

收集完整搜索体验时间

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

现状&竞品数据



手机百度



竞品



数据测算方 法



解决方法



点击搜索到首屏展 2497ms 示



1222ms



上下游统计 --



客户端耗时



882ms



N/A



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



网络+服务器耗时



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

络/HHVM/chunked



首屏渲染



437ms



254ms



js埋点



内核/差异化模板



P.S：wifi环境，15日均值

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

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

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

结论

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

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

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

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

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

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

用户很关注进度条：强迫症吗？

通过实验验证方案

AA实验 AB实验

底部框sug去除实验

底部框去除后数据



A：保留搜索框



B：去除搜索框



页面大小



125K



104K



首屏时间







十条结果







用户可操作







总下载时间







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

准入：防止退化，保护成果

利用 Python+adb+monkey 脚本

准入：防止退化，保护成果

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

冷启动时间（优化后）

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

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

搜索结果（优化后）

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

速度项目怎么做？

监控+分析：

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

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

- 确立标准 - 防止退化

Q&A



<ThankYou!>

PoweredBynodePPTv0.9.8-3