减少DOM节点数量与层级深度避免重排重绘导致页面性能劣化

一、把页面想象成做饭

咱们都点过外卖，也都在家里自己炒过菜。你想啊，你家里厨房就那么点儿大，锅碗瓢盆堆得哪儿都是。要是你炒个青菜还得先把一堆不用的盘子挪开，找到锅铲，再转身去拿油壶，那这顿饭做起来肯定又慢又累，对吧？

浏览器渲染咱们的网页，其实跟做饭是同一个道理。浏览器拿到一堆HTML代码以后，得把这些标签变成一个个能看得见的“小盒子”，摆到屏幕上。这个过程里有两个特别费劲的环节：一个叫“重排”，另一个叫“重绘”。重排呢，就是浏览器得重新算一遍，屏幕上这些盒子该放哪儿、该多大；重绘呢，就是算好位置以后，再拿“画笔”把盒子画出来。要是这两个环节反复折腾，就好比你炒个菜，一会儿重新摆一遍碗筷，一会儿又重新刷一遍锅，那这饭做得能不慢吗？

所以，这篇文章咱们就聊聊一个特别实在的事儿：怎么通过减少DOM节点的数量和层级深度，让浏览器少干点儿重排重绘的活儿，页面跑得飞起。我尽量用大白话，把这事儿给你说明白。

二、为啥节点一多，页面就变“吞吞吐吐”了

2.1 节点多了，浏览器要多干多少活

咱们平时写的网页，每一个标签，比如一个<div>、一个<span>、一个按钮，在浏览器眼里都是一个“节点”。这些节点摞在一起，组成了页面。

你琢磨一下，咱们更新页面上的一个数值，比如购物车里的数量从“1”变成“2”，浏览器是不是得重新算一下这个数字周围的东西有没有受影响？如果页面上只有十个节点，那浏览器扫一眼就完事儿了。要是页面有一万个节点，那浏览器就得把这堆节点挨个儿检查一遍，看谁受影响、谁没受影响。你说，这一万个人排队过安检，和十个人过安检，能一样快吗？

关键问题在于，很多时候咱们改一个地方，浏览器为了保险，会把整个页面或者一大片区域的布局重新算一遍。这就要命了。你只是想改个数字，结果浏览器把整个页面从头到尾重新捋了一遍，这性能不就白白浪费了吗？这在专业上叫“重排”，在咱们大白话里就叫“白干活”。

2.2 举个例子，看看节点膨胀有多吓人

咱们用一个生活中的例子来感受一下。假设咱们要在页面上展示一个长长的列表，里面是几千条数据。咱们来看看，如果不管不顾地往页面里塞节点，会是什么效果。

猜测你平时用Vue开发，这里就以Vue技术栈为例说明。

// 技术栈：Vue 3（组合式API）
<script setup>
import { ref } from 'vue';

// 模拟一大堆数据，咱就说这有2000条吧
const listData = ref(
  Array.from({ length: 2000 }, (_, index) => ({
    id: index,
    name: `用户-${index}`,
    desc: '这是一段很长很长的描述文字，目的就是为了让这个节点内容更丰满。'
  }))
);

// 这种方式非常直接，直接把2000条数据全部渲染成DOM节点
// 每个节点里又有好几个嵌套的<div>，这就让页面多了好几千个节点

// 于是用户在页面上随便滚一下鼠标，浏览器就得处理这好几千个节点
// 每次滚动、点击、修改，浏览器都可能要重新计算这一大堆节点的位置
</script>

<template>
  <div class="list-container">
    <div class="list-item" v-for="item in listData" :key="item.id">
      <div class="item-name">{{ item.name }}</div>
      <div class="item-desc">{{ item.desc }}</div>
      <div class="item-action">
        <button>点我</button>
      </div>
    </div>
  </div>
</template>

这个代码看着很简单，功能也挺好理解。但你想啊，2000条数据，每条数据里至少有个名字、描述、按钮，算下来就是6000多个节点。这还只是2000条，如果哪天后端接口一口气给你返回两万条数据，那页面上直接就是六万多个节点。浏览器光是把这些节点管理起来就够头疼的了，稍微有个风吹草动，比如点一下按钮，它可能就得把这几万个节点重新过一遍。你说页面能不卡吗？

2.3 节点数量多的场景

咱们生活里其实经常能碰到这种“节点膨胀”的情况。比如：

• 电商平台的后台订单列表，一页显示几百个订单，每个订单下面还有商品明细。
• 管理系统的权限树，一个部门套一个子部门，一层套一层。
• 长列表日志预览，比如咱们看服务器日志，一条一条摞下来，可能上千条。

这种场景下，如果咱们不做任何处理，傻乎乎地把所有数据都渲染成节点，那页面的性能就全靠浏览器硬扛了。浏览器扛不住，卡的就是咱们用户。

三、层级太深，就像螺丝壳里做道场

3.1 嵌套太深，浏览器找东西都费劲

说完了“多”，咱们再说说“深”。

有些朋友写页面的时候喜欢一层套一层，大概长这样：

<div>
  <div>
    <div>
      <div>
        <span>你好呀</span>
      </div>
    </div>
  </div>
</div>

这就是典型的三层嵌套，实际项目里五层、六层嵌套也不少见。有时候是因为组件封装得太细，有时候是历史遗留代码，反正就是一层包着一层。这样写代码的时候可能没觉得怎么样，但在浏览器眼里，它就得多花力气去维护这个嵌套关系。

为啥呢？因为浏览器在计算布局的时候，得一层一层往下找。它想看看最里面这个<span>在哪儿，就得先算出最外层<div>的位置，再算里面那层<div>的位置，再算更里面那层的位置……就跟你在一个非常深的抽屉里找东西一样，每拉开一层抽屉，都比上次多费点儿劲。

更重要的是，如果咱们改动了最外层这个<div>的某个样式，比如给它加了个padding，那浏览器就“哗啦”一下把里面所有层级的节点全都重新计算一遍尺寸和位置。这个成本是成倍增加的。层级越深，受影响的节点越多，重排的范围就越广，页面自然就慢下来了。

3.2 用代码看看层级深是什么样

在Vue里，咱们经常用组件嵌套来搭页面。比如下面这种：

// 技术栈：Vue 3（组合式API）
// 这里是层级很深的组件嵌套示例
// 实际项目中这种结构非常常见，尤其是处理一些复杂的页面布局时

// 看起来是没啥问题，但咱们看看这里有多少层

我们有这样一个嵌套结构：

// 技术栈：Vue 3（组合式API）
// 页面根组件设计
<template>
  <!-- 第一层：页面总容器 -->
  <div class="page">
    <!-- 第二层：主要区域 -->
    <div class="main-area">
      <!-- 第三层：内容盒子 -->
      <div class="content-box">
        <!-- 第四层：内层容器 -->
        <div class="inner-wrap">
          <!-- 第五层：最终数据展示 -->
          <div class="data-show">
            <!-- 第六层：具体的一条信息 -->
            <p>这里展示一条信息</p>
          </div>
        </div>
      </div>
    </div>
  </div>
</template>

你看，为了展示一行字，咱们裹了五层大棉袄。这还只是一个静态结构。如果咱们要在这个深层的地方动态更新数据，比如用户名变了，那浏览器就会从最外层的.page开始，一路算到最内部的<p>标签，所有中间层级的节点都要参与布局计算。这就像咱们平时出门穿了好几层衣服，结果进屋只想脱一件，却必须把外面的拉链全拉开，多累啊。

为了解决这个问题，咱们写代码的时候就得养成一个好习惯：能用一层解决的问题，绝对不用两层；能用两层解决的，绝对不用三层。减少无效的包裹层级，这不光是代码看着清爽，浏览器渲染起来也轻松。

四、给页面“减肥”：几个能落地的实操技巧

前面唠了这么多，总得给点干货。这章节咱们就讲几个接地气的办法，帮咱们把DOM节点数量和层级压下来。还是用Vue技术栈来说明。

4.1 巧用虚拟滚动，专治长列表

虚拟滚动是个啥意思呢？就是说，页面虽然有一万条数据，但用户屏幕就那么高，能看到的也就那么二十来条。那咱们干嘛要把一万条都渲染出来呢？咱们只渲染用户当前看得到的那二十条，等用户滚动了，再动态地把滚出去的那几条卸载掉，换上滚进来的新数据。

这样页面上始终保持只有二十多个节点，浏览器一点儿都不累。

// 技术栈：Vue 3（组合式API）
<script setup>
import { ref, computed, onMounted } from 'vue';

// 假设后端返回了10000条数据
const allData = ref(
  Array.from({ length: 10000 }, (_, index) => `列表项内容-${index}`)
);

// 咱们的“视口”高度，就按400px算吧
const viewportHeight = 400;
// 每个列表项的高度，固定50px
const itemHeight = 50;
// 当前滚动位置
const scrollTop = ref(0);

// 看看视口里能容纳多少条
const visibleCount = computed(() => Math.ceil(viewportHeight / itemHeight));

// 计算当前起始索引
const startIndex = computed(() => Math.floor(scrollTop.value / itemHeight));

// 结束索引，稍微多渲染几个，作为缓冲，滚动时不至于白屏
const endIndex = computed(() => startIndex.value + visibleCount.value + 4);

// 真正渲染到DOM里的数据，就这么二十来条
const visibleData = computed(() => {
  return allData.value.slice(startIndex.value, endIndex.value);
});

// 给最外层容器设置一个总高度，让滚动条看着是真的有这么多数据
const totalHeight = computed(() => {
  return allData.value.length * itemHeight;
});

// 滚动条动的时候，更新滚动位置
function handleScroll(event) {
  scrollTop.value = event.target.scrollTop;
}

onMounted(() => {
  // 页面挂载后，就只看得到那么几条，DOM节点数非常少
});
</script>

<template>
  <!-- 
    overflow-y: auto 让这个容器可以滚动；
    :style 把总高度绑上去，保证滚动条长度是对的。
  -->
  <div class="virtual-list" style="overflow-y: auto; height: 400px;" @scroll="handleScroll">
    <!-- 
      这个div用来占位，把高度撑起来，让滚动条看起来像滚动了整个列表。
    -->
    <div :style="{ height: totalHeight + 'px', position: 'relative' }">
      <!-- 
        这里做一次“位移”，把当前这二十条内容挪到正确的位置上
      -->
      <div :style="{ transform: `translateY(${startIndex * itemHeight}px)` }">
        <!-- 
          只渲染用户当前能看到的条目
        -->
        <div v-for="(item, index) in visibleData" :key="startIndex + index" style="height: 50px;">
          {{ item }}
        </div>
      </div>
    </div>
  </div>
</template>

你看这个例子，虽然数据有一万条，但页面里实际的节点数只有十来二十个。用户不管怎么滚动，浏览器需要处理的节点都差不多。这就是典型的“节点减肥”，效果立竿见影。

4.2 尽量少用多层包裹，用语义化标签代替

咱们平时写页面，不要一上来就几个<div>套几个<div>。很多时候，咱们可以用更简单的语义化标签，或者用更扁平的CSS结构来实现。

比如下面这种情况，咱们就不需要套三层：

// 技术栈：Vue 3（组合式API）
<script setup>
import { ref } from 'vue';

// 模拟用户信息
const userInfo = ref({
  name: '张三',
  age: 28,
  email: 'zhangsan@example.com'
});
</script>

<template>
  <!-- 
    不推荐的做法：为了展示一条卡片信息，套三层div
    注意，这是一种“反面教材”的写法，咱们看看就好
  -->
  <div class="card">
    <div class="card-body">
      <div class="card-content">
        <p>{{ userInfo.name }}</p>
        <p>{{ userInfo.age }}</p>
        <p>{{ userInfo.email }}</p>
      </div>
    </div>
  </div>
</template>

其实咱们可以这样写，层级直接从三层变成一层：

// 技术栈：Vue 3（组合式API）
<script setup>
import { ref } from 'vue';

// 模拟用户信息
const userInfo = ref({
  name: '张三',
  age: 28,
  email: 'zhangsan@example.com'
});
</script>

<template>
  <!-- 
    推荐的做法：用CSS直接搞定样式，没有多余的无意义层级
  -->
  <div class="card" style="padding: 20px; border: 1px solid #eee;">
    <p>姓名：{{ userInfo.name }}</p>
    <p>年龄：{{ userInfo.age }}</p>
    <p>邮箱：{{ userInfo.email }}</p>
  </div>
</template>

这整块区域还是原来的内容，但节点数量就从四个变成了两个。别小看这一点点改动，积少成多，一个页面上几十处这样的地方，加起来就能少掉好几百个节点。

4.3 做好按需加载，别把东西全堆在首页

还有一个很常见的毛病，就是咱们做一个页面，不管用户用不用得到，把所有模块都一股脑儿渲染出来。比如一个后台系统的首页，又有图表、又有表格、又有日历、又有待办事项，其实用户主要就看那个表格，其他的一眼都没看过。

那咱们何必把那些模块全部堆在首页呢？Vue里头有个特别好用的东西叫defineAsyncComponent，它能让咱们把某些组件单独切开，等要用的时候再加载。

// 技术栈：Vue 3（组合式API）
<script setup>
import { ref } from 'vue';
import { defineAsyncComponent } from 'vue';

// 这个日历组件，用户不点开，就不渲染，也不加载相关代码
const AsyncCalendar = defineAsyncComponent(() =>
  import('./components/BigCalendar.vue')
);

// 这个数据列表组件，是用户一定会看的，就同步加载
import MainTable from './components/MainTable.vue';

// 控制是否显示日历
const isCalendarVisible = ref(false);

// 用户点击按钮后才去渲染日历组件
function showCalendar() {
  isCalendarVisible.value = true;
}
</script>

<template>
  <div>
    <!-- 这个是主要表格，进页面就看得到 -->
    <MainTable />

    <!-- 日历延迟加载，不点开就不创建节点 -->
    <button @click="showCalendar">打开日历</button>
    <AsyncCalendar v-if="isCalendarVisible" />
  </div>
</template>

这样一来，页面初始打开的时候就只有一个表格，不加载日历组件，既减少了网络请求，又减少了DOM节点。等到用户确实需要看日历了，咱们再把它渲染出来。这是性能优化里非常推荐的做法。

4.4 善用v-if和v-show，别傻傻分不清

可能有的朋友平时用v-if和v-show比较随意，觉得都能控制元素显示隐藏，随便用一个就行。其实这里头大有讲究。

简单来说，v-if是“真的没有”，它压根儿就不会把节点创建出来。而v-show是“有这个节点，只是用CSS把它藏起来了”。从减少DOM节点的角度来看，如果某块内容在大部分时间是不显示的，那就应该用v-if。如果这个内容需要频繁地切换显示和隐藏，那用v-show会更流畅。

咱们举个小例子：

// 技术栈：Vue 3（组合式API）
<script setup>
import { ref } from 'vue';

// 这个标记用户有没有权限
const hasPermission = ref(false);
// 这个标记是否展开详情
const isExpanded = ref(true);
</script>

<template>
  <div>
    <!-- 
      如果用户没有权限，那这块内容就不要渲染出来
      用v-if，当hasPermission为false时，这个节点根本不存在
    -->
    <div v-if="hasPermission" class="admin-panel">
      这里是管理员才能看到的内容
    </div>

    <!-- 
      这个详情区域需要用户频繁点击展开/收起
      比如每次点击都让isExpanded在true和false之间切换
      如果这里用v-if，那每次切换都得创建节点、销毁节点，开销很大
      用v-show的话，节点一直在，只是hidden属性在变，快得很
    -->
    <div v-show="isExpanded" class="detail-area">
      这里是订单详情的信息，用户喜欢一次看几眼
    </div>
  </div>
</template>

大家看到区别了吧，不常看见的内容用v-if省节点，频繁切换的内容用v-show省开销。这一招用好了，页面节点数量能轻松减少一大截。

五、亲手改造一个“臃肿”的页面

光说不练假把式。咱们找个典型场景，亲手把它改造一下。

5.1 改造前的页面（反例）

假设咱们要做一个商品评论区，里面有1000条评论。每条评论要显示用户名、头像、评论内容、点赞数。

这是个很常见的场景，但常见的错误也很典型。咱们来看：

// 技术栈：Vue 3（组合式API）
<script setup>
import { ref } from 'vue';

// 构造1000条评论数据
const comments = ref(
  Array.from({ length: 1000 }, (_, index) => ({
    id: index,
    user: `用户${index}`,
    avatar: `https://example.com/avatar.png`,
    content: '这是一条评论，内容比较长，咱们主要是为了演示页面节点性能和优化方案。',
    likes: Math.floor(Math.random() * 100)
  }))
);
</script>

<template>
  <!-- 直接渲染所有评论，没有任何性能优化，属于反面教材 -->
  <div class="comments">
    <div class="comment-item" v-for="item in comments" :key="item.id">
      <!-- 头像 -->
      <img :src="item.avatar" alt="头像" />
      <!-- 用户名 -->
      <span class="comment-user">{{ item.user }}</span>
      <!-- 评论内容 -->
      <p class="comment-content">{{ item.content }}</p>
      <!-- 点赞 -->
      <span class="comment-like">{{ item.likes }} 赞</span>
    </div>
  </div>
</template>

这个页面前端一加载，就必须要渲染1000条评论。每个评论算上头像一个<img>，加上外面的<div>，一共至少五个节点。1000乘以5就是5000个节点。如果用户刚好翻到这条评论要点赞，浏览器就要重新计算这5000个节点里受影响的区域，能不费劲吗？

5.2 改造后的页面（正例）

现在我们来想想怎么优化。

1. 这1000条不能全部渲染，用之前聊过的虚拟滚动。
2. 头像这种不重要的图片，如果用户没划到那里，就不要加载，减少网络阻塞。
3. 当用户点赞的时候，只更新当前那一条数据，不要让整个列表跟着重新渲染。

基于这几条思路，我们改造一下。

// 技术栈：Vue 3（组合式API）
<script setup>
import { ref, computed } from 'vue';

// 构造1000条评论数据
const allComments = ref(
  Array.from({ length: 1000 }, (_, index) => ({
    id: index,
    user: `用户${index}`,
    avatar: `https://example.com/avatar.png`,
    content: '这是一条评论，内容比较长，咱们主要是为了演示页面节点性能和优化方案。',
    likes: Math.floor(Math.random() * 100)
  }))
);

// 下面的配置用于实现虚拟滚动
const itemHeight = 100; // 每条评论的高度大概100px，具体看样式
const viewportHeight = 500; // 可视区域高度500px
const scrollTop = ref(0);

// 起始位置和结束位置
const startIndex = computed(() => Math.floor(scrollTop.value / itemHeight));
const visibleCount = computed(() => Math.ceil(viewportHeight / itemHeight));

// 结束索引加一点点缓冲，让滚动不那么突兀
const endIndex = computed(() => startIndex.value + visibleCount.value + 5);

// 真正要渲染的评论只有这十几条
const visibleComments = computed(() => {
  return allComments.value.slice(startIndex.value, endIndex.value);
});

// 整个列表的高度，用于撑开滚动条
const totalHeight = computed(() => {
  return allComments.value.length * itemHeight;
});

// 点赞操作，直接修改具体的某一条数据
// 注意：因为只有十几条在页面上，修改其中一条的likes值时，
// Vue只更新那一个节点的文字，不需要动其他节点
function userLike(commentId) {
  const target = allComments.value.find(item => item.id === commentId);
  if (target) {
    target.likes += 1;
  }
}

// 滚动事件
function onScroll(event) {
  scrollTop.value = event.target.scrollTop;
}
</script>

<template>
  <!-- 
    外层容器，设置高度和滚动
  -->
  <div class="comments-viewport" style="overflow-y: auto; height: 500px;" @scroll="onScroll">
    <!-- 
      占位div，高度为全部数据的总高度
    -->
    <div :style="{ height: totalHeight + 'px', position: 'relative' }">
      <!-- 
        把可见区域的内容移动到正确的位置
      -->
      <div :style="{ transform: `translateY(${startIndex * itemHeight}px)` }">
        <!-- 
          这里只渲染十几条节点，跟之前五千个节点比，简直是天壤之别
        -->
        <div class="comment-item" v-for="item in visibleComments" :key="item.id">
          <!-- 头像 -->
          <img :src="item.avatar" alt="头像" />
          <!-- 用户名 -->
          <span class="comment-user">{{ item.user }}</span>
          <!-- 评论内容 -->
          <p class="comment-content">{{ item.content }}</p>
          <!-- 点赞，点击后调用方法，只修改当前那一条 -->
          <button @click="userLike(item.id)">{{ item.likes }} 赞</button>
        </div>
      </div>
    </div>
  </div>
</template>

咱们来看看这个改动量：

• 改动前，页面需要创建5000个左右节点。
• 改动后，页面只创建十几、二十个节点。不管滚动到哪里，节点数量都是这么多。

这带来的体验提升是从“有点卡”直接变成“非常丝滑”。而且你注意看，userLike方法里，咱们直接操作的是具体的某一条数据，跟其他999条评论没关系，所以Vue只需要重新渲染那一个节点的数字就行了，完全不会牵动整个列表。

六、聊聊这些事一般在哪儿用得上

那么这个优化思路在哪些场合特别有效果呢？

第一类是数据大屏。大屏上全是图表，图表下面的数据可能每分钟刷新一次。如果底层的DOM节点太多，每次刷新都要重排重绘，那大屏就会变成“幻灯片”，一帧一帧地卡。用虚拟滚动或者按需加载，保证有效节点不多，刷新才顺滑。

第二类是表格系统，尤其是那种一个页面十几列、几千行的表格。银行交易流水、ERP系统订单明细、运维平台的日志列表，这些数据量动不动就是几千上万条。如果不控制节点数量，用户拖动滚动条的时候就会明显能感觉到非常钝。

第三类是无限下拉的信息流，像咱们平时刷的社交媒体动态，刷一条增加一条，如果不做裁剪，那越刷越卡，内存早晚爆掉。

到了这三种场景，减少节点数量和层级深度就不是“锦上添花”了，而是“雪中送炭”。

七、这些优化方法有啥优缺点

万事都有两面性。咱们讲的这些办法当然也并不是只有好处没有坏处。

减少节点数量的优点：

• 浏览器要维护的节点少了，内存占用自然降低。
• 重排重绘的范围大幅缩小，页面响应更快。
• 滚动、点击、输入等交互操作会变得特别跟手。

减少节点数量的注意事项或者说缺点：

• 虚拟滚动会引入一些计算逻辑，比如要动态计算索引、位移。代码复杂度会提高一点点。
• 懒加载组件（按需加载）需要拆代码，如果拆分得太细，可能请求的次数变多，网络开销变大。这时候要平衡一下代码分割的力度。
• 用v-if的时候，如果频繁切换，创建销毁节点本身也有消耗，不能为了减节点而无脑用v-if，要跟v-show搭配着来。

减少层级深度的优点：

• 浏览器在计算样式和布局时，遍历节点路径短了，速度更快。
• CSS 样式继承计算也更高效。
• 代码结构更清晰，后期维护起来不容易让人头晕。

减少层级深度的注意事项：

• 层级太扁平可能导致CSS写起来稍微费点劲，比如没有那个深层的容器可以用，就要靠margin或者padding来调间距。
• 有时候为了语义化，适当保留两层、三层嵌套是合理的，不要为了扁平而扁平。

八、整个事儿我的一些心得

说到底，这页面的性能优化就跟咱们平时收拾屋子是一个道理。屋子大不大不重要，重要的是东西摆得整齐不整齐。你愿意把不用的东西收进柜子里，把常用的放在手边，那屋子自然就显得宽敞明亮。页面也是一样，我们别把那些用户压根看不到的DOM节点全堆在页面上，也别用一层又一层无意义的嵌套把浏览器给绕晕。

所以说到底，核心策略就几件事：能不建的就别建，能不嵌套的就不嵌套；只渲染用户看得见的，等要用的时候再渲染。这几件事儿看着简单，但真正做起来，需要从设计组件的阶段就开始思考——这个模块是不是一定要渲染？这个节点放在这里有什么用？

咱们作为开发者，对页面的掌控感其实就藏在这些细节里头。希望读完这篇文章，咱们以后写代码的时候，能多想一想：我这样写，浏览器会不会累？如果累，能不能让它轻松一点？就冲这个念头，咱们页面的性能就已经开始变好了。

在日常开发过程中，咱们可以养成本能反应：面对一个长列表，先想想虚拟滚动；面对一个不常用的模块，先用异步组件；面对一段无明显语义的包裹标签，先试试能不能删掉。好的使用体验就是这么多一点一滴的细节撑起来的。