前因
本来这篇想写一下CSS选择器的性能优化，但是写着写着就发现相关的知识点非常的多，需要查阅很多资料才能学透彻然后完成写作，所以打算慢下来研究。在查询资料的过程中又用到了developers.google.com这个网站，其实之前研究其他知识的时候就大致的浏览过，觉得里面的内容很有价值对基础知识有一个详细的总结，本打算之后有时间系统的学习一下。目前正好趁研究Performance的这个机会把相关的章节做一下学习整理。我会针对Web fundamentals里性能部分的所有知识点写一系列的文章，但具体的章节划分还要根据空闲时间来考量。
Performance Overview
对应页面：https://developers.google.com/web/fundamentals/performance/
Web性能优化基础目录.PNG
从目录中可以看到Performance这部分包含了非常多的知识点，尤其是对渲染这块进行了详细的说明。在此页面的相关资源处还包括Chrome DevTool的文章和一些Udacity的课程，并且Codelab部分使用一个网页游戏作为例子指导进行了实际的优化。
Measure Performance with the RAIL Model
对应页面：https://developers.google.com/web/fundamentals/performance/rail
什么是RAIL Model
RAIL指的是以用户为中心的性能模型，分别对应Response, Animation, Idle, Load这四部分。
主要知识点
- Focus on the user
以下的数据展示了在不同delay时长内用户的不同体验- 0 ~ 16ms
用户不喜欢无意义的等待，比如loading page，我们的网页如果要让用户感到顺畅，需要在每秒钟完成60帧的渲染。也就是每帧大概耗费16ms。 - 0 ~ 100ms
在用户操作后小于100ms的响应是让用户感觉平顺的reaction - 100 ~ 300ms
如果delay在这个时间范围内，用户是可以细微察觉到的 - 300 ~ 1000ms
这会给人一个正在运行的任务的感觉，比如加载页面和改变视图 - 1000+ms
超过1s会使用户开始不专注于当前的工作 - 10,000+ms
非常差的用户体验，可能导致用户流失
- 0 ~ 16ms
- Respond to users immediately - 100ms
根据上面的数据，为了避免让用户感到停顿感，我们要把对用户输入的响应控制在100ms以内。充分利用这100ms做重要的事情，如果可以的话，在后台运行一些运算。对于大于500ms才能完成的任务，最好提供反馈或提示。 -
Animating/Scrolling, produce a frame in under 10ms
Animation process.PNG
动画的每一帧都要经历五个部分，但是我们只有大约16ms来完成每帧，再刨除浏览器的额外运行时间，每帧需要在10ms内完成。所以我们要充分利用用户输入等待回应的100ms来提前进行重要的计算来完成平滑动画的体验。
- Maximize main thread idle time
充分利用闲置时间(idle time)来完成deferred的任务。使用最小的必要数据集来启动你的应用，使用之后的空闲时间来加载剩下的数据。此外为了实现100ms以内的响应，需要把主线程工作切割成50ms的块，这样才可以响应并处理用户的操作。如果用户在交互操作，那么最优先的就是响应用户的操作。
例子：
目前在做的关于一个entity窗口的显示方式的改变就与这种方式相同。原先是加载了所有的entity数据并更新到相应的位置之后才显示窗口，这样会让用户有比较明显的等待时间。而更新后的逻辑则采用最小集的窗口启动数据先显示窗口，再统一的加载和应用其他数据。这样可以用户点击链接后的窗口响应时间缩减到1s左右。 - Keep user engaged; deliver interactive content in under 1000ms
加载网站应该控制在1s以内，这个结果可以通过渐进的渲染完成，即先加载最重要的数据，在空闲时间再加载其他内容。主要关注在优化最佳渲染路径(以后的文章会进一步说明)来防止渲染阻塞。
Summary
Web性能优化基础总结.PNG
