tl;dr:
想要保持页面的快速运行，你需要仅加载当前页面所需的 JavaScript 代码。优先考虑用户所需，之后运用代码分离懒加载其他内容。
Is it happening - 在这个时期，你可以开始往屏幕上分发内容（页面是否开始跳转？服务端是否开始响应？）。
Is it useful - 在这个时期，你已经完成了文本或内容的绘制，并允许用户从其中获取价值与有用信息。
Is it usable - 在这个时期，用户可以与页面进行实际操作，并能产生一些有意义的交互。
页面交互性解释与建议
JavaScript 的实际成本所在，则不得不说说的浏览器的线程。当浏览器在处理你在 JavaScript 中定义的各种事件时，它可能同时在该线程上还在处理用户的输入，而这就是我们所说的主线程。
通过 WebPageTest 和 Lighthouse (源)测得到移动端 Google News 的 Time-to-Interactive 数据显示，不同机型在完成交互性上存在巨大差异，高端机型需花费7秒才能让页面具备交互性，而针对同一场景低端机型则需要55秒之久。我们都希望页面的可交互性可以越快越好，但怎样为交互性定义一个好的目标呢？
当我们在浏览器中输入一串 URL，实际都发生了些什么？
当一个请求发送给了服务端，它会返回一些标记文件。之后，浏览器则解析这些标记（通常是 HTML），并从中找到必要的 CSS，JavaScript 与图片资源引用，然后向服务端再次获取这些额外资源并处理。
橙色代表的是解析 JavaScript 所用的时间，黄色代表的是编译耗时。两者加到一起占了大部分页面 JavaScript 执行的30%的时间。
并不是所有网站都需要在2G网络或者低端机型上表现良好，这取决于你的实际用户群，这也是当下大家一直都在说的“用数据说话”。但请记住，即便高端机型用户也可能会遇到弱网环境，所以 JavaScript 下载时间至关重要，请善用压缩技术
// 优化前
import OtherComponent from './OtherComponent';
const MyComponent = () => (
<OtherComponent/>
);// 优化后
import Loadable from 'react-loadable';
const LoadableOtherComponent = Loadable({
loader: () => import('./OtherComponent'),
loading: () => <div>Loading...</div>,
});
const MyComponent = () => (
<LoadableOtherComponent/>
);PRPL 即推送，渲染，预缓存和懒加载。结合 service worker 使用更加。例如这周给师兄完善 PWA Demo 的一个小功能时，就用到了 React 在服务端渲染时采用的 renderToString 方法，在这个过程中，就是利用 HTML 在未加载 JavaScript 等资源的情况 下使用 App Shell 优化页面首次访问时的白屏体验。还挺有意思，有时间可以细说一下这个事。
监控
Long Tasks — 利用这个 API 你可以收集那些耗时超过50毫秒、可能会阻塞主线程的任务（及其脚本），并将其数据记录用于后续分析
First Input Delay (FID) 是一个度量标准，用于衡量用户首次与你的网站互动（即点击按钮时）到浏览器实际能够响应该互动的时间。虽然它还是一个新标准，但已经有 polyfill 实现。