骨架屏加载优化实践：提升前端用户体验的关键技术
西门沐希为啥要折腾骨架屏？
最近项目里又遇到白屏问题，用户点开列表页，等了两秒才出来内容，体验差得一批。产品经理直接甩锅：“你这加载太慢了！” 其实接口就 300ms，但首屏渲染卡在 JS 执行和数据绑定上。这时候，骨架屏（Skeleton Screen）就成了我的救命稻草——用静态占位先糊住用户眼睛，等真实数据回来再替换。
但骨架屏怎么做？我试过好几种方案，每种都有坑，也有爽点。今天就来聊聊我踩过的雷，以及现在我到底用哪个。
手写 CSS 骨架：最原始，但最可控
最早期，我都是手动写 CSS 骨架。比如一个卡片列表，每个卡片有头像、标题、描述，我就用几个 div + background 动画搞定：
<div class="skeleton-card">
<div class="skeleton-avatar"></div>
<div class="skeleton-content">
<div class="skeleton-line short"></div>
<div class="skeleton-line long"></div>
</div>
</div>.skeleton-card {
display: flex;
padding: 16px;
border-bottom: 1px solid #eee;
}
.skeleton-avatar {
width: 40px;
height: 40px;
border-radius: 50%;
background: linear-gradient(90deg, #f0f0f0 25%, #e0e0e0 50%, #f0f0f0 75%);
background-size: 200% 100%;
animation: loading 1.5s infinite;
}
.skeleton-line {
height: 16px;
margin-top: 8px;
background: linear-gradient(90deg, #f0f0f0 25%, #e0e0e0 50%, #f0f0f0 75%);
background-size: 200% 100%;
animation: loading 1.5s infinite;
}
.skeleton-line.short { width: 60%; }
.skeleton-line.long { width: 100%; }
@keyframes loading {
0% { background-position: 200% 0; }
100% { background-position: -200% 0; }
}这套方案的优点是：完全掌控样式，性能几乎无开销。CSS 动画轻量，不依赖 JS，首屏就能跑。而且结构清晰，改起来也快。
但缺点也很明显：**重复劳动多**。每个页面都要手写一套，组件一多，维护成本飙升。而且一旦 UI 改动（比如间距变了），所有骨架都要跟着调。我之前在一个大项目里用了这个方案，后来 UI 调整了三次，我差点把骨架组件全删了重写。
用现成的 UI 库：省事，但容易被绑架
后来我图省事，直接用 Ant Design 或 Element Plus 的 Skeleton 组件。比如 AntD 的用法：
import { Skeleton } from 'antd';
function MyList() {
const [loading, setLoading] = useState(true);
const [data, setData] = useState([]);
useEffect(() => {
fetch('https://jztheme.com/api/data')
.then(res => res.json())
.then(data => {
setData(data);
setLoading(false);
});
}, []);
return (
<div>
{loading ? (
<Skeleton active paragraph={{ rows: 4 }} />
) : (
data.map(item => <Item key={item.id} data={item} />)
)}
</div>
);
}确实方便，几行代码搞定。而且这些库的骨架动画做得挺精致，还支持自定义行数、圆角、avatar 等。
但问题来了：你被库绑死了。如果哪天你想换个动画效果，或者调整骨架比例，发现 API 不支持，就得 hack。更糟的是，如果项目不用 AntD，为了骨架屏引入整个 UI 库？那 bundle size 直接爆炸。我见过有人为了一个 Skeleton 引了 200KB 的包，结果只用了 5% 的功能，纯属浪费。
所以，除非你已经在用这些 UI 库，否则我不推荐专门为了骨架屏引入它们。
自动生成骨架屏：听起来很美，用起来很痛
前两年流行过“自动生成骨架屏”的工具，比如 page-skeleton-webpack-plugin 或者 skeleton-element。原理是在构建时截图页面，然后生成对应的 SVG 或 HTML 骨架。
我折腾过 page-skeleton-webpack-plugin，配置复杂到怀疑人生。它要求你有一个可运行的 dev server，还要手动标注哪些区域是动态内容。生成出来的骨架经常错位，尤其是响应式布局下，移动端和桌面端根本对不上。改一次 UI，就得重新跑一遍生成流程，比手写还累。
更坑的是，它生成的骨架是静态图片或 SVG，无法响应主题色变化。我们项目支持深色模式，骨架颜色得跟着变，但自动生成的骨架是固定色值，根本没法适配。最后我删了插件，回归手写。
所以，除非你的页面结构极其固定、且不需要适配多主题，否则别碰这类方案。省下的时间，全花在 debug 生成结果上了。
我的选型逻辑：能手写就手写，实在不行再封装
现在我的策略很明确：优先手写 CSS 骨架，但抽象成可复用的原子组件。
比如我会建一个 SkeletonCard、SkeletonList、SkeletonAvatar 这样的基础组件，内部用 CSS 实现，外部通过 props 控制行数、尺寸等。这样既保留了手写的灵活性，又避免了重复劳动。
// SkeletonCard.jsx
export default function SkeletonCard({ lines = 2, avatar = true }) {
return (
<div className="skeleton-card">
{avatar && <div className="skeleton-avatar"></div>}
<div className="skeleton-content">
{Array.from({ length: lines }).map((_, i) => (
<div key={i} className={skeleton-line ${i === 0 ? 'short' : 'long'}}></div>
))}
</div>
</div>
);
}用的时候：
{loading ? <SkeletonCard lines={3} /> : <RealCard data={data} />}这样，样式统一、体积小、无依赖，还能配合 CSS 变量做主题切换。比如：
:root {
--skeleton-color: #f0f0f0;
--skeleton-highlight: #e0e0e0;
}
[data-theme='dark'] {
--skeleton-color: #333;
--skeleton-highlight: #444;
}
.skeleton-avatar {
background: linear-gradient(90deg, var(--skeleton-color) 25%, var(--skeleton-highlight) 50%, var(--skeleton-color) 75%);
}完美适配深色模式，而且零 JS 开销。
当然，如果项目已经重度依赖某个 UI 库，比如 AntD，那直接用它的 Skeleton 也行，毕竟省事。但如果是新项目，或者追求极致性能，我强烈推荐手写 + 封装这套组合拳。
踩坑提醒：这三点一定注意
- 骨架高度要和真实内容一致：否则数据回来时页面会“跳动”。我之前没注意，标题行高设错了，加载完内容整个页面往上蹦，用户差点以为页面崩了。
- 别在骨架上加复杂交互：骨架只是占位，别给它加 hover、click 事件。有次我误把骨架当真实按钮，点了没反应，用户以为功能坏了。
- SSR 场景要小心：如果用 Next.js 或 Nuxt，骨架必须能在服务端渲染。纯 CSS 方案天然支持，但如果是基于 JS 的动态生成，可能得额外处理。
总结一下
骨架屏不是银弹，但用对了能大幅提升感知性能。我的经验是：手写 CSS 最稳，UI 库组件次之，自动生成基本别碰。关键是要根据项目规模、技术栈和维护成本权衡。小项目直接手写，大项目就封装成基础组件复用。
以上是我踩坑后的总结，有更优的实现方式欢迎评论区交流。如果你也在用骨架屏，不妨说说你遇到的坑？
暂无评论