网站加载慢？用户不是没耐心，是真等不了
你点开一个网站，转圈三秒没反应——手指已经划走了。这不是用户挑剔，是你页面还没来得及“开口说话”，人家就转身去别处了。
预加载不是玄学，也不是给技术简历镀金的词。它是你在用户抬脚前，悄悄把下一扇门推开的动作。
什么是预加载？它和懒加载有什么区别？
懒加载：等用户滑到眼前了，再手忙脚乱去拿资源。
预加载：用户刚站定，你就把ta可能要的东西，提前摆到了桌上。
它们不打架，是前后站位不同的搭档。
比如你做的是装修案例展示站，首页轮播里有5张高清实景图。如果只用懒加载，用户滑到第3张时才开始下载，中间卡顿、白屏、图片一点点“爬”出来——体验像在等电梯开门。换成预加载，用户打开首页那会儿，第2、3、4张图已经在后台静默下载好了，滑动时就是连贯的视觉流。
关键就一句：别等用户点下去才开始跑，要在ta抬手之前，先把路铺好。
有个本地家居设计工作室的网站，以前文章列表页每张封面图都是鼠标悬停才触发加载。结果用户hover半秒就移开了，图还在半路，点击率一直上不去。后来他们改了策略：首页加载完，立刻预加载首屏所有封面图 + 下一屏前3张。悬停响应几乎零延迟，咨询表单提交量也明显提升。
你该预加载哪些资源？3个关键点
预加载不是“越多越好”，而是“刚刚好”。加错地方，反而拖垮首屏。
1. 关键CSS和字体
首屏渲染离不开的CSS，别靠JS异步拉；中文字体文件动辄几百KB，不提前招呼，用户先看一眼“宋体闪现”，再跳成你选的思源黑体——这个闪，比白屏还刺眼。用<link rel="preload">明确告诉浏览器：“这个样式/字体，现在就要。”
2. 用户马上要看到的图片
人在看第一屏，你就该把第二屏的图悄悄下好。怎么判断“马上”？移动端用户一划就是半屏，你可以监听滚动位置+速度，快滑就多载两张，慢翻就只载下一张。别一口气拉20张缩略图——用户流量不是你的测试服务器。
3. 下一个页面的核心资源
用户还在浏览你写的“小户型收纳技巧”，其实ta很可能点开第三条“宜家平替清单”。这时候，你就可以用prefetch提前把那篇文章的CSS、JS、甚至首屏HTML骨架拉下来。等ta真点进去，页面几乎是“啪”一下弹出来。
有个独立摄影博客作者这么干：文章列表页加载完，自动prefetch阅读量最高的3篇详情页。读者从列表跳转到正文，几乎感觉不到等待，平均停留时间直接翻倍。
预加载的4种实现方式，别再只用一种
别把rel="preload"当万能胶带。不同场景，得换不同工具。
方法一：<link rel="preload">
适合“现在就要”的资源：首屏CSS、关键字体、核心JS。一定要加as属性（比如as="font"），不然浏览器没法按类型缓存，等于白喊。
方法二：<link rel="prefetch">
适合“待会儿可能要用”的资源：下一页的CSS、某个二级页面的JS。优先级低，浏览器空闲时才下载，不抢首屏带宽。
方法三：JS动态预加载
想更精细控制？比如用户鼠标在“预约咨询”按钮上悬停超过300ms，就立刻new Image().src = '/contact-page.js'。这种交互式预加载，特别适合内容型站点。
方法四：Service Worker预缓存
如果你的网站已接入PWA（比如用了Workbox），可以在install阶段把首页、文章页模板这些高频资源缓存进本地。用户第二次访问，连网络都不用碰。
建议组合着来：首屏命脉用preload，下一步大概率点的用prefetch，常驻页面用Service Worker兜底。别死守一种，就像做饭不光靠盐。
预加载做错了，反而会拖慢网站
我见过太多人加了一堆preload，结果首页更慢了——不是预加载有问题，是没想清楚“谁该先上”。
雷区1：预加载太多，首屏反被拖累
把整站图片、所有字体、连404页面的JS都preload一遍？浏览器会优先下载这些，首屏渲染反而排队等。记住：只预加载用户睁眼就看到、或者3秒内大概率会看到的内容。
雷区2：预加载和懒加载撞车
HTML里写了<link rel="preload" href="hero.jpg">，JS里又用lozad.js去懒加载同一张图——资源被下了两次。检查你的图片加载逻辑，预加载过的，懒加载插件就绕道走。
雷区3：忘了老浏览器
IE？不认preload。加了也白加。简单办法：用JS检测document.createElement('link').relList.supports('preload')，不支持就退化成XMLHttpRequest手动拉，或干脆不预加载。
有个教育类网站吃过亏：首页所有中文字体全preload，结果字体文件太大，首屏渲染被卡住。后来只预加载标题用的那款字体，正文用prefetch空闲时载，页面“呼吸感”立马回来了。
预加载在移动端和PC端，策略完全不同
手机和电脑上的用户，根本不是同一批人，连“等”的耐性都不一样。
移动端：信号飘、流量贵、手指快。预加载要“轻”：只载当前视口+下一屏的小图；用<link rel="preconnect">提前连CDN，省掉DNS查询那几百毫秒——这招成本极低，但对弱网用户很友好。
PC端：鼠标悬停是天然预告。用户把指针停在“免费试听”按钮上0.3秒，基本就是在说“我准备点了”。这时候用JS触发prefetch，比等点击再发请求快得多。另外，PC用户爱开一堆标签页，预加载请求数得控住，别一把占满6个并发通道。
之前帮一个在线乐器教学平台调优：移动端滚动时，只预加载下一屏的课程缩略图（压缩到100KB以内）；PC端则在用户hover课程卡片时，预加载详情页的视频封面+简介数据。改完后，移动端跳出率降了，PC端试听按钮点击率涨了。
今天就能执行的3个操作步骤
别收藏吃灰。现在打开浏览器，照着做：
第一步：打开Chrome DevTools → Network 标签页 → 刷新你的首页
盯紧那几个红色警告图标，特别是加载时间长的CSS、字体、大图。挑出首屏必须的1–2个资源，在<head>里加上<link rel="preload" as="style" href="main.css">，再刷新测一次首屏渲染时间。
第二步：找你网站的列表页（文章/商品/案例）
在页面底部加一段轻量JS：监听滚动，当用户快到底部时，动态插入<link rel="prefetch" href="https://yoursite.com/img/thumb-2.jpg">，只预加载下一页的缩略图URL，别载整页。
第三步：在导航链接上加悬停预加载
比如你的“关于我们”链接是<a href="/about">关于我们</a>，就加一行JS：当鼠标悬停超过300ms，执行const link = document.createElement('link'); link.rel = 'prefetch'; link.href = '/about'; document.head.appendChild(link);。用户移开也不撤，资源留着备用。
做完这三步，再用Lighthouse跑一次性能分。你会看到“最大内容绘制”（LCP）那栏，数字变小了——用户真的感受到了。
今晚睡前花20分钟，改完就部署。别等“下次迭代”，用户不会为你的排期买单。