弱网下图片可用性靠结构化dom与分阶段资源控制实现：外层容器固定尺寸，内层用模糊缩略图与原图叠放过渡，服务端需生成渐进式jpeg，html仅保留必要dom并统一js加载管控。
弱网下图片不能靠“等它慢慢加载”，必须用结构化 DOM + 分阶段资源控制来抢出可用性。 直接写 <img src="big.jpg"> 或依赖 loading="lazy" 都会卡在白屏或 layout shift 上——关键不是图多大，而是 HTML 初始结构是否允许浏览器在 1 秒内渲染出可识别的视觉锚点。
用双层 DOM 结构实现模糊→清晰过渡
这不是纯 CSS 技巧，而是 HTML 层级的语义约定：外层容器固定尺寸、内层两张图绝对定位叠放，且各自承担明确职责。
- 第一张图是极小尺寸缩略图（如 20×20 px），
src指向 base64 或 CDN 上的 LQIP 地址，设filter: blur(8px)和opacity: 0.9，作为视觉占位底图 - 第二张图是原图，
position: absolute覆盖其上，初始opacity: 0，监听onload后加 class 切换为opacity: 1 - 必须给外层
<div> 显式设置 <code>width/height，否则 Safari 在图像解码完成前会触发重排，破坏 LCP - PNG/GIF 有透明通道时，底图需加
background: #f5f5f5，否则透出底层文字或色块造成视觉干扰 - 用户上传的原始图默认是 baseline JPEG，即使后缀为
.jpg，也绝不会触发逐层渲染 - Node.js + sharp 示例中
.jpeg({ progressive: true })是必要步骤；PHP 中要调用imageinterlace($image, 1)；ImageMagick 命令必须带-interlace Plane - WebP/AVIF 不支持传统渐进式，但可用
<picture></picture>+<source type="image/webp"></source>回退到 JPEG progressive，避免降级失败 - 注意：渐进式 JPEG 文件体积通常比 baseline 大 5–10%，但弱网下首帧感知速度提升远超此代价
-
<main></main>内只保留 LCP 图片对应 DOM，其余全部用<div data-lazy="gallery"></div>占位，真实内容延迟挂载 - 禁用
data-autoplay、data-init类自动触发逻辑；改由 JS 检测navigator.connection.effectiveType或自定义网络状态后显式调用renderGallery() - 深度超过 3 层的嵌套容器（如
div > div > article > figure）用display: contents扁平化，减少无意义 wrapper 触发 layout - 所有图片
src不直接写路径，统一走 JS 加载器封装，内置AbortController和 1500ms 超时，防止 pending 请求卡死整个资源队列
渐进式 JPEG 必须由服务端生成，HTML 无法启用
浏览器不会“自动把普通 JPG 变成渐进式”——progressive: true 是 sharp/ImageMagick/PIL 等工具在保存时写入文件头的编码标志，HTML 里写再多属性也没用。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
避免 DOM 膨胀导致解析阻塞
弱网下 HTML 解析快、JS 执行慢、资源加载更慢。若初始 HTML 包含大量 <img> 标签（尤其带 data-src 的懒加载占位），会加剧主线程压力和 layout thrashing。
最容易被忽略的是：渐进式效果是否生效，不取决于你写了多少 CSS 动画，而取决于初始 HTML 是否只包含最小必要 DOM、服务端是否真正输出了 progressive 编码的 JPEG、以及 fetch 是否被 abort 机制兜住。三者缺一，弱网下就还是白屏或闪动。
