研究显示，任何超过1秒的延迟都将打断用户的思维流畅状态，带来不好的体验，从而流失客户，我希望做的是不论在任何设备和网络环境下都要保持网页的流畅性，提供更好的体验。
想要满足，一秒的预算可不是那么容易，但幸运的是，我们可以在一秒内完成可见区域的渲染，让用户尽快可以与页面互动。可以当在用户和页面互动时，在后台持续加载剩余页面。
DNS Lookup (200 ms)
TCP Connection (200 ms)
HTTP Request and Response (200 ms)
DNS 查询 (200 ms)
TCP 连接 (200 ms)
HTTP 请求与响应 (200 ms）
在移动页面上达到“首屏秒开”的准则，则会碰到不同网络环境的挑战，可能用户正在以 2g/3g/4g的环境来访问你的网站，移动网络的延迟明显高于有限链接，并将消耗我们一秒内首屏秒开的预算
不同网络环境下，访问速度不同
以下3g/4g的网络传输率
200-300 ms roundtrip times for 3G networks
50-100 ms roundtrip times for 4G network
你要明白，你的主流用户依然是3g，我们不得不把3g每次网络访问的消耗时间，假设为200ms
明白了这一点之后，我们来倒推一下时间。如果我们来分析一下浏览器与服务器之间一次典型的通信过程，会发现 600 ms 的时间就已经被网络本身消耗掉了：一次 DNS 查询用于将主机名（比如 google.com）解析为 IP 地址，一次网络往返用于发起 TCP 握手，以及最后一次完整的网络往返用于发送 HTTP 请求。我们就只剩下 400 ms 了！
建立请求1秒已消耗600ms
DNS Lookup (200 ms)
TCP Connection (200 ms)
HTTP Request and Response (200 ms)
DNS 查询 (200 ms)
TCP 连接 (200 ms)
HTTP 请求与响应 (200 ms)
这600ms是不可避免的3g网络消耗，对此无能为力。
————————————分割线
服务器必须在200ms内渲染出响应内容
除去网络延迟后，仍有400ms的时间以供我们进行优化，服务端必须渲染出相应内容，客户端应用程序代码必须执行，而且浏览器要完成内容的布局和渲染。服务器响应时间就是除去网络传输时间之后，一台服务器首先会返回HTML所花费的时间。因为我们剩下的时间太少了，这个时间应该控制在最低限度，理想程度应该控制在200ms以下，越少越好。
—————————————分割线
最大程度减少重定向次数
在开发中最大可能的减少HTTP重定向次数，因为每一次重定向会额外的增加网络往返1次或者2次（如果再次查询dns则是两次）在3g网络上将会导致几百毫米的延迟，如果需要，尽量避免重定向到二级域名。
—————————————分割线
首次渲染网络返回的渲染次数应该减到最少
由于TCP评估链接状态方面采取了一种特殊机制 （参见TCP慢启动）一次全新的TCP链接无法一次用满客户端和服务器之间的全部有效带宽，这种情况下，服务器在首次网络往返中，通过一个人新的链接（约14kb）最多发送10个TCP包，必须等待客户端应答这些数据才可以增加它的拥塞窗口并且继续发送数据，因为考虑到TCP的这种行为，所以优化你的内容就显得十分重要，完成页面首次渲染所需的网络往返次数应减到最少，首屏内容应该不大于14kb，这样浏览器在一次网络往返后就可以绘制页面，还有记得服务器软件要升级到最新版本，否则你的数据包上限可能只有3～4个。