接手网易考拉商品详情页前端性能优化的时候我手机里存着一条用户反馈截图“商品图半天出不来一直在转圈。”这几乎是电商详情页最常见的抱怨但解决起来远比想象复杂。详情页是所有前端业务里信息密度最高、资源加载最重、链路最长的页面之一主图轮播、SKU切换、详情长图、评价列表、相似推荐再加上海外商品特有的物流、税费、保税仓信息模块内容量几乎相当于一个小型门户。这篇博客把我处理这次性能优化的完整过程写下来包括最开始的指标埋点、CDN与图片服务优化、渲染链路重构、长列表虚拟滚动以及线上监控闭环搭建。无论你是电商前端开发、做H5的内容团队还是准备面试被问到“详情页性能优化怎么搞”的人都能从里面拿到可以直接落地的思路和代码。1. 问题定位先从用户吐槽开始三类反馈背后的技术翻译1.1 把“打开慢”“卡”“图不出”翻译成可量化指标用户反馈通常是情绪化的做性能优化的人如果只盯着情绪化的描述很容易被带偏。真实情况是用户说“打开慢”的时候背后可能是三个完全不同的技术问题网络传输慢、JS阻塞渲染、接口串行等待。所以我做的第一件事是把所有零散反馈归类和具体的技术阶段对应起来。用户反馈对应的技术阶段常见根因打开慢、白屏久网络与首屏渲染资源体积大、脚本阻塞渲染、接口串行等待滚动卡顿、点击延迟渲染与主线程长列表DOM过多、布局抖动、事件监听阻塞图片不显示或加载慢网络与图片服务原图地址过大、CDN节点质量差、未按需压缩裁剪做完分类后方向就清楚了网络层要压字节数、渲染层要拆阻塞、交互层要降DOM和主线程负载。但那时候我手上只有用户反馈没有数据支撑所以下一步是搭一套最小可用的性能埋点。1.2 用PerformanceObserver搭一套最小可用性能采集在优化之前我们线上没有任何性能数据问题全靠肉眼和用户投诉。现代的浏览器已经提供了PerformanceObserver接口我直接用它来采集LCP、FID和CLS这几个核心指标不需要引入额外的监控SDK。const metrics {}; function sendBeacon(payload) { if (navigator.sendBeacon) { navigator.sendBeacon(/api/performance-log, JSON.stringify(payload)); } else { fetch(/api/performance-log, { method: POST, body: JSON.stringify(payload), keepalive: true }); } } // LCP最大内容绘制详情页通常就是商品主图 try { const lcpObserver new PerformanceObserver((list) { const entries list.getEntries(); const latestEntry entries[entries.length - 1]; metrics.lcp latestEntry.startTime; sendBeacon(metrics); }); lcpObserver.observe({ type: largest-contentful-paint, buffered: true }); } catch (e) {} // FID首次输入延迟 try { const fidObserver new PerformanceObserver((list) { list.getEntries().forEach((entry) { metrics.fid entry.processingStart - entry.startTime; sendBeacon(metrics); }); }); fidObserver.observe({ type: first-input, buffered: true }); } catch (e) {}这段代码可以直接塞进页面头部外链脚本里。需要注意两个细节一是sendBeacon必须在页面还活着的时候调用不能在beforeunload里用同步fetch否则大概率丢数据。二是上报不要太大太频繁我把多条指标合并成一个对象在LCP触发后再整体上报避免每次交互都打一条日志。如果你们的流量比较大还要加采样率比如只上报10%的UV否则后端日志会非常恐怖。1.3 优化前的基线数据决定了顺序埋点上线跑了一周我拿到的数据大概是这样Android中低端机平均白屏时间1.8秒iPhone平均首屏时间4.2秒弱网下整页图片总字节数平均2.8MB图片占整页资源比重超过70%。这些数字基本验证了我的判断——考拉这种跨境电商详情页最大的性能杀手就是图片数量和体积其次是脚本阻塞渲染和长列表DOM。根据数据我制定了优化顺序先压网络层图片裁剪、压缩、CDN上WebP、缓存策略调整。这是见效最快、ROI最高的一步。再拆渲染层骨架屏、首屏直出、懒加载边界控制。最后抠交互层长列表虚拟滚动、请求空闲调度。这个顺序很重要。我见过不少团队一上来就折腾虚拟滚动和框架优化结果图片没压一个详情页4MB流量再怎么做渲染优化都拦不住白屏。先把最大的水管放水再去修水龙头的缝隙才是性价比最高的做法。2. 网络侧提速图片服务裁剪、缓存策略与CDN边缘节点2.1 为什么图片是考拉商品详情页的流量大头跨境电商详情页的图片多到什么程度一个典型商品会有主图轮播5-8张、颜色/尺码SKU切换图每项1张、卖点细节图、尺码对照表、海关申报信息图、海外用户实拍评价图以及底部一张超长的详情页长图。这些图加起来一个页面上二三十张图片是很正常的而且很多是海外商家直接上传的原图没有任何处理直接走CDN下发。更麻烦的是SKU切换时前端经常用JS替换img.src每次替换又是一次完整的图片请求。如果原图是3000x3000分辨率、2MB大小用户每换一个颜色就要下载2MB体验自然灾难。所以图片优化的核心只有一件事让CDN在边缘节点就按需产出合适尺寸、合适格式、合适质量的图片而不是让用户直接下载原图。2.2 图片服务参数化裁剪一张原图多种尺寸我接手时发现业务代码里直接写死了图片地址有些还带了模糊参数风格完全不统一。正确做法是统一走图片服务通过URL参数在CDN边缘节点实时裁剪。以我们用的图片处理服务为例主流的OssImage、ImgProxy等也都支持类似机制// 改造前直接使用原图地址 const url https://img.example.com/goods/12345.jpg; // 改造后统一走图片处理参数 const imgUrl buildImg(https://img.example.com/goods/12345.jpg, { width: 750, // 详情页宽度 2倍屏750px足够 quality: 80, // JPEG/WebP质量电商场景80左右清晰度损失极小 format: webp // 支持WebP时使用否则自动回退 }); function buildImg(src, { width, quality, format }) { // 具体参数格式以图片服务为准 return ${src}?imageView2/2/w/${width}/q/${quality}/format/${format}; }关键参数我说明一下w750针对移动端详情页750px基本覆盖了2倍屏宽度。图片宽度超过屏幕物理像素再加DPR是浪费流量。如果你要做高清屏适配可以按window.devicePixelRatio动态计算但通常750-800px足够。q80JPEG质量压缩到80%肉眼几乎看不出差异体积能砍掉40%左右。低于70就要小心了商品图的文字会发虚。formatwebpWebP在同等质量下比JPEG小30%左右。但要注意兼容性iOS 14以下的旧手机对WebP支持有限所以必须做降级处理常见的做法是CDN根据请求头里的Accept字段自动选择WebP或者JPEG而不是在前端硬拼格式。底部的详情长图单独处理。这类图宽度通常固定高度可能几千像素用户是边滚动边看的。我把它切成多个瓦片每个瓦片仍然走CDN参数裁剪配合后端的懒加载用户滚到哪个位置才加载哪一块。前端的懒加载技术后面详说这里先记住一个结论长图不能整张一次性加载必须切片。2.3 缓存策略强缓存、协商缓存和版本号强制刷新压完体积之后就是缓存。详情页的JS、CSS、图片都是静态资源改动频率低应该尽量用强缓存。我用hash指纹命名静态文件配合Cache-Control: max-age31536000, immutable这样一年内同名文件不会再请求。HTML入口文件则设置no-cache保证每次访问都能确认版本。// Express中间件示例思路可以迁移到Nginx app.use((req, res, next) { if (/\.(js|css|png|jpg|jpeg|webp|woff2?)/.test(req.url)) { res.setHeader(Cache-Control, public, max-age31536000, immutable); } else if (req.path /index.html) { res.setHeader(Cache-Control, no-cache); } next(); });这里会遇到一个经典问题如果HTML被缓存用户永远拿不到新版本如果HTML不缓存每次访问都要回源校验。我们的方案是HTML走ETag协商缓存内容变了就200没变就304成本很低。页面发布时前端构建工具会给每个静态文件重新计算hash文件名index.html里引用的URL就会变化用户自然拉取新资源这就是很多团队说的“通过版本号的变更让前端强制刷新页面”的原理。注意不要用时间戳做文件名那样会导致CDN命中率急剧下降每发一次版所有用户都要重新下载全部资源。2.4 CDN节点质量的排查经验图片体积压下来后有个别用户反馈依然慢我查日志发现这些用户集中在偏远地区CDN节点覆盖不到位回源链路很长。这里分享一个排查技巧用浏览器开发者工具的Network面板看resource耗时如果TTFB很高多半是DNS解析或节点选择问题如果content download时间很长才是图片本身太大。观察到个别地域明显偏慢后我们做了一轮CDN服务商切换和节点预热把核心商品图在上线前主动预热到全国节点效果立竿见影。3. 渲染侧提速骨架屏、懒加载边界与首屏数据直出3.1 骨架屏不只是好看它直接改善白屏感知网络层优化做完页面资源从2.8MB降到1.6MB左右但白屏期间用户仍然什么都看不到体验上还是“死等”。我们决定上骨架屏。骨架屏在电商详情页尤其有效因为用户进来最关心的就是“商品在不在”“长什么样”一个灰色的图片占位和文字条能让用户觉得页面正在加载而不是网络断了。实现时有两个方案一是写纯CSS的渐变背景模拟色块在首屏HTML里直接输出骨架屏DOM二是用Vue/React组件在数据未返回前渲染占位状态。我们在首屏用了第一种因为HTML直出后再由JS接管可以避免白屏期渲染进程的空转。骨架屏的配色要注意饱和度别太高灰色调的渐变最不容易和真实商品图产生“页面坏了”的错觉。真实内容加载完成后我会加一个opacity的淡入过渡让骨架屏平滑过渡为真实图片避免突兀跳动。.skeleton { background: linear-gradient(90deg, #f0f0f0 25%, #e8e8e8 37%, #f0f0f0 63%); background-size: 400% 100%; animation: skeleton-loading 1.4s ease infinite; } keyframes skeleton-loading { 0% { background-position: 100% 50%; } 100% { background-position: 0 50%; } }3.2 懒加载的真正边界不是所有图片都该懒懒加载被很多人套成模板正文里所有img都加loadinglazy结果首屏主图也被延迟加载反而让FCP变慢这就是没有边界意识。详情页的懒加载策略应该是首屏范围内的图片预加载首屏外的图片懒加载。首屏主图是用户最先看到的内容必须立即加载我甚至用link relpreload asimage把它提前到CSS和JS之前发起请求link relpreload asimage hrefhttps://img.example.com/goods/12345.jpg?imageView2/2/w/750/q/80/format/webp首屏以外的图片用IntersectionObserver做懒加载设置rootMargin: 200px 0px提前200px开始加载用户滚动到之前就已经准备好了感知不到加载过程。const lazyImages document.querySelectorAll(img[data-src]); const imageObserver new IntersectionObserver((entries) { entries.forEach((entry) { if (entry.isIntersecting) { const img entry.target; if (img.dataset.src) { img.src img.dataset.src; img.removeAttribute(data-src); } imageObserver.unobserve(img); } }); }, { rootMargin: 200px 0px, threshold: 0.1 }); lazyImages.forEach((img) imageObserver.observe(img));注意几个坑懒加载的图片初始src不能是空字符串否则浏览器会自动请求当前页面地址>script typeapplication/json iddetail-data {goods: {...}, sku: {...}, stock: {...}} /script前端首屏渲染时先从#detail-data取数不再发接口请求这样首屏时间就不再被网络RTT左右。但直出方案要特别注意数据实时性库存、价格这种强时效数据不能直出太早否则用户看到的价格和下单页不一致会给业务带来客诉风险。我们的折中方案是商品名称、图片、SKU列表等静态信息直出库存和价格仍然异步刷新。4. 交互流畅度主线程降载、长评论列表虚拟滚动与任务调度4.1 滚动卡顿的根因不只是DOM多还有强制同步布局图片加载和首屏白屏解决后用户反馈里还剩一个长期的刺头评价列表滚到后面越来越卡。我打开调试工具一看详情页的评价列表一次性渲染了全部N条评价每个评价包含头像、用户名、评价图片、文字整个页面DOM节点数轻松超过3000个。再加上相似推荐模块又是一个图片瀑布流滚动时浏览器要不停地布局、绘制、合成中低端Android机直接掉到30帧以下。此外老代码里还有一个经典问题滚动或resize回调里频繁读写DOM的几何属性触发强制同步布局。比如在滚动事件里做这种操作// 这是典型的布局抖动会强制同步计算整个页面的布局 function onScroll() { const headerHeight header.offsetHeight; content.style.top headerHeight scrollTop px; imageWrapper.style.top image.offsetTop px; }优化思路是批量读取再统一写入或者直接用requestAnimationFrame把写入逻辑合并到同一帧。现代浏览器里还能用CSS containmentcontain: layout style paint把子组件的布局影响隔离减少范围扩散。4.2 固定高度虚拟列表与“评价区点击展开”的取舍对评价列表这种结构相对规整的列表虚拟滚动是正解。固定高度列表的虚拟滚动实现逻辑不复杂可视区高度除以每个item高度得到需要渲染的条数滚动时根据scrollTop算出起始索引只渲染可视区前后一小段。const itemHeight 160; // 每条评价平均高度可以动态计算 const viewportHeight 600; const totalItems comments.length; let startIndex 0; let endIndex Math.ceil(viewportHeight / itemHeight); function updateCommentList(scrollTop) { startIndex Math.max(0, Math.floor(scrollTop / itemHeight) - 2); endIndex Math.min( totalItems, startIndex Math.ceil(viewportHeight / itemHeight) 4 ); renderComments(startIndex, endIndex); } container.addEventListener(scroll, () { updateCommentList(container.scrollTop); }, { passive: true });我把代码简化成了核心骨架真实项目里还要处理滚动条比例计算、复用DOM节点、图片在虚拟列表里的懒加载配合、以及滚动到底部的触底加载。这里有一个重要经验虚拟列表对不定高度的内容很痛苦评价图片有的有、有的没有高度差异大。我在里面做了一个近似处理根据前两条评价的实际渲染高度估算平均高度滚动时再修正偏移误差。这个方案比完全定高的虚拟列表复杂一点但体验稳定得多。当然虚拟列表不是唯一选择。像评价这种“不完全要紧”的内容直接做“点击展开全部评价”的分页模式更简单代价是多一次用户交互。我的实际决策是前两条评价加载在首屏其余评价全部折叠起来点击“查看全部”再进入独立列表页。这么做既保证了首屏干净也彻底绕开了长列表的性能问题。如果你的产品不允许跳页面再上虚拟滚动否则不要为了炫技增加维护成本。4.3 用requestIdleCallback和Web Worker让主线程喘口气详情页还有一个隐蔽的性能杀手首屏加载时JS要在主线程做很多“看似必须”的操作比如数据分析上报、图片解码后的尺寸计算、埋点记录、各种第三方SDK初始化。这些任务和首屏渲染挤在同一帧导致用户看到页面了但无法滚动点击没反应。我的处理思路是把非关键任务放到浏览器空闲时段执行function scheduleTask(task) { if (requestIdleCallback in window) { requestIdleCallback(() task(), { timeout: 2000 }); } else { setTimeout(() task(), 1000); } }图片解码、压缩计算这类CPU密集任务我放到Web Worker里执行避免占用主线程const worker new Worker(/assets/img-process.js); worker.postMessage({ imageData: largeImageBlob }); worker.onmessage (e) { // 拿到处理后的数据再更新界面 };需要强调一点不是所有任务都适合丢到Worker。DOM操作用不了Worker直接把任务丢进去只会增加消息通信开销。我通常只把“需要大量计算但不需要DOM”的任务放进去比如图片的Blob转ArrayBuffer、评价文本的敏感词过滤、上报数据的聚合处理。这些任务放到Worker后主线程在Chrome DevTools Performance面板上的长任务从原来300ms以上降到100ms以下用户滚动卡顿的投诉明显减少。5. 线上监控与持续优化从一次性优化变成常态防线5.1 数据不能只看平均数要分场景分机型优化上线后我最担心的是“局部变好、整体退步”的假象。性能数据不能只看平均首屏时间必须按网络、机型、地域、页面模块拆分。同一个指标在iPhone 15和Android千元机上的体验天差地别。我搭的监控看板分为三个维度网络维度WiFi、4G、弱网网络慢速分别统计弱网看的是兜底能力。机型维度高、中、低三档机型分开重点盯低端机的LCP和FID。页面模块维度主图加载时间、评价模块加载时间、推荐模块加载时间互相独立。这样拆开后某个模块的回归能第一时间发现而不是整个页面平均数据勉强达标时蒙在鼓里。比如有一次监控发现低端机的评价模块LCP涨了500ms最终定位到是虚拟列表的估算高度在旧机型上偏差太大导致频繁滚动修正消耗了主线程。如果只看全局平均值这个问题很可能被首屏图片优化带来的收益掩盖。5.2 性能预算进CI让新功能的PR不敢随便加重量做过性能优化的人都知道最大的敌人不是遗留代码而是开发流程里不断新增的资源。这周加一个轮播插件下周加一个埋点SDK图片越传越大性能问题就是这样悄然回归的。我引入的是资源预算机制在CI阶段用构建产物做检查首屏JS体积预算不超过150KB gzip。单页面总资源预算整页gzip后不超过2MB。LCP预算通过线上RUM数据扮演如果连续一周的P75 LCP超过2.5s自动告警。CI脚本里可以用webpack的bundleAnalyzer输出大小报告再写一段简单的shell或Node脚本做阈值判断。预算一开始别定得太狠要给业务迭代留一点余量否则团队会为了指标天天改代码反而影响产品节奏。我的经验是先砍到现有规模的80%稳定后再说。5.3 灰度对比和回滚经验做性能优化也要有“止损开关”性能优化方案上线前我在内网灰度了5%的流量对比了新旧版本的真实用户数据。灰度对比的好处是能发现一些实验室测不出的问题——比如某个图片格式降级策略在真实的Android低端机混合内容下会出现部分图糊某个CDN缓存参数在特定ISP下出现304回源偏多。灰度期间没有大面积的用户投诉数据面也确认了首屏时间明显下降后我才逐步放量到100%。但这套流程里也踩过一个大坑新版本发布后由于我在HTML里设置了no-cache本该每次都回源校验结果部分旧版App WebView对ETag支持不完善缓存了旧页面。用户在很长一段时间里看到的还是优化前的页面导致线上RUM数据和灰度阶段完全对不上。最后解决方案是给页面URL额外拼一个发布版本号参数?v20250401服务端发布时自动递增通过版本号变更强制前端刷新页面资源。这个机制虽然简单但我后来在多个项目里都在用它几乎是最可靠的兜底手段。优化完成后最想说的一件事这轮优化做完后我的体感是详情页性能优化不是一次性攻坚战而是一套必须长期运转的节奏。图片压得过分会收到“图不清晰”的投诉缓存策略开得太狠发版之后部分用户依然停留在旧页面懒加载范围控制不好还可能影响搜索引擎的收录。每个策略都是双刃剑真正决定成败的是一开始就把数据埋点、灰度对比和预算检查接进常态化机制而不是每次等线上出事故才去抢救。如果只让我留三条建议给后来者我会说先把指标埋点跑起来用数据定优化顺序再集中火力压最大的资源大头通常就是图片最后才去碰框架层和DOM层的细活。这个顺序能让你在最快时间内看到收益也比较容易让业务方感受到性能优化带来的实际价值。
接手网易考拉商品详情页前端性能优化的时候我手机里存着一条用户反馈截图“商品图半天出不来一直在转圈。”这几乎是电商详情页最常见的抱怨但解决起来远比想象复杂。详情页是所有前端业务里信息密度最高、资源加载最重、链路最长的页面之一主图轮播、SKU切换、详情长图、评价列表、相似推荐再加上海外商品特有的物流、税费、保税仓信息模块内容量几乎相当于一个小型门户。这篇博客把我处理这次性能优化的完整过程写下来包括最开始的指标埋点、CDN与图片服务优化、渲染链路重构、长列表虚拟滚动以及线上监控闭环搭建。无论你是电商前端开发、做H5的内容团队还是准备面试被问到“详情页性能优化怎么搞”的人都能从里面拿到可以直接落地的思路和代码。1. 问题定位先从用户吐槽开始三类反馈背后的技术翻译1.1 把“打开慢”“卡”“图不出”翻译成可量化指标用户反馈通常是情绪化的做性能优化的人如果只盯着情绪化的描述很容易被带偏。真实情况是用户说“打开慢”的时候背后可能是三个完全不同的技术问题网络传输慢、JS阻塞渲染、接口串行等待。所以我做的第一件事是把所有零散反馈归类和具体的技术阶段对应起来。用户反馈对应的技术阶段常见根因打开慢、白屏久网络与首屏渲染资源体积大、脚本阻塞渲染、接口串行等待滚动卡顿、点击延迟渲染与主线程长列表DOM过多、布局抖动、事件监听阻塞图片不显示或加载慢网络与图片服务原图地址过大、CDN节点质量差、未按需压缩裁剪做完分类后方向就清楚了网络层要压字节数、渲染层要拆阻塞、交互层要降DOM和主线程负载。但那时候我手上只有用户反馈没有数据支撑所以下一步是搭一套最小可用的性能埋点。1.2 用PerformanceObserver搭一套最小可用性能采集在优化之前我们线上没有任何性能数据问题全靠肉眼和用户投诉。现代的浏览器已经提供了PerformanceObserver接口我直接用它来采集LCP、FID和CLS这几个核心指标不需要引入额外的监控SDK。const metrics {}; function sendBeacon(payload) { if (navigator.sendBeacon) { navigator.sendBeacon(/api/performance-log, JSON.stringify(payload)); } else { fetch(/api/performance-log, { method: POST, body: JSON.stringify(payload), keepalive: true }); } } // LCP最大内容绘制详情页通常就是商品主图 try { const lcpObserver new PerformanceObserver((list) { const entries list.getEntries(); const latestEntry entries[entries.length - 1]; metrics.lcp latestEntry.startTime; sendBeacon(metrics); }); lcpObserver.observe({ type: largest-contentful-paint, buffered: true }); } catch (e) {} // FID首次输入延迟 try { const fidObserver new PerformanceObserver((list) { list.getEntries().forEach((entry) { metrics.fid entry.processingStart - entry.startTime; sendBeacon(metrics); }); }); fidObserver.observe({ type: first-input, buffered: true }); } catch (e) {}这段代码可以直接塞进页面头部外链脚本里。需要注意两个细节一是sendBeacon必须在页面还活着的时候调用不能在beforeunload里用同步fetch否则大概率丢数据。二是上报不要太大太频繁我把多条指标合并成一个对象在LCP触发后再整体上报避免每次交互都打一条日志。如果你们的流量比较大还要加采样率比如只上报10%的UV否则后端日志会非常恐怖。1.3 优化前的基线数据决定了顺序埋点上线跑了一周我拿到的数据大概是这样Android中低端机平均白屏时间1.8秒iPhone平均首屏时间4.2秒弱网下整页图片总字节数平均2.8MB图片占整页资源比重超过70%。这些数字基本验证了我的判断——考拉这种跨境电商详情页最大的性能杀手就是图片数量和体积其次是脚本阻塞渲染和长列表DOM。根据数据我制定了优化顺序先压网络层图片裁剪、压缩、CDN上WebP、缓存策略调整。这是见效最快、ROI最高的一步。再拆渲染层骨架屏、首屏直出、懒加载边界控制。最后抠交互层长列表虚拟滚动、请求空闲调度。这个顺序很重要。我见过不少团队一上来就折腾虚拟滚动和框架优化结果图片没压一个详情页4MB流量再怎么做渲染优化都拦不住白屏。先把最大的水管放水再去修水龙头的缝隙才是性价比最高的做法。2. 网络侧提速图片服务裁剪、缓存策略与CDN边缘节点2.1 为什么图片是考拉商品详情页的流量大头跨境电商详情页的图片多到什么程度一个典型商品会有主图轮播5-8张、颜色/尺码SKU切换图每项1张、卖点细节图、尺码对照表、海关申报信息图、海外用户实拍评价图以及底部一张超长的详情页长图。这些图加起来一个页面上二三十张图片是很正常的而且很多是海外商家直接上传的原图没有任何处理直接走CDN下发。更麻烦的是SKU切换时前端经常用JS替换img.src每次替换又是一次完整的图片请求。如果原图是3000x3000分辨率、2MB大小用户每换一个颜色就要下载2MB体验自然灾难。所以图片优化的核心只有一件事让CDN在边缘节点就按需产出合适尺寸、合适格式、合适质量的图片而不是让用户直接下载原图。2.2 图片服务参数化裁剪一张原图多种尺寸我接手时发现业务代码里直接写死了图片地址有些还带了模糊参数风格完全不统一。正确做法是统一走图片服务通过URL参数在CDN边缘节点实时裁剪。以我们用的图片处理服务为例主流的OssImage、ImgProxy等也都支持类似机制// 改造前直接使用原图地址 const url https://img.example.com/goods/12345.jpg; // 改造后统一走图片处理参数 const imgUrl buildImg(https://img.example.com/goods/12345.jpg, { width: 750, // 详情页宽度 2倍屏750px足够 quality: 80, // JPEG/WebP质量电商场景80左右清晰度损失极小 format: webp // 支持WebP时使用否则自动回退 }); function buildImg(src, { width, quality, format }) { // 具体参数格式以图片服务为准 return ${src}?imageView2/2/w/${width}/q/${quality}/format/${format}; }关键参数我说明一下w750针对移动端详情页750px基本覆盖了2倍屏宽度。图片宽度超过屏幕物理像素再加DPR是浪费流量。如果你要做高清屏适配可以按window.devicePixelRatio动态计算但通常750-800px足够。q80JPEG质量压缩到80%肉眼几乎看不出差异体积能砍掉40%左右。低于70就要小心了商品图的文字会发虚。formatwebpWebP在同等质量下比JPEG小30%左右。但要注意兼容性iOS 14以下的旧手机对WebP支持有限所以必须做降级处理常见的做法是CDN根据请求头里的Accept字段自动选择WebP或者JPEG而不是在前端硬拼格式。底部的详情长图单独处理。这类图宽度通常固定高度可能几千像素用户是边滚动边看的。我把它切成多个瓦片每个瓦片仍然走CDN参数裁剪配合后端的懒加载用户滚到哪个位置才加载哪一块。前端的懒加载技术后面详说这里先记住一个结论长图不能整张一次性加载必须切片。2.3 缓存策略强缓存、协商缓存和版本号强制刷新压完体积之后就是缓存。详情页的JS、CSS、图片都是静态资源改动频率低应该尽量用强缓存。我用hash指纹命名静态文件配合Cache-Control: max-age31536000, immutable这样一年内同名文件不会再请求。HTML入口文件则设置no-cache保证每次访问都能确认版本。// Express中间件示例思路可以迁移到Nginx app.use((req, res, next) { if (/\.(js|css|png|jpg|jpeg|webp|woff2?)/.test(req.url)) { res.setHeader(Cache-Control, public, max-age31536000, immutable); } else if (req.path /index.html) { res.setHeader(Cache-Control, no-cache); } next(); });这里会遇到一个经典问题如果HTML被缓存用户永远拿不到新版本如果HTML不缓存每次访问都要回源校验。我们的方案是HTML走ETag协商缓存内容变了就200没变就304成本很低。页面发布时前端构建工具会给每个静态文件重新计算hash文件名index.html里引用的URL就会变化用户自然拉取新资源这就是很多团队说的“通过版本号的变更让前端强制刷新页面”的原理。注意不要用时间戳做文件名那样会导致CDN命中率急剧下降每发一次版所有用户都要重新下载全部资源。2.4 CDN节点质量的排查经验图片体积压下来后有个别用户反馈依然慢我查日志发现这些用户集中在偏远地区CDN节点覆盖不到位回源链路很长。这里分享一个排查技巧用浏览器开发者工具的Network面板看resource耗时如果TTFB很高多半是DNS解析或节点选择问题如果content download时间很长才是图片本身太大。观察到个别地域明显偏慢后我们做了一轮CDN服务商切换和节点预热把核心商品图在上线前主动预热到全国节点效果立竿见影。3. 渲染侧提速骨架屏、懒加载边界与首屏数据直出3.1 骨架屏不只是好看它直接改善白屏感知网络层优化做完页面资源从2.8MB降到1.6MB左右但白屏期间用户仍然什么都看不到体验上还是“死等”。我们决定上骨架屏。骨架屏在电商详情页尤其有效因为用户进来最关心的就是“商品在不在”“长什么样”一个灰色的图片占位和文字条能让用户觉得页面正在加载而不是网络断了。实现时有两个方案一是写纯CSS的渐变背景模拟色块在首屏HTML里直接输出骨架屏DOM二是用Vue/React组件在数据未返回前渲染占位状态。我们在首屏用了第一种因为HTML直出后再由JS接管可以避免白屏期渲染进程的空转。骨架屏的配色要注意饱和度别太高灰色调的渐变最不容易和真实商品图产生“页面坏了”的错觉。真实内容加载完成后我会加一个opacity的淡入过渡让骨架屏平滑过渡为真实图片避免突兀跳动。.skeleton { background: linear-gradient(90deg, #f0f0f0 25%, #e8e8e8 37%, #f0f0f0 63%); background-size: 400% 100%; animation: skeleton-loading 1.4s ease infinite; } keyframes skeleton-loading { 0% { background-position: 100% 50%; } 100% { background-position: 0 50%; } }3.2 懒加载的真正边界不是所有图片都该懒懒加载被很多人套成模板正文里所有img都加loadinglazy结果首屏主图也被延迟加载反而让FCP变慢这就是没有边界意识。详情页的懒加载策略应该是首屏范围内的图片预加载首屏外的图片懒加载。首屏主图是用户最先看到的内容必须立即加载我甚至用link relpreload asimage把它提前到CSS和JS之前发起请求link relpreload asimage hrefhttps://img.example.com/goods/12345.jpg?imageView2/2/w/750/q/80/format/webp首屏以外的图片用IntersectionObserver做懒加载设置rootMargin: 200px 0px提前200px开始加载用户滚动到之前就已经准备好了感知不到加载过程。const lazyImages document.querySelectorAll(img[data-src]); const imageObserver new IntersectionObserver((entries) { entries.forEach((entry) { if (entry.isIntersecting) { const img entry.target; if (img.dataset.src) { img.src img.dataset.src; img.removeAttribute(data-src); } imageObserver.unobserve(img); } }); }, { rootMargin: 200px 0px, threshold: 0.1 }); lazyImages.forEach((img) imageObserver.observe(img));注意几个坑懒加载的图片初始src不能是空字符串否则浏览器会自动请求当前页面地址>script typeapplication/json iddetail-data {goods: {...}, sku: {...}, stock: {...}} /script前端首屏渲染时先从#detail-data取数不再发接口请求这样首屏时间就不再被网络RTT左右。但直出方案要特别注意数据实时性库存、价格这种强时效数据不能直出太早否则用户看到的价格和下单页不一致会给业务带来客诉风险。我们的折中方案是商品名称、图片、SKU列表等静态信息直出库存和价格仍然异步刷新。4. 交互流畅度主线程降载、长评论列表虚拟滚动与任务调度4.1 滚动卡顿的根因不只是DOM多还有强制同步布局图片加载和首屏白屏解决后用户反馈里还剩一个长期的刺头评价列表滚到后面越来越卡。我打开调试工具一看详情页的评价列表一次性渲染了全部N条评价每个评价包含头像、用户名、评价图片、文字整个页面DOM节点数轻松超过3000个。再加上相似推荐模块又是一个图片瀑布流滚动时浏览器要不停地布局、绘制、合成中低端Android机直接掉到30帧以下。此外老代码里还有一个经典问题滚动或resize回调里频繁读写DOM的几何属性触发强制同步布局。比如在滚动事件里做这种操作// 这是典型的布局抖动会强制同步计算整个页面的布局 function onScroll() { const headerHeight header.offsetHeight; content.style.top headerHeight scrollTop px; imageWrapper.style.top image.offsetTop px; }优化思路是批量读取再统一写入或者直接用requestAnimationFrame把写入逻辑合并到同一帧。现代浏览器里还能用CSS containmentcontain: layout style paint把子组件的布局影响隔离减少范围扩散。4.2 固定高度虚拟列表与“评价区点击展开”的取舍对评价列表这种结构相对规整的列表虚拟滚动是正解。固定高度列表的虚拟滚动实现逻辑不复杂可视区高度除以每个item高度得到需要渲染的条数滚动时根据scrollTop算出起始索引只渲染可视区前后一小段。const itemHeight 160; // 每条评价平均高度可以动态计算 const viewportHeight 600; const totalItems comments.length; let startIndex 0; let endIndex Math.ceil(viewportHeight / itemHeight); function updateCommentList(scrollTop) { startIndex Math.max(0, Math.floor(scrollTop / itemHeight) - 2); endIndex Math.min( totalItems, startIndex Math.ceil(viewportHeight / itemHeight) 4 ); renderComments(startIndex, endIndex); } container.addEventListener(scroll, () { updateCommentList(container.scrollTop); }, { passive: true });我把代码简化成了核心骨架真实项目里还要处理滚动条比例计算、复用DOM节点、图片在虚拟列表里的懒加载配合、以及滚动到底部的触底加载。这里有一个重要经验虚拟列表对不定高度的内容很痛苦评价图片有的有、有的没有高度差异大。我在里面做了一个近似处理根据前两条评价的实际渲染高度估算平均高度滚动时再修正偏移误差。这个方案比完全定高的虚拟列表复杂一点但体验稳定得多。当然虚拟列表不是唯一选择。像评价这种“不完全要紧”的内容直接做“点击展开全部评价”的分页模式更简单代价是多一次用户交互。我的实际决策是前两条评价加载在首屏其余评价全部折叠起来点击“查看全部”再进入独立列表页。这么做既保证了首屏干净也彻底绕开了长列表的性能问题。如果你的产品不允许跳页面再上虚拟滚动否则不要为了炫技增加维护成本。4.3 用requestIdleCallback和Web Worker让主线程喘口气详情页还有一个隐蔽的性能杀手首屏加载时JS要在主线程做很多“看似必须”的操作比如数据分析上报、图片解码后的尺寸计算、埋点记录、各种第三方SDK初始化。这些任务和首屏渲染挤在同一帧导致用户看到页面了但无法滚动点击没反应。我的处理思路是把非关键任务放到浏览器空闲时段执行function scheduleTask(task) { if (requestIdleCallback in window) { requestIdleCallback(() task(), { timeout: 2000 }); } else { setTimeout(() task(), 1000); } }图片解码、压缩计算这类CPU密集任务我放到Web Worker里执行避免占用主线程const worker new Worker(/assets/img-process.js); worker.postMessage({ imageData: largeImageBlob }); worker.onmessage (e) { // 拿到处理后的数据再更新界面 };需要强调一点不是所有任务都适合丢到Worker。DOM操作用不了Worker直接把任务丢进去只会增加消息通信开销。我通常只把“需要大量计算但不需要DOM”的任务放进去比如图片的Blob转ArrayBuffer、评价文本的敏感词过滤、上报数据的聚合处理。这些任务放到Worker后主线程在Chrome DevTools Performance面板上的长任务从原来300ms以上降到100ms以下用户滚动卡顿的投诉明显减少。5. 线上监控与持续优化从一次性优化变成常态防线5.1 数据不能只看平均数要分场景分机型优化上线后我最担心的是“局部变好、整体退步”的假象。性能数据不能只看平均首屏时间必须按网络、机型、地域、页面模块拆分。同一个指标在iPhone 15和Android千元机上的体验天差地别。我搭的监控看板分为三个维度网络维度WiFi、4G、弱网网络慢速分别统计弱网看的是兜底能力。机型维度高、中、低三档机型分开重点盯低端机的LCP和FID。页面模块维度主图加载时间、评价模块加载时间、推荐模块加载时间互相独立。这样拆开后某个模块的回归能第一时间发现而不是整个页面平均数据勉强达标时蒙在鼓里。比如有一次监控发现低端机的评价模块LCP涨了500ms最终定位到是虚拟列表的估算高度在旧机型上偏差太大导致频繁滚动修正消耗了主线程。如果只看全局平均值这个问题很可能被首屏图片优化带来的收益掩盖。5.2 性能预算进CI让新功能的PR不敢随便加重量做过性能优化的人都知道最大的敌人不是遗留代码而是开发流程里不断新增的资源。这周加一个轮播插件下周加一个埋点SDK图片越传越大性能问题就是这样悄然回归的。我引入的是资源预算机制在CI阶段用构建产物做检查首屏JS体积预算不超过150KB gzip。单页面总资源预算整页gzip后不超过2MB。LCP预算通过线上RUM数据扮演如果连续一周的P75 LCP超过2.5s自动告警。CI脚本里可以用webpack的bundleAnalyzer输出大小报告再写一段简单的shell或Node脚本做阈值判断。预算一开始别定得太狠要给业务迭代留一点余量否则团队会为了指标天天改代码反而影响产品节奏。我的经验是先砍到现有规模的80%稳定后再说。5.3 灰度对比和回滚经验做性能优化也要有“止损开关”性能优化方案上线前我在内网灰度了5%的流量对比了新旧版本的真实用户数据。灰度对比的好处是能发现一些实验室测不出的问题——比如某个图片格式降级策略在真实的Android低端机混合内容下会出现部分图糊某个CDN缓存参数在特定ISP下出现304回源偏多。灰度期间没有大面积的用户投诉数据面也确认了首屏时间明显下降后我才逐步放量到100%。但这套流程里也踩过一个大坑新版本发布后由于我在HTML里设置了no-cache本该每次都回源校验结果部分旧版App WebView对ETag支持不完善缓存了旧页面。用户在很长一段时间里看到的还是优化前的页面导致线上RUM数据和灰度阶段完全对不上。最后解决方案是给页面URL额外拼一个发布版本号参数?v20250401服务端发布时自动递增通过版本号变更强制前端刷新页面资源。这个机制虽然简单但我后来在多个项目里都在用它几乎是最可靠的兜底手段。优化完成后最想说的一件事这轮优化做完后我的体感是详情页性能优化不是一次性攻坚战而是一套必须长期运转的节奏。图片压得过分会收到“图不清晰”的投诉缓存策略开得太狠发版之后部分用户依然停留在旧页面懒加载范围控制不好还可能影响搜索引擎的收录。每个策略都是双刃剑真正决定成败的是一开始就把数据埋点、灰度对比和预算检查接进常态化机制而不是每次等线上出事故才去抢救。如果只让我留三条建议给后来者我会说先把指标埋点跑起来用数据定优化顺序再集中火力压最大的资源大头通常就是图片最后才去碰框架层和DOM层的细活。这个顺序能让你在最快时间内看到收益也比较容易让业务方感受到性能优化带来的实际价值。
