需在network面板用filter:font精准筛选字体请求，检查timing中ttfb>300ms或content download>1s的请求，按waterfall排序定位首屏瓶颈，并通过type列确认font/woff2等类型以排除js/css干扰。
你想精准定位网页中第三方字体（如Google Fonts、阿里图标字体、自托管woff2文件）从请求发出到渲染完成的完整耗时，避免被JS/CSS等其他资源干扰，必须在Network面板中准确筛选并展开Timing细节。
筛选出所有字体请求
在Network面板左上角过滤框中输入 font，回车确认。Chrome会自动匹配包含 font、woff、woff2、ttf、otf、eot 的请求，但【务必手动补全 filter:font】——仅靠输入“font”可能漏掉无扩展名或带query参数的字体请求，而 filter:font 是Chrome原生支持的专用过滤语法，能稳定捕获所有 MIME type 为 font/* 的资源。
若列表为空，检查是否勾选了“Disable cache”；未勾选时浏览器可能直接从内存缓存返回字体，不触发网络请求。
查看单个字体的分阶段耗时
点击任一筛选出的字体条目（如 fonts.googleapis.com/css?family=Inter:wght@400;700），切换到下方面板的 Timing 标签页。
此时瀑布图将清晰拆解为六段：DNS Lookup（蓝色）、Initial Connection（绿色）、SSL Setup（青绿）、Request Sent（紫色）、Waiting (TTFB)（橙色）、Content Download（红色）。其中【TTFB > 300ms 或 Content Download > 1s 的字体请求需优先优化】——前者说明服务器响应慢或网络远，后者往往因字体文件过大或CDN未开启Brotli压缩。
对比多个字体的加载顺序与阻塞关系
方法一：按 Waterfall 列升序排列 → 找出最早开始（Start Time 最小）且持续时间最长的字体请求，它极可能是首屏文字渲染的瓶颈源。
方法二：右键表头 → 勾选 “Waterfall”、“Size”、“Type”、“Status” → 观察 Type 列是否显示为 font/woff2 或 font/woff；若显示为 document 或 xhr，说明该字体是通过CSS @import 或 JS 动态注入的，其加载时机不可控，需回溯源头代码。
方法三：启用 Preserve log → 切换页面路由后仍保留字体请求记录，避免单页应用（SPA）跳转时丢失关键字体加载链路。
