预加载图片需按场景选机制：link rel="preload"用于首屏确定关键图，必须静态路径、写在head最前、加as="image"；new Image()适用于交互后按需加载，需先绑事件再赋值src并控制并发。

预加载图片不是“加个属性就变快”，而是要分清场景选对机制：link rel="preload"适用于首屏确定会用的图，new Image()适用于运行时按需触发的加载，二者不能混用或互相替代。

什么时候必须用 link rel="preload"

当你有明确的首屏关键图（比如 banner、logo、登录页主视觉），且路径在构建时就固定，就必须用它。这是唯一能在 HTML 解析阶段就发起请求的方式，能抢在 DOM 构建前把资源拉进缓存。

• as="image" 必须写，漏掉就退化成普通 fetch，Network 面板里 Priority 显示为 Low，Initiator 是 (Other)
• 必须放在 <head> 最前面，紧贴 <meta charset> 后；动态插入（如 document.createElement('link')）完全无效
• href 必须是静态字符串，不能含 ${name}、./images/hero.jpg（相对路径易错）等；推荐用绝对路径如 /assets/logo.webp
• Chrome 101+ 可加 fetchpriority="high"，抬高请求优先级；旧版忽略，无副作用

为什么 new Image() 不能乱用

它适合用户交互后才决定是否加载的场景（比如 hover 按钮后预载下一页缩略图），但顺序和并发控制稍错就会失败或卡住。

html-to-pptx-converter

使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。

下载

• 必须先绑定 onload/onerror，再赋值 src；否则缓存命中时事件同步触发，回调直接跳过
• 要检查 img.complete === true，若为真，说明已缓存，需立刻执行成功逻辑
• 浏览器并发请求数通常只有 6~8 个，循环中密集 new Image() 会导致排队阻塞；建议用 Promise 控制并发（例如每次最多 4 个）
• 不要写 new Image().src = url 这种简写，无法捕获失败，也无法链式等待

哪些写法看似像预加载，其实完全无效

最常见的误操作就是把延迟加载当成提前加载，或者用非标准方式干扰浏览器原生逻辑。

立即学习“前端免费学习笔记（深入）”；

• loading="lazy" 是推迟加载，不是预加载；哪怕加在首屏 <img> 上，Chrome 仍可能等到滚动前 500px 才发请求
• display: none 或 CSS background-image 伪隐藏，语义不清、Lighthouse 不识别、缓存策略不可控，且可能被浏览器优化掉
• decoding="async" 只影响解码时机，和下载时机无关；loading="eager" 是默认行为，不等于“提前”
• 同一张图既 preload 又在 <img src> 中引用，但 href 和 src 路径大小写/斜杠不一致（如 /logo.webp vs logo.webp），会导致二次请求

真正有效的预加载，核心就两条：路径必须静态准确，时机必须足够早。任何试图用 JS 动态拼接路径、或靠 CSS 技巧绕过规范的做法，都会在某个浏览器版本或网络条件下失效。