网站客户端的演进

发布：2018-11-29 17:09:22 浏览：3589

客户端主要有两种选择:一种是基于浏览器HtML5页面的，一种是Native模式的。到底是选择HTML5还是Native，Native如何解决快速迭代问题?

1.是Native还是HTML5

当前移动端主要还是以Native实现为主，从用户体验角度来考虑，Native的实现要比HTML5更流畅，同时Native还可以基于本地做很多在浏览器里不能做的优化，如大数据的存储、可以定制的通信协议、更方便地保持长连接以及更容易实现的实时消息推送。

当然HTML5也有无法比拟的优势，比如客户端更轻量级、服务端发布更迅速、不需要用户升级版本等。长期来看，移动端是否会像早期PC那样从富客户端转向浏览器呢?笔者觉得未必，理由如下。

首先，相比HTMLS，Native实现性能优势更好。当前移动端都在追求极致体验，App无疑会比HTMLS有更多的优势；其次，移动端屏幕较小，基于网页的交互和App相比还有很多限制。最重要的是，不同的商家会主推带有品牌标识的App还是会向统一-的浏览器靠拢?从目前的趋势看，App会是手机端上争夺的重点，所以笔者推测直接基于手机端的浏览器的应用不会成为主流的前端。

2.HTML5的页面优化

HTMLS页面优化一般可以从以下几个地方人手。

第一，CSS内联异步加载。如果页面中有内容要依赖CSS的加载，很多时候就会出现白屏一这其实就是CSS阻塞了加载，CSS出不来就导致看不到首屏。CSS内联加载可以节省异步HTTP请求，CSS内联异步加载后可以大大缓解白屏问题。不过，就算内联以后也要观察异步CSS文件的大小，并且异步之后要观察domReady的时间变化。当然CSS内联也有可能会导致repaint和reflow的问题，并且由于异步内容增大，服务端的性能开销也会增加。

第二，其他的优化。端上的优化已经有一整套的优化方法列表了，这里介绍一些我们在实践中发现并验证过的一些特别的优化点，如assets合并、整合页面中inline的JSICSS到外部文件、将iframe改为JSONP调用、背景图合并和将非首屏内容加载改为异步等。

第三，bigpipe首屏加载。2012年的时候，Facebook有一个比较火的技术叫bigpipe，可以提升页面的首屏加载效果，于是我们尝试过采用类似的技术测试首屏的加载效果，

点击链接http://www.webpagetest.org/video/compare.php?tests=140318M5_7GV%2C140318Z27CJ&thumbSize=200&ival=100&endfull，可以通过webpagetest看到页面的优化效果。

3.Cookie压缩

在无线场景下要额外注意Cookie，如果没有留意，它可能会占用你一次无线请求下的大部分内容，而且有可能并不会让你察觉，所以有必要对Cookie进行压缩测试。Cookie是在HTTP的头部，通常的gzip和deflate都是针对HTTPbody的压缩但并不能压缩Cookie，要想对Cookie做压缩测试必须单独处理，压缩方式是将Cookie的多个K/V对看成普通的文本，进行文本压缩。

4.URL短域名

URL短域名也很好理解，如果无线数据传输中有大量的域名，而域名又比较长，就会产生很多无谓的数据传输，最典型的应用像微博的hp://.cn，可以节省很多字节。但是像这种直接使用真实的t.cn的短域名是比较奢华的办法，比较简单的是使用约定的标签替换，在解析时再替换回去。

5.CDN前置缓存

在有大量静态数据请求的页面中使用CDN前置缓存对网站的加速访问非常有效。对比分析了杭州主站和CDN上的两张图片，一张是空图片，一张是50KB大小的图片。空图片用于测试RTT，50KB的图片用于测试网速。

6.如何实现端的快速迭代

前面介绍了无线场景下端的优化措施，那么当我们使用Native来实现时，遇到的一个问题是基于App的Native如何解决客户端更新和服务端的快速迭代问题，一-般有两种思路:一种是客户端用同-一种技术开发，然后通过工具编译技术把它编译成不同平台，上能够执行的代码，如当前的ReactNative；另一种思路是将客户端中经常需要更新的模块做成动态推送的，用模板+数据的方式，在不同的客户端平台上实现一个小的解析引擎来实现快速个性化的定制。

那么再说回来，基于前面的这些推断，网站建设多终端和服务端交互主要是以数据+模板的方式为主，那么服务端提供格式化的数据将成为必然选项。所以涉及的问题就是服务端既要提供格式化的数据(HTTPJOSN数据)，又要支持传统的PC的方式:基于JOSN数据渲染出HTML页面。我们在后面会进一步介绍如何解决无线和传统PC之间的这种差异。