1. 网页加载速度的瓶颈到底卡在哪做前端这些年被问得最多的问题之一就是“页面怎么还是这么慢”。很多人第一反应是压缩图片、上CDN、开gzip这些当然有用但做完之后往往发现首屏该慢还是慢。问题出在哪出在浏览器拿到HTML之后才开始一个个去发现CSS、JS、字体、图片这些资源发现一个请求一个请求回来再解析解析完再发现下一层依赖。这个“串行发现”的过程才是真正吃掉时间的元凶。预加载器Preloader要解决的就是这件事。它的核心思路非常朴素在浏览器正式解析HTML之前提前告诉它“待会儿你会用到这些东西先去拿”。浏览器内部其实一直有一个预加载扫描器Preload Scanner它会在主解析器被JS阻塞的时候偷偷往后扫HTML把能提前拿的资源先发起请求。但这个扫描器能力有限它只能看到HTML里写死的标签对于JS动态插入的、CSS里引用的、字体文件里的资源它一概看不见。所以我们要做的就是用preload、prefetch、preconnect、dns-prefetch这一套资源提示Resource Hints指令把预加载扫描器看不到的关键资源手动喂给它。这篇文章就是把我自己在多个项目里落地预加载器的完整思路、参数选择、踩过的坑一次性讲清楚。不管你是刚接触性能优化的新手还是已经调过几轮Lighthouse的老手应该都能从里面找到能直接抄的东西。先明确一下适用范围这套方法对内容型站点、电商详情页、后台管理系统、移动端H5都适用尤其是那种首屏依赖自定义字体、首屏大图、关键CSS框架的场景收益最明显。下面我按“思路拆解—细节解析—实操落地—问题排查”的顺序展开中间会穿插具体的代码和参数计算。2. 预加载器的整体设计与方案选型2.1 为什么不能只靠浏览器自带的预加载扫描器浏览器自带的预加载扫描器Preload Scanner是一个独立于主解析器的轻量级扫描线程。它的工作方式是主线程在解析HTML遇到script阻塞时扫描器继续往后读HTML源码遇到link relstylesheet、script src、img src这类标签就提前发起请求。听起来很美好但它有几个硬伤。第一它看不到JS动态创建的资源。比如你用document.createElement(link)插入的CSS或者React/Vue组件里动态import的chunk扫描器完全无感。第二它看不到CSS内部的引用。一个background-image: url(...)扫描器要等CSS下载并解析完才知道有这个图片。第三它看不到字体文件。font-face里的src指向的woff2同样要等CSS解析。第四它的优先级判断比较粗糙有时候会把非关键资源提到关键资源前面反而拖慢首屏。我实测过一个典型场景一个首屏用了自定义字体的落地页不做任何预加载时字体请求要等CSS下载解析完才发起LCP最大内容绘制时间比做了字体预加载的版本慢了将近400ms。这400ms在移动端4G网络下就是实打实的用户流失。2.2 preload、prefetch、preconnect、dns-prefetch到底怎么选这四个指令经常被混用其实它们解决的是不同阶段的问题。我用一个表格把它们的区别列清楚这是我在实际选型时最常用的对照表。指令作用阶段优先级典型用途是否跨域需加crossorigindns-prefetchDNS解析最低提前解析第三方域名否preconnectDNSTCPTLS中提前建立连接是跨域时preload当前页面必需资源高字体、首屏图、关键CSS/JS是字体和跨域资源必须prefetch下一个页面可能用到的资源最低预取下一页的JS chunk否选型的逻辑是这样的如果资源是当前页面渲染必需的用preload如果是下一个导航可能用到的用prefetch如果只是知道待会儿要连某个第三方域名但还不确定具体资源用preconnect如果连连接都嫌贵只想省DNS那几十毫秒用dns-prefetch。这里有个容易搞混的点preload的优先级是“高”它会和当前页面的关键资源抢带宽。所以千万不要滥用只preload真正影响首屏的东西。我见过有人把十几个图片全preload结果首屏CSS的请求被挤到后面LCP反而变差。这是典型的“优化变劣化”。2.3 预加载策略的三种落地模式在实际项目里我一般把预加载策略分成三种模式按项目复杂度递进。第一种是静态声明式直接在HTML的head里写死link relpreload。适合资源固定的场景比如官网首页的字体和主视觉图。优点是零JS依赖浏览器一拿到HTML就开始预加载时机最早。缺点是灵活性差资源变了要改HTML。第二种是构建时注入式用Webpack、Vite这类构建工具的插件在打包时自动把关键资源注入到HTML模板里。比如html-webpack-plugin配合自定义钩子或者Vite的transformIndexHtml。这种方式适合资源带hash、每次构建都变的场景能自动维护preload列表。第三种是运行时动态式用JS在页面加载早期根据路由、设备、网络状况动态插入link relpreload。适合SPA比如根据当前路由预加载下一个页面的chunk。但要注意JS插入的preload时机比HTML里写死的晚收益会打折扣所以只用于非首屏关键的预取。我的建议是首屏关键资源用第一种或第二种非首屏的用第三种。三者可以组合不冲突。3. 核心细节解析与实操要点3.1 preload的as属性写错等于白写link relpreload必须带as属性它告诉浏览器这个资源的类型浏览器据此设置正确的优先级、请求头和缓存策略。as的值可以是script、style、font、image、fetch、document等。写错as的后果很严重浏览器会把它当成未知类型用低优先级去拿而且可能重复下载。我踩过的一个坑字体文件写成了asfont但忘了加crossorigin结果浏览器发了两次请求一次是preload的匿名请求一次是CSS里font-face发起的带凭据请求两者缓存不命中白白浪费一个RTT。字体文件因为受CORS限制crossorigin是必须的哪怕同域也要加。这个细节很多文档一笔带过但实际不写就是双倍请求。!-- 正确写法字体必须带crossorigin -- link relpreload href/fonts/main.woff2 asfont typefont/woff2 crossorigin !-- 正确写法首屏关键CSS -- link relpreload href/css/critical.css asstyle !-- 正确写法首屏JS -- link relpreload href/js/app.js asscript还有一个细节type属性虽然不是必须的但强烈建议加上。浏览器可以用它来判断自己是否支持这个格式不支持就不下载。比如typefont/woff2老浏览器不支持woff2就直接跳过省一次无用请求。3.2 字体预加载收益最大也最容易翻车字体是预加载收益最明显的资源因为字体文件通常几百KB而且它阻塞文本渲染。如果不预加载浏览器要等CSSOM构建完、发现font-face、再发起请求这个链路很长。预加载能把字体请求提前到和CSS并行。但字体预加载有几个坑。第一crossorigin必须加前面说了。第二不要preload所有字重。一个字体家族可能有regular、medium、bold、light四个文件全preload就是四倍带宽。我的做法是只preload首屏实际用到的字重通常是regular和bold两个。第三考虑用font-display: swap配合让文本先用系统字体渲染字体加载完再替换避免FOIT不可见文本闪烁。参数上我一般会算一下假设字体文件200KB移动端4G下行约1.5MB/s下载耗时约130ms。如果不预加载这130ms要叠加在CSS解析之后实际感知延迟可能到300ms以上。预加载后这130ms和CSS下载并行感知延迟降到接近0。这就是为什么字体预加载的ROI特别高。3.3 首屏图片预加载响应式图片的坑首屏大图Hero Image通常是LCP元素预加载它能直接改善LCP指标。但响应式图片用srcset时浏览器要根据视口宽度、DPR设备像素比来选择具体加载哪张图。如果你在HTML里写死preload某一张可能和浏览器实际选择的不一致导致重复下载。正确的做法是用imagesrcset和imagesizes属性让preload也参与响应式选择link relpreload asimage href/img/hero-800.jpg imagesrcset/img/hero-400.jpg 400w, /img/hero-800.jpg 800w, /img/hero-1600.jpg 1600w imagesizes100vw这样浏览器会根据和img相同的逻辑选择图片避免重复。这个写法兼容性已经不错现代浏览器都支持。如果项目要兼容很老的浏览器可以退化成只preload默认图但要接受可能的重复下载。3.4 prefetch的时机与优先级控制prefetch的优先级是“最低”浏览器会在空闲时下载不影响当前页面。它适合预取下一个页面要用的资源。比如用户在列表页你预判他可能点进详情页就prefetch详情页的JS chunk。但prefetch有个问题它下载的资源会存进HTTP缓存如果用户一直不导航到那个页面这次下载就浪费了。所以prefetch要基于真实的行为预测不能瞎猜。我的经验是对于转化路径明确的场景比如电商从列表到详情prefetch收益明显对于路径发散的场景收益不稳定。另外SPA里用Webpack的magic comment可以很方便地做prefetch// 预取详情页chunk但不立即执行 import(/* webpackPrefetch: true */ ./DetailPage);这行代码会在浏览器空闲时下载DetailPage的chunk。注意是webpackPrefetch不是webpackPreload后者会立即以高优先级下载用错了会拖慢当前页面。3.5 优先级提示fetchpriority的补充作用除了preload现代浏览器还支持fetchpriority属性可以手动调整资源优先级。比如首屏大图可以设fetchpriorityhigh非首屏的轮播图设fetchprioritylow。它和preload配合使用效果更好preload负责提前发起fetchpriority负责调整在请求队列里的位置。img src/img/hero.jpg fetchpriorityhigh alt首屏主图 link relpreload href/img/hero.jpg asimage fetchpriorityhigh不过要注意fetchpriority和preload同时用时如果优先级设置冲突以preload的为准。这个属性目前Chrome、Edge、Firefox都支持Safari稍晚但也跟上了。对于不支持的老浏览器它会忽略不影响功能。4. 实操过程与核心环节实现4.1 第一步用Lighthouse和DevTools定位真正的瓶颈优化之前先测量不然就是瞎猜。我一般用两个工具Lighthouse看整体评分和LCP、FCP指标Chrome DevTools的Performance面板看具体的请求瀑布图。在Performance面板里重点看几个东西主线程被阻塞的时间段、资源请求的发起时机、有没有串行的依赖链。比如你看到字体请求在CSS解析完之后才发起那就是典型的预加载缺失。再比如你看到首屏图片的请求排在很后面那就是优先级问题。我习惯把瀑布图截图标出每个关键资源的“发现时间”和“发起时间”。这两个时间差越大说明预加载的收益空间越大。字体通常差几百毫秒首屏图差一两百毫秒这些都是可以抢回来的。4.2 第二步确定关键资源清单不是所有资源都值得预加载。我的筛选标准是三条影响首屏渲染的、体积较大的、发现时机较晚的。三条都满足的优先preload。具体来说首屏关键CSS、首屏JS、自定义字体、LCP图片这四类基本都要preload。非首屏的图片、下一个页面的chunk、第三方统计脚本这些用prefetch或干脆不预加载。这里有个判断技巧打开DevTools的Coverage面板看哪些CSS和JS在首屏被用到了。如果某个CSS文件首屏只用了一小部分那说明它不该被preload而应该拆分出关键CSS单独preload。这个拆分工作可以用critical这类工具自动提取。4.3 第三步在HTML中落地preload标签确定清单后在head里按优先级顺序写preload。顺序很重要浏览器按HTML里的出现顺序处理所以把最关键的放最前面。head !-- 1. 关键CSS最先 -- link relpreload href/css/critical.css asstyle !-- 2. 字体次之 -- link relpreload href/fonts/main-regular.woff2 asfont typefont/woff2 crossorigin link relpreload href/fonts/main-bold.woff2 asfont typefont/woff2 crossorigin !-- 3. 首屏JS -- link relpreload href/js/app.js asscript !-- 4. LCP图片 -- link relpreload asimage href/img/hero.jpg fetchpriorityhigh !-- 5. 第三方域名预连接 -- link relpreconnect hrefhttps://cdn.example.com crossorigin link reldns-prefetch hrefhttps://analytics.example.com /head注意preload的CSS和JS如果只是preload而不实际使用浏览器会警告“资源被预加载但未在几秒内使用”。所以preload的资源必须在页面里真实引用否则就是浪费。比如preload了critical.css后面必须有一个link relstylesheet href/css/critical.css来消费它。4.4 第四步构建时自动注入preload手动维护preload列表在资源带hash的项目里很痛苦每次构建hash都变。我用Vite的话会在vite.config.js里写一个插件在transformIndexHtml钩子里读取manifest把关键chunk注入preload。// vite.config.js 简化示例 export default { plugins: [{ name: inject-preload, transformIndexHtml(html, ctx) { const manifest ctx.bundle; const preloads []; for (const [key, chunk] of Object.entries(manifest)) { if (chunk.type chunk chunk.isEntry) { preloads.push(link relpreload href/${chunk.fileName} asscript); } if (chunk.type asset key.endsWith(.css)) { preloads.push(link relpreload href/${chunk.fileName} asstyle); } } return html.replace(/head, preloads.join(\n) /head); } }] };Webpack的话用html-webpack-plugin的preload选项或者自己写一个插件在emit阶段改HTML。核心思路是一样的从构建产物里挑出关键资源注入到head。4.5 第五步验证预加载是否生效写完preload后一定要验证。打开DevTools的Network面板看资源的“Initiator”列。如果显示的是“preload”说明预加载生效了如果显示的是“parser”或“script”说明没生效可能是as写错或者标签位置不对。还要看有没有重复请求。同一个资源出现两次一次是preload一次是实际使用说明缓存没命中通常是crossorigin或as不匹配导致的。这种情况必须修否则预加载反而增加负担。最后用Lighthouse再跑一次对比LCP、FCP、TTI的变化。正常情况下字体预加载能让FCP提升10%到20%首屏图预加载能让LCP提升15%到30%。如果没提升甚至变差就要回头检查是不是preload了非关键资源抢了带宽。5. 常见问题与排查技巧实录5.1 预加载了但浏览器警告“未使用”这个警告的意思是你preload了一个资源但页面在几秒内没有真正引用它。常见原因有三个。一是preload的URL和实际引用的URL不一致比如多了个查询参数或者路径大小写不同。二是preload了但对应的link relstylesheet或script被JS延迟插入了浏览器等不及。三是preload了根本不需要的资源纯属多余。排查方法在Network面板里找到那个资源看它的Initiator是不是preload然后看页面里有没有对应的消费标签。如果URL不一致用绝对路径统一。如果是JS延迟插入考虑把消费标签也提前或者干脆不preload。5.2 字体预加载后出现双倍请求前面提过字体必须加crossorigin。但还有一种情况font-face里的src用了local()优先浏览器先找本地字体找不到才下载。如果本地有同名字体preload的远程字体就白下了。这种情况要么去掉local()要么接受这个浪费。还有一种双倍请求是CDN域名和主域不一致导致的。preload用的是主域URLCSS里用的是CDN URL浏览器视为两个资源。解决方法是统一URL或者preload时就用CDN的绝对URL。5.3 preload抢带宽导致首屏更慢这是最典型的“优化变劣化”。原因通常是preload了太多非关键资源或者preload的资源优先级设得太高把真正关键的CSS/JS挤下去了。排查方法在Network面板按优先级排序看高优先级的请求里有没有不该出现的。我的经验法则是首屏preload的资源不超过5个总大小不超过500KB。超过这个数就要重新审视哪些是真的关键。另外preload的图片如果很大比如超过200KB考虑用fetchprioritylow降级或者干脆不preload让它自然加载。5.4 prefetch的资源一直没被使用prefetch是空闲时下载如果用户一直不导航到目标页面这些下载就浪费了。更糟的是如果prefetch的资源很大会占用带宽和磁盘缓存。排查方法在Application面板的Cache Storage里看prefetch的资源有没有被后续页面命中。我的做法是只对转化路径明确的下一页做prefetch而且限制prefetch的资源大小。对于路径不确定的场景宁可不prefetch也不要浪费用户流量。移动端尤其要注意用户可能用的是按流量计费的网络。5.5 常见问题速查表现象可能原因解决方法浏览器警告preload未使用URL不一致或消费标签延迟统一URL提前消费标签字体双倍请求缺crossorigin或URL不一致加crossorigin统一URL首屏变慢preload过多或优先级冲突精简preload列表调整fetchpriorityprefetch浪费用户未导航到目标页只对明确路径prefetch限制大小preload不生效as写错或标签位置不对检查as值放到head最前重复下载缓存未命中检查crossorigin和as匹配5.6 几个容易被忽略的实操心得第一个心得preload的标签位置比你想的重要。放在head最前面和放在中间实际发起时机可能差几十毫秒。因为浏览器是流式解析HTML的越早看到越早发起。我一般把最关键的CSS和字体preload放在meta charset之后、所有其他标签之前。第二个心得不要preloaddocument类型的资源。有人想preload下一个HTML页面用asdocument但浏览器对它的支持不好而且prefetch更适合这个场景。preload document容易导致当前页面导航被干扰。第三个心得HTTP/2下preload的收益会变化。HTTP/2支持多路复用多个请求可以并行所以preload的“提前发起”收益相对HTTP/1.1会小一些。但字体和动态插入的资源仍然受益因为它们的发现时机问题没变。不要因为上了HTTP/2就完全放弃preload。第四个心得Service Worker和preload可以配合。Service Worker可以拦截preload的请求从缓存直接返回进一步降低延迟。但要注意Service Worker的安装时机如果它还没激活preload还是走网络。这个组合适合PWA场景。第五个心得监控真实用户的预加载效果。Lighthouse是实验室数据真实用户的网络环境千差万别。我一般会埋点记录字体的实际加载时间、LCP的实际分布用RUM真实用户监控数据来验证预加载的收益。有时候实验室里提升明显真实环境里因为网络抖动收益被稀释了。6. 不同场景下的预加载组合策略6.1 内容型站点字体和首图优先内容型站点博客、新闻、文档的首屏核心是文字和主图。字体预加载收益最大因为文字是主要内容字体阻塞直接影响阅读。首图如果是LCP元素也要preload。CSS方面如果用了UI框架建议提取关键CSS单独preload框架CSS用prefetch或异步加载。这类站点的预加载清单通常很短一个regular字体、一个bold字体、关键CSS、首图。四个资源总大小控制在300KB以内。prefetch可以预取下一篇文章的图片但要看用户滚动行为不一定值得。6.2 电商详情页图片和交互JS并重电商详情页的首屏有商品主图、价格、购买按钮。主图通常是LCP元素必须preload。购买按钮的交互JS如果体积大也要preload否则用户点的时候才加载体验差。字体如果用了品牌字体同样preload。这类页面的坑在于图片多。主图preload但缩略图、详情图不要preload用懒加载。prefetch可以预取购物车页面的chunk因为从详情页到购物车是明确路径。6.3 后台管理系统JS chunk和字体后台系统的首屏通常是框架JS和登录态检查。JS chunk体积大preload能明显改善TTI。字体如果用了图标字体也要preload否则图标会闪烁。CSS方面后台系统一般用组件库关键CSS提取比较麻烦可以只preload框架CSS。后台系统的特点是路由多prefetch很有用。根据当前路由预取相邻路由的chunk用户点击时几乎秒开。Webpack的webpackPrefetch在这里很合适。6.4 移动端H5轻量化优先移动端网络和CPU都受限预加载要更克制。字体预加载仍然值得但只preload一个regular字重bold用合成。首图preload要考虑DPR用imagesrcset避免下载过大图。prefetch在移动端要慎用因为流量贵用户可能不领情。移动端还有一个特殊点preconnect的收益比桌面端大因为移动网络建立连接的开销更高。对第三方域名先dns-prefetch再preconnect能省几十到上百毫秒。7. 预加载器的边界与后续扩展预加载器不是银弹它解决的是“发现时机”问题不解决“资源太大”问题。如果一个字体文件2MBpreload也只能让它早点开始下载下载时间还是那么长。所以预加载要和资源压缩、格式优化配合。字体用woff2图片用AVIF/WebPJS做tree-shaking这些是基础。另外预加载的收益会随着浏览器能力进化而变化。现在浏览器自带的预加载扫描器越来越聪明fetchpriority、priority hints这些新API也在普及。未来可能很多现在需要手动preload的场景浏览器会自动处理。但至少目前手动预加载仍然是性价比很高的优化手段。后续可以扩展的方向用Speculation Rules API做更激进的预渲染用103 Early Hints在服务端就告诉浏览器预加载什么。这两个是更前沿的方案适合对性能要求极高的场景。我目前在几个项目里试了Early Hints配合preloadLCP能再降10%左右但需要服务端和CDN支持落地成本比纯前端preload高。最后分享一个我自己的检查习惯每次上线前用DevTools的Network面板把网络限速到“Slow 4G”然后硬刷新看首屏关键资源的请求瀑布图。如果字体、首图、关键CSS的请求都在HTML解析的早期就发起了说明预加载到位了。如果还有资源排在后面等就继续补preload。这个习惯帮我抓出了不少遗漏。