HTML中Link标签Preload在特定字体格式提前加载中的应用实战-html教程-PHP中文网

必须用as="font"并配crossorigin属性，否则浏览器丢弃预加载数据；as="font"触发字体专用加载器，启用高优先级、CORS检查和独立缓存，而as="fetch"仅走普通HTTP缓存，无法被@font-face复用。

html中link标签preload在特定字体格式提前加载中的应用实战

字体 preload 不生效，90% 是因为 as="font" 没配对 crossorigin，哪怕同源也必须写——浏览器不自动降级，而是直接丢弃已下载数据。

为什么 WOFF2 字体必须用 `as="font"` 而不是 `as="fetch"`

浏览器对字体有独立加载器（FontLoader），as="font" 才会触发它：走高优先级队列、启用 CORS 检查、进字体专属缓存池；as="fetch" 只走普通 HTTP 缓存，后续 @font-face 根本无法复用——即使 URL 完全一致，也会重复下载。

常见错误是把字体当 API 处理，写成 as="fetch" 并加 crossorigin="anonymous"，Network 里能看到 200，但控制台无报错，文字就是空白（FOIT）。

as="font" → 浏览器自动发 Accept: font/woff2,*/*，匹配服务端返回的 Content-Type: font/woff2
as="fetch" → 发 Accept: */*，即使返回 font/woff2，字体引擎也不认
as="script" 或 as="style" 预加载 WOFF2 文件，同样无法绑定到 @font-face

`crossorigin` 怎么写才对：空值才是正确写法

字体强制要求 CORS 上下文，但 W3C 规范允许 crossorigin 属性不带值——即 crossorigin（无等号、无引号）表示匿名模式。这是最安全、兼容性最好的写法。

写成 crossorigin="anonymous" 在 Chrome/Safari 中虽能工作，但部分 CDN 或旧版服务端可能因头校验严格而拒绝；写成 crossorigin="use-credentials" 几乎必然失败，因为字体服务极少支持凭据传输。

DeepBI DHTML 页面生成器

生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur

下载

最关键的是：哪怕字体和 HTML 同源，也必须显式声明 crossorigin。浏览器不会“自动降级”，而是直接丢弃已下载的字体数据，导致 @font-face 重新发起一次带 CORS 头的请求。

✅ 正确：
❌ 无效：（漏 crossorigin）
⚠️ 风险：（非必要，增加兼容性负担）

路径必须完全一致，包括查询参数、大小写、末尾斜杠

浏览器复用预加载字体的判断逻辑是“URL 字符串完全相等”，不是路径归一化匹配。如果 @font-face 里写的是 url('/fonts/inter-bold.woff2?v=2.1')，但的 href 是 /fonts/inter-bold.woff2，就不会复用——哪怕服务端 301 重定向过去，浏览器也认为这是两个资源。

确保的 href 和 @font-face 中 src 的 url() 内容逐字符一致
注意大小写：Linux 服务器区分 Inter-Bold.woff2 和 inter-bold.woff2
注意末尾斜杠：/fonts/inter.woff2 ≠ /fonts/inter.woff2/
CDN 域名也要一致：用 https://cdn.example.com/fonts/... 就不能在 CSS 里写 url('/fonts/...')

真正容易被忽略的点是：所有这些条件（as="font"、crossorigin、路径完全一致、type 匹配 MIME）必须同时满足，缺一不可。少一个，字体就白 preload —— Network 里能看到请求成功，Performance 面板里 duration 很短，但 renderBlocking 仍为 true，文字照常空白几秒。