最好用的vue图片,vue图片网站

image.png

image.png

于是针对这些优化建议，我们需要做一些常规的优化：

1. 减少未使用的javascript
2. 移出阻塞渲染的资源
3. 图片质量压缩
4. 限制使用字体数量，尽可能少使用变体
5. 优化关键渲染路径：只加载当前页面渲染所需的必要资源，将次要资源放在页面渲染完成后加载

我们知道lighthouse 中有六个性能指标，而在这六个指标中，LCP、 FCP、speed index、 这三个指数尤为重要，因为在一般情况下 这个三个指标会影响 TTI、TBT、CLS 的分数

所以在我们在优化时， 需要提高LCP、 FCP和speedIndex 的分数，经过测试， 即使是空页面也会有时间上的损耗， 初始分数基本都是0.8秒

注意：需要值得大家注意的是，我们当前所有测试全部建立在，移动端（之所以用移动端，是由于pc 的强大算力，很少有性能瓶颈）的基础上,并且页面上必须有一下内容，才能得出分数，内容必须包括一下的一种或者多种

• 内嵌在svg元素内的image元素
• video元素（使用封面图像）
• 通过url\(\)[8]函数（而非使用CSS 渐变[9]）加载的带有背景图像的元素
• 包含文本节点或其他行内级文本元素子元素的块级元素[10]。

否则就会有如下错误

image.png

接下来我们就从LCP、 FCP和speedIndex 这三个指标入手

顾名思义就是首次内容绘制，也就是页面最开始绘制内容的时间，但是由于我们现在开发的页面都是spa应用，所以，框架层面的初始化是一定会有一定的性能损耗的，以vue-cli 搭建的脚手架为例，当我初始化空的脚手架，打包后上传cdn部署，FCP 就会从0.8s提上到1.5秒，由此可见vue 的diff 也不是免费的他也会有性能上的损耗。另外，搜索公众号Linux就该这样学后台回复“猴子”，获取一份惊喜礼包。

在优化页面的内容之前我们声明三个前提

1. 提高FCP的时间其实就是在优化关键渲染路径[11]
2. 如果它是一个样式文件（CSS文件），浏览器就必须在渲染页面之前完全解析它（这就是为什么说CSS具有渲染阻碍性）
3. 如果它是一个脚本文件（JavaScript文件），浏览器必须：停止解析，下载脚本，并运行它。只有在这之后，它才能继续解析，因为 JavaScript 脚本可以改变页面内容（特别是HTML）。（这就是为什么说JavaScript阻塞解析）

针对以上的用例测试，我们发现，无论我们怎么优化，框架本身的性能损耗是无法抹除的，我们唯一能做的就是让框架更早的去执行初始化，并且初始化更少的内容，可做的优化手段如下：

1. 所有初始化用不到的js 文件全部走异步加载，也就是加上defer或者asnyc ，并且一些需要走cdn的第三方插件需要放在页面底部（因为放在顶部，他的解析会阻止html 的解析，从而影响css 等文件的下载，这也是雅虎军规的一条）
2. js 文件拆包，以vue-cli 为例，一般情况下我们可以通过cli的配置 splitChunks 做代码分割，将一些第三方的包走cdn，或者拆包。如果有路由的情况下将路由做拆包处理，保证每个路由只加载当前路由对应的js代码
3. 优化文件大小 减少字体包、css文件、以及js文件的大小（当然这些 脚手架默认都已经做了）
4. 优化项目结构，每个组件的初始化都是有性能损耗的，在在保证可维护性的基础上，尽量减少初始化组件的加载数量

5、网络协议层面的优化，这个优化手段需要服务端配合纯前端已经无法达到，在现在云服务器盛行的时代,自家单位一般都会默认在云服务器中开启这些优化手段，比如开启gzip，使用cdn 等等

其实说来说去，提高FCP 的核心只有理念之后两个 减少初始化视图内容和 减少初始化下载资源大小

顾名思义就是最大内容绘制， 何时报告LCP,官方是这样说的

为了应对这种潜在的变化，浏览器会在绘制第一帧后立即分发一个largest-contentful-paint类型的`PerformanceEntry`[12]，用于识别最大内容元素。但是，在渲染后续帧之后，浏览器会在最大内容元素发生变化时分发另一个`PerformanceEntry`[13]。

例如，在一个带有文本和首图的网页上，浏览器最初可能只渲染文本部分，并在此期间分发一个largest-contentful-paint条目，其element属性通常会引用一个<p>或<h1> 。随后，一旦首图完成加载，浏览器就会分发第二个largest-contentful-paint条目，其element属性将引用<img> 。

需要注意的是，一个元素只有在渲染完成并且对用户可见后才能被视为最大内容元素。尚未加载的图像不会被视为"渲染完成"。在字体阻塞期[14]使用网页字体的文本节点亦是如此。在这种情况下，较小的元素可能会被报告为最大内容元素，但一旦更大的元素完成渲染，就会通过另一个PerformanceEntry对象进行报告。

其实用大白话解释就是，通常情况下，图片、视频以及大量文本绘制完成后就会报告LCP

理解了这一点，的优化手段就明确了,尽量减少这些资源的大小就可以了，经过测试，减少首屏渲染的图片以及视频内容大小后，整体分数显著提高，提供一些优化方法：

1. 本地图片可以使用在线压缩工具自己压缩 推荐tinypng.com[15]
2. 接口中附带图片，一般情况下单位中都有对应的oss或者cdn传参配置通过地址栏传参方式控制图片质量
3. 图片懒加载

Speed Index采用可视页面加载的视觉进度，计算内容绘制速度的总分。为此，首先需要能够计算在页面加载期间，各个时间点“完成”了多少部分。在WebPagetest中，通过捕获在浏览器中加载页面的视频并检查每个视频帧（在启用视频捕获的测试中，每秒10帧）来完成的，这个算法在下面有描述，但现在假设我们可以为每个视频帧分配一个完整的百分比（在每个帧下显示的数字）

以上是官方解释的计算方式，其实通俗的将，所谓速度指数就是衡量页面内容填充的速度

image.png

一图胜千言

经过测试，跟LCP相同，图片以及视频内容对于SpeedIndex的影响巨大，所有优化方向，通之前一致，总的来说，只要提高LCP 以及FCP 的时间SpeedIndex 的时间就会有显著提高

不过需要注意的是，接口的速度也会影响SpeedIndex的时间，由于AJAX流行的今天，我们大多数的数据都是使用接口拉取。如果接口速度过慢，他就会影响你页面的初始渲染， 导致性能问题，所以，在做性能优化的同时，请求后端伙伴协助，也是性能优化的一个方案

上述分析，根据三个指标提供了一些常规的优化手段，那么在这些优化手段中，有的你可以立马排查到，并且优化例如：

1. 优化图像，优化字体大小
2. 跟服务端配合利用浏览器缓存机制.启用cdn、启用gzip等
3. 减少网络协议过程中的消耗，减少http 请求、减少dns查询、避免重定向
4. 优化关键渲染路径，异步加载js等

但是有的优化手段我们不容易排查，因为他是打在包里面的，这个js 文件包含了很多逻辑怎么办，这里我有两个手段或许能够帮助排查出性能瓶颈发生在哪里：

在通常情况下，我们无法判断的优化点，都是在打包后，我们无法分析出，那些东西不是我们在首屏必须需要的，从而不能做出针对新的优化，为了解决当前问题，各大bundle厂商也都有各自的分析包的方案

以vue-cli 为例

"report": "vue-cli-service build --report" 复制代码

我们只需要在脚手架中提供以上命令，就能在打包时生成，整个包的分析文件