AI 摘要：本文探讨了字体预加载 (font preload) 对网站性能的利弊。虽然预加载可以减少字体切换导致的双重渲染和版式抖动，但在 Chrome 等浏览器的机制下，可能会推迟 First Contentful Paint (FCP) 和 Largest Contentful Paint (LCP)。文章重点分析了预加载在不同场景下的风险与收益，并提出了实践建议：仅预加载关键字体、自托管字体、谨慎区分文本字体与图标字体。结论是：预加载并非万能方案，而应基于实际数据与场景做针对性优化。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]
1. 不预加载字体的情况
• 默认情况下，浏览器会先渲染系统字体，再替换为下载完成的 Web 字体，造成二次渲染与视觉抖动。
• 开发者常用预加载来避免多次绘制。

2. 预加载字体的权衡 (Trade-offs)
• 预加载强制浏览器提前下载字体，但可能延迟首屏渲染。
• 大多数现代浏览器支持 link rel="preload"，但行为存在差异。

3. 浏览器行为与渲染延迟
• Chrome 从 2023 年起更改机制：延迟首屏渲染 (first paint)，等待字体加载完成，从而减少布局错位。
• 这种优化虽然稳定首屏效果，却可能推迟 FCP 与 LCP。

4. Chrome 的预加载超时 (Preloading timeout)
• Chromium 设计了两个超时机制：
• 1500ms 自导航开始计算，避免过长等待。
• 100ms 自最后一个阻塞性资源加载完成开始计算，保证不会显著拖慢首屏渲染。

5. 预加载最佳实践
• 仅预加载首屏必需字体，避免过度使用。
• 始终加上 crossorigin 属性，即使同域下载。
• 尽量自托管字体，避免额外 DNS/TLS 开销。
• 优先预加载文本字体，不建议预加载图标字体（初期核心是可读内容，而非交互按钮）。

6. 结论 (Bottom line)
• 字体预加载可以优化体验，也可能破坏性能。
• 建议从小规模测试入手，基于真实用户数据决策，不盲目“一刀切”。