关于页面响应时间，有一个著名的“2-5-8原则”。当用户访问一个页面时：当他们在2秒内得到响应时，他们觉得系统响应很快；当他们在2-5秒之间得到响应时，他们觉得系统的响应速度还可以；当他们在5-8秒内得到响应时，会感觉系统的响应速度很慢，但是可以接受；而当超过8秒仍未收到响应时，用户会觉得系统很糟糕，然后选择离开站点，或者发起第二次请求。一个网站要想抢到用户，网站的速度和稳定性首当其冲。从各种前端监控平台，可以获取到页面上的大量性能指标。本文将介绍几个关键指标，并给出相应的优化思路。开始渲染时间这个时间点表示浏览器开始绘制页面。在此之前，页面是白屏，所以也称为白屏时间。这个时间点可以用公式TimeToStartRender=TTFB(TimeToFirstByte)+TTDD(TimeToDocumentDownload)+TTHE(TimeToHeadEnd)来表示。其中，TTFB表示从浏览器发起请求到服务器返回第一个字节的时间，TTDD表示从服务器加载HTML文档的时间，TTHE表示完成解析文档头所需的时间。在高级浏览器中有相应的属性来获取这个时间点。Chrome可以通过chrome.loadTimes().firstPaintTime获取，IE9+可以通过performance.timing.msFirstPaint获取。在不支持的浏览器中，可以根据上述公式获取header资源加载的时间，模拟得到一个近似值。开始呈现时间越快，用户越早看到页面。这个时间点的优化包括：1)优化服务器响应时间，尽快在服务器端输出2)减小html文件的大小3)减少header资源，将脚本放在body中作为muchaspossible尚未加载，用户与页面的交互此时已经可用。可以用公式TimeToDomReady=TTSR(TimeToStartRender)+TTDC(TimeToDomCreated)+TTST(TimeToScript)来表示。上面已经介绍了TTSR，TTDC代表的是创建DOM树所花费的时间。TTST代表BODY中所有静态脚本的加载和执行时间。在高级浏览器中，有一个DOMContentLoaded事件对应。MDN上描述DOMContentLoaded事件的文档如下。DOMContentLoaded事件在文档完全加载和解析时触发，无需等待样式表、图像和子框架完成加载（加载事件可用于检测完全加载的页面）。详细规范可以在W3C的HTML5规范中找到。从MDN文档可以看出，这个事件主要是指DOM文档加载解析完成。看似很简单，但是DOMContentLoaded事件的触发与CSS和JS息息相关。现在有一个专门的术语CriticalRenderingPath（关键渲染路径）来描述，在【KeyRenderingPath】一文中详细介绍了关键渲染路径对DOMContentLoaded的影响。在不支持DOMContentLoaded事件的浏览器中，可以通过模拟得到近似值。主要模拟方法有：1）低版本webkit内核浏览器可以轮询document.readyState2）ie可以通过setTimeout方法不断调用documentElement的doScroll，直到可以使用，具体实现方法可以参考主流框架的实现（jquery等）。DOMReady时间点意味着用户可以和页面进行交互，所以越早越好，这个时间点的优化包括：1）降低DOM结构的复杂度，尽可能少的节点，不要嵌套过深2）优化关键呈现路径的首屏时间该时间点表示用户看到首屏页面的时间。这个时间点很重要，但很难获得。一般只能通过模拟得到一个大概的时间。一般的模拟方法有：1）不断获取屏幕截图，当屏幕截图不再变化时，可以认为是首屏时间。可以参考webPagetest的SpeedIndex算法；2）一般影响首屏的主要因素是图片的加载。页面加载完成后判断图片是否在首屏，最慢的可以认为是首屏时间。当然，还需要考虑其他细节。具体可以参考【7天搭建一个前端性能监控系统】这个时间点的优化包括：1）页面首屏的显示尽量不依赖js代码,js放在domReady中后执行或加载2）延迟加载首屏外的图片3）首屏结构尽量简单，首屏外的css可以onload加载以延迟的方式。这个时间点就是开窗的时候。给用户最明显的感受就是浏览器标签页加载状态结束。这个时间点的优化方法是：1）减少资源请求次数和文件大小2）将未初始化的脚本放到onLoad中，在onLoad之后执行3）异步加载不需要同步的脚本以便优化整个站点的性能，可以考虑在页面onload的时候做一些预加载，预加载其他页面需要的资源。
