按需加载实战指南：提升前端性能的关键技术解析
设计师艺天在移动端项目中落地按需加载：一次真实的性能优化实战
去年我接手了一个面向三四线城市用户的电商小程序，技术栈是 Vue 3 + Vite + TypeScript。项目初期为了赶上线，很多页面和组件都是全量打包，首屏加载时间一度飙到 4 秒以上。用户反馈“点开就卡住”，尤其在低端安卓机上体验更差。老板直接拍桌子：“再不优化，下个月 KPI 扣光。” 我们团队评估后决定引入按需加载（Lazy Loading）策略，把非首屏资源拆出来，能晚加载的绝不提前。说白了，就是让用户先看到东西，再慢慢补内容。
技术应用：从路由到组件的全面懒加载
我们主要从两个层面动手：路由级懒加载和组件级懒加载。前者用 Vue Router 的动态 import，后者用 defineAsyncComponent。Vite 对动态 import 原生支持，不用额外配置，这点比 Webpack 省心多了。
路由懒加载改造很简单，把原来的静态引入换成动态导入就行：
const routes = [
{
path: '/home',
component: () => import('@/views/Home.vue')
},
{
path: '/product/:id',
component: () => import('@/views/ProductDetail.vue')
}
]
对于首页里那些“下面还有”的模块，比如商品推荐、用户评价，我们用 defineAsyncComponent 包一层，配合 Intersection Observer 实现滚动触发：
import { defineAsyncComponent } from 'vue'
const LazyRecommend = defineAsyncComponent(() =>
import('@/components/RecommendSection.vue')
)
// 在模板中使用
// <LazyRecommend v-if="shouldLoadRecommend" />
关键是如何判断“该加载了”。我们封装了一个简单的指令：
app.directive('lazy-load', {
mounted(el, binding) {
const observer = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
binding.value() // 触发加载回调
observer.unobserve(el)
}
})
}, { threshold: 0.1 })
observer.observe(el)
}
})
这样在模板里就能写成 <div v-lazy-load="loadRecommend">，逻辑清晰，复用也方便。
遇到的挑战：兼容性、依赖和加载时机的坑
理想很丰满，现实很骨感。第一个问题是低端安卓机对 Intersection Observer 支持不全，部分机型直接报错。我们测试时发现华为荣耀 8C 这种老机型根本进不了回调，导致模块永远不加载。第二个麻烦是组件内部有第三方依赖，比如一个图表组件用了 ECharts，但 ECharts 本身很大，如果在异步组件里直接 import，会把整个 ECharts 打包进去，反而拖慢加载。最头疼的是加载时机——有些组件虽然不在首屏，但用户滑动很快，等 Intersection Observer 触发时用户已经滑过去了，体验还不如直接加载。
折腾了一下午，我们意识到不能只靠浏览器原生 API，还得加兜底策略。比如设置一个最大延迟时间，或者预加载临近区域的内容。但怎么平衡“省流量”和“别让用户等”成了难题。
解决方案：Polyfill + 依赖拆分 + 智能预加载
针对兼容性问题，我们引入了 intersection-observer 的 polyfill，并在 main.js 里做条件加载：
if (!('IntersectionObserver' in window)) {
import('intersection-observer').then(() => {
console.log('Loaded IntersectionObserver polyfill')
})
}
对于 ECharts 这类重型依赖，我们改用动态 import + 全局注册的方式。在异步组件内部不直接 import，而是通过一个加载函数按需拉取：
// utils/loadECharts.js
let echartsInstance = null
export async function loadECharts() {
if (!echartsInstance) {
const { default: echarts } = await import('echarts')
echartsInstance = echarts
}
return echartsInstance
}
// 在 RecommendSection.vue 中
onMounted(async () => {
const echarts = await loadECharts()
// 初始化图表
})
这样 ECharts 只在真正需要时才加载，且全局只加载一次。
至于加载时机，我们给 lazy-load 指令加了预加载逻辑：当元素距离视口还有 200px 时就触发加载。同时设置一个 2 秒超时兜底，避免用户静止不动时内容不出现：
app.directive('lazy-load', {
mounted(el, binding) {
let timeoutId = null
const loadFn = () => {
clearTimeout(timeoutId)
binding.value()
}
const observer = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting || entry.intersectionRatio > 0) {
loadFn()
observer.unobserve(el)
}
})
}, { rootMargin: '200px' }) // 提前 200px 触发
observer.observe(el)
timeoutId = setTimeout(loadFn, 2000) // 2秒兜底
}
})
效果评估：首屏快了 60%，崩溃率下降
上线一周后，我们通过埋点和 Lighthouse 复测数据：首屏加载时间从平均 4.2 秒降到 1.7 秒，降幅接近 60%。更重要的是，低端机的白屏时间大幅缩短，用户跳出率下降了 22%。Crashlytics 上的 JS 内存溢出错误也减少了 40%，因为一次性加载的代码少了。虽然网络请求次数略增（多了几个 chunk），但总体流量反而下降，因为用户没等到加载完就退出的情况变少了。老板终于没再提 KPI 的事。
经验总结：别为了技术而技术，要为体验而优化
这次按需加载让我明白，性能优化不是炫技，而是解决真实问题。几点建议给后来者：
- 先测再改：用 Lighthouse 或真机 profiling 找瓶颈，别凭感觉优化。我们一开始以为图片是主因，结果发现是 JS bundle 太大。
- 兜底机制不能少：Intersection Observer 不是万能的，尤其在低端机上，必须有超时或 fallback 逻辑。
- 拆分要合理：不是所有组件都适合懒加载。比如导航栏、搜索框这种高频交互元素，提前加载反而体验更好。
- 监控要跟上：上线后持续观察加载失败率、用户等待时间，避免“优化”变成“劣化”。
按需加载不是银弹，但它确实帮我们把一个“卡成 PPT”的项目救了回来。如果你也在做移动端项目，别等用户骂了才动手——早拆一点，早轻松一点。
