图片加载慢的关键在于“何时加载”和“加载什么”，而非仅靠压缩；应谨慎使用loading="lazy"，仅用于距首屏较远的图片，首屏关键图须禁用，Chrome 76+等主流浏览器支持。
直接上结论：图片加载慢不是单靠“压缩”就能解决的，关键在「什么时候加载」和「加载什么」。多数白屏或卡顿，其实卡在首屏大图没出来、或一堆非可视区图片抢带宽。
怎么用 loading="lazy" 安全启用原生懒加载
这是最轻量、浏览器原生支持的方案，但容易误用。
- 只对
loading="lazy"应用于距离首屏较远的<img>，比如列表页第 3 屏之后的图；首屏 Hero 图、Logo、按钮图标必须禁用该属性，否则可能延迟渲染甚至被跳过 - Chrome 76+、Firefox 75+、Safari 15.4+ 支持，但低版本 iOS Safari（if ('loading' in HTMLImageElement.prototype)
- 不要和
srcset或picture混用时忽略响应式逻辑——loading="lazy"本身不改变资源选择规则，只是推迟触发时机
为什么首屏图片必须内联或 preload，而不是等 DOM 解析完
浏览器解析 HTML 是流式的，但遇到 <img src="hero.jpg"> 才开始下载。如果这张图体积大、CDN 响应慢，首屏就白着等。
- 对首屏关键图（如 banner、登录头像），在
<head>中加<link rel="preload" as="image" href="hero.webp">，强制提前发起请求 -
href必须是最终要加载的 URL（不能是占位符），且建议用.webp或.avif格式，避免再做格式协商 - 别把所有图都
preload：它会抢占主文档和 CSS 的带宽，反而拖慢渲染；只 preload 真正影响 LCP（最大内容绘制）的那 1–2 张
data-src + IntersectionObserver 自定义懒加载怎么写才不卡主线程
当需要控制加载时机、占位图、错误回退，或兼容老浏览器时，得自己实现。但写错容易引发重排或内存泄漏。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
- 初始
<img src="placeholder.svg" width="300" height="200">，必须设width/height防止加载时布局抖动 - Observer 回调里只做两件事：赋值
el.src = el.dataset.src，然后调用observer.unobserve(el)—— 别在里面塞 DOM 操作、AJAX 或重绘逻辑 - 避免监听全部
img[data-src]：先过滤掉已在视口内的元素，否则刚进页面就批量触发，失去“懒”的意义
CDN 和响应式图片怎么配才不白忙活
把图传到 CDN 不等于自动优化；没配对格式和尺寸，用户手机还在下 2MB 的桌面图。
- 用
<picture>+<source media="(max-width: 768px)" srcset="hero-400w.webp 1x, hero-800w.webp 2x">，让浏览器按设备像素比和 DPR 自选 - CDN 要开启自动格式转换（如 Cloudinary 加
f_auto参数）、动态缩放（w_800）和 WebP/AVIF 回退；否则你传的是 PNG，CDN 还是吐 PNG - 别在
src里写绝对路径又硬编码尺寸——构建时用 loader（如 webpack 的image-minimizer-webpack-plugin）生成srcset更可靠
真正卡住加载的，往往不是某张图太大，而是几十张图在 onload 里触发了重复 resize、重排或未清理的 Observer 实例。优化图片加载，本质是做减法：砍掉不该加载的、压住不该抢带宽的、盯紧那几张决定 LCP 的。
