web 前端Web前端之路让前端飞

2017GMTC 移动Web优化

2017-07-10  本文已影响138人  雨_树

移动Web优化专场主要讲在移动设备上如何优化H5,使得Web运行的性能能够尽可能的接近Natvie。

QQ移动页面框架优化实践

主要是Android QQ方面,因为大部分的内容基于H5开发,所以页面优化对Android QQ的性能提升很有用。

传统页面的优化实践

页面加载的核心是通过CDN(Content Delivery Network)进行静态内容的分发,以及从"Data Server"获取动态数据:


这种方案是非常依赖于网络质量的,并且动态数据是在页面打开时才获取,导致空白页面的出现:


WebView池
不在单独使用时才创建WebView,而是预先处理,在系统空闲的阶段预先创建,并对使用完的WebView进行回收利用,也就是集中统一处理,而使用的程序“即拿即用”,另外为便于复用,抽取上下文关系到独立的中间层:

静态直出

优化静态直出,向“Data Server”获取最新的动态数据后,更新首屏页面,这些发布到“CDN”上,减少了用户需要动态更新的数据:


所谓“直出”,是Web性能优化的一个概念,简单的说就是将多次网络请求获取页面的方式变成减少请求次数,让Web服务器一次性的将渲染好的页面数据返回,这篇文章直出理论与实践总结讲的不错,一步步的讲解了多种直出模式(前后端分离->数据直出->服务端渲染):

离线预推

对于动态请求过度依赖于网络的问题,在登录阶段即开始更新离线包,作为WebView的耳机缓存,减少实时网络请求:



针对可能占用过多带宽的问题:使用“7z”生成压缩包,使用“Bsdiff”生成增量包,尽量减少带宽要求。

动态直出页面的优化实践Sonic

由于业务的变化,“个性化推荐”,使得动态直出成为必须考虑的选项,而不同于静态直出,动态直出面对的问题包括:

然后我们可以看看QQ采取的哪些措施


在"WebView"launch的时候就开始执行网络请求,而不是空等。


其实还是一种预先下载的行为,然后自动的将网络流保存到内存中,使用时边加载边解析,避免空等。


实时缓存,在使用缓存的时候更新缓存:第一次页面打开后会有缓存,下次打开直接用,再等待下载更新。避免重刷,这个会导致白闪,只刷新局部页面。

要实现“增量更新”只要在数据格式上进行规范,使得提交和合并都简单易行

在此基础上的可以使用"Preload"实现预下载继续优化:


这套系统叫做"Sonic"已经开源了:


关于移动页面框架的一点思考

最后比较了Web和Native:


建议根据具体的应用业务选择合适的框架:


移动网页加速的通用解决方案探讨和实践

遇到的困扰

这里首先介绍了目前困扰大家的“速度低下”的移动网络的现状,这个直接影响到了企业的业务,比如“在1.5s内每慢500ms,就会降低3%的用户点击”,所以如何提升性能,对于站点的意义很大。

业界已有一些解决方案,比如:

对于百度搜索来说,结果页点出效果有很多不足:

框架设计和实现

加速的常用优化手段:

雪碧图是指CSS Sprite,CSS精灵,是一种CSS图像合并技术,将小图标和背景图像合并到一张图片上,然后利用CSS的背景定位来显示需要显示的图片部分。

需要解决的核心问题:



这里可以很清晰的看到,百度是通过解决这四个核心问题来实现加速:

框架设计的核心组成:


可以看到加速框架设计的核心组成,主要是三部分:

加速原理

网络连接优化
CDN(Content Delivery Network)实际上是通过摆放节点服务器是的在现有互联网基础上形成了一个虚拟网络,可以通过智能分析更好的平衡网络请求,使用CDN来优化网络连接应该算是一种比较通用的方法了。

静态自适应布局
根据不同设备的具体情况,自动布局,对百度这种公司来说,面向的用户来自互联网的不同角落,使用的设备也是各式各样,自适应布局非常重要。

首屏
优先加载首屏资源,特别对于可见资源要有限加载,不可见资源只是在触发是加载,对于非首屏资源,不加载,直到进入可视区域。

资源缓存
包括图片、脚本、字体文件等,所有资源都采用统一cache域名。

资源加载顺序控制
根据组件的生命周期和加载优先级合理调配,就像上菜一样,菜没上,先上一碗饭就不好了。

Pre-rendering
预渲染页面,预先取得加速框架的JS/CSS等

图片优化
图片占整体资源的比例达60%,使用Guetzli压缩,使用WEBP格式

开发工具集

也开源了。

比较

对比我们自己的情况:客户因为是面向企业的,所以机器的类型固定,相对可以现在在高端;Native的内容居多,页面依赖较少;不需要经常性的实时更新。

上一篇下一篇

猜你喜欢

热点阅读