图片加载速度取决于src解析、原生懒加载支持及预加载三要素；loading="lazy"仅对img/iframe生效，需有src/srcset且非首屏才延迟，旧WebView需降级检测；src强制请求，srcset为候选匹配；preload与lazy不可混用于首屏图；未设宽高或占位符会导致布局抖动。
图片加载速度不是独立存在的，它直接受 HTML 中 src 属性是否被立即解析、浏览器是否支持原生懒加载、以及资源是否被提前预加载这三件事控制。
loading="lazy" 为什么有时不生效
看似加了 loading="lazy" 就能懒加载，但实际常被忽略的触发条件有：
- 只对
<img>和<iframe>生效，<picture>或背景图里的 URL 不走这个机制 - 必须有明确的
src或srcset，如果用data-src存地址却没 JS 补位，图片根本不会加载 - 首屏内（默认约 1250px 范围）的图片，即使写了
loading="lazy"，浏览器也可能主动 eager 加载——这是策略，不是 bug - 某些低版本 Android WebView（如 Android 9 以下系统自带 WebView）不识别该属性，需降级检测：
'loading' in HTMLImageElement.prototype
src 和 srcset 的加载行为差异
src 是强制立即发起请求的单值入口；srcset 则是“候选池”，浏览器根据设备像素比（DPR）、视口宽度等条件自主选择最匹配的一项加载。关键区别在于：
- 写了
srcset但没写src，部分旧浏览器（如 IE11）会直接不加载任何图 - 写了
src+srcset，现代浏览器优先按srcset匹配，但src作为兜底存在——若所有srcset条件都不满足，仍会加载src -
srcset不改变懒加载逻辑：如果同时设了loading="lazy"，最终选中的那张图仍会延迟加载
preload 和 loading="lazy" 能一起用吗
能，但必须分清目的，否则互相抵消：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
- 对首屏大图（比如 Hero 图），应该用
<link rel="preload" as="image" href="hero.webp">，并**去掉**loading="lazy"—— 否则 preload 提前拉取，lazy 又拦着不渲染，白忙一场 - 对非首屏图，不要 preload，否则抢占带宽，反而拖慢关键资源（如 CSS、JS）下载
-
preload的as值必须准确，图片必须写as="image"，字体必须加crossorigin，否则可能加载失败或被浏览器忽略
为什么图片“刷一下才出来”或“布局抖动”
这不是加载慢，而是 HTML 结构和样式没预留空间导致的渲染问题：
- 没设
width和height属性，浏览器无法预估图片尺寸，加载后突然撑开容器，引发重排（reflow） - 用 CSS 的
width: 100%或max-width缩放图片，但原始图尺寸极大，仍会下载完整体积，浪费带宽 - 懒加载完成前没给占位符（如纯色背景、SVG 骨架图），视觉上就是“空白→闪现”，用户感知为卡顿
- 多个图片同时进入视口触发批量加载，瞬间并发请求过多，尤其在弱网下易超时或排队
真正影响图片呈现快慢的，从来不是“图片本身多大”，而是 HTML 是否让浏览器清楚地知道“什么时候该加载、加载哪张、加载完放多大”。这些细节藏在属性组合里，而不是某个开关一开就万事大吉。
