你的网站加载慢，真不怪服务器

图片压了，代码缩了，CDN也上了——可用户点开首页还是卡一下。别急着升级带宽，先看看浏览器是不是在“等指令”。预加载这事儿，就像提前叫好外卖，等你饿了，饭已经热在门口了。

预加载到底是什么？它如何偷偷帮你提速？

预加载就是你在 HTML 里写一句“这个文件马上要用，现在就去下”，让浏览器趁还没忙起来，先把资源悄悄拉进缓存。

它不抢当前页面的网速，也不打断首屏渲染。只挑那些“不用等不住”的东西：比如第一眼看到的大图、撑起排版的字体、或者一打开就要动效的 JS。

就像你刷电商列表页时，手指已经悬在某个商品上——这时候提前把它的详情页 JS 下好，点下去的瞬间，3D 旋转直接转起来，根本不用等。

一个真实案例：我们帮一家家居电商优化产品页。用户从列表页点进去，总要顿半秒才看到 3D 模型。查下来发现，那个模型渲染脚本体积大、又没压缩。我们在列表页 <head> 里加了一行预加载，上线后，用户反馈“点进去快多了”，实际首屏可交互时间也明显缩短。

预加载有哪几种？别用错了“工具”

预加载不是万能膏药，不同场景得用不同的 <link> 标签。用错反而拖后腿：

  1. <link rel="preload">：干最急的活。当前页面立刻需要的资源，必须加载。比如首屏字体、关键 CSS、主图。
  2. <link rel="prefetch">：干“以后可能用”的活。用户下一步大概率点的链接对应的资源，比如搜索结果页的 JS，优先级低，空闲时才下载。
  3. <link rel="prerender">：太猛，慎用。不只是下载，连整个页面都提前在后台渲染好。适合极少数跳转路径非常固定的场景（比如登录页→控制台），但内存和流量吃得多。
  4. <link rel="dns-prefetch"> 和 <link rel="preconnect">：打地基的活。前者提前查好第三方域名的 IP 地址；后者连 TCP 和 TLS 握手都提前做完。适合你要从 cdn.jsdelivr.net 或 fonts.googleapis.com 加资源的情况。

最容易搞混的是 preload 和 prefetch：

  • preload 是给“我现在就要用”的资源；
  • prefetch 是给“我待会儿可能点进去”的页面准备的。
    拿下一个页面的 JS 用 preload 塞进当前页？它会跟首屏资源抢带宽，反而让首页更慢。

如何正确设置预加载？手把手教你操作

全靠一行 <link>，加在 HTML 的 <head> 最开头，越早越好。

关键是两个属性：

  • rel 决定“干什么”（preload / prefetch / preconnect）
  • as 告诉浏览器“这是啥”，它才能按正确优先级处理。比如 as="font" 会让字体加载不阻塞文本渲染，as="script" 才会触发 JS 解析队列。

常用组合：

<!-- 预加载关键字体，注意 crossorigin -->
<link rel="preload" href="fonts/inter.woff2" as="font" type="font/woff2" crossorigin>

<!-- 预加载首屏必需的 CSS -->
<link rel="preload" href="/css/critical.css" as="style">

<!-- 提前连上 CDN，为后续资源提速 -->
<link rel="preconnect" href="https://cdn.example.com">

实操建议：打开 Chrome，右键 → “检查” → 切到 Lighthouse 面板，点“生成报告”。跑完后直接看“机会”栏——它会明确告诉你：“预加载关键请求”，并列出 1～3 个最该加的资源地址。这就是你今天的任务清单。

预加载的常见陷阱：为什么你设置了却没效果？

加了标签 ≠ 起效。这几个坑，我们踩过：

陷阱一： preload 了不重要的东西
比如给页脚的统计 JS 或隐私弹窗 CSS 加了 preload。它们根本不影响首屏，反而挤占带宽，让真正关键的资源排队。

陷阱二：标签放得太晚
如果 <link rel="preload"> 写在 <head> 里一堆 CSS 和 JS 后面，或者用 JS 动态插入，浏览器读到它时，首屏资源早就开始下载了。它得出现在 <head> 第一行附近。

陷阱三：资源根本没缓存
预加载一次，下次访问还得重下？检查服务器返回头：确保 Cache-Control: public, max-age=31536000 这类长效缓存生效。否则预加载只是白忙一场。

陷阱四：一口气 preload 二十个资源
我们试过在一个新闻站首页预加载十几张次日头条图——结果移动端加载变慢，用户滑动都卡。预加载是精准狙击，不是地毯轰炸。

如何验证预加载是否真的生效了？

别信感觉，看网络面板。

打开 Chrome DevTools → “网络”（Network）标签页 → 刷新页面。

  • 找到你预加载的资源，看“Size”列：如果是 from memory cache 或 from disk cache，且时间戳比它被实际调用的时间早很多，基本就成了；
  • 看“瀑布图”：预加载请求会出现在非常靠前的位置，旁边标着浅绿色 “Preload” 字样；
  • 切到“性能”（Performance）面板录一段，展开“网络”轨道——预加载请求会在 HTML 解析刚开始时就冒出来。

如果没看到这些，先检查路径对不对、as 值写没写错、有没有被其他 <link> 或 <script> 挡在后面。

今天下班前就能执行的一个具体步骤

现在，打开你正在维护或最常改的那个网站的首页。
按 F12 打开 Chrome DevTools → 切到 “Lighthouse” 面板 → 点击 “生成报告”。
等分析完成，直接点开 “机会” 折叠栏 → 找到 “预加载关键请求”。

复制第一个推荐资源的 URL（比如 /assets/main.css），打开你网站的 HTML 模板文件（通常是 index.html 或 _layout.html），找到 <head> 开头，在第一行就粘贴：

<link rel="preload" href="/assets/main.css" as="style">

保存，推送到测试环境，再跑一遍 Lighthouse。对比前后“性能”分数和“机会”列表——如果那条建议消失了，说明它已生效。