预加载节点必须在构建时注入，运行时加没用：浏览器只在html解析初期识别，动态插入（如document.createelement('link')）完全无效；必须置于内、后且尽可能靠前，否则降级为低优先级请求。

预加载节点必须在构建时注入，运行时加没用

HTML静态生成系统里，link rel="preload"这类节点不能靠JS在页面加载后动态插入——浏览器的预加载扫描器只在HTML解析初期工作，等document.readyState === 'interactive'时再塞link，早就错过时机了。常见错误是用document.createElement('link') + appendChild，这种写法对性能毫无帮助。

真正有效的注入点只有两个：服务端模板渲染阶段或构建工具打包阶段。比如用Webpack配合html-webpack-plugin，在templateParameters里把预加载列表传进去；或者用Next.js的getStaticProps返回资源路径，在Head组件里渲染link标签。

• 必须确保link rel="preload"出现在内、且尽可能靠前（紧贴<meta charset>后）
• 不能放在里，浏览器直接忽略
• 若用SSG生成静态HTML，所有preload节点必须已存在于输出文件中，CDN缓存后无法再改

as属性写错等于白写，字体和图片要特别注意

as不是可选字段，它是浏览器决定请求优先级、CORS策略、缓存分区的关键依据。漏写或类型不匹配，Priority直接掉到Low，和普通fetch无异。

首屏大图用as="image"，Web Font必须用as="font"并带上crossorigin——Chrome 120+默认强制CORS检查，同域字体不加也会被丢弃。而as="script"或as="style"则需配套处理执行逻辑：前者要配defer或async，后者得跟一个onload回调把rel从preload切到stylesheet。

html-ppt-to-pdf

将使用 `

` 约定的 HTML 幻灯片转换为高保真、矢量文本 PDF（使用 Playwright + Chromium 原生 PDF 功能）。

下载

• as="font" → 必须带crossorigin，哪怕字体在同域
• as="image" → 不支持srcset或sizes，只适合确定尺寸/格式的单图
• as="style" → 必须加onload="this.onload=null;this.rel='stylesheet'"，否则只下载不解析

preload不是越多越好，首屏外资源慎用

把非首屏资源（比如底部“相关推荐”模块的JS、折叠区域的图片）也写成preload，会抢占当前页连接数和带宽，反而拖慢关键资源加载。浏览器对同一域名的并发连接有限制，预加载太多低优先级资源，可能让critical.css或首屏img排队更久。

判断要不要preload，只看一条：这个资源是否在HTML解析过程中“发现得太晚”，导致渲染阻塞？比如CSS里@font-face引用的woff2、内联style里的background-image、或者type="module"脚本后紧跟的chunk。

• 首屏可见区域内的大图、字体、关键CSS/JS → 适合preload
• 用户滚动后才出现的内容 → 改用loading="lazy"或IntersectionObserver触发加载
• 下一页大概率访问的资源（如商品详情页JS）→ 用prefetch，别用preload

验证是否生效不能只看HTML源码

光检查HTML里有没有那行link rel="preload"没意义。真正要看的是Chrome DevTools → Network面板里的实际行为：

• 筛选Initiator列，找preload（不是parser或script）
• 检查Priority列：应为Highest或High；若显示Medium或Low，说明as写错或缺crossorigin
• 点开请求详情，确认Response Headers含timing-Allow-Origin（跨域字体必需）

最容易被忽略的是：preload只绕过HTML解析顺序限制，不解决网络延迟或服务器响应慢。如果资源本身加载慢，加了preload也快不起来。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！