【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址https://gitcode.com/gh_mirrors/fr/Front-End-Checklist点击查看免费下载Resource hints资源提示让浏览器在常规 HTML 解析流程之外提前发现关键资源从而显著缩短首屏加载的关键路径。本文基于 Front-End-Checklist 仓库中 performance-resource-hints 技能文档及其 references/rule.md 参考文档系统讲解 preload、prefetch、preconnect、dns-prefetch 四种提示的适用场景、决策规则、框架级写法与验证方法并对照仓库源码说明实际项目中的落地方式。读完本文你将掌握如何针对自己的站点判断该提示什么、不该提示什么并用瀑布图数据验证优化是否真正生效。什么是 Resource Hints为什么它们能加速加载浏览器的 HTML 解析器是按顺序发现资源的CSS 文件中引用的字体要等 CSS 被解析之后才会被请求首屏图片要等img标签被解析到才会开始下载。这种串行发现会让关键路径上出现不必要的等待。Resource hints 通过link rel...标签向浏览器提供提前预告让它在资源被正常解析发现之前就启动 DNS 查询、TCP 连接、TLS 握手甚至完整下载。正如参考文档 references/rule.md 所言资源提示只有在浏览器原本会发现得太晚时才真正有用——它只在你用对了时机、命中了正确的资源时才加速用错了反而比不加提示更糟。Front-End-Checklist 将这条规则归类为performance/loading子类别优先级为high、难度intermediate、预估耗时20 分钟对应的内容规则文件位于 packages/content/rules/en/performance/resource-hints.mdx其中列出了四条快速参考要点用preload加载首屏关键资源字体、首屏图用preconnect建立第三方源CDN、API、分析服务的早期连接用prefetch预取下一次导航很可能需要的资源用dns-prefetch作为preconnect的轻量替代。平均而言合理的资源提示可以让 LCPLargest Contentful Paint提升约 100–300ms。四种 Hint 的本质区别与决策规则preload、prefetch、preconnect、dns-prefetch对应浏览器加载流程中不同深度的预热动作Hint用途应避免的场景实用上限preload当前路由、首屏绘制或 LCP 需要但发现得太晚的资源未来路由的资产、低优先级组件、已被及早发现的资源每条路由通常不超过 3–5 个prefetch下一个路由或下一次交互很可能会用、但当前并不必须的资源当前路由的关键资产对带宽敏感用户且下一步不确定时只针对最可能的下一个导航目标preconnect确定即将使用的源尤其是字体、媒体 CDN 或首屏路由上的 API投机性的第三方、很久以后才用的源通常不超过 2–4 个源dns-prefetch置信度较低的外部源此时完整建连为时过早已在关键路径上、值得完整preconnect的源作为轻量回退而非无差别默认这张决策表同样出现在 references/rule.md 和 content 规则 中是整条规则的核心。它的要点是提示的层级越深从 dns-prefetch 到 preconnect 到 preload消耗的资源越多因此只应该为置信度越高的资源使用。dns-prefetch只做 DNS 解析开销最小适合可能用但不确定的源preconnectDNS TCP TLS 全链路建连适合确定马上要用的第三方源prefetch以低优先级提前拉取资源到缓存适合下一步大概率会用的资产preload以高优先级立即获取资源适合当前页面关键路径上、但发现太晚的资产。仓库还提供了独立的 preconnect 技能进一步强调preconnect 只在外部落源确定需要在首屏附近使用、且建连开销原本会落在关键路径上时才有效对于可能用也可能不用的源应优先选择dns-prefetch。实战一用 preload 加速当前路由的关键资产preload告诉浏览器这个资源现在就重要请立刻以高优先级获取。两个最典型的场景是 LCP 候选图和字体。head !-- Good: hero image is the likely LCP candidate -- link relpreload href/images/hero.webp asimage typeimage/webp fetchpriorityhigh !-- Good: route-critical font discovered late through CSS -- link relpreload href/fonts/inter-latin.woff2 asfont typefont/woff2 crossorigin /head几个属性值得注意as声明资源类型image、font、script、style、document等浏览器据此决定请求优先级与缓存复用。缺少as会让 preload 失去优先级意义还可能产生重复请求。type声明 MIME 类型帮助浏览器跳过不需要的下载例如只支持 WebP 的场景。crossorigin字体资源的 preload 必须携带crossorigin否则会触发双重请求一次 no-cors、一次 cors。fetchpriorityhigh进一步提升 LCP 候选图的请求优先级。参考文档 references/rule.md 特别给出了反模式示例——同一页面堆了 6 个字体/脚本 preload 和 3 个投机性 preconnecthead !-- Bad: too many preloads compete with each other -- link relpreload href/fonts/a.woff2 asfont crossorigin link relpreload href/fonts/b.woff2 asfont crossorigin link relpreload href/fonts/c.woff2 asfont crossorigin link relpreload href/carousel.js asscript link relpreload href/reviews.js asscript link relpreload href/chat-widget.js asscript !-- Bad: speculative origins do not deserve early socket setup -- link relpreconnect hrefhttps://chat.example.com link relpreconnect hrefhttps://ads.example.com link relpreconnect hrefhttps://social.example.com /head过多的 preload 会彼此争抢带宽与解析器注意力反而拖慢真正重要的 CSS、字体和 LCP 资源对只在交互后才会用到的聊天、广告、社交组件做 preconnect 则纯属浪费连接预算。实战二用 prefetch 预热下一次导航prefetch以低优先级提前拉取下一个很可能的步骤让后续导航感觉是瞬时的。关键区分在于prefetch 服务于未来路由而不是当前路由。head !-- Good: likely next navigation -- link relprefetch href/checkout link relprefetch href/static/checkout.js asscript !-- Bad: current-route critical CSS should be loaded normally or preloaded -- link relprefetch href/styles/home.css asstyle /head对当前路由的关键 CSS 使用 prefetch 是错误的它不会进入关键路径的优先级队列只是给网络平添噪音。另外也不应 prefetch 当前已经打开的页面那不会改善发现顺序。除了静态标签也可以在交互时动态注入 prefetch 提示例如鼠标悬停到导航链接时再预取目标页hover 场景置信度高值得预取参见 html-resource-hints 参考文档 中的 JS 示例// Prefetch routes the user is likely to visit // Can be triggered on hover for high confidence navLinks.forEach(link { link.addEventListener(mouseenter, () { const prefetch document.createElement(link) prefetch.rel prefetch prefetch.href link.href document.head.appendChild(prefetch) }, { once: true }) })实战三用 preconnect 与 dns-prefetch 处理第三方源第三方源Google Fonts、媒体 CDN、API、分析平台的建连开销——DNS 查询、TCP 握手、TLS 协商——往往都在关键路径上。preconnect可以把这些步骤提前到首屏资源真正发起请求之前完成。head !-- Good: fonts are used in the first viewport -- link relpreconnect hrefhttps://fonts.googleapis.com link relpreconnect hrefhttps://fonts.gstatic.com crossorigin !-- Good: image CDN serves the hero media -- link relpreconnect hrefhttps://images.example-cdn.com crossorigin !-- Better than preconnect for speculative vendors -- link reldns-prefetch hrefhttps://analytics.example.com /head使用要点字体源必须带crossorigin字体通过 CORS 获取只对当前路由确定会用、且在首屏附近的源做 preconnect通常控制在 2–4 个对分析、标签管理等可能用但不确定的源dns-prefetch仅做 DNS 解析是比完整preconnect更划算的选择如https://www.googletagmanager.com这类域名同源资源通常收益有限因为浏览器对同源已有成熟的连接复用策略preconnect 主要针对第三方。preconnect 技能文档 归纳了同样的决策规则仅当外部源确定在当前路由、且大约在首屏之前或附近需要时使用preconnect源只是可能时优先dns-prefetch每条页面控制在 2–4 个高价值源对字体等 CORS 资源带上crossorigin。为什么它重要收益与代价参考文档 references/rule.md 列出了四个层面的影响更早发现真正关键的资源preload 可以让首屏图、字体、路由关键 CSS 更早进入网络减少浪费的往返preconnect 可以从关键路径上移除少数已知外部源的 DNS、TCP、TLS 建连后续动作更平滑prefetch 让下一个路由或交互感觉即时误用代价高昂每一个多余的 preload、prefetch、preconnect 都会与更重要的工作争抢带宽、socket 和解析器注意力。html-resource-hints 参考文档 还给出了一个直观的量化为关键字体增加一条 preload 指令可以消除 100–300ms 的 FOITFlash of Invisible Text字体加载期间的文字不可见闪烁。这是因为浏览器原本要等 CSS 解析完才发现字体而 preload 打破了这条依赖链让字体获取与解析并行。框架级落地HTML、Vite、Next.js 与 React参考文档与 content 规则 提供了多框架示例核心写法如下。原生 HTML也适用于 Vite 项目的 index.htmlhead link relpreconnect hrefhttps://fonts.gstatic.com crossorigin link relpreload href/fonts/Inter.woff2 asfont typefont/woff2 crossorigin /headNext.jsApp Router 的 Root Layoutimport type { ReactNode } from react export default function RootLayout({ children }: { children: ReactNode }) { return ( html langen head link relpreconnect hrefhttps://fonts.gstatic.com crossOriginanonymous / link relpreload href/fonts/Inter.woff2 asfont typefont/woff2 crossOriginanonymous / /head body{children}/body /html ) }React配合 react-helmet 管理 headimport { Helmet } from react-helmet function PricingPage() { return ( Helmet link relprefetch href/signup / link relprefetch href/static/signup.js asscript / /Helmet ) }值得注意的是Front-End-Checklist 自身在 Next.js 应用 apps/web/app/layout.tsx 中通过next/font/google自托管 Sora、Public_Sans、Fira_Code 三套字体const sora Sora({ variable: --font-sora, subsets: [latin], display: swap })next/font会自动为这些字体生成preload与preconnect提示包括crossorigin与display: swap配置这正是用框架能力替代手写资源提示的实践路径手写提示容易遗漏crossorigin、as等属性而框架级 API 把正确性内建在工具链里。你也可以在代码审查时核对next/font生成的 HTML 来验证提示是否齐全。常见错误清单综合 references/rule.md 与 html-resource-hints最常见的五类错误是preload 了当前路由并不需要的资源从 CSS、字体和 LCP 资源上偷走带宽prefetch 了当前已经打开的页面不改善发现顺序只会增加噪音preconnect 了太多源为每个供应商都提前打开 socket浪费连接预算与电量漏写as或crossorigin属性错误会降低优先级判断精度或触发重复请求字体双重下载跳过测量资源提示只有在瀑布图确实按预期变化时才有意义改完必须验证。另外还有一条频率极高的具体错误字体 preload 漏掉crossorigin导致双重下载以及对首屏后 2 秒内用不到的资源过度 preload——每个 preload 都在争抢带宽只 preload 真正必要的东西。如何验证自动化检查与手动检查资源提示优化是否生效不能靠感觉必须回到测量数据。参考文档 references/rule.md 给出了标准的验证流程。自动化检查用 Lighthouse、PageSpeed Insights 或浏览器 DevTools 测量受影响页面确认目标指标LCP、TTFB 等确实提升检查 Network 瀑布图或 Performance 时间线确认预期的资源/执行变化真正发生了Lighthouse 中有专门的 preconnect-to-required-origins 审计可用来发现缺失的 preconnectWebPageTest 的 Waterfall 视图可以直观看到 DNS/TCP/TLS 是否被提前。手动检查在节流的移动端 profile 下验证不只是本地桌面环境因为桌面网络往往掩盖建连开销如果该规则对应某个性能预算或 Web Vital 阈值确认页面现在保持在阈值之内对最终渲染出的 HTML浏览器页面源码核验提示标签确实存在且属性完整。总结Resource hints 的核心方法论可以浓缩为一句话只在资源发现得太晚处提示提示的力度dns-prefetch → preconnect → prefetch → preload与资源的重要性、置信度成正比。preload 服务当前路由的关键资产prefetch 预热下一次导航preconnect 为确定要用的第三方源提前建连dns-prefetch 为不确定的源做轻量准备——而每一步都要以瀑布图数据为最终裁判。如果你正在审计慢页面加载建议同时关联仓库中的相关规则一并复查lazy-loading、lazy-above-fold、fetchpriority-attribute与third-party-scripts见 content 规则元数据。它们同属performance/loading区域与资源提示共同构成完整的加载性能优化链路。完整的技能定义与快速参考可见 skills/performance-resource-hints/SKILL.mdHTML 侧的补充细节可参考 skills/html-resource-hints/references/rule.mdpreconnect 专项规则见 skills/preconnect/SKILL.md。赞分享【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址https://gitcode.com/gh_mirrors/fr/Front-End-Checklist点击查看免费下载相关推荐Front-End-Checklist 前端性能指南preload、prefetch、preconnect 与 dns-prefetch 资源提示Resource Hints完整实战Front End Checklist 前端性能指南preload、prefetch、preconnect 与 dns prefetch 资源提示ResouFront-End-Checklist 资源提示Resource Hints实战指南用 preload / prefetch / preconnect 将 LCP 提前 100-300msFront End Checklist 资源提示Resource Hints实战指南用 preload / prefetch / preconnect 将Front-End-Checklist 性能规则实战用 preload、prefetch、preconnect 与 dns-prefetch 精确控制资源加载优先级Front End Checklist 性能规则实战用 preload、prefetch、preconnect 与 dns prefetch 精确控制资源加载创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 用 Resource Hints 加速前端加载：preload、prefetch、preconnect 与 dns-prefetch 实战指南
【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址https://gitcode.com/gh_mirrors/fr/Front-End-Checklist点击查看免费下载Resource hints资源提示让浏览器在常规 HTML 解析流程之外提前发现关键资源从而显著缩短首屏加载的关键路径。本文基于 Front-End-Checklist 仓库中 performance-resource-hints 技能文档及其 references/rule.md 参考文档系统讲解 preload、prefetch、preconnect、dns-prefetch 四种提示的适用场景、决策规则、框架级写法与验证方法并对照仓库源码说明实际项目中的落地方式。读完本文你将掌握如何针对自己的站点判断该提示什么、不该提示什么并用瀑布图数据验证优化是否真正生效。什么是 Resource Hints为什么它们能加速加载浏览器的 HTML 解析器是按顺序发现资源的CSS 文件中引用的字体要等 CSS 被解析之后才会被请求首屏图片要等img标签被解析到才会开始下载。这种串行发现会让关键路径上出现不必要的等待。Resource hints 通过link rel...标签向浏览器提供提前预告让它在资源被正常解析发现之前就启动 DNS 查询、TCP 连接、TLS 握手甚至完整下载。正如参考文档 references/rule.md 所言资源提示只有在浏览器原本会发现得太晚时才真正有用——它只在你用对了时机、命中了正确的资源时才加速用错了反而比不加提示更糟。Front-End-Checklist 将这条规则归类为performance/loading子类别优先级为high、难度intermediate、预估耗时20 分钟对应的内容规则文件位于 packages/content/rules/en/performance/resource-hints.mdx其中列出了四条快速参考要点用preload加载首屏关键资源字体、首屏图用preconnect建立第三方源CDN、API、分析服务的早期连接用prefetch预取下一次导航很可能需要的资源用dns-prefetch作为preconnect的轻量替代。平均而言合理的资源提示可以让 LCPLargest Contentful Paint提升约 100–300ms。四种 Hint 的本质区别与决策规则preload、prefetch、preconnect、dns-prefetch对应浏览器加载流程中不同深度的预热动作Hint用途应避免的场景实用上限preload当前路由、首屏绘制或 LCP 需要但发现得太晚的资源未来路由的资产、低优先级组件、已被及早发现的资源每条路由通常不超过 3–5 个prefetch下一个路由或下一次交互很可能会用、但当前并不必须的资源当前路由的关键资产对带宽敏感用户且下一步不确定时只针对最可能的下一个导航目标preconnect确定即将使用的源尤其是字体、媒体 CDN 或首屏路由上的 API投机性的第三方、很久以后才用的源通常不超过 2–4 个源dns-prefetch置信度较低的外部源此时完整建连为时过早已在关键路径上、值得完整preconnect的源作为轻量回退而非无差别默认这张决策表同样出现在 references/rule.md 和 content 规则 中是整条规则的核心。它的要点是提示的层级越深从 dns-prefetch 到 preconnect 到 preload消耗的资源越多因此只应该为置信度越高的资源使用。dns-prefetch只做 DNS 解析开销最小适合可能用但不确定的源preconnectDNS TCP TLS 全链路建连适合确定马上要用的第三方源prefetch以低优先级提前拉取资源到缓存适合下一步大概率会用的资产preload以高优先级立即获取资源适合当前页面关键路径上、但发现太晚的资产。仓库还提供了独立的 preconnect 技能进一步强调preconnect 只在外部落源确定需要在首屏附近使用、且建连开销原本会落在关键路径上时才有效对于可能用也可能不用的源应优先选择dns-prefetch。实战一用 preload 加速当前路由的关键资产preload告诉浏览器这个资源现在就重要请立刻以高优先级获取。两个最典型的场景是 LCP 候选图和字体。head !-- Good: hero image is the likely LCP candidate -- link relpreload href/images/hero.webp asimage typeimage/webp fetchpriorityhigh !-- Good: route-critical font discovered late through CSS -- link relpreload href/fonts/inter-latin.woff2 asfont typefont/woff2 crossorigin /head几个属性值得注意as声明资源类型image、font、script、style、document等浏览器据此决定请求优先级与缓存复用。缺少as会让 preload 失去优先级意义还可能产生重复请求。type声明 MIME 类型帮助浏览器跳过不需要的下载例如只支持 WebP 的场景。crossorigin字体资源的 preload 必须携带crossorigin否则会触发双重请求一次 no-cors、一次 cors。fetchpriorityhigh进一步提升 LCP 候选图的请求优先级。参考文档 references/rule.md 特别给出了反模式示例——同一页面堆了 6 个字体/脚本 preload 和 3 个投机性 preconnecthead !-- Bad: too many preloads compete with each other -- link relpreload href/fonts/a.woff2 asfont crossorigin link relpreload href/fonts/b.woff2 asfont crossorigin link relpreload href/fonts/c.woff2 asfont crossorigin link relpreload href/carousel.js asscript link relpreload href/reviews.js asscript link relpreload href/chat-widget.js asscript !-- Bad: speculative origins do not deserve early socket setup -- link relpreconnect hrefhttps://chat.example.com link relpreconnect hrefhttps://ads.example.com link relpreconnect hrefhttps://social.example.com /head过多的 preload 会彼此争抢带宽与解析器注意力反而拖慢真正重要的 CSS、字体和 LCP 资源对只在交互后才会用到的聊天、广告、社交组件做 preconnect 则纯属浪费连接预算。实战二用 prefetch 预热下一次导航prefetch以低优先级提前拉取下一个很可能的步骤让后续导航感觉是瞬时的。关键区分在于prefetch 服务于未来路由而不是当前路由。head !-- Good: likely next navigation -- link relprefetch href/checkout link relprefetch href/static/checkout.js asscript !-- Bad: current-route critical CSS should be loaded normally or preloaded -- link relprefetch href/styles/home.css asstyle /head对当前路由的关键 CSS 使用 prefetch 是错误的它不会进入关键路径的优先级队列只是给网络平添噪音。另外也不应 prefetch 当前已经打开的页面那不会改善发现顺序。除了静态标签也可以在交互时动态注入 prefetch 提示例如鼠标悬停到导航链接时再预取目标页hover 场景置信度高值得预取参见 html-resource-hints 参考文档 中的 JS 示例// Prefetch routes the user is likely to visit // Can be triggered on hover for high confidence navLinks.forEach(link { link.addEventListener(mouseenter, () { const prefetch document.createElement(link) prefetch.rel prefetch prefetch.href link.href document.head.appendChild(prefetch) }, { once: true }) })实战三用 preconnect 与 dns-prefetch 处理第三方源第三方源Google Fonts、媒体 CDN、API、分析平台的建连开销——DNS 查询、TCP 握手、TLS 协商——往往都在关键路径上。preconnect可以把这些步骤提前到首屏资源真正发起请求之前完成。head !-- Good: fonts are used in the first viewport -- link relpreconnect hrefhttps://fonts.googleapis.com link relpreconnect hrefhttps://fonts.gstatic.com crossorigin !-- Good: image CDN serves the hero media -- link relpreconnect hrefhttps://images.example-cdn.com crossorigin !-- Better than preconnect for speculative vendors -- link reldns-prefetch hrefhttps://analytics.example.com /head使用要点字体源必须带crossorigin字体通过 CORS 获取只对当前路由确定会用、且在首屏附近的源做 preconnect通常控制在 2–4 个对分析、标签管理等可能用但不确定的源dns-prefetch仅做 DNS 解析是比完整preconnect更划算的选择如https://www.googletagmanager.com这类域名同源资源通常收益有限因为浏览器对同源已有成熟的连接复用策略preconnect 主要针对第三方。preconnect 技能文档 归纳了同样的决策规则仅当外部源确定在当前路由、且大约在首屏之前或附近需要时使用preconnect源只是可能时优先dns-prefetch每条页面控制在 2–4 个高价值源对字体等 CORS 资源带上crossorigin。为什么它重要收益与代价参考文档 references/rule.md 列出了四个层面的影响更早发现真正关键的资源preload 可以让首屏图、字体、路由关键 CSS 更早进入网络减少浪费的往返preconnect 可以从关键路径上移除少数已知外部源的 DNS、TCP、TLS 建连后续动作更平滑prefetch 让下一个路由或交互感觉即时误用代价高昂每一个多余的 preload、prefetch、preconnect 都会与更重要的工作争抢带宽、socket 和解析器注意力。html-resource-hints 参考文档 还给出了一个直观的量化为关键字体增加一条 preload 指令可以消除 100–300ms 的 FOITFlash of Invisible Text字体加载期间的文字不可见闪烁。这是因为浏览器原本要等 CSS 解析完才发现字体而 preload 打破了这条依赖链让字体获取与解析并行。框架级落地HTML、Vite、Next.js 与 React参考文档与 content 规则 提供了多框架示例核心写法如下。原生 HTML也适用于 Vite 项目的 index.htmlhead link relpreconnect hrefhttps://fonts.gstatic.com crossorigin link relpreload href/fonts/Inter.woff2 asfont typefont/woff2 crossorigin /headNext.jsApp Router 的 Root Layoutimport type { ReactNode } from react export default function RootLayout({ children }: { children: ReactNode }) { return ( html langen head link relpreconnect hrefhttps://fonts.gstatic.com crossOriginanonymous / link relpreload href/fonts/Inter.woff2 asfont typefont/woff2 crossOriginanonymous / /head body{children}/body /html ) }React配合 react-helmet 管理 headimport { Helmet } from react-helmet function PricingPage() { return ( Helmet link relprefetch href/signup / link relprefetch href/static/signup.js asscript / /Helmet ) }值得注意的是Front-End-Checklist 自身在 Next.js 应用 apps/web/app/layout.tsx 中通过next/font/google自托管 Sora、Public_Sans、Fira_Code 三套字体const sora Sora({ variable: --font-sora, subsets: [latin], display: swap })next/font会自动为这些字体生成preload与preconnect提示包括crossorigin与display: swap配置这正是用框架能力替代手写资源提示的实践路径手写提示容易遗漏crossorigin、as等属性而框架级 API 把正确性内建在工具链里。你也可以在代码审查时核对next/font生成的 HTML 来验证提示是否齐全。常见错误清单综合 references/rule.md 与 html-resource-hints最常见的五类错误是preload 了当前路由并不需要的资源从 CSS、字体和 LCP 资源上偷走带宽prefetch 了当前已经打开的页面不改善发现顺序只会增加噪音preconnect 了太多源为每个供应商都提前打开 socket浪费连接预算与电量漏写as或crossorigin属性错误会降低优先级判断精度或触发重复请求字体双重下载跳过测量资源提示只有在瀑布图确实按预期变化时才有意义改完必须验证。另外还有一条频率极高的具体错误字体 preload 漏掉crossorigin导致双重下载以及对首屏后 2 秒内用不到的资源过度 preload——每个 preload 都在争抢带宽只 preload 真正必要的东西。如何验证自动化检查与手动检查资源提示优化是否生效不能靠感觉必须回到测量数据。参考文档 references/rule.md 给出了标准的验证流程。自动化检查用 Lighthouse、PageSpeed Insights 或浏览器 DevTools 测量受影响页面确认目标指标LCP、TTFB 等确实提升检查 Network 瀑布图或 Performance 时间线确认预期的资源/执行变化真正发生了Lighthouse 中有专门的 preconnect-to-required-origins 审计可用来发现缺失的 preconnectWebPageTest 的 Waterfall 视图可以直观看到 DNS/TCP/TLS 是否被提前。手动检查在节流的移动端 profile 下验证不只是本地桌面环境因为桌面网络往往掩盖建连开销如果该规则对应某个性能预算或 Web Vital 阈值确认页面现在保持在阈值之内对最终渲染出的 HTML浏览器页面源码核验提示标签确实存在且属性完整。总结Resource hints 的核心方法论可以浓缩为一句话只在资源发现得太晚处提示提示的力度dns-prefetch → preconnect → prefetch → preload与资源的重要性、置信度成正比。preload 服务当前路由的关键资产prefetch 预热下一次导航preconnect 为确定要用的第三方源提前建连dns-prefetch 为不确定的源做轻量准备——而每一步都要以瀑布图数据为最终裁判。如果你正在审计慢页面加载建议同时关联仓库中的相关规则一并复查lazy-loading、lazy-above-fold、fetchpriority-attribute与third-party-scripts见 content 规则元数据。它们同属performance/loading区域与资源提示共同构成完整的加载性能优化链路。完整的技能定义与快速参考可见 skills/performance-resource-hints/SKILL.mdHTML 侧的补充细节可参考 skills/html-resource-hints/references/rule.mdpreconnect 专项规则见 skills/preconnect/SKILL.md。赞分享【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址https://gitcode.com/gh_mirrors/fr/Front-End-Checklist点击查看免费下载相关推荐Front-End-Checklist 前端性能指南preload、prefetch、preconnect 与 dns-prefetch 资源提示Resource Hints完整实战Front End Checklist 前端性能指南preload、prefetch、preconnect 与 dns prefetch 资源提示ResouFront-End-Checklist 资源提示Resource Hints实战指南用 preload / prefetch / preconnect 将 LCP 提前 100-300msFront End Checklist 资源提示Resource Hints实战指南用 preload / prefetch / preconnect 将Front-End-Checklist 性能规则实战用 preload、prefetch、preconnect 与 dns-prefetch 精确控制资源加载优先级Front End Checklist 性能规则实战用 preload、prefetch、preconnect 与 dns prefetch 精确控制资源加载创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考