FCP 第一绘画内容

1 .第一绘画内容，度量标准从页面开始加载到频幕上呈现页面内容的任何部分的时间，文本，图像，svg元素，非白色canvas元素都算
2 .js测量

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntriesByName('first-contentful-paint')) {
    console.log('FCP candidate:', entry.startTime, entry);
  }
}).observe({type: 'paint', buffered: true});

3 .为了提供良好的用户体验，网站应努力使First Contentful Paint在加载页面的1秒内发生。为确保您达到大多数用户的这一目标，衡量移动设备和台式机设备的页面加载量的第75个百分位是一个很好的衡量标准

最大绘画内容

1 .测量从页面开始加载到屏幕上最大的文本块或图像元素被渲染为止的时间
2 .较旧的指标（例如 load或 DOMContentLoaded） 不好，因为它们不一定与用户在屏幕上看到的相对应。
3 .为了提供良好的用户体验，网站应努力在页面开始加载后的前2.5秒内进行“最大内容绘画”
4 .为“最大内容绘画”报告的元素的大小通常是用户在视口中可见的大小。如果元素延伸到视口之外，或者任何元素被裁剪或具有不可见的 溢出，则这些部分不会计入元素的大小
5 .为了使计算和分配新性能条目的性能开销保持较低，对元素大小或位置的更改不会生成新的LCP候选对象。仅考虑元素的初始大小和在视口中的位置，这意味着可能不会报告最初在屏幕外渲染然后在屏幕上过渡的图像。这也意味着最初在视口中渲染的元素随后被下推，但视线外仍然会报告其初始的视口大小
6 .js测量

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('LCP candidate:', entry.startTime, entry);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

7 .服务器响应时间慢
渲染阻止的JavaScript和CSS
资源加载时间
客户端渲染

FID

1 .测量从用户首次与您的网站进行交互，当他们点击链接，或使用自定义的js驱动的控件到浏览器真正能够访问之间的时间
2 .首次输入延迟（FID）是一种重要的以用户为中心的度量，用于衡量 负载响应能力， 因为它可以量化用户尝试与无响应页面进行交互时的体验-低FID有助于确保页面 可用
3 .为了提供良好的用户体验，站点应努力使首次输入延迟小于100毫秒
4 .由于浏览器的主线程正忙于执行其他操作，所以会发生输入延迟（又称输入延迟），因此它（尚未）响应用户。发生这种情况的一个常见原因是浏览器忙于解析和执行由您的应用加载的大型JavaScript文件。在执行此操作时，它无法运行任何事件侦听器，因为正在加载的JavaScript可能会告诉它执行其他操作
5 .FID测量接收输入事件与下一次主线程空闲之间的增量。这意味着即使在未注册事件侦听器的情况下，也将测量FID
6 .FID是一种度量页面加载过程中响应度的指标。因此，它仅关注来自离散操作（例如单击，轻敲和按键）的输入事件.其他交互（例如滚动和缩放）是连续的动作，并且具有完全不同的性能约束（而且，浏览器通常能够通过在单独的线程上运行它们来隐藏其延迟）
7 .js检测

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const delay = entry.processingStart - entry.startTime;
    console.log('FID candidate:', delay, entry);
  }
}).observe({type: 'first-input', buffered: true});

8 .解决

1 .感觉react框架应该有做优化。
2 .分手长期任务.将长时间运行的代码分解为较小的异步任务
3 .检查第三方脚本的执行
4 .使用webworker执行部分代码
5 .https://github.com/GoogleChromeLabs/comlink 第三方库
6 .延迟未使用的JavaScript 

TTI

1 .TTI度量标准衡量从页面开始加载到其主要子资源加载之间的时间，它能够快速可靠地响应用户输入
2 .为了提供良好的用户体验，在一般的移动硬件上进行测试时，网站应努力使互动时间少于5秒。

TBT

1 .“总阻塞时间”（TBT）度量标准度量了“第一内容油漆（FCP）”和“交互时间”（TTI）之间的总 时间， 在该时间中，主线程被阻塞足够长的时间以防止输入响应
2 .只要存在长任务，该主线程即被视为“阻塞”，该任务在主线程上运行超过50毫秒（ms）。我们说主线程“被阻止”是因为浏览器无法中断正在进行的任务。因此，如果用户确实在较长的任务中间与页面进行交互，则浏览器必须等待任务完成才能响应
3 .如果主线程至少有五秒钟没有执行长任务，则TTI认为页面“可靠地交互”
4 .为了提供良好的用户体验，在一般的移动硬件上进行测试时，站点应努力使总阻止时间小于300毫秒
5 .好像还要学习下如何阅读lighthouse的报告

CLS

1 .CLS会测量页面整个生命周期中发生的每个 意外布局转移的所有单独布局转移分数的总和
2 .甲布局移发生的任何时间的可见元素改变其从一个所再现的帧到下一个位置
3 .为了提供良好的用户体验，网站应努力使CLS分数小于0.1
4 .请注意，仅当现有元素更改其起始位置时，才会发生布局转换。如果将新元素添加到DOM或现有元素更改了大小，则只要更改不会导致其他可见元素更改其起始位置，该元素就不会算作布局偏移
5 .并非所有的布局转换都是不好的。实际上，许多动态Web应用程序经常更改页面上元素的开始位置，仅当用户不期望布局转换时，它才是不好的。另一方面，响应于用户交互（单击链接，按下按钮，在搜索框中键入内容等）而发生的布局偏移通常很好，只要该偏移发生在与交互关系足够近的位置即可向用户清除
6 .js测试

let cls = 0;

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    if (!entry.hadRecentInput) {
      cls += entry.value;
      console.log('Current CLS value:', cls, entry);
    }
  }
}).observe({type: 'layout-shift', buffered: true});

7 .改善

1 .**请务必在图片和视频元素上包含size属性，否则请使用[CSS宽高比框](https://css-tricks.com/aspect-ratio-boxes/)保留所需的空间。**这种方法可确保在加载图像时浏览器可以在文档中分配正确的空间量。请注意，您也可以使用[unsize-media功能部件策略](https://github.com/w3c/webappsec-feature-policy/blob/master/policies/unsized-media.md) 在支持功能部件策略的浏览器中强制执行此行为
2 .除非响应用户交互，否则切勿在现有内容上方插入内容。这样可以确保可以预期发生任何版式移位
3 .首选将转换动画替换为触发布局更改的属性动画。对过渡进行动画处理，以提供状态与状态之间的上下文和连续性。
4 .无尺寸的广告，嵌入和iframe ，尽量避免
5 .### 嵌入和iframe [＃](https://web.dev/optimize-cls/#embeds-and-iframes)

可嵌入的窗口小部件使您可以在页面中嵌入可移植的Web内容（例如，来自YouTube的视频，来自Google地图的地图，社交媒体帖子等）。这些嵌入可以采用多种形式
6 .### 动态内容📐 [＃](https://web.dev/optimize-cls/#dynamic-content)

**摘要：**除非响应用户交互，否则请避免在现有内容之上插入新内容。这样可以确保可以预期发生任何版式移位
7 .### 导致FOUT / FOIT的Web字体📝 [＃](https://web.dev/optimize-cls/#web-fonts-causing-foutfoit)

下载和呈现Web字体可以通过两种方式引起布局变化：

*   后备字体替换为新字体（FOUT-未样式化文本的闪烁）
*   显示“不可见”文本，直到呈现新字体为止（FOIT-不可见文本闪烁）

 。### 动画🏃‍♀️ [＃](https://web.dev/optimize-cls/#animations)

**摘要：**不想`transform`动画性质触发布局改变的动画。

对CSS属性值的更改可能需要浏览器对这些更改做出反应。许多值触发重新布局，绘制和合成，例如`box-shadow`和`box-sizing`。可以以不太昂贵的方式更改许多CSS属性

优化js加载

1 .如果遇到无法响应摇树的顽固库，请查看该库是否使用ES6语法导出其方法。如果它以CommonJS格式（例如module.exports）导出内容，则该代码不会被webpack摇晃。一些插件为CommonJS模块提供了摇树功能（例如 webpack-common-shake），但这只能达到某些您无法摇晃的CommonJS模式的程度。如果您想可靠地摆脱应用程序中未使用的依赖项，则应继续使用ES6模块

离线存储

1 .总的来说，依照兼容性和异步这俩关键标准，indexDB是最适合做离线存储的方式
2 .

优化关键路径渲染

1 .通过优化关键路径渲染，可以缩短首次渲染时间。
2 .构建模型对象

1 .浏览器渲染页面前需要先构造dom树和CSSOM树，所以我们需要尽快保证将HTML和CSS都提供给浏览器
2 .parse HTML 这个是将一堆HTML字符转换成DOM树的时间
3 .Recalculate Style 这个是渲染css花费的时间

full-process.png

3 .构建渲染树

1 .从DOM树的根节点开始遍历每个可见节点，某些节点不可见，不会体现在渲染输出中，所以会被忽略
2 .某些节点通过css隐藏，所以在渲染树种也会被忽略
3 .对于每个可见节点，为其寻找适配的CSSOM规则并应用他们
4 .发射可见节点，连同内容和计算的样式

4 .知道了有哪些节点和他们的计算样式，这个时候就应该计算他们在设备视口的确切位置和大小了
5 .将渲染树种的每个节点转换成屏幕上的实际元素

阻塞渲染的css

1 .默认情况下，css被视为阻塞渲染的资源，这就意味着浏览器将不会渲染任何已经处理的内容，除非cssOM构建完毕
2 .所以要精简css，尽快提供css资源，并利用媒体类型和查询来解除对渲染的阻塞
3 .如果我们有一些 CSS 样式只在特定条件下（例如显示网页或将网页投影到大型显示器上时）使用，又该如何？如果这些资源不阻塞渲染，该有多好

<link href="style.css" rel="stylesheet">
<link href="print.css" rel="stylesheet" media="print">
<link href="other.css" rel="stylesheet" media="(min-width: 40em)">

4 .声明您的样式表资产时，请密切注意媒体类型和查询，因为它们将严重影响关键渲染路径的性能

使用js添加交互

1 .js可以查询和修改DOM和CSSOM
2 .js执行将会阻止cssom
3 .除非将js显示声明为异步，不然他会阻止构建DOM
4 .我们的脚本在文档的何处插入，就在何处执行。当 HTML 解析器遇到一个 script 标记时，它会暂停构建 DOM，将控制权移交给 JavaScript 引擎；等 JavaScript 引擎运行完毕，浏览器会从中断的地方恢复 DOM 构建
5 .简言之，JavaScript 在 DOM、CSSOM 和 JavaScript 执行之间引入了大量新的依赖关系，从而可能导致浏览器在处理以及在屏幕上渲染网页时出现大幅延迟
6 .JavaScript 执行会“阻止解析器”：当浏览器遇到文档中的脚本时，它必须暂停 DOM 构建，将控制权移交给 JavaScript 运行时，让脚本执行完毕，然后再继续构建 DOM。我们在前面的示例中已经见过内联脚本的实用情况。
7 .向script 标记添加异步关键字可以指示浏览器在等待脚本可用期间不阻止DOM 构建，这样可以显着提升性能。

时间戳

1 .domloading:这个整个过程的起始时间戳，浏览器即将开始解析第一批收到的HTML文档字节
2 .domINteractive:表示浏览器完成对所有HTML的解析并且DOM构建完成的时间点
3 .domContentLoaded:表示DOM准备就绪并且没有样式表阻止js执行的时间点，意味着现在可以构建渲染树了
4 .domComplete:所有处理完成，并且网页上的所有资源都以下载完毕。
5 .loadEvent:网页加载的最后一步，浏览器会触发onload事件
6 .

优化关键渲染路径

1 .从以下几点因素来操作
2 .关键资源的数量
3 .关键路径的长度：关键路径长度受所有关键资源与其字节大小之间依赖关系图的影响：某些资源只能在上一资源处理完毕之后才能开始下载，并且资源越大，下载所需的往返次数就越多
4 .关键字节的数量
5 .JavaScript 资源会阻塞解析器，除非将其标记为 async 或通过专门的 JavaScript 代码段进行添加

http2

1 .https://hpbn.co/http2/
2 .h3-Q050 google还是猛啊，直接使用http3协议

1 .减少了 TCP 三次握手及 TLS 握手时间
2 .解决多路复用丢包时的线头阻塞问题
3 .优化重传策略
4 .流量控制
5 .连接迁移
6 .弱网环境好像也不行
7 .chrome-extension://ikhdkkncnoglghljlkmcimlnlhkeamad/pdf-viewer/web/viewer.html?file=https%3A%2F%2Fpic.huodongjia.com%2Fganhuodocs%2F2018-04-28%2F1524906080.9.pdf 微博的分享
8 .Caddy + Quic 
9 .客户端⼀一般选⽤用⾕谷歌chrome cronet库