只有stylesheet、icon、preload、modulepreload能触发资源加载;prefetch和preconnect行为迥异,混用拖慢首屏;noopener/noreferrer在link上无效;next/prev等值已被弃用。
link 标签引入外部资源,rel 值不是“随便填的描述”,填错就等于没写——浏览器要么忽略,要么加载错类型、触发错误策略、甚至埋下安全漏洞。
rel 值真能触发资源加载?只有明确告诉浏览器“这是什么”的值,才会真正下载并处理资源:
stylesheet:唯一能加载并应用 CSS 的值;写成 style、css 或漏掉 rel,样式表不会生效icon:会触发 favicon 下载,但必须配 type(如 image/x-icon)和 sizes(如 32x32),否则多数浏览器 fallback 到根目录 /favicon.ico,且不保证显示preload:会提前加载资源,但必须带 as(如 as="script" 或 as="font"),否则降级为普通 link,不预加载modulepreload:只对 ES 模块 JS 有效,as="script" 不够,必须是模块语法(含 type="module" 的脚本才能用它加载)rel="prefetch" 和 rel="preconnect" 容易误配的边界这两个值看起来都“提前做点事”,但行为差异极大,混用反而拖慢首屏:
prefetch 是空闲时低优先级获取整个响应体(HTML、JS、JSON 都行),适合用户**下一步大概率访问的页面**;写成 prefetch 却指向一个 2MB 的图片,会浪费带宽preconnect 只建立 TCP + TLS 连接,不发 HTTP 请求,必须是**完整协议+域名**(如 https://cdn.example.com),不能带路径(/fonts/xxx.woff2 会失败)link;写成 rel="preconnect" href="https://a.com https://b.com" 会被当做一个非法 URL 忽略dns-prefetch 更轻量,只查 DNS,对 HTTPS 站点收益有限——现代浏览器已自动优化同域 DNS 查询rel 写在 link 上却想防 XSS?别白费力气noopener、noreferrer 这类值,在 link 标签上完全无效:
立即学习“前端免费学习笔记(深入)”;
a[target="_blank"] 场景下起作用,用于切断 window.opener 访问和 referrer 泄露<link rel="stylesheet"> 或 <link rel="icon"> 上,浏览器直接忽略,既不报错也不生效noreferrer 和 no-referrer:后者是 <meta name="referrer"> 的 content 值,协议层级不同,不能互换rel="noopener noreferrer" 的是 a 标签,不是 link
rel 值不少教程还在列这些,但它们要么被规范移除,要么浏览器根本不实现:
next/prev:Chrome 曾尝试预取,现已被弃用;搜索引擎也明确表示不再用于分页识别——Pagination 应靠 rel="canonical" + JSON-LD 结构化数据alternate 单独使用(无 hreflang 或 type):对 SEO 零效果;Google 明确不识别纯 rel="alternate"
author、help、license:HTML5 保留语义,但浏览器既不加载、也不暴露 API、更不参与渲染或索引shortlink:RFC 4287 定义,但无任何浏览器行为;GitHub 等平台用它只是内部约定,非标准执行真正关键的不是“有多少个 rel 值”,而是每个值是否被浏览器按规范解析——漏掉 as、错配 type、或把语义值当功能值用,都会让 link 标签变成一段安静的 HTML 注释。