骨架屏怎么提升性能的？骨架屏的原理及实现

笔试题（6 题）

1. 骨架屏的作用

骨架屏是什么？它怎么提升性能和用户体验？从性能指标角度分析（FCP、LCP、CLS）。

【作答】：

骨架屏定义: 骨架屏（Skeleton Screen）是一种页面加载占位符技术，通过展示页面的大致结构轮廓（如灰色矩形块、圆形占位符等），模拟真实内容的布局，在数据加载完成前给用户提供视觉反馈。

提升性能的机制:

提前渲染: 骨架屏 HTML 体积小，可以快速渲染，避免白屏
减少感知延迟: 用户看到内容结构，心理上感觉加载更快
保持布局稳定: 骨架屏与真实内容布局一致，减少 CLS（累积布局偏移）
降低用户焦虑: 视觉反馈让用户知道页面正在加载，而非卡死

对性能指标的影响: FCP (First Contentful Paint):

骨架屏 HTML 体积小（通常<5KB），可以快速渲染
内联在 HTML 中时，FCP 时间可提前到 HTML 解析完成时
相比白屏，FCP 提前 200-500ms

LCP (Largest Contentful Paint):

如果骨架屏是 LCP 元素，可以提前 LCP 时间
但需要注意：真实内容加载后，LCP 会重新计算
最佳实践：确保真实 LCP 元素（如首屏图片）尽快加载

CLS (Cumulative Layout Shift):

骨架屏与真实内容布局一致时，CLS 接近 0
如果布局不匹配，会导致较大的 CLS
关键：保持骨架屏与真实内容的尺寸、位置、间距一致

用户体验提升:

减少感知等待时间: 用户看到结构，感觉加载更快
降低跳出率: 有视觉反馈，用户更愿意等待
提升品牌形象: 专业、细致的交互设计
改善弱网体验: 在慢网络下，骨架屏提供即时反馈

2. 骨架屏实现方式

骨架屏有哪些实现方式（手写、自动生成、SSR 内联、图片占位）？各自的优缺点？

【作答】：

手写骨架屏: 优点:

完全可控，可以精确匹配真实内容布局
体积小，性能最优
样式和动画可以完全自定义
不依赖额外工具，实现简单

缺点:

开发成本高，每个页面都需要单独编写
维护成本高，页面结构变化需要同步更新骨架屏
不适合动态内容或复杂布局
容易与真实内容不同步

自动生成: 优点:

开发效率高，可以批量生成
自动匹配真实内容结构
适合复杂页面和动态内容
维护成本低，可以自动化更新

缺点:

需要额外工具和构建流程
生成的代码可能不够精简
样式可能不够完美，需要手动调整
对动态内容的处理可能不够准确

SSR 内联: 优点:

首次渲染最快，无需等待 JS 执行
SEO 友好，搜索引擎可以看到内容结构
减少 FCP 时间
适合首屏关键内容

缺点:

增加 HTML 体积
需要服务端支持
缓存策略需要仔细设计
动态内容处理复杂

图片占位: 优点:

实现简单，只需替换图片 src
可以展示图片的宽高比
适合图片较多的页面

缺点:

只能占位图片，不能展示整体布局
图片加载可能影响性能
不够灵活，无法展示复杂结构
用户体验不如完整骨架屏

3. 骨架屏自动生成

如何自动生成骨架屏？Puppeteer 截图、DOM 结构分析、样式简化的原理？

【作答】：

Puppeteer 截图方案: 原理:

使用 Puppeteer 启动无头浏览器，访问目标页面
等待页面加载完成（或指定时间）
对页面进行截图，生成灰度/模糊版本
将截图转换为 SVG 或 Base64 内联图片
作为骨架屏使用

优点: 完全自动化，视觉效果好缺点: 体积大，需要服务端支持，生成时间长

DOM 结构分析: 原理:

分析真实页面的 DOM 结构
识别关键元素（文本、图片、按钮等）
提取元素的尺寸、位置、样式信息
生成对应的骨架屏 DOM 结构
简化样式（去除颜色、图片，保留布局）

实现步骤:

遍历 DOM 树，识别块级元素
提取元素的宽高、margin、padding
文本元素替换为灰色矩形
图片元素替换为灰色占位块
保留关键布局属性（flex、grid 等）

样式简化: 原理:

移除所有颜色相关属性（color、background-color、border-color 等）
统一使用灰色系（#f0f0f0、#e0e0e0 等）
移除背景图片，使用纯色或渐变
简化边框和阴影
保留布局相关属性（width、height、margin、padding、display 等）
移除动画和过渡效果（或简化为 shimmer 动画）

示例转换: 真实样式: background: linear-gradient(...), color: #333, border: 1px solid #ddd 骨架样式: background: #f0f0f0, border: none

完整流程:

开发阶段: 编写真实页面组件
构建阶段:
- 使用 Puppeteer 访问页面，或分析组件结构
- 生成骨架屏 HTML/CSS
- 内联到 HTML 或生成独立文件
运行时:
- 首次加载显示骨架屏
- 数据加载完成后，平滑过渡到真实内容
- 移除骨架屏 DOM

4. 骨架屏注入时机

骨架屏应该在什么时候注入？HTML 内联 vs JS 动态插入？SSR/SSG 下如何处理？

【作答】：

注入时机: 最佳时机: HTML 解析完成后立即显示，在 JS 执行和数据加载之前关键原则: 越早越好，减少白屏时间

HTML 内联: 实现方式:

将骨架屏 HTML 直接写在 HTML 文件的<body>中
或通过 SSR 在服务端渲染时注入
使用<style>标签内联 CSS

优点:

渲染最快，无需等待 JS
FCP 时间最短
SEO 友好
适合首屏关键内容

缺点:

增加 HTML 体积
需要服务端支持
缓存策略复杂
不适合动态路由

示例:

<html>
  <head>...</head>
  `<body>`
    <div class="skeleton">
      <div class="skeleton-header">...</div>
      <div class="skeleton-content">...</div>
    </div>
    \<script\>
      // 真实内容加载后移除骨架屏
      window.addEventListener('load', () => {
        document.querySelector('.skeleton').remove();
      });
    </script>
  </body>
</html>

JS 动态插入: 实现方式:

在入口 JS 文件中，优先执行骨架屏渲染逻辑
使用 document.write 或 DOM 操作插入骨架屏
数据加载完成后移除

优点:

灵活，可以根据路由动态生成
不增加 HTML 体积
适合 SPA 应用
可以复用组件

缺点:

需要等待 JS 执行，FCP 稍慢
如果 JS 加载慢，可能看不到骨架屏
需要确保 JS 尽早执行

示例:

// main.js
function renderSkeleton() {
  const skeleton = document.createElement('div')
  skeleton.innerHTML = '<div class="skeleton">...</div>'
  document.body.appendChild(skeleton)
}

// 立即执行
renderSkeleton()

// 数据加载完成后
fetchData().then((data) => {
  renderRealContent(data)
  document.querySelector('.skeleton').remove()
})

SSR/SSG 下的处理: SSR (Server-Side Rendering):

在服务端渲染时，将骨架屏 HTML 内联到响应中
使用 React/Vue 的 SSR 能力，渲染骨架屏组件
客户端 hydration 时，平滑过渡到真实内容

SSG (Static Site Generation):

构建时生成包含骨架屏的 HTML
对于动态内容，使用占位数据渲染骨架屏
客户端激活后，替换为真实数据

Next.js 示例:

// pages/index.js
export default function Home({ initialData }) {
  const [data, setData] = useState(initialData)
  const [loading, setLoading] = useState(!initialData)

  return <div>{loading ? <SkeletonScreen /> : <RealContent data={data} />}</div>
}

// getServerSideProps 或 getStaticProps
export async function getServerSideProps() {
  // 服务端获取数据，如果慢则返回null，显示骨架屏
  const data = await fetchData()
  return { props: { initialData: data } }
}

关键点:

SSR 下，如果数据获取快，直接渲染真实内容
如果数据获取慢，先渲染骨架屏，数据到达后更新
使用 React Suspense 可以更好地处理这种场景

5. 骨架屏与加载状态

骨架屏与传统 Loading（菊花图、进度条）的区别？什么场景用骨架屏，什么场景用 Loading？

【作答】：

骨架屏 vs Loading: 骨架屏:

展示页面结构轮廓，模拟真实内容布局
提供空间感知，用户知道内容的大致位置
适合内容加载场景
视觉上更自然，用户感觉内容"正在填充"

Loading (菊花图/进度条):

抽象的加载指示器，不展示内容结构
只表示"正在加载"状态
适合操作反馈（提交表单、上传文件等）
视觉上更明显，但信息量少

核心区别:

骨架屏: 展示"什么内容" + "在哪里"
Loading: 只展示"正在加载"

骨架屏适用场景:

内容展示页面: 列表页、详情页、首页等
首屏加载: 页面首次打开，数据加载中
分页加载: 列表翻页，新内容加载
路由切换: SPA 中路由切换，新页面加载
数据刷新: 下拉刷新，重新加载数据

典型场景:

电商商品列表页
新闻资讯详情页
社交媒体的信息流
后台管理的数据表格

Loading 适用场景:

操作反馈: 表单提交、文件上传、删除操作
短时加载: 加载时间<1 秒，不需要展示结构
全局加载: 整个应用初始化
不确定内容: 不知道会加载什么内容
模态操作: 弹窗、对话框中的操作

典型场景:

登录按钮点击后
文件上传进度
数据导出
API 请求（非内容展示）

组合使用: 最佳实践: 骨架屏 + 轻量 Loading 指示器

场景 1: 首屏加载

显示骨架屏（展示页面结构）
在骨架屏上叠加一个小的 loading 动画（表示正在加载）
数据到达后，平滑过渡到真实内容

场景 2: 操作反馈

用户点击"提交"按钮
按钮显示 loading 状态（防止重复提交）
如果操作会跳转页面，目标页面显示骨架屏

场景 3: 分步加载

首屏数据快速到达 → 直接显示内容
次要内容加载中 → 对应区域显示骨架屏
操作反馈 → 使用 Loading

示例代码:

function Page() {
  const [data, setData] = useState(null)
  const [submitting, setSubmitting] = useState(false)

  return (
    <div>
      {data ? (
        <Content data={data} />
      ) : (
        <SkeletonScreen>
          <LoadingSpinner size="small" /> {/* 叠加loading */}
        </SkeletonScreen>
      )}

      <button onClick={handleSubmit} disabled={submitting}>
        {submitting ? <LoadingSpinner /> : '提交'}
      </button>
    </div>
  )
}

6. 骨架屏动画效果

如何实现骨架屏的闪烁/渐变动画效果？CSS animation/shimmer 效果的实现？

【作答】：

/* 你的 CSS 实现 */

/* 方案1: Shimmer 闪烁效果（最常用） */
.skeleton {
  position: relative;
  background: #f0f0f0;
  overflow: hidden;
}

.skeleton::after {
  content: '';
  position: absolute;
  top: 0;
  left: -100%;
  width: 100%;
  height: 100%;
  background: linear-gradient(
    90deg,
    transparent,
    rgba(255, 255, 255, 0.6),
    transparent
  );
  animation: shimmer 1.5s infinite;
}

@keyframes shimmer {
  0% {
    left: -100%;
  }
  100% {
    left: 100%;
  }
}

/* 方案2: 脉冲效果 */
.skeleton-pulse {
  background: #f0f0f0;
  animation: pulse 1.5s ease-in-out infinite;
}

@keyframes pulse {
  0%,
  100% {
    opacity: 1;
  }
  50% {
    opacity: 0.6;
  }
}

/* 方案3: 渐变移动效果 */
.skeleton-gradient {
  background: linear-gradient(90deg, #f0f0f0 0%, #e0e0e0 50%, #f0f0f0 100%);
  background-size: 200% 100%;
  animation: gradient 1.5s ease-in-out infinite;
}

@keyframes gradient {
  0% {
    background-position: 200% 0;
  }
  100% {
    background-position: -200% 0;
  }
}

/* 方案4: 波浪效果 */
.skeleton-wave {
  background: #f0f0f0;
  position: relative;
  overflow: hidden;
}

.skeleton-wave::before {
  content: '';
  position: absolute;
  top: 0;
  left: -100%;
  width: 100%;
  height: 100%;
  background: linear-gradient(
    90deg,
    transparent 0%,
    rgba(255, 255, 255, 0.4) 50%,
    transparent 100%
  );
  animation: wave 2s infinite;
}

@keyframes wave {
  0% {
    left: -100%;
  }
  100% {
    left: 100%;
  }
}

/* 完整骨架屏组件示例 */
.skeleton-container {
  padding: 20px;
}

.skeleton-header {
  display: flex;
  align-items: center;
  margin-bottom: 20px;
}

.skeleton-avatar {
  width: 50px;
  height: 50px;
  border-radius: 50%;
  background: #f0f0f0;
  margin-right: 15px;
  position: relative;
  overflow: hidden;
}

.skeleton-avatar::after {
  content: '';
  position: absolute;
  top: 0;
  left: -100%;
  width: 100%;
  height: 100%;
  background: linear-gradient(
    90deg,
    transparent,
    rgba(255, 255, 255, 0.6),
    transparent
  );
  animation: shimmer 1.5s infinite;
}

.skeleton-text {
  flex: 1;
}

.skeleton-line {
  height: 16px;
  background: #f0f0f0;
  border-radius: 4px;
  margin-bottom: 10px;
  position: relative;
  overflow: hidden;
}

.skeleton-line::after {
  content: '';
  position: absolute;
  top: 0;
  left: -100%;
  width: 100%;
  height: 100%;
  background: linear-gradient(
    90deg,
    transparent,
    rgba(255, 255, 255, 0.6),
    transparent
  );
  animation: shimmer 1.5s infinite;
}

.skeleton-line.short {
  width: 60%;
}

.skeleton-line.medium {
  width: 80%;
}

.skeleton-line.long {
  width: 100%;
}

/* 性能优化：使用 will-change 和 transform */
.skeleton-optimized {
  will-change: transform;
}

.skeleton-optimized::after {
  transform: translateX(-100%);
  animation: shimmer-optimized 1.5s infinite;
}

@keyframes shimmer-optimized {
  0% {
    transform: translateX(-100%);
  }
  100% {
    transform: translateX(100%);
  }
}

/* 减少重绘：使用 opacity */
.skeleton-opacity {
  background: #f0f0f0;
  position: relative;
}

.skeleton-opacity::after {
  content: '';
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
  background: rgba(255, 255, 255, 0.6);
  animation: fade 1.5s ease-in-out infinite;
}

@keyframes fade {
  0%,
  100% {
    opacity: 0;
  }
  50% {
    opacity: 1;
  }
}

面试题（4 题）

1. 骨架屏技术选型

给一个复杂页面设计骨架屏方案，你会如何选型（手写 vs 自动生成）？需要考虑哪些因素？

【作答】：

选型决策树:

页面复杂度
- 简单页面（<5 个区块）→ 手写
- 复杂页面（>10 个区块，动态布局）→ 自动生成
页面数量
- 少量页面（<10 个）→ 手写
- 大量页面（>20 个）→ 自动生成
更新频率
- 稳定页面（很少改动）→ 手写
- 频繁迭代 → 自动生成
团队规模
- 小团队（<5 人）→ 手写更灵活
- 大团队 → 自动生成，统一规范
性能要求
- 极致性能 → 手写（体积最小）
- 可接受稍大体积 → 自动生成

复杂页面选型方案:

方案 A: 混合方案（推荐）

首屏关键区域: 手写（精确控制，性能最优）
次要区域: 自动生成（快速开发）
动态内容: 使用通用骨架屏组件

方案 B: 分层骨架屏

Level 1: 页面级骨架屏（手写，展示整体布局）
Level 2: 组件级骨架屏（自动生成或组件库）
Level 3: 元素级骨架屏（通用组件）

具体实施:

分析页面结构
- 识别关键区块（Header、Content、Sidebar 等）
- 评估每个区块的复杂度
- 确定加载优先级
技术选型
- 核心首屏: 手写，内联 HTML
- 次要内容: 使用 React Skeleton 组件库
- 动态列表: 自动生成或模板化
工具选择
- 手写: 直接编写 HTML/CSS 或使用组件
- 自动生成:
  - page-skeleton-loader (Webpack 插件)
  - react-content-loader (React 组件)
  - vue-skeleton-webpack-plugin (Vue 插件)
实施步骤
- 第一步: 手写首屏骨架屏（MVP）
- 第二步: 评估效果，决定是否自动化
- 第三步: 建立组件库，统一规范
- 第四步: 逐步自动化非关键区域

需要考虑的因素:

开发成本
- 手写: 初期成本高，但长期维护简单
- 自动生成: 初期成本低，但需要工具维护
性能影响
- 骨架屏体积（HTML/CSS 大小）
- 渲染性能（DOM 复杂度）
- 动画性能（CSS 动画优化）
维护成本
- 页面结构变化时的同步成本
- 工具链的维护成本
- 团队学习成本
用户体验
- 骨架屏与真实内容的匹配度
- 过渡动画的流畅度
- 不同设备的适配
技术栈兼容性
- React/Vue/Angular 等框架支持
- SSR/SSG 支持
- 构建工具集成
团队能力
- 前端开发能力
- 工具开发能力
- 设计规范统一性

实际案例: 电商首页（复杂页面）:

顶部导航: 手写（固定结构）
Banner 轮播: 手写（关键首屏）
商品分类: 自动生成（动态内容）
商品列表: 使用组件库（可复用）
底部信息: 手写（简单结构）

决策结果: 混合方案

首屏手写，确保性能和体验
动态内容使用自动生成
建立组件库，提高复用性

2. 骨架屏性能优化

骨架屏本身也会影响性能（体积、渲染），如何优化？如何平衡骨架屏的精细度与性能？

【作答】：

性能问题分析:

体积问题
- HTML 体积过大，影响首屏加载
- CSS 体积过大，阻塞渲染
- 内联图片/Base64 体积大
渲染问题
- DOM 节点过多，解析慢
- 复杂 CSS 选择器，渲染慢
- 动画性能问题（重绘、重排）
内存问题
- 骨架屏 DOM 未及时清理
- 动画未正确销毁

优化策略:

体积优化
- HTML 优化: 简化 DOM 结构，减少嵌套，目标<3KB
- CSS 优化: 内联关键 CSS，压缩，目标<2KB
- 使用类名缩写
渲染优化
- 减少 DOM 节点，使用 CSS 伪元素
- 使用 transform 和 opacity（GPU 加速）
- 避免触发重排的属性
动画优化
- 使用 transform 而非 left/top
- 在低端设备上禁用动画

精细度与性能平衡:

Level 1: 极简（<1KB，性能极高，体验一般）
Level 2: 基础（2-3KB，推荐，体验良好）
Level 3: 精细（5-10KB，体验优秀）

平衡策略:

首屏精细化，非首屏简化
关键区域精细化，次要区域简化
根据网络条件和设备性能动态调整

最佳实践:

目标体积: <3KB（HTML+CSS）
DOM 节点: <50 个
动画: 使用 GPU 加速属性
性能指标: FCP<100ms, LCP<200ms, CLS=0

3. 骨架屏与真实内容过渡

骨架屏到真实内容的过渡如何做得平滑？如何避免闪烁和布局抖动（CLS）？

【作答】：

过渡问题分析:

闪烁问题: 骨架屏突然消失，颜色突变
布局抖动（CLS）: 尺寸不一致，字体/图片加载导致变化
视觉不连贯: 位置偏移，间距不一致

平滑过渡方案:

淡入淡出过渡
- 使用 opacity 过渡，时间 200-300ms
- 骨架屏淡出，真实内容淡入
交叉淡入淡出
- 骨架屏和真实内容同时存在
- 使用绝对定位重叠
渐进式替换
- 按区块逐步替换
- 使用 React Suspense

避免布局抖动（CLS）:

尺寸匹配
- 骨架屏与真实内容尺寸完全一致
- 精确测量真实内容尺寸
字体预加载
- 使用 font-display: swap
- 骨架屏使用相同字体
图片占位
- 使用 aspect-ratio 保持宽高比
- 预留图片空间
内容预留
- 文本行数预留
- 列表项数量预留
布局一致性
- 使用相同的 flex/grid 布局
- 保持相同的 gap、align-items 等

最佳实践检查清单:

✅ 骨架屏尺寸与真实内容完全一致
✅ 使用 opacity 过渡，避免 display 切换
✅ 字体已预加载或使用 fallback
✅ 图片使用 aspect-ratio 占位
✅ 布局系统完全一致
✅ 过渡时间 200-300ms
✅ 监控 CLS 指标，确保为 0

4. 骨架屏实践经验

讲一个你实现骨架屏的经验：技术方案、实施过程、效果数据、遇到的问题？

【作答】：

项目背景: 电商平台首页优化项目，目标是提升首屏加载体验和性能指标。

技术方案:

选型决策
- 首屏关键区域: 手写骨架屏
- 商品列表: 使用 react-content-loader 组件库
- 注入方式: SSR 内联 + 客户端渐进式替换
技术栈
- React + Next.js
- react-content-loader
- CSS Modules

实施过程:

阶段 1: 设计和开发（1 周）
阶段 2: 集成和优化（3 天）
阶段 3: 测试和监控（2 天）
阶段 4: 全量上线（1 天）

效果数据:

性能指标提升:

FCP: 1.2s → 0.8s (提升 33%)
LCP: 2.5s → 1.8s (提升 28%)
CLS: 0.15 → 0.02 (改善 87%)
TTI: 3.2s → 2.6s (提升 19%)

用户体验指标:

跳出率: 降低 12%
页面停留时间: 增加 18%
首屏内容点击率: 提升 25%
用户满意度: 4.2 → 4.6

业务指标:

首页转化率: 提升 8%
商品点击率: 提升 15%
订单量: 提升 5%

遇到的问题及解决方案:

问题 1: 骨架屏与真实内容尺寸不一致导致 CLS 解决: 使用 Chrome DevTools 精确测量，建立设计规范，使用 CSS 变量

问题 2: 骨架屏体积过大（8KB）解决: 简化 DOM 结构，压缩 CSS，使用类名缩写，降至 3KB

问题 3: 低端设备动画卡顿解决: 使用 transform 替代 left，添加 will-change，检测设备性能

问题 4: SSR 和客户端 hydration 不一致解决: 确保服务端和客户端使用相同组件，使用 React.hydrate

问题 5: 动态内容骨架屏生成困难解决: 使用固定数量骨架屏项，使用 react-content-loader 的 SVG 方案

经验总结:

精确的尺寸匹配是避免 CLS 的关键
混合方案（手写+组件库）平衡了质量和效率
性能优化（体积、动画）很重要
充分的测试（设备、网络）必不可少

骨架屏怎么提升性能的？骨架屏的原理及实现

On this page