如何在 CDN 上托管字体：分步指南

web fonts

如何在 CDN 上托管字体
分步指南

在 CDN 上托管字体，能明显改善加载速度、可扩展性与稳定性。但「CDN」一词在授权语境下含义并不唯一。这份指南先厘清授权边界，再给出七个可以照着做下去的实施步骤。

本文作者 Jeff Carey（资深首席软件工程师、开发者关系负责人）

CDN，即内容分发网络，由遍布全球的服务器组成。它就近缓存并分发包括字体在内的网页资源，把资源推到离每位用户地理位置最近的节点，从而降低延迟、缩短页面加载时间。

借助 CDN 托管字体，浏览器与字体文件之间的距离被压缩，字体在全球各地都能更快渲染。与本地托管相比，CDN 带来三方面优势：全球加载更快、可用性更稳定；带宽利用更高效，源站压力更小；字体渲染与缓存更高效，Core Web Vitals 表现更好。

理解 CDN 字体托管

对大型品牌和平台而言，基于 CDN 的网页字体交付还有一层意义：它让字体在每一个数字触点上都能流畅、可扩展地呈现。市场活动、产品界面、网站、包装与线下物料用的是同一套字体，交付链路却各不相同，CDN 正好把这条链路收拢到统一的出口。

不过，托管位置的选择会直接影响授权是否成立。下文先厘清「CDN」在授权语境下的几种含义，再进入具体实施步骤。

CDN 交付并不只有一种授权模式

在这份指南里，「CDN」可能指三种完全不同的做法，各自的授权口径也不一样。

术语	含义	典型授权口径
Monotype 字体交付服务	由 Monotype 运营的网页字体交付，包括授权嵌入或产品 CDN	授权协议包含 Monotype 交付服务时，属于覆盖范围
在自有基础设施或经授权的托管服务商上自托管	由你控制的服务器、云 CDN 或边缘 CDN 提供已授权的 WOFF2/WOFF 文件；也可以依据书面协议，由第三方为你托管。交付范围限定在已授权的域名内	只要交付不超出授权范围，通常包含在标准 Monotype 网页字体授权之内
公共或开放 CDN 再分发	把字体文件放到通用公共 CDN 或包托管平台，例如 jsDelivr 或 unpkg，可被广泛抓取，超出你已授权的部署范围	在标准 Monotype 网页字体条款下，通常不被允许

下文各步骤聚焦于通过自有源站或经授权的托管服务商进行自托管。这些步骤不适用于把商业 Monotype 字体软件发布到公共开放 CDN。

另请参阅参考库中的说明：Monotype 字体交付与自托管的区别。

第 1 步：核对字体授权与报告要求

在把字体上传到任何位置之前，先确认授权是否覆盖网页嵌入，以及你计划采用的交付方式。桌面端授权不覆盖浏览器分发。网页字体授权通常覆盖，但合同或文档里出现的「CDN」一词，仍需要仔细读一遍。

在许多 Monotype 网页字体协议下，从你控制的基础设施提供已授权文件，包括经授权的第三方托管服务商（例如为你的授权域名配置的云 CDN），都被视为自托管。也就是说，不会因为用了边缘缓存，就必须另外购买一项产品。这与 Monotype 自有的字体交付服务不同，也与把文件放到公共或开放 CDN、任由无关站点抓取的做法不同。

同时核对报告与跟踪义务。部分 Monotype 网页字体授权要求提交使用报告，例如按月度页面浏览量统计；对于自托管交付，还可能要求在字体文件旁部署跟踪脚本。无论字体由你的源站提供，还是通过经授权的托管方交付，这些义务都可能适用。

授权类型与路径	浏览器分发	用于自有域名的 CDN 或托管	公共开放 CDN（例如 jsDelivr）	报告与跟踪
桌面端	否	否	否	不适用
标准网页字体（典型情况）	是	通常可以，前提是范围限定为你	通常不行	依协议而定
Monotype 网页字体	是	是，前提是协议允许	否	通常需要，请核对条款
Monotype 字体交付	是	不适用，由 Monotype 提供	不适用	依产品条款而定

尽早确认这些细节，既能避免合规问题，也能避免把方案建立在一套授权并不允许的交付模式上。

第 2 步：为 CDN 交付准备并优化字体文件

上传之前先优化字体文件，缩短加载时间、提升性能。最有效的做法是以 WOFF2 格式提供字体，这是网页压缩的行业标准，文件体积比 WOFF 小约 30%。

对字体做子集化，只保留站点实际需要的字符和字重。移除未使用的字形、字重与扩展字符，能进一步缩小体积、加快交付。

一套干净的优化字体包应当包含：

WOFF2，首选格式，覆盖绝大多数现代浏览器。
WOFF 或 TTF，可选回退格式，用于少量旧版浏览器。

做好准备，可以让 CDN 交付既快又省，同时保住字体排印的质量。

第 3 步：把字体上传到选定的 CDN

所选基础设施要同时满足两件事：性能需求和授权要求。

对于商业 Monotype 字体，优先选择由你控制的托管方或 CDN，也可以依据书面托管协议由第三方为你提供服务，并把交付范围限定在已授权的域名内。把字体文件上传到你的存储或源站，例如对象存储，再配置 CDN 分发来提供这些资源。这就是第 1 步提到的经授权托管服务商或自托管路径。

如果协议包含 Monotype 字体交付服务，你可能根本不需要把生产用字体文件上传到自有 CDN，该产品由 Monotype 负责交付。若这种方式契合你的授权范围与工作流程，可以直接采用。

方案	适用场景	关于 Monotype 字体授权的说明
商业云 CDN 或静态托管，例如 Cloudflare、CloudFront、BunnyCDN、Azure CDN	自托管的生产站点	交付范围限定在已授权域名、且协议覆盖时，通常适用
Monotype 字体交付服务	希望由字体厂商负责交付的团队	授权包含时使用；这与在自有 CDN 上自托管不是一回事
公共开放 CDN 或包托管平台，例如 jsDelivr、unpkg	部分开放或可自由再分发的字体	不建议用于商业 Monotype 字体软件，文件会超出授权部署范围、被广泛抓取
带版本号的开放仓库，例如 Fontsource 风格的公共链接	公共字体生态	同样需要谨慎：这类托管不能当作专有 Monotype 文件的安全授权渠道

对于 Cloudflare、CloudFront 这类商业网络，把优化后的 WOFF2 文件上传到存储桶或源站，再让 CDN 指向这些对象。生产授权文件尽量不放进公共代码仓库，并把可抓取范围限制在授权覆盖的域名内。

第 4 步：配置 CDN 缓存与压缩

缓存与压缩直接决定速度和渲染稳定性。缓存会把字体文件同时存放在 CDN 边缘节点和用户浏览器里，重复访问即可瞬间加载。

配置时遵循以下原则：

配合带哈希的文件名，设置较长的 TTL（生存时间）。例如边缘节点和浏览器缓存都设为一年。
对 font/woff2、application/font-woff 等字体 MIME 类型启用压缩，可选 Gzip 或 Brotli。
文件哈希变化后重新部署，确保浏览器总能拿到更新版本。

带哈希文件名的强缓存策略，能让交付近乎即时，也让版本管理变得简单。

第 5 步：设置 CORS 响应头并测试跨域访问

跨域资源共享（CORS）让浏览器可以从与页面不同源的地址加载字体。如果字体由与站点源不同的 CDN 或托管主机名提供，CORS 响应头缺失或配置错误就会导致浏览器拦截字体。表现往往是字形缺失，或者静默回退到系统字体，页面上并不会给出明确报错。排查时请查看 DevTools 网络面板中的 Font 项以及实际渲染的字形，不要只看控制台。

对于已授权的商业字体，请设置范围明确的允许清单，与页面源一一对应：

Access-Control-Allow-Origin: https://www.yourdomain.com

使用真实的站点源，必要时包含协议、主机和端口。尽量指定具体源，不要用通配符。Access-Control-Allow-Origin: * 是通用 CDN 示例里的常见写法，但对典型的 Monotype 自托管或经授权托管交付并不合适，字体访问应当只对已知的授权源开放。如果服务多个已授权的前端源，请按源分别配置允许清单，或使用 CDN 提供的按请求源变化的机制。当响应随请求源变化时，设置 Vary: Origin，避免共享缓存复用错误的 CORS 响应头。

响应头配置在哪儿，取决于服务商：

Cloudflare：Transform Rules 或 Workers。
CloudFront：源响应头策略。
对象存储（例如 S3）：存储桶或响应头配置。

CORS 设置检查清单

Access-Control-Allow-Origin 限定到已授权的页面源，授权字体不使用 *
需要时已设置 Vary: Origin
清除缓存后，已在多个浏览器中测试字体
更新响应头或文件后，已刷新 CDN 缓存

同源交付，也就是页面与字体在同一主机，通常无需配置 CORS。通过经授权托管方进行跨域交付，则始终需要。

第 6 步：用带哈希的文件名实现缓存失效

缓存失效机制的作用，是即使用户浏览器缓存了旧版本，也能拿到更新后的字体文件。

为每次更新的文件加上唯一的内容哈希，例如 brand-sans-regular.a1b2c3.woff2。这样 CDN 与浏览器可以长期缓存字体，哈希一变就立即提供最新版本。

改名之后，同步更新所有 @font-face 中的 CSS 引用。带哈希的文件名让版本跟踪更高效，不必手动清缓存。

带哈希的字体文件上了 CDN，再用 @font-face 声明接入样式表。它告诉浏览器去哪里找文件，以及如何使用。

@font-face {
  font-family: "BrandSans";
  src: url("https://cdn.example.com/fonts/brand-sans-regular.a1b2c3.woff2") format("woff2"),
       url("https://cdn.example.com/fonts/brand-sans-regular.a1b2c3.woff") format("woff");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

把 BrandSans 换成实际的字体家族名，并把 URL 改成你的 CDN 路径。font-display: swap 会先显示回退文本，等网页字体加载完成后再替换，这是拿到良好累积布局偏移（CLS）评分的关键。

第 7 步：添加资源提示，优化字体加载

资源提示告诉浏览器哪些资源应当优先处理。对 CDN 托管的字体来说，合适的提示能同时提升速度与稳定性。

添加 preconnect 提示，尽早与 CDN 建立连接：

<link rel="preconnect" href="https://cdn.example.com">

然后预加载首屏渲染所需的那个字体文件：

<link rel="preload" href="https://cdn.example.com/fonts/brand-sans-regular.a1b2c3.woff2" as="font" type="font/woff2" crossorigin="anonymous">

配合有针对性的 preload 和合理的 font-display 设置，这些提示能减少阻塞，让字体在各设备上快速、稳定地渲染。

小结

在 CDN 上托管字体，可以提升性能、可扩展性与可靠性。前提是这里的「CDN」指你控制的基础设施，或经授权的托管服务商，向你已授权的域名提供已授权文件；也包括依据协议使用 Monotype 自有的字体交付服务。它并不等于把商业 Monotype 字体软件发布到公共或开放 CDN，让无关站点都能抓取。

要落地一套又快又合规的方案：核对网页字体授权，以及报告与跟踪要求；优化并子集化字体，优先 WOFF2，WOFF 与 TTF 作为可选回退；上传到合适的经授权托管方，或使用 Monotype 交付服务；配置长效缓存与压缩；跨域时设置范围明确的 CORS 响应头，并在 DevTools 中验证；用带哈希的文件名实现缓存失效；再按需添加资源提示与 font-display: swap。遵循这些步骤，有助于保持字体排印一致、提升 Core Web Vitals，并让交付始终停留在授权范围内。

继续探索

和 CDN 托管方式相比，自托管把字体在性能、隐私与交付上的控制权交还给你。

了解自托管网络字体最佳实践

{
  "totalBlocks": 1,
  "blocks": [
    {
      "component": "shared.rich-text",
      "title": "如何在 CDN 上托管字体"
    }
  ],
  "spliced": {
    "articleFooter": false
  },
  "useRecommendation": false,
  "strapiRelatedCount": 0,
  "relatedCount": 0,
  "designersCount": 0,
  "hasDesigners": false
}