一、从输入 URL 到页面呈现：完整链路

在讨论优化之前，先建立全局视角。当用户在地址栏敲下回车，浏览器大致经历以下阶段：

二、关键渲染路径（CRP）

浏览器把 HTML/CSS 变成屏幕像素的过程叫关键渲染路径（Critical Rendering Path），共六个步骤：

1. 构建 DOM 树：HTML 字节流 → 字符 → 词法分析 → 节点 → DOM 树。
2. 构建 CSSOM 树：解析所有样式（外链 <link>、<style>、行内），生成样式规则树。
3. 合并渲染树（Render Tree）：DOM + CSSOM 结合，只保留可见节点。display:none 的元素不会进入渲染树，而 visibility:hidden 的会（占据布局但不绘制）。
4. 布局（Layout / Reflow）：计算每个节点的几何信息——位置与尺寸。
5. 绘制（Paint）：把节点转成绘制指令，填充颜色、文字、边框、阴影等。
6. 合成（Composite）：把绘制好的图层交给合成器，最终由 GPU 合成为屏幕画面。

2.1 CSS 阻塞渲染

浏览器必须等 CSSOM 构建完成才能进入布局——因为样式会影响布局结果。所以外链 CSS 是”渲染阻塞资源”：

1
2
3
4
5

<!-- 阻塞：CSS 没下载解析完，页面不会绘制 -->
<link rel="stylesheet" href="/critical.css">

<!-- 非关键 CSS 可异步加载，避免阻塞首屏 -->
<link rel="stylesheet" href="/non-critical.css" media="print" onload="this.media='all'">

2.2 JS 阻塞解析

普通的 <script> 会暂停 HTML 解析去下载并执行脚本（因为脚本可能修改 DOM），因此把 <script> 放在 <head> 里是经典性能杀手。defer 与 async 是两种解法：

三、重排（Reflow）与重绘（Repaint）

渲染完成后，用户操作或脚本改样式会触发局部重新渲染，这才是前端交互性能的主战场。

结论：重排必然引起重绘，重绘不一定引起重排。优化的核心是尽量把改动限制在”只重绘”甚至”只合成”。

3.1 强制同步布局（Layout Thrashing）

浏览器本会把样式变更攒起来批量处理，但你一旦用 JS 去读取布局属性（offsetTop、offsetWidth、scrollTop、getComputedStyle 等），浏览器为了给出正确值，会立即清空队列、强制完成一次重排——这就是”强制同步布局”。读写交替会把它放大成性能灾难：

1
2
3
4
5
6
7
8

// ❌ 反例：读 → 写 → 读 → 写，每次读都强制重排
for (let i = 0; i < items.length; i++) {
  items[i].style.height = box.offsetHeight + 'px'
}

// ✅ 正例：先一次性读完，再批量写
const h = box.offsetHeight
items.forEach(el => { el.style.height = h + 'px' })

四、合成层与 GPU 加速

现代浏览器会把页面拆成多个图层（Layer），布局与绘制后交给合成器（Compositor）在 GPU 上合成。若某个元素的变换只发生在合成层内部，浏览器可以跳过 Layout 和 Paint，直接重新合成——这就是”GPU 加速”的本质。

只触发合成的两个属性：

• transform（位移、缩放、旋转）
• opacity

1
2
3
4
5
6
7

/* ❌ 触发重排 + 重绘，每帧都在布局 */
.box { transition: top .3s; }
.box:hover { top: -10px; }

/* ✅ 只触发合成，由 GPU 处理，动画顺滑 */
.box { transition: transform .3s; }
.box:hover { transform: translateY(-10px); }

will-change 可提前把元素提升为合成层（升层）：

1

.card { will-change: transform; } /* 提前升层，动画更稳 */

五、渲染性能优化实战

结合上面的原理，落地到日常开发：

requestAnimationFrame 让动画与浏览器刷新同步，避免掉帧：

1
2
3
4
5
6
7

let x = 0
function move() {
  x += 2
  el.style.transform = `translateX(${x}px)` // 只触发合成
  if (x < 300) requestAnimationFrame(move)
}
requestAnimationFrame(move)

六、浏览器缓存策略：强缓存与协商缓存

再快的渲染，也不如”根本不用重新下载”省事。浏览器缓存分两层：

6.1 强缓存

命中强缓存时，浏览器不发起请求，直接用本地副本，响应头：

Cache-Control 常用指令：

1
2
3

Cache-Control: max-age=31536000, immutable   # 一年内不再校验（配合 hash 文件名）
Cache-Control: no-cache                        # 可缓存，但每次都协商校验
Cache-Control: no-store                        # 完全不缓存（敏感数据）

6.2 协商缓存

强缓存过期后，浏览器携带校验字段发起请求，由服务器决定返回 304（用本地）还是 200（返回新内容）：

优先级：Cache-Control > Expires；ETag > Last-Modified。

6.3 缓存位置与最佳实践

浏览器缓存按优先级查找：Service Worker → Memory Cache → Disk Cache → Push Cache。

生产实战的黄金组合：

1
2

<!-- 构建产物带内容哈希，配合长缓存 -->
<script src="/static/app.8f3a1c.js" defer></script>

七、首屏与加载性能优化

首屏体验（用户第一眼看到内容的速度）由 LCP（最大内容绘制） 等指标衡量。落地清单：

1. 关键 CSS 内联，非关键 CSS 异步加载，避免渲染阻塞。
2. 脚本用 defer，第三方脚本用 async。
3. 代码分割 + Tree Shaking，首屏只加载必要 JS。
4. 图片优化：合适的格式（WebP/AVIF）、width/height 占位防抖动、首屏图不要懒加载。
5. 资源提示：preconnect/dns-prefetch 提前建连，preload 预加载关键资源，prefetch 预取下一步可能用到的资源。
6. 非首屏图片懒加载：

1
2

<img src="hero.webp" fetchpriority="high" width="1200" height="600" alt="首屏主图">
<img src="below.webp" loading="lazy" width="800" height="400" alt="下方图片">

1
2
3
4
5
6
7
8
9
10

// 需要更精细控制时，用 IntersectionObserver 实现懒加载
const io = new IntersectionObserver((entries) => {
  entries.forEach(e => {
    if (e.isIntersecting) {
      e.target.src = e.target.dataset.src
      io.unobserve(e.target)
    }
  })
})
document.querySelectorAll('img[data-src]').forEach(img => io.observe(img))

1. 骨架屏 / SSR / SSG：先给出结构占位，减少白屏焦虑，兼顾 SEO。

八、生产避坑清单

1. 别在循环里读写 DOM 交替——先读后写，规避强制同步布局。
2. 动画只用 transform / opacity，别用 top/left/width。
3. will-change 按需增删，不要长期挂在大批量元素上。
4. 长列表用虚拟滚动，别一次性渲染上万 DOM。
5. 首屏关键图片不要懒加载，它会拖慢 LCP；loading="lazy" 只给视口外的图。
6. 静态资源加内容 hash + 长缓存，HTML 走协商缓存，别把入口页也设成一年强缓存。
7. 分清 no-cache 与 no-store：前者校验，后者不存。
8. defer vs async 按依赖选：业务脚本用 defer，独立脚本用 async。
9. 减少重排影响范围：批量操作、DocumentFragment、contain: layout 都能收敛成本。
10. 别过度优化：先测量（Performance 面板、Lighthouse）再动手，用数据定位瓶颈，而不是凭感觉堆技巧。