1. 先别急着动手优化把“性能债”量化清楚做商品详情页的前端性能优化最怕的就是一上来就“凭感觉”改代码——感觉图片慢就压缩图片感觉白屏久就上骨架屏改了一圈发现数据没变化用户反馈还是老样子。携程商品详情页这个项目我接手的时候线上已经积累了不少用户投诉主要集中在打开慢、滚动卡顿、图片半天出不来。但到底慢在哪、卡在哪团队里没人说得出准确数字。所以我的第一步不是写优化代码而是把性能现状完整摸了一遍。用大白话说先知道欠了多少债才能决定先还哪笔。摸底我主要用了三套手段上线前用 Lighthouse 做实验室指标扫描拿 FCP首次内容绘制、LCP最大内容绘制、CLS布局偏移这些核心指标做基线。浏览器端用 Performance API PerformanceObserver 采集真实用户数据RUM把首屏相关的时间点DNS、TCP、TTFB、资源加载、脚本执行全部打点落库。结合用户反馈和线上错误监控把“体感卡顿”翻译成具体的指标异常。比如用户说“图片半天出不来”对应到 LCP 时间过长用户说“点了日期没反应”对应到长任务Long Task阻塞了主线程。这一步做完问题分布就很清晰了首屏白屏时间长TCP 和 TTFB 正常但解析执行时间长、大图渲染慢图片体积过大且没有懒加载、滚动卡顿列表渲染没有做虚拟化长任务频繁阻塞主线程。有了这份“体检报告”后面每一项优化都能对应到真实数据也就有了明确的验收标准。1.1 商品详情页到底卡在哪先修好埋点再谈体验我之前见过不少团队优化做到一半发现没法验收根因就是埋点缺失——你根本不知道改动前后的差距是多少。所以这次我做的第一件事是把商品详情页的埋点补全用标准的 PerformanceTiming 和 PerformanceResourceTiming 数据把整个页面从“用户输入 URL”到“图片加载完成”拆成一段一段看。关键的时间节点有这么几个TTFBTime To First Byte浏览器收到服务器首个字节的时间反映网络链路和后端响应速度。FCP页面第一个文本、图片或 Canvas 绘制出来的时间也就是用户感知“页面有反应了”的时刻。LCP页面视口内最大元素通常是首屏主图绘制完成的时间这是用户感知“页面加载完”的关键节点。TBTTotal Blocking Time主线程被长任务阻塞的总时长直接决定用户点击和滚动是否“跟手”。CLS页面布局发生意外偏移的程度详情页最常见的问题就是图片没有预留尺寸加载完成后把整个页面“挤”下去。每个指标都对应一个埋点采集点采集完统一上报到日志平台。说实话这套埋点本身不复杂复杂的在于“不要遗漏移动端场景”——用户从微信、App 内嵌 WebView、浏览器三个渠道进入网络环境完全不同。我在这轮优化里特意按渠道维度把数据分了组后面分析瓶颈时才能分清哪些问题是网络本身的、哪些是前端代码造成的。1.2 用 Lighthouse 和 Performance API 摸清基线实验室数据和真实数据要配合着看。Lighthouse 提供的是“可控环境下的模拟结果”Performance API 提供的是“真实用户在不同网络下的表现”两者缺一不可。我用 Lighthouse 跑了三次取中位数得到基线大概是指标优化前基线行业参考线FCP2.8s1.8s 以内LCP4.6s2.5s 以内TBT620ms200ms 以内CLS0.180.1 以内光看 LCP 接近 5 秒就知道首屏一定有大体积资源在阻塞。再用 PerformanceResourceTiming 拉一遍所有资源的耗时明细发现首屏主图一张 3000px 宽的酒店实拍图下载耗时占了近 40%而且图片本身没有配置响应式尺寸移动端用户也在下载那张全尺寸大图。这里有一个特别容易被忽略的细节Performance API 拿到的资源耗时是“网络传输耗时 解码耗时”的总和。我发现有些图片的 transferSize 不大但 decode 时间非常长原因是图片格式太老JPEG 基线格式浏览器解码时需要整块整块地解耗尽了主线程。这个发现直接影响了后面图片格式选型的决策——不能只看体积还得看解码成本。1.3 从指标反推瓶颈一张表看懂问题分布摸完基线后我把所有性能问题整理成了一张“瓶颈分布表”每一条都对应具体的指标、发生率、影响范围问题现象对应指标预估影响占比首屏主图体积大、解码慢LCP、TBT约 35%底部长列表一次性渲染 200 节点TBT、FPS约 25%图片未懒加载首屏触发了大量不必要的请求FCP、LCP约 15%接口串行请求详情数据和图片地址互相等待FCP、LCP约 10%第三方脚本和统计脚本阻塞主线程TBT、FID约 10%布局抖动图片无尺寸占位CLS约 5%有了这张表优先级就很明确先解决占大头的问题再做精细化的体验打磨。后面每个章节的优化动作基本都对应这张表里的一行。2. 网络层的优化把不该下行的流量挡在前面优化完埋点、拿到基线后我开始动网络层。其实网络层优化往往是最先被想到的因为手段直接、效果直观。但很多人容易犯一个错误只顾着压缩资源、上 CDN却忽略了缓存策略和资源本身的“命中率”。在真实用户环境里一次页面访问产生的流量大头是图片和 JS 静态资源很多资源在首次访问后才缓存如果缓存策略配置错了用户每次回来都要重新下载一遍再压缩也是白搭。2.1 CDN 和 HTTP 缓存策略的重新盘点之前项目里很多静态资源的响应头没有显式配置 Cache-Control默认走了浏览器的启发式缓存。启发式缓存的一大问题是不同的浏览器、不同的资源类型缓存时间完全不可控有的资源你明明希望它过期浏览器却把它缓存了很久导致上线后用户还看到旧版本有的资源你希望它复用结果浏览器每次都回源校验。我这次做了两件事资源 URL 统一带内容哈希fingerprint。文件名变化代表内容变化配合Cache-Control: max-age31536000, immutable让命中缓存时完全不走网络资源更新时文件名变了也不会撞旧缓存。这是从根源上解决缓存失效问题的手段。HTML 文档本身设为no-cache每次回源校验保证用户拿到的 HTML 一定是最新的而 HTML 引用的带哈希的静态资源则可以放心长缓存。这里有个实战技巧把大体积图片的缓存时间设成max-age31536000, immutable因为图片是最典型的“一次访问、长期复用”资源旅行产品的图片内容几乎不会变长缓存对二次访问体验的提升非常明显。我自己实测第二三四天回到同一个详情页图片基本全是内存缓存或磁盘缓存命中网络请求数为 0。2.2 图片是详情页最大的流量黑洞商品详情页的图片是性能优化的“重灾区”。酒店实拍图、房型图、周边景点图一屏下来轻轻松松几十张单张动辄 200KB 以上。针对图片我做了几个层次的处理格式升级把大部分 JPEG 图片转成 WebP。WebP 在同等视觉质量下体积能小 25%~35%而且解码速度比 JPEG 更快尤其是压缩模式。带透明通道的 PNG 则全部走 WebP 的有损或无损模式收益更明显。AVIF 我也做过 A/B 测试在携程的图片域上 AVIF 比 WebP 还能再小 30%但部分低端安卓机的解码兼容性还有问题所以我把它做成“降级渐进”方案给支持 AVIF 的浏览器优先下发 AVIF不支持的自动回退 WebP 或 JPEG。响应式图片用srcsetsizes让移动端只下载适合自己屏幕宽度的图片。这是一个非常值得做的事情——之前移动端用户单张主图要下载 3000px 宽、几百 KB 的大图现在只下载 750px 宽的图直接省掉了近 70% 的流量。懒加载首屏固定加载、首屏外的图片一律loadinglazy。这里有个坑loadinglazy是浏览器原生的懒加载但它不会自动“取消”已经开始的请求所以最好配合 IntersectionObserver 自己做阈值控制。我在项目里用的是自定义懒加载指令进入视口前 300px 才开始加载既保证了不白请求又不会让图片“到了眼前才加载”。有个细节值得说明图片的decodingasync属性一定要加上。它告诉浏览器“这张图片的解码不要阻塞主线程”尤其是首屏主图加了这个属性后 TBT 能明显降下来。fetchpriorityhigh则给首屏主图一个抢占网络资源的优先权配合preload让它在 HTML 解析阶段就开始下载。2.3 传输层的小花招Brotli、HTTP/2、连接预热很多性能优化文章的教材都集中在“压缩什么”但很少讲“怎么把压缩后的文件更快地传过去”。我这次补上了传输层的优化。压缩算法升级把静态资源和 API 响应的通用 gzip 换成 Brotli。Brotli 的压缩率在文本类资源上比 gzip 高 10%~20%而且解压速度接近。对于 H5 页面这种大量 JS/CSS/HTML 文本的场景收益非常可观。HTTP/2 确认确认图片来源和静态资源 CDN 都开了 HTTP/2用多路复用减少连接数。这里我要提醒一句如果你的资源还是 HTTP/1.1做域名分片反而可能降低性能不要照搬旧时代的优化手段。关键连接预热在 HTMLhead里加上dns-prefetch、preconnect对图片 CDN 域名和 API 域名提前建立连接。这个操作代码量极小但对首屏的收益是实实在在的——节省了一次 DNS 查询和完整 TCPTLS 握手时间。我实测在移动端弱网环境下光这一个改动就让 TTFB 降低了 100~200ms。提示preconnect和dns-prefetch不要滥用。每个域名的预连接都会占用设备资源移动端尤其明显。我通常只对“首屏一定访问”的 2~3 个域名做preconnect其余域名用dns-prefetch即可。3. 首屏渲染链路让用户在 1 秒内看到“房型图”“快”是有两层含义的加载快和渲染快。多数团队的优化注意力都集中在“加载快”即网络耗时却忽略了“渲染快”——也就是 HTML 和 JS 拿到手之后要花多久才能把界面画出来。商品详情页这类信息密集页面首屏渲染链路的长短直接决定用户能不能在“耐心窗口”内看到核心内容。3.1 从接口串行到并行请求我接手时发现一个问题详情页首屏要展示的信息非常多但这些信息来自多个接口代码里的逻辑是“先请求商品基础信息拿到图片列表后再请求图片细节”天然串行。加上接口本身要经过网关转发每个接口的耗时叠加首屏可用数据到达的时间被拉得很长。优化的思路是“并行”。我把首屏所需的接口分成两组关键路径接口商品基础信息、主图列表、价格日历。这三个没有互相依赖直接Promise.all并行请求。非关键路径接口用户评价摘要、周边推荐、商家资质等。这些内容不阻塞首屏我用requestIdleCallback或滚动到对应位置时才触发请求。改完并行的当天我用 Performance 面板测试首屏接口的完成时间从 1.8s 降到了 0.9s直接减半。这里还有一个额外收益并行接口让“触达首屏数据”的时间点提前了配合下面的骨架屏方案用户能更快看到页面框架体感上“打开速度快了很多”。3.2 骨架屏和占位先给用户一个“容器”商品详情页最怕的不是“加载慢”而是“加载中白屏”。白屏给用户的心理暗示是“页面挂了”而骨架屏给的心理暗示是“正在为你展开内容马上就好”。我的实现方式是在 HTML 里直接内联首屏骨架屏的 CSS 和 DOM 结构确保脚本加载期间就有一幅“灰色线条版详情页”展示出来。等接口返回后用真实内容替换骨架结构。这里要点是骨架屏必须纯 CSS 实现不依赖任何 JS 库。用渐变色模拟“呼吸”动画成本极低但对视觉体验的提升很明显。关键图片区域要留好宽高比占位避免内容渲染后发生布局偏移CLS。比如主图区域固定 4:3 比例价格区域固定高度推荐区域固定卡片高度。宁可空白也不要“加载完跳一下”。我做过实验同样 2 秒的加载时间有骨架屏的版本和无骨架屏的版本用户感知等待时间差了接近一倍。骨架屏不只是“视觉点缀”它实实在在降低了用户的焦虑感。3.3 关键路径上的脚本裁剪与资源优先级首屏渲染链路中影响最大、也最容易被忽视的是 JavaScript。移动端 CPU 性能远弱于桌面端一段 200KB 的 JS在低端安卓机上解析执行可能耗时 500ms 以上。详情页历史包袱重第三方脚本、埋点 SDK、地图组件、图表库全部堆在入口文件里导致用户要下载并执行一大包和首屏无关的代码。我做了三件事代码分割把首屏不需要的代码全部拆成异步 chunk。地图组件、图表库、用户评价模块、分享组件全部走import()动态加载。首屏的 JS 总大小从 800KB 降到 180KBFCP 和 LCP 都有了显著改善。预加载关键资源对首屏主图和最重要的 JS 文件用link relpreload提前指定优先级。不用的脚本则用async或defer防止阻塞解析。删除埋点阻塞第三方统计 SDK 的加载从同步改为异步并且用domReady之后才注入。这一步直接消掉了首屏里约 200ms 的长任务阻塞。注意代码分割一定要配合路由级的懒加载和对首屏内容的精确判断。分割太细会导致请求数爆炸HTTP/2 下虽然连接复用但每个 chunk 都有请求开销分割太粗又起不到效果。我通常把颗粒度控制在“页面模块”这一层而不是“函数”一层。4. 运行时交互优化详情页不能只“打开快”首屏性能达标后用户还会有一种抱怨“页面打开是挺快但往后滑的时候一顿一顿的。”这种体验问题靠网络层优化解决不了需要从运行时渲染和交互响应的角度去处理。详情页的特殊性在于信息极其密集楼层很多而且每层都是图片、列表、卡片混排。移动端的滚动场景非常考验前端对 DOM 数量和布局计算的控制力。4.1 长列表与图片懒加载详情页的“用户评价”和“周边推荐”模块数据量可能很大。早期实现是直接渲染全部 list 项一个模块 200 个 DOM 节点四个模块就是 800 个节点。当用户滚动经过时浏览器同时管理这么多节点的布局、样式计算、绘制帧率自然上不去表现为滚动“卡卡”的。优化方案是虚拟滚动。我用vue/vue-virtual-scrollerVue 技术栈或者react-virtualizedReact 技术栈把可视区外的节点“虚拟化”——不在视口内的列表项不渲染滚动时动态回收和创建。这样用户看到的始终只有视口内的十几个节点DOM 总数从 800 降到 50 以内滚动帧率稳定在 60fps。这个方案的实现有几个注意点列表项高度必须固定或能精确估算否则滚动到一半会跳来跳去。评价内容的文本高度不同我统一做成了两行截断高度可控。虚拟滚动区域需要设置固定高度外层容器用overflow-y: scroll内层用绝对定位模拟完整列表高度否则滚动条长度和内容不匹配用户摸不到底。图片懒加载要与虚拟滚动协同虚拟列表自身会销毁不可见节点所以图片懒加载只需要关注“刚进入可视区”的那一批用 IntersectionObserver 监听容器内部的图片即可不要在全局监听。4.2 高频交互的防抖与帧率控制详情页的高频交互主要集中在几个点价格日历的日期切换、房型选择的切换、图片轮播的左右滑动、筛选条件的点击。这些交互在响应时如果有重计算或网络请求最容易产生卡顿和视觉断层。我做了两个层面的优化防抖 节流日历切换时日历数据的重计算和请求统一做 150ms 的防抖。用户在日期上快速连点只有停下来后才触发真正的数据请求。图片轮播的切换逻辑做节流保证频率不超过 60ms 一次避免快速滑动产生多个叠加的动画请求。requestAnimationFrame同步动画所有跟滚动联动的动画效果比如跟随滚动的价格悬浮球、图片懒加载的淡入效果都放在requestAnimationFrame里执行保证动画能对齐屏幕刷新率减少掉帧。这里分享一个踩过的坑防抖时间不要设太长。有同事把日历请求的防抖设成了 500ms结果用户快速翻日期时每次都要等半秒才出数据体感反而更卡。合适的防抖时间应该是“用户的交互频率 一次请求的时长”综合算出来的多测试几种值找到自然手感和响应速度的平衡点。4.3 缓存策略优化从内存到 localStorage 再到 Service Worker用户反复进入同一个商品详情页是一个很常见的场景——看了这个酒店回到列表又点进来对比。如果每次都全量请求体验和性能都很差。所以缓存策略是运行时优化里很重要的一环。我分了三层来做内存缓存同一 session 内进入详情页时先检查内存里有没有已请求过的数据。用简单的 Map 存 key商品 ID 日期范围到响应数据的引用。这个缓存清空机制很粗暴但有效——页面 unload 或 30 分钟没有访问就清掉避免内存泄漏。localStorage 缓存对于用户高频访问的近期商品把核心的静态数据商品基本信息、图片列表按“商品 ID 7 天有效期”存进 localStorage。再次进入时先渲染缓存数据再异步拉取最新数据做 diff 更新。这个策略让重复访问详情页的首屏时间比首次访问快了约 60%。Service Worker 缓存针对静态资源JS/CSS/图片我在项目里引入了 Service Worker 做预缓存和运行时缓存策略。对带哈希的 JS/CSS 走 Cache First对图片走 Stale While Revalidate对 API 接口暂时不做缓存——商品价格和库存数据太动态缓存容易造成误导。注意Service Worker 的引入成本不低调试和维护也有门槛。如果团队没有专门的 PWA 或离线需求我建议先只做 localStorage 层级的缓存收益/成本比更高。Service Worker 适合“有余力再上”的团队。5. 线上验证与持续监控优化完不算完性能优化是一个持续过程不是发一版代码就完事了。我相信很多人都有这种经历优化完本地测试很漂亮结果上线后用户反馈“还是慢啊”。原因就是线上线下环境不同真实用户的设备、网络速率、缓存状态、并发流量都和实验室环境有差异。5.1 用真实用户监控数据校准优化效果我在优化上线后的第二天拉取了一周的真实用户数据RUM做对比。核心看三个指标LCP 的 P75 值线上优化前后对比P75 从 4.2s 降到 2.3s。TBT 的 P75 值从 540ms 降到 170ms。首屏渲染完成率统计进入页面后 3 秒内完成首屏渲染的用户占比从 58% 提升到 81%。对比做出来我心里才真正有了底。这里有个关键认知实验室数据只能用来发现问题和快速迭代真实用户数据才是最终裁判。我建议每次优化迭代都至少观察 1~3 天数据不要因为一两次实验变好就急着下结论。尤其是移动端弱网用户占比较高的情况P75 和 P95 的改善比 P50 更值得关注。5.2 性能预算与 CI 卡的搭建为了避免“优化完又慢慢退化”我在项目的 CI 流水线里加了一个性能预算卡点每次构建时用 Lighthouse CI 跑一遍性能审计如果 LCP 超过 3.5s 或 JS bundle 总大小超过 220KB构建直接失败代码合不进去。性能预算分两层体积预算首屏 JS 总大小 ≤ 180KBgzip 后CSS 总量 ≤ 50KB单张首屏图片 ≤ 150KB。性能评分预算Lighthouse Performance 分数 ≥ 85LCP ≤ 2.5sCLS ≤ 0.1。这个机制刚开始同事会有抵触情绪觉得“优化卡得太死开发效率受影响”。运行两周后大家就习惯了反而变成了一个质量红线——新功能上线时发现预算超标会主动排查大依赖和冗余代码而不是等用户投诉后再回头补。5.3 回归测试别让优化变成“拆东墙补西墙”性能优化里最容易犯的一个错误是某项优化指标提升了但用户整体体验反而更差了。比如我把图片全部改成 WebP 后LCP 指标很好看但如果没有正确配置降级一部分老安卓机的用户直接在页面上看到破碎图片代码分割后首屏 JS 变小了但路由切换时出现白屏等待用户体验反而更差。我在每次优化上线前都会做一轮“回归测试”多个档位的模拟网速测试从 4G 到 2G以及无缓存首次访问场景。多设备真机测试iOS 和 Android 各选主流机型低端机至少两台。核心路径测试详情页的打开、滚动、日期选择、切换房型、加入收藏全流程走一遍。这套回归机制帮我挡住了两次事故。一次是 WebP 兼容性导致的图片裂图问题另一次是 Service Worker 缓存导致页面更新不及时的问题。优化要追求“全局最优”而不是“单一指标最优”这是每个性能优化工程师都要记住的。6. 踩坑记录与写给后来者的建议每一轮优化做完我都会整理一份踩坑笔记。这次商品详情页的性能优化有几个坑是真金白银趟过来的写出来供后面接手的人参考。6.1 我在这轮优化中踩过的 5 个坑坑一盲目全量压缩图片导致画质下降。旅行类产品的图片对画质要求很高一味的压缩率会带来肉眼可见的细节损失。我在压缩率上做过对比WebP 的 quality 参数设置在 72~78 之间时肉眼几乎无差异但体积比 quality85 节省了约 30%。这个参数要基于产品场景反复试。坑二loadinglazy和 IntersectionObserver 同时用效果互相抵消。浏览器原生 lazy 和自定义的懒加载指令冲突导致图片在预期外的时间点开始加载。最后我只保留了自定义 IntersectionObserver 方案把原生 lazy 全部去掉行为完全可控。坑三骨架屏和真实内容的 DOM 结构不一致导致替换时白屏闪烁。骨架屏是“灰色卡片”风格真实内容是“图文卡片”宽高不一致。后来我把骨架屏的 DOM 结构完全对齐真实模块只是内容用占位色遮罩替换时就不会闪了。坑四Service Worker 预缓存了带哈希的 JS但是剥离了更新逻辑。用户拿到的页面永远是最新的 HTML但脚本却是旧的缓存版本功能和样式出现错乱。后来我把更新策略改成 Stale While Revalidate并加了版本号管理问题才解决。坑五接口并行请求之后没有做异常处理。某个接口偶尔超时整个Promise.all直接 reject导致首屏全部挂掉骨架屏一直转圈。后面把关键接口改成Promise.allSettled并给每个接口设置了独立的超时和降级策略才彻底稳下来。6.2 一些可以直接抄的配置片段如果你也要做详情页的优化这几个配置可以直接按需抄走。通用head连接优化link relpreconnect hrefhttps://img.example.com crossorigin / link relpreconnect hrefhttps://api.example.com / link reldns-prefetch hrefhttps://img.example.com /关键图片预加载 异步解码img srchttps://img.example.com/hotel/main-750w.webp srcset https://img.example.com/hotel/main-375w.webp 375w, https://img.example.com/hotel/main-750w.webp 750w, https://img.example.com/hotel/main-1200w.webp 1200w sizes(max-width: 750px) 100vw, 50vw width750 height563 alt酒店主图 fetchpriorityhigh decodingasync /接口并行 降级处理const [hotelInfo, gallery, price] await Promise.allSettled([ fetch(/api/hotel/${id}/info), fetch(/api/hotel/${id}/gallery), fetch(/api/hotel/${id}/price), ]); // 每个接口单独判断状态失败时用默认数据兜底6.3 后续可以继续做的优化这轮优化做完后核心指标已经达标但我心里清楚还有几件事可以做只是受限于优先级和资源留到了后续迭代接口数据聚合层优化后端做 BFF 聚合把首屏的 5 个接口合并成 1 个减少移动端弱网下的请求往返次数。这个优化能把首屏接口耗时再压掉 40% 左右。WebP 全量替换后的 AVIF 渐进升级把 AVIF 作为 WebP 的下一代替代方案在兼容性允许的流量里逐步放量预计还能省掉约 30% 的图片体积。关键路径的 SSR 化目前首屏是 CSR 渲染虽然骨架屏缓解了白屏但 HTML 里没有内容SEO 和社交分享的卡片信息还是不完整。后续考虑对详情页做轻量 SSR 或预渲染让首屏 HTML 自带核心内容字段。这个方向如果做好了详情页的性能还有 20%~30% 的优化空间。优化没有终点但每一步都要用数据和用户体感来验证而不是靠感觉做事。