先来看下H5页面的渲染经过：
使用服务端渲染方式，即前端看不到页面接口请求的页面加载顺序如下：
访问一个页面url，浏览器开始进行dns解析，找到域名对应ip的前端服务器。进行tcp/ip连接的握手，连接建立后，服务器通过访问的路由获取html文件，并请求接口获得接口数据，将两者拼接在一起。
将页面传输到客户端浏览器端，浏览器通过页面源代码读取出需要加载的静态资源。
进入静态资源加载和页面渲染过程。静态资源主要包括js、css、图片等。css资源的加载是否完成关系页面是否可以开始渲染。
首屏时间，首屏时间直接关系到用户所感知到的页面打开速度。基于下面的案例，首屏时间基本由html的document、穿插的2个js加载时间、3个css加载时间、4个穿插的js加载时间、最后一个css加载时间相加得到，累计3497ms。远未达到页面秒开的速度。这里要说明的一点是：js的加载会打断css的加载，css加载的打断会影响渲染树的构建，因此js的穿插在这里显得比较随意。如果看到js加载穿插在css资源之前，可作为页面速度优化的一项。
看到中间有个css文件的加载时间拉的很长，这里要注意到，静态资源如果放在不同域名下，会造成dns解析时间的增加。因为如果一个页面的资源都在相同域名下，是不需要多次dns解析的。
再来解读一下html文件的为例的时间消费状态：
queued at 开始排队时间
started at 开始时间
queueing 排队（started at-queued at）
stalled 停滞
chrome一次性只能处理6个tcp请求。其他的请求必须等待6个请求完成，这个等待时间是构成stalling的主要部分，所以说，前端开发时候，要使用cdn，要减少同一个域名下的tcp请求。通过不同地区ping一个域名查看ip地址是否不同来确认是否开启cdn加速 netstat查看tcp连接状态
DNS Lookup 域名解析所耗时间
Initial connection 初始化连接时间，一般指tcp三次握手时间
SSL https特有，一种协议
request sent 请求发送时间
waiting（ttfb） 首字节时间
第一字节的时间= DNS解析的时间+socket三次握手时间+http请求时间+第一字节返回的时间，如果这里时间较长，要考虑是否接口交互速度慢还是前端在服务端的工作机制较慢导致的。
其他优化点：
移动端webview初始化时机（内核预加载、打开webview与dns解析、h5页面html文件请求同步进行。）
后端接口调用网关状况、sql查询快慢、是否存在第三方业务调用
tcp/ip 最大连接数（静态资源的数量，决定了是否有资源需要排队，chrome一次最多6个？）
排队时间（根据一次最大连接数给出资源加载优先级并根据优先级进行加载？）
连接建立机制（是否保持长连接）
缓存机制（强制缓存/协商缓存机制，注意客户端和服务器时间同步问题）
资源域名来源是一个还是多个？dns解析数量
get和post请求的区别（get是一次请求，post是2次请求）
是否每个静态资源的请求都带上了不需要带的cookies（有些资源和实际业务在同一个域名下）
公共资源的预加载及共用机制
layout（Reflow）与Repaint，优先使用repaint