企业官网建设流程全解析

我印象很深的一次经历，是一个电商营销H5，上线当晚就被运营同事截图投诉：iPhone上开屏动画结束后，往下滑商品列表时手指已经划出去了，页面还停在原地，过了快半秒才开始滚动，接着又是一顿一顿地刷新。那时候我还习惯用“把图片压缩一下、接口合并一下”这种玄学方式处理，结果毫无改善。后来把性能问题当成一道计算题来解，才真正找到门路。

这篇文章想把移动端H5性能优化这件事讲透——从卡顿产生的原理，到用工具定位瓶颈，再到渲染、资源、内存三个方向的具体优化手段，最后用一个实际案例串起整个流程。不管你现在用的是原生JS、Vue还是React，只要交付的页面跑在手机浏览器里，下面这些思路和方法都能直接用。

1. 为什么你的H5页面一滚动就掉帧：卡顿问题的本质拆解

1.1 帧预算与主线程：一次16.7ms的生死时速

先明确一个基本概念：手机屏幕的刷新率通常是60Hz，也就是说每秒要刷新60帧画面。每一帧留给浏览器的时间大约16.7ms。浏览器在这16.7ms里要完成JS脚本执行、样式计算、布局、绘制、合成这一整套渲染管线，只要其中任何一步超时，这一帧就出不来，表现出来就是掉帧、卡顿。

我对团队的同学们常打一个比方：这就像做流水线快餐，从接到订单到出餐只有16.7秒，洗菜切菜炒菜装盘必须在这个时限内全部完成。你不在切菜环节优化，反而去把盐罐子换了个位置，那高峰期照样出不了餐。H5性能优化的所有手段，归根到底都是在为这16.7ms争取时间。

用Chrome DevTools的Performance面板去录制一段滚动操作，你能直观看到主线程上排着一个个任务，红色背景的“long task”就是超时任务。一次long task意味着用户感受到了一个卡顿帧。如果一段滚动操作里连续出现好几个long task，用户就会觉得“这页面卡死了”。所以排查卡顿，第一步永远是找long task。

1.2 移动端硬件的现实：手机不是缩小版桌面浏览器

桌面端Chrome跑得飞快，不代表手机浏览器也一样。移动端CPU的核心调度更保守，多核性能释放受限于功耗和散热，GPU能力与显存带宽和桌面端差了好几个量级。内存方面，中低端安卓机可用内存可能只有2GB到3GB，页面稍微吃内存，系统就会触发回收机制，导致突然白屏或者动画掉帧。

更麻烦的是浏览器内核碎片化。iOS上所有浏览器都必须用WebKit内核，安卓上则普遍是Chromium内核，但不同厂商还会魔改WebView的底层参数。同一个CSS动画，在iPhone 15 Pro上丝滑如在黄油上滑行，放到一款旧安卓机上可能直接变成幻灯片。这就是为什么我始终强调：性能优化必须以真实设备为准，不能只看开发者工具的设备模拟器。

1.3 先把问题分类：渲染卡、逻辑卡还是加载慢

碰到一个性能问题，不要急着改代码，先判断类别。我自己的分类框架是四类：

这四个类别不是互斥的，一个页面可能同时踩中好几个坑。但分类能帮你确定优先处理的方向——如果首屏白屏4秒，那渲染动画再顺滑也没意义，先解决加载链路。

2. 动手前先做的三件事：定位瓶颈比动手优化更重要

2.1 Performance面板：录一段操作，找到主线程的“长任务”

先说一个我见过很多次的场景：同事跟我说页面卡，我问他怎么判断的，他回答“感觉有点卡”。感觉这个词没法作为优化依据，你必须用数据把“卡”量化出来。

Chrome DevTools的Performance面板是最基础的工具。操作路径是：打开DevTools，切到Performance面板（注意新版Chrome可能变成Recorder或者需要单独打开工具菜单），点击左上角录制按钮，然后在页面上完成一段典型的用户操作——滚动商品列表、切换Tab、点击弹窗——最后停止录制。

录制完成后重点关注三块区域：

• Summary条：记录整段录制里Scripting、Rendering、Painting、其他类别耗费时间的占比。如果Scripting占了60%以上，问题大概率在JS执行；如果Rendering和Painting占比很高，那就是样式和绘制层面的问题。
• 主线程火焰图：能看到每一个函数调用的耗时。遇到红色的“长任务”标记，点开看具体是哪个函数，很多时候能直接定位到某个耗时循环或者强制同步布局。
• Network区间：看每个网络请求在时间轴上的位置。资源请求如果挤在海浪里一样并行发出，并且阻塞了DOMContentLoaded，那就是加载阶段的问题。

“查Performance面板”这句话写起来轻巧，真正用的时候有几个容易踩到的坑：一是模拟器默认的CPU节流和真实手机差很远，要在DevTools里把CPU调到4x或6x slowdown再测，更接近中低端机的状况；二是移动端页面最好打开设备工具栏选择一台真实机型再录制，否则结果没有参考性；三是录制的操作要连续、有代表性，不要只滚两下就停，否则火焰图数据不足，看不出规律。

2.2 帧率实时监控：用Stats.js把掉帧变成数字

Performance面板能看历史记录，但你在真机上调试时，更需要一个实时的帧率读数。我自己常用的方案是stats.js，一个不到2KB的小库，能在页面角落显示当前FPS和帧时间。

如果你不想引外部库，手写一个简易帧率统计器也很简单。最核心的思路是用requestAnimationFrame的节奏来计算：记录上次回调的时间戳，如果两次回调之间的间隔超过40ms，说明中间有掉帧；连续统计一定帧数后，就能算出平均FPS。

把这个工具临时嵌入页面里，在真机上进行真实的滑动、点击、播放动画等操作，就能得到一个非常有说服力的数字：优化前24fps，优化后57fps。这个数字既方便你自己评估优化效果，也方便向产品和运营同事证明“问题确实被修复了”。

2.3 Network瀑布图：从加载顺序看资源瓶颈

很多卡顿其实不是运行时卡顿，而是加载阶段导致的“假卡顿”。比如用户点进来白屏3秒，然后页面哐一下全部出现，给人的感觉就是“卡了一下”。

这种问题要从Network面板看瀑布图，核心观察三个点：

• 请求数量：一个H5首屏发出五六十个请求，在移动网络下光是排队就要浪费大量时间。HTTP/1.1时代浏览器对一个域名并发连接数是6，超过6个就要排队；HTTP/2虽然改了机制，但请求多了仍然会带来服务器和解析压力。
• 单个资源大小：一张2MB的图片、一个800KB的JS文件，都会让首屏时间成倍增加。移动端的网络状况比你想的糟糕得多，4G信号满格时下载速度可能都达不到理论值。
• 关键资源链：从HTML文档加载，到CSS阻塞渲染，再到JS阻塞解析，最后图片逐个出现——这条链路上任何一个环节慢，都会拖后首屏。用瀑布图可以直观看到哪些资源在阻塞。

我见过最典型的问题，是设计师在Sketch里做了一张1920px宽的banner原图导出为PNG，直接塞进H5里。手机屏幕逻辑宽度只有375px，但用户被迫下载了相当于桌面端的整张大图。这种问题不看瀑布图很难发现，因为你预览时用的是高速网络和桌面Chrome缓存，根本感受不到用户实际下载时的痛苦。

3. 渲染层降本增效：合成层、重排重绘与GPU加速的取舍

3.1 重排重绘的代价：为什么left: x动画卡成PPT

任何元素显示在屏幕上，都需要经历布局（layout）和绘制（paint）过程。当你用JavaScript去修改元素样式时，如果修改的属性会影响文档流中的位置或尺寸，浏览器就需要重新计算整个页面或部分区域的布局——这就是重排（reflow）。如果只影响颜色、背景等视觉属性，不需要改变布局，只需重新绘制——这就是重绘（repaint）。

重排的代价远高于重绘，因为在重排后往往还要连带触发重绘。频发的重排是移动端H5卡顿的头号元凶。

举个最常见的反面案例。很多人做跑马灯或者横向拖拽效果，习惯这样写：

element.style.left = x + 'px';

修改left属性会触发layout，浏览器需要重新计算这个元素的几何位置，以及后续元素是否受影响。如果滚动事件里每帧都这么写，每一帧都要做layout+paint，低端机直接卡成PPT。

更隐蔽的是“强制同步布局”（Forced Synchronous Layout）。比如你先读取了某个元素的offsetHeight，然后修改它的style属性，接下来又去读取offsetWidth。浏览器为了返回准确的读取值，不得不强制提前执行一次尚未完成的布局计算。读写操作交织在一起，就会造成反复多次布局，性能极差。

3.2 transform+opacity的神奇之处：为什么它走合成器

浏览器渲染管线经过多年演进，已经支持将某些CSS属性交给独立的合成器（compositor）处理。合成器作用在GPU上，将页面的不同部分分层，只对变化的层做合成，不需要重新走layout和paint。

可以触发合成器的属性就是两个：transform和opacity。把位移动画从left改成transform: translateX()之后，浏览器每一帧只需要告诉合成器“这一层移动了多少”，然后由GPU去拼接画面。这也是为什么业界所有滚动动画、入场动画、拖拽交互都推荐用transform而非top/left。

对比一下：

/* 不推荐：触发layout + paint */ .box { left: 0; transition: left 0.3s; } /* 推荐：仅触发composite */ .box { transform: translateX(0); transition: transform 0.3s; }

同样做位移，两者在性能上差距巨大。用transform的动画哪怕在很低的帧率下也不会导致布局抖动。

但要提醒一句：能走合成器的动画，也应该控制合成层的数量。合成器虽然快，但每一层都是一份独立的纹理，要占用GPU内存。移动端GPU内存并不宽裕，几十个层同时存在可能直接造成内存压力，反而触发性能问题。

3.3 will-change、contain与content-visibility：给浏览器“划重点”

既然合成层这么好用，聪明的开发者自然会想：能不能提前告诉浏览器，某个元素接下来要做动画，请你预先给它创建合成层？这就是will-change属性的作用。

.anim-target { will-change: transform, opacity; }

will-change本身是个好工具，但很考验使用姿势。如果你对一个元素设置will-change: transform，浏览器会立刻给它创建一个独立的合成层，这个层的纹理在动画还没开始时就占用了内存。如果页面上有几十个元素都设置了will-change，合成层数量暴涨，GPU内存吃紧，结果就是还没开始优化就已经给性能埋了雷。

我的习惯是：只在动画开始前加will-change，动画结束后移除。用JS控制：

element.style.willChange = 'transform'; requestAnimationFrame(() => { element.style.transform = 'translateX(100px)'; }); element.addEventListener('transitionend', () => { element.style.willChange = 'auto'; });

另外两个容易被忽略但非常实用的CSS属性是contain和content-visibility。

contain的作用是告诉浏览器：这个元素的内部变化不会影响外部布局。比如一个商品卡片内部的文字长度变化，不会影响卡片外部的兄弟元素。加上contain: content之后，浏览器可以把这个元素内部的样式计算、布局、绘制独立出来，不向上传播，减少不必要的重排范围。

content-visibility: auto则更激进，它可以让视口外的元素直接跳过渲染。对于超长页面特别有用——比如一个H5里有几百个商品卡片或者评论列表，屏幕上看得到的只有前几个，其余部分完全可以暂时不渲染，等滑到附近时再渲染。配合contain-intrinsic-size给元素一个预估高度，还能避免滚动条高度跳动的问题。

.long-list-item { content-visibility: auto; contain-intrinsic-size: 200px; }

这里有个比较典型的注意点：content-visibility: auto虽然有奇效，但如果你依赖锚点定位或者页面内搜索，跳过渲染的内容可能会影响定位结果，使用前要评估业务场景。

3.4 分批渲染与虚拟滚动：从源头减少DOM数量

有没有想过，很多卡顿其实不是“渲染太慢”，而是“要渲染的东西太多了”。DOM本身是个昂贵的数据结构，每多一个节点，浏览器在样式计算、布局、绘制时就要多处理一份数据。与其优化单个节点的渲染成本，不如直接从源头减少同时存在的节点数量。

对长列表，两个常用的手段是分批渲染和虚拟滚动。

分批渲染的思路是把一个巨大的循环渲染拆分成多个小批次，每一批只生成一小段DOM然后插入页面，通过requestAnimationFrame或者requestIdleCallback分批推进。比如一次性要渲染1万条数据，可以拆成每帧渲染50条，这样即使总时间差不多，但用户不会感到页面卡死。缺点是如果数据量特别大，依然会残留性能问题。

虚拟滚动是更彻底的方案：只渲染视口附近的节点，其他的用空白占位，代码库实现比如vue-virtual-scroller、react-window，或者移动端常见的better-scroll结合虚拟列表。当用户滑动时，动态回收离开视口的DOM，创建进入视口的DOM。整个页面无论数据量多大，实际存在的节点数都保持在几十个以内。

我自己做移动端H5时，只要列表超过100条，就会直接上虚拟滚动，不愿意赌用户的手机性能。因为真机上的体验差距太悬殊了：一次性渲染500个商品卡片，低端机光是插入DOM就要几百毫秒，期间主线程完全阻塞，用户连点击都无法响应。

4. 图片、字体与首屏资源：移动网络下的加载提速方案

4.1 图片格式选型：WebP、AVIF与响应式srcset组合拳

图片永远是H5性能优化里最值得投入的板块。很多页面的体积分布，图片占了70%以上。一个页面加载慢，八成是图片在拖后腿。

先聊格式选型。JPEG体积大且不支持透明通道，PNG在复杂图形上体积失控，GIF和APNG更是动图杀手。WebP是谷歌推出的格式，同等画质下体积比JPEG小25%到35%，支持透明通道和动画，iOS 14及以上、安卓5及以上都支持。AVIF压缩率比WebP再高20%到50%，但解码更吃CPU，在低端机上加载大量AVIF图可能会出现解码耗时，所以我一般建议AVIF作为高画质WebP方案的补充，而不是主推。

具体到代码，除了在图片处理管线里导出WebP格式，还需要配合响应式图片让不同屏幕宽度加载不同分辨率的图。

<img src="banner-750.jpg" srcset="banner-375.jpg 375w, banner-750.jpg 750w, banner-1440.jpg 1440w" sizes="100vw" alt="banner" >

这里面的关键点是：srcset让浏览器根据视口宽度和设备像素比选择最合适的图。iPhone 15 Pro的逻辑宽度是393，但设备像素比是3，所以总像素宽度接近1200px，适合加载750w档位。老安卓机跑750w就足够了，不会去下载1440的图。

移动端H5里还有一个很常见的陷阱：首屏大图全部没有设宽度高度，图片加载完成后页面布局突然跳动，对用户体验破坏很大。建议给img标签直接写死宽高，或者用aspect-ratio CSS属性占位，防止布局位移。

如果需要延迟加载屏幕外的图片，可以用loading="lazy"属性，但要记住：首屏图片顺序靠前的不要加lazy，因为浏览器不知道哪张是首屏，加了反而可能导致首屏图片延迟加载。

4.2 字体子集化与font-display：字体的“按需加载”

移动端H5的另一个隐形性能杀手是自定义字体。设计师喜欢用特殊字体做标题，比如方正兰亭、思源黑体这些。一个完整的字体文件动不动几MB，就算woff2压缩完也要一两百KB到几百KB。更可怕的是，有些CSS写法会让字体文件阻塞页面文字渲染。

你见过那种打开H5后文字先是空白，过了几秒突然全部出现的现象吗？往往就是font-display属性没设置好。浏览器默认的字体加载策略（block）会让使用该字体的文字在字体加载完成前完全隐藏，字体文件越大，白屏时间越长。

最简单的解法是设置font-display: swap。这样浏览器会先用系统字体渲染文字，等自定义字体加载完成后再替换，用户不至于看到一片空白。

更进一步的做法是字体子集化。业务场景里，一个H5标题可能只用到十几个汉字，完全没必要求一个完整的包含上万个汉字的字体文件。可以用fonttools这类工具从字体文件中提取出用到的字符，生成一个只有几KB的子集字体，同时用unicode-range让浏览器只下载需要的部分。

@font-face { font-family: 'MyTitleFont'; src: url('my-font.woff2') format('woff2'); font-display: swap; unicode-range: U+4E00-9FFF; /* 仅中文范围 */ }

如果页面同时有中英文混排，可以把中文字体子集和英文字体分开加载，英文用更小的字体文件。实测下来，一次字体优化能把白屏时间减少500ms以上，是性价比非常高的优化。

4.3 代码分包与预加载：把加载链路拆得更细

移动端H5的最终大小里，JavaScript也常常是重磅炸弹。Vue或React全家桶打包出来的vendor.js动辄几百KB，如果入口文件包含所有页面所需的代码，用户虽然只看了首页，也要下载整个应用的代码。

路由级按需加载是解决这个问题的标配。Vue Router或者React Router都支持动态导入路由组件，配合Webpack的splitChunks或Vite的manualChunks，把公共依赖和业务代码拆成多个chunk。首屏只加载当前页面需要的chunk，进入其他页面时再加载对应代码。

const routes = [ { path: '/home', component: () => import('./views/Home.vue'), }, { path: '/detail', component: () => import('./views/Detail.vue'), }, ];

除了代码分包，资源预加载也值得重视。有些H5页面的首屏是图片，图片是CSS背景图引用，那么浏览器要等到解析到CSS规则时才会去下载。如果想第一时间就加载这些关键资源，可以在HTML的head里加preload提示：

<link rel="preload" as="image" href="hero.webp">

预加载既能加速首屏资源的下载时机，又不会像普通script那样阻塞解析。它适合用来加载首屏banner图、背景图、关键字体等少数核心资源。注意preload不要滥用，加载了不在首屏使用的资源反而会浪费带宽。

5. 内存泄漏与长列表渲染：运行期性能陷阱的排查与修复

5.1 事件监听器、定时器与闭包：泄漏的三个经典来源

很多H5的卡顿不是一开始就卡，是越用越卡。用户在一个页面停留几分钟，切了几个Tab，页面开始变得迟滞，最后的终极形态是崩溃白屏。这种“越用越卡”的问题，几乎都是内存泄漏造成的。

移动端H5里最常见的泄漏来源有三个：

第一个是事件监听器。如果你在组件里用addEventListener给全局对象绑定了监听器，比如window.addEventListener('scroll', handler)，而在组件销毁时没有调用removeEventListener，那么这个监听器会一直存活，它引用的闭包和DOM节点也不会被垃圾回收。

第二个是定时器。setInterval在组件销毁时没有clearInterval，定时器回调就会一直执行，它持有的变量永远不会释放。再叠加DOM操作，内存会持续增长。

第三个是闭包持有DOM节点。比如你在某个函数里用变量引用了页面上一个元素，然后这个函数被赋给了全局变量或者保存在一个长生命周期的对象里，DOM节点就无法被回收。用Chrome的Memory面板拍堆快照，你会看到一堆“Detached DOM”节点，这就是已经脱离文档树但还没被回收的元素。

我自己的排查流程是：在页面操作前后各拍一次堆快照，对比两次快照中Retained Size显著增长的对象，顺着引用链往下找。如果看到某个DOM节点或者Vue组件实例被一个全局事件处理器引用，基本就是泄漏了。修复方式很简单：对应生命周期里清理监听器和定时器，用flag标记组件是否已销毁。

5.2 树组件与长列表：为什么一次性渲染直接卡死

业务开发中常见的数据结构是树形结构，比如移动端的地区选择、组织架构、商品分类。vant的TreeSelect、element的el-tree、或者自己封装的树选择器，在数据量大的时候都容易踩坑。

问题在于：树组件在展开时，很多人习惯把子节点也一次性渲染出来。比如一个省市区数据有3000个节点，全量展开就是3000个DOM节点，再加上每个节点的事件、class、绑定数据，页面想快都难。

我的建议是只渲染当前展开层级的节点，采用懒展开的方式。用户点开某个节点，再去请求它的子节点数据，或者从内存数据里动态取。对于Vue来说，可以把树数据做一次扁平化，渲染时只保留可见节点，用一个activePath记录当前展开路径，这样实际渲染的DOM数量永远只跟当前展示层级的节点数有关。

长列表的问题类似。移动端H5中列表类的场景非常多：商品列表、评论列表、信息流资讯。如果数据量超过一两百条，就不建议全量渲染了。虚拟滚动是首选，如果团队暂时没有虚拟滚动组件，至少也要做分页加载，下拉到底才加载下一页。避免在页面初始渲染时把所有数据一次性塞给DOM。

5.3 Web Worker分流：把计算任务请出主线程

主线程既要处理用户的点击、滚动、输入，又要执行JavaScript代码，还要协调渲染。当某个计算任务特别重的时候，用户的所有交互都会被阻塞。

Web Worker能提供另一个JavaScript运行线程，让复杂计算不占用主线程。我把计算密集型的JSON数据清洗、复杂的排序过滤、图片数据转换、数据压缩解压等任务放到Worker里执行。

// main.js const worker = new Worker('/worker.js'); worker.postMessage(largeData); worker.onmessage = function (event) { const result = event.data; // 更新页面 }; // worker.js self.onmessage = function (event) { const data = event.data; // 处理耗时计算 const result = processData(data); self.postMessage(result); };

使用Worker时注意几点：Worker里没有DOM，不能直接更新界面；postMessage传递数据会进行结构化克隆，大数据量有拷贝开销；移动端创建Worker也有一定成本，只有计算确实很重时才值得用。

我之前接手的项目里有一个榜单模块，前端要从接口拿到2万条用户数据，在前端完成排名计算和区间聚合。原来在页面主线程做，计算耗时接近3秒，页面卡得连滚动都费劲。把计算搬到Worker之后，主线程完全不受影响，计算时间不变，但用户可以正常操作页面，体验完全两回事。

5.4 防抖与节流：高频事件处理器的缓冲机制

scroll、resize、touchmove、mousemove这类事件触发的频率远高于用户可感知的交互频率。如果每个事件回调里都执行了较重的操作，主线程会被彻底淹没。最典型的场景是滚动事件回调里直接修改DOM结构，每滚动一个像素就触发一次重排。

防抖（debounce）的思路是：事件停止触发一段时间后才执行回调，适合输入联想、窗口尺寸变化后的重布局。节流（throttle）的思路是：每隔固定时间最多执行一次，适合滚动事件和mousemove。两者有微妙差别，我通常组合使用。

滚动事件最推荐的方案是requestAnimationFrame节流。rAF本身就是浏览器的帧回调，把它作为节流时机天然契合渲染管线：

let ticking = false; function onScroll() { if (!ticking) { requestAnimationFrame(() => { // 执行滚动相关逻辑 ticking = false; }); ticking = true; } } window.addEventListener('scroll', onScroll, { passive: true });

注意上面我加了{ passive: true }，这个参数告诉浏览器：滚动事件的监听器不会调用preventDefault，因此浏览器可以立即开始滚动而不必等待事件处理函数执行完毕。去掉这个参数，每次滚动都要先询问JS“你要不要阻止我的默认滚动行为”，本身就是一种性能损耗。

6. 一个复杂营销H5的优化实录：从23帧到58帧的完整操盘

6.1 原始页面为什么慢：问题清单

前面讲了这么多原理和手段，我用一个真实案例把它们串起来。这是我接过的一个电商大促活动页，入口在直播间，用户点进来的首屏是一个品牌视频头图，下面跟着商品瀑布流、销量排行榜、秒杀倒计时，以及一个常驻底部的抽奖弹窗按钮。

页面在低端安卓机上的初始状态是：白屏2.5秒，进入后滚动掉帧，排行榜区域每3秒刷新一次数据，刷新时页面肉眼可见地卡一下。用Stats.js实测，滚动状态下的平均帧率只有23fps。

我先把问题列成清单，逐个确认根因：

• 首屏三张大图都是PNG，合计4.8MB，手机实际只需要375px宽度的图
• 视频自动播放设置不当，不在视口内也预加载了全部视频数据
• 商品瀑布流一次性渲染200个商品卡片，每个卡片都有box-shadow和圆角大阴影
• 排行榜每3秒一个setInterval请求接口，然后通过innerHTML整体重写DOM
• 标题字体文件1.2MB，没有子集化，也没有font-display: swap
• 页面加载了完整的jQuery库，只为了用它的动画和工具函数
• 大量元素使用position: absolute和left/top做动画
• 滚动事件监听器里直接做DOM样式修改

这几乎是移动端H5性能问题的全家桶。每个单项都不算特别严重，叠加起来就是灾难。

6.2 逐项优化与前后对比

优化的实施顺序我遵循一条原则：先解决加载问题，再解决运行时问题。因为加载阶段的白屏会决定用户是否愿意留下来，而运行时的流畅度决定用户是否能完成浏览和购买。

第一步，处理首屏图片。把PNG全部转成WebP，用工具批量输出375w、750w、1440w三档尺寸，配合srcset让设备选择合适档位。首屏图片总大小从4.8MB降到1.1MB，白屏时间从2.5秒降到0.8秒。

第二步，处理视频。改用poster占位，用户点击播放时才加载真实视频流，同时给video标签加preload="none"属性。这一项直接省掉了几MB的流量和加载时间。

第三步，改造商品列表。引入虚拟滚动组件，窗口内只保留大约20个商品节点。同时移除box-shadow，改用1px的border与底部渐变模拟分割线。原本200个节点的重排重绘，变成20个节点，滚动开销大幅下降。

第四步，排行榜数据刷新不再全量重写DOM。把setInterval的轮询间隔从3秒调到10秒，并且只在数据真正变化时更新差异部分。用数组diff替代innerHTML整体替换。同时把响应式数据处理逻辑移入Web Worker。

第五步，字体子集化。提取页面标题中实际用到的十几个汉字，字体文件从1.2MB减到23KB，并加上font-display: swap，标题文字不再白屏等待。

第六步，用transform替换left/top动画。把倒计时的翻牌动画改成transform: translateY和scale，纯合成器动画，帧率显著提升。

第七步，移除jQuery依赖，用原生API改写，并给所有滚动事件加上passive: true。

优化完成后的数据：

这个案例里最让我意外的不是帧率提升，而是内存峰值下降得这么明显。内存峰值降低意味着低端机上的崩溃率大幅下降，这个问题之前完全被忽略了。

6.3 可以直接抄走的自查清单

最后整理一份自查清单，每次H5页面开发完发版前，我都要求团队同学对着过一遍：

• 首屏请求数是否超过30个？请求体积是否超过2MB？
• 首屏图片是否用了WebP？是否有响应式尺寸？
• 页面是否使用了自定义字体？字体是否子集化？font-display是否为swap？
• 动画是否全部使用transform和opacity？是否有元素绑定了will-change且未移除？
• 是否存在一次性渲染超过100个DOM节点的列表？
• scroll/resize/touchmove等事件是否做了节流或rAF合并？是否加了passive: true？
• 定时器和全局事件监听器是否在页面销毁时被清理？
• 是否有可移入Worker的计算任务？
• 连续操作几次页面后，内存是否回到初始状态？

这份清单里的每一项，对应到我前面讲的原理，都是可以快速验证的硬指标。如果一项一项都通过，页面的卡顿问题大概率已经被你在开发阶段解决了。

最后说一个让我印象很深的经验：性能优化不是一次性的“攻坚”，而更接近一种日常习惯。每次我写完页面，都会先用无痕模式录一段Performance，看看有没有长任务；每次评审设计稿，我都会顺口问一句“这个首屏图能不能控制在30KB以内”。养成习惯之后，你会发现本来需要集中排查的卡顿问题，大多数在开发阶段就被顺手按掉了。真等到运营拿着视频来找你，再好的优化技巧也只是在补救，而不是预防。