共计 3762 个字符，预计需要花费 10 分钟才能阅读完成。
本文首发于微信公众号：大迁世界, 我的微信：qq449245884，我会第一工夫和你分享前端行业趋势，学习路径等等。
更多开源作品请看 GitHub https://github.com/qq449245884/xiaozhi，蕴含一线大厂面试残缺考点、材料以及我的系列文章。
目前，图像是 Web 中规模最大的资源，无论是总传输大小还是每页申请数量。截至 2022 年 6 月，中位数网页的总传输大小约为 2MB，其中图像仅占近一半。能够说，优化图像申请可能是咱们能够进行的最大性能优化。
推延图像申请
首先，咱们来看一个重要的属性：loading="lazy":
<img src="image.jpg" loading="lazy" alt="…">应用这个属性可能很简略，但它对性能的影响能够十分无效的：如果图像不呈现在视口中，那么就不会发出请求，并且也不会节约带宽。
然而，有一个问题：推延申请意味着不能利用浏览器尽早申请图像。如果在布局顶部的 img 元素上应用 loading="lazy"，因而在页面首次加载时更有可能呈现在用户的视口中，则这些图像对用户来说可能显示得更慢。
优先提醒
loading 属性是 Web 规范致力的一个成绩，让开发人员对浏览器申请的优先级更多地管制。
大家可能晓得浏览器的根本申请优先级办法：例如，对文档 <head> 中的内部 CSS 文件的申请会优先执行并阻止渲染，而对于在 </body> 之前的内部 JavaScript 文件的申请被提早到渲染实现。如果 <img> 上的 loading 属性的值是 'lazy'，则相干的图像申请将被提早，直到浏览器确定它将显示给用户为止。否则，该图像将具备与页面上任何其余图像雷同的优先级。
实验性的 fetchpriority 属性让开发人员对资源的优先级更加精密地管制，容许咱们绝对于同类资源标记资源为 'high' 和 'low' 优先级。
fetchpriority 的应用场景与 loading 属性类似，但覆盖面更广。例如，咱们能够仅在用户交互后显示的图像上应用 fetchpriority="low"（无论该图像是否在用户的视口中），以优先解决页面上的可见图像，或应用 fetchpriority="high" 优先解决咱们晓得页面渲染后立刻可见的视口。
留神，fetchpriority 与 loading 不同，它不会从根本上扭转浏览器的行为。它不会批示浏览器在其余资源之前加载某些资源，而是为它对申请资源的决策提供了重要的背景。
掂量图像的影响
在优化图像时，对用户的感知性能通常更为重要，并且比仅仅测量数据传输大小更难掂量。
Web Vitals 提供可掂量的、可操作的指标和领导，以进步用户体验，突出了诸如网页服务器响应工夫过慢、渲染问题和交互提早等问题。外围 Web Vitals 是这些指标的一个子集，专一于用户对单个页面的间接体验——一组技术测量，它们独特决定了体验对用户来说有多快。
Cumulative Layout Shift
累积布局位移（CLS）是视觉稳定性的度量。它是掂量页面内容布局在加载资源并渲染页面时如何挪动的指标。任何应用了 Web 的人都有过因页面在某个提早的字体或图片资源忽然渲染而跳动而导致在长文章中的地位失落的经验，或者把交互元素挪动到指针之外的地位。
CLS 高的状况最多只是一种麻烦，在最坏的状况下是导致用户谬误的起因，例如，在用户单击时“勾销”按钮挪动到先前被“确认”按钮占用的地位。
因为加载工夫较长以及它们在布局中所占的空间，因而图像是导致 CLS 分数较高的常见起因。
事例：https://codepen.io/web-dot-de…
因为古代浏览器的绝对较新的变动，防止因图像导致的高 CLS 分数比你设想的更容易。如果你曾经在前端工作了几年，对 <img> 上的 width 和height属性曾经很相熟：在 CSS 的宽泛采纳之前，这是管制图像大小的惟一办法。
<img src="image.jpg" height="200" width="400" alt="…">这些属性因为试图将款式和标记拆散，特地是响应式网页设计使得通过 CSS 指定百分比尺寸的必要性，而不再应用。在响应式网页设计的晚期，” 删除未应用的 width 和height 属性 ” 是常见的倡议，因为咱们在 CSS 中指定的值，即 max-width: 100% 和height: auto，将笼罩它们。
<img src="image.jpg" alt="…">img {
max-width: 100%;
height: auto;
}在以前的状况中，删除了 <img> 元素上的 height 和width属性后，浏览器确定图像高度的惟一办法是申请源、解析它并在其固有的比例渲染它，基于样式表利用后在布局中占据的宽度。这个过程的大部分在页面渲染后才实现，新计算出的高度导致了其余布局的挪动。
从 2019 年开始，浏览器行为被更新以不同的形式解决 width 和height属性。这些属性不再用于确定 img 元素在布局中的固定、像素为根底的大小，而是能够认为代表图像的长宽比，语法雷同。古代浏览器会在页面渲染前将这些值除以对方，以确定 img 元 素的外在长宽比，从而容许它在布局渲染时保留图像占据的空间。
作为一项规定，咱们应该始终在 <img> 上应用 height 和width属性，其值应与图像源的外在大小匹配，只有咱们确保指定了 height：auto 和max-width：100%，以笼罩 HTML 属性中的高度即可。
<img src="image.jpg" height="200" width="400" alt="…">img {
max-width: 100%;
height: auto;
}通过在 <img> 元素上应用 width 和 height 属性，将防止因图像而导致的 CLS 高分。
事例：https://codepen.io/web-dot-de…
重要的是，这种办法没有任何毛病，因为它依赖于长期存在的浏览器行为，任何反对根本 CSS 的浏览器都将像平常一样工作，HTML 属性中的 height 和 width 属性将被款式笼罩。
尽管 width 和 height 属性通过保留图像所需的布局空间来防止 CLS 问题，但会向用户渲染空白或低质量的占位符，期待图像传输和党建也不现实。只管能够采取一些措施缩小加载慢的图像的可测量和可察觉影响，但向用户更快地党建残缺图像的惟一办法是通过减小传输大小。
Largest Contentful Paint
最大内容绘制（LCP）掂量用户可视视口中最大“内容绘制”元素渲染所需的工夫，即占可见页面最大百分比的内容元素。在表面上，这个指标仿佛过于具体，但它实际上代表了从用户的角度看到页面大部分内容已被渲染的工夫。 LCP 是（感知的）性能的要害指标。
DOMContentLoaded或 window.onload 事件等指标能够用于确定以后页面加载的过程在技术上已实现，但它们不肯定对应于用户对页面的体验。在用户视线外的元素的渲染略有提早，将被计入这些指标中，但可能齐全被事实世界的用户疏忽。长 LCP 意味着用户对页面的第一印象是页面迟缓或彻底停滞。
用户对 LCP 的感知对用户体验产生间接影响。去年 Vodafone 进行的一项试验发现，LCP 进步 31% 不仅导致销售额减少了 8%，这自身就是一个很好的后果，但他们的总用户中，潜在客户数量减少了 15%，拜访购物车的用户数量减少了 11%。
在 70% 以上的网页中，初始视口中的最大元素波及图像，能够是独自的 <img> 元素，也能够是具备背景图像的元素。换句话说，70% 的页面的 LCP 分数都是基于图像性能。不难想象，大而引人注目的图像和标记很可能会在“above the fold”被找到。
咱们能够采取一些步骤来防止 LCP 提早：首先，不要在above the fold 图像上指定 loading="lazy"，因为提早申请直到页面渲染实现将可能对 LCP 分数产生微小的负面影响。其次，应用 fetchpriority="high" 能够通知浏览器该图像的传输应该优先于页面上的其余图像。
牢记这些规定，进步页面 LCP 分数的最重要的事件是缩小传输和渲染这些图像所需的工夫。为了实现这一指标，您要放弃图像源尽可能小和高效（当然不会就义品质），并确保用户仅获取对他们的浏览上下文最有意义的图像资源。
总结
图像资源是对用户带宽的最大散失，这是从传输每个渲染页面所必须的其余资源所耗费的带宽。图像在性能感知方面引入了重要问题，无论是在四周页面布局渲染后还是之前。简而言之：图像资源造成了侵害。
尽管如此令人生畏，然而“如果图像少一些，Web 的性能就会更好”必定是仅仅从性能角度来说是正确的，但它也对用户造成了微小的不利影响。图像是 Web 的重要组成部分，咱们不应该仅为了性能而斗争有意义的内容的品质。
代码部署后可能存在的 BUG 没法实时晓得，预先为了解决这些 BUG，花了大量的工夫进行 log 调试，这边顺便给大家举荐一个好用的 BUG 监控工具 Fundebug。
原文：https://web.dev/learn/images/…
交换
有幻想，有干货，微信搜寻 【大迁世界】 关注这个在凌晨还在刷碗的刷碗智。
本文 GitHub https://github.com/qq449245884/xiaozhi 已收录，有一线大厂面试残缺考点、材料以及我的系列文章。
