网页性能优化

[yangbin1994]

发生了什么让你觉得页面卡顿了？

当你对着电脑屏幕什么也不做的情况下，显示器也会以每秒60次的频率正在不断的更新屏幕上的图像。
如果一个方块，从A位置移动到B位置，以每秒1px的速度，那么也每帧需要移动1 / 60px，如果小于这个总速度，就会出现卡顿的情况。

setTimeout 不太ok

继续上面的题目

setTimeout(() => {
  $box.style.left += 1 / 60 + 'px'
}, 1000 / 60 ≈ 16.7ms)

理想情况下，上面的代码实现的动画很流畅，但是都是知道 setTimeout 只有在主线程空闲的情况下，才会执行，所以可能执行间隔大于16.7ms，那么刷新频率一致的情况下，就会出现卡顿的感觉。

requestAnimationFrame 这个不错！

与 setTimeout 相比，requestAnimationFrame 最大的优势是由系统来决定回调函数的执行时机。它能保证回调函数在屏幕每一次的刷新间隔中只被执行一次，这样就不会引起动画对象丢帧的现象。

callback 函数也很重要呀

有了 requestAnimationFrame，可以保证动画执行时机了，但是如果动画的渲染时间特别长怎么办。。。长到超过了一帧间隔16.7ms，还是会很卡，见下图

具体优化方式参考 网页性能管理详解

[yangbin1994]

什么时候请求返回304？

如果A向B要东西，来看A的视角，如果我第一次要，直接传达请求就行，如果大于1次，则传达请求的同时带上上一次请求得到的元信息；来看B的视角，如果收到请求，判断是否第一次发送，如果是的话就直接返回A想要的东西，如果附带了元信息，则先看一下元信息描述的资源更新时间是否小于当前资源最后更新时间，如果是，就返回新资源，并附带更新时刻元信息，如果一致，则告诉A资源没有变化，用以前的就行了如果大于的话，就告诉A你时间有问题，给你东西的同时做出一些调整。

上述步骤，如果资源没有发生改变服务器就是以304的形式告知客户端。

A向B请求的时候，每次都要进行资源更新检查，只有在资源体量巨大的情况的下，才能体现出高效。进一步优化是，B向A返回资源的同时，很自信的告诉A，如果在接下来的一个星期里，你再次请求相同资源，直接用缓存里的就行了，因为这一个星期，我保证不更新！这样的话，就节省了请求检查时开销。

PS：要保证操作资源的一致性，不然更新时间的比较没有意义。

资料参考：rccoder/blog#12