企业官网建设流程全解析

前几天深夜复盘详情页改动数据时，我看到首屏时间从 2.8 秒掉到 1.1 秒，LCP 从 2.6 秒掉到 1.0 秒，截图发到群里，气氛一下子就不一样了。我们做的是一个服装行业的 B2B 交易平台，平时团队内部都把它叫衣联网，商品详情页是商家和采购商之间最重要的一道门。过去一个多月，我们集中做了一轮商品详情页前端性能优化，从首屏数据链路、商品图加载、SKU 交互到缓存与预取，能动的几乎都动了一遍。这篇文章把这轮改造的过程、取舍、踩坑和最终结果完整记录下来。如果你也在做电商详情页，尤其是服装类目这种大图多、SKU 多、交互重的页面，这里面的很多思路可以直接抄作业。

1. 先搞清楚：详情页慢的根源到底在哪

1.1 为什么服装类目的详情页尤其值得做

服装类目和普通标品详情页有一个很大的差异：图片决定购买体验。一件衣服通常有正面、背面、细节、模特上身、尺码对照等多张图，图片数量多、单张体积大，而且详情区域往往是一张很长的长图。在 B2B 场景下，采购商经常在手机上同时对比多款商品，加载慢一点，用户就会切回列表页继续翻，损失的可能是询单甚至下单。

当时我们看后台数据，移动端详情页的首屏渲染时间 p50 在 2.8 秒左右，p90 甚至超过 5 秒。再往下拆，跳出率在详情页已经高到不容忽视的程度。做性能优化之前，我们给自己定了一个原则：优化不是为了跑分，而是为了把用户打开详情页到完成核心动作的路径变短。商品详情页恰好是搜索列表之后的最后一道转化关卡，用户进来就是看货、选 SKU、问价、下单，这些动作全部依赖页面能不能快速稳定地响应。所以就算看起来"页面不算复杂"，它也完全值得专门做一轮完整优化。

1.2 指标口径：我们拿什么判断"变快了"

这次没有只盯一个指标，我们定了几个维度，分别对应不同阶段的用户体验：

• 首屏渲染相关：FCP 和 LCP。FCP 看页面主体框架出现的速度，LCP 看首屏最大元素，通常就是商品主图或者标题，什么时候真正绘制出来。
• 交互响应相关：TBT 和 INP。TBT 观察主线程长时间阻塞的情况，INP 直接看用户点击、选择 SKU 等操作的实际延迟。
• 布局稳定性：CLS。图片加载后如果不占位，文字会跳，用户点错是体验事故。
• 业务指标：跳出率、加购转化率、询单转化率。这些指标才能证明性能优化有没有真正变成业务收益。

有一个很重要的注意事项：实验室工具和线上监控的数据口径不一样。实验室工具模拟固定设备和固定网络，能对比两版代码之间的差异，但它不等于真实用户感受。真实用户分布在各种机型、各种网络环境里，所以我们用线上性能监控的 p50 / p75 / p90 来评估整体水位。两种数据分开看，不要混着放进同一个对比表格里，否则很容易被假象误导。

1.3 瓶颈排序与改造路线

我们先把详情页需要优化的点全部列出来，按"影响面"和"改动成本"排了优先级：

当时的判断是：先把"数据能不能更快到达页面"和"图片能不能更小"这两件事解决掉，再来处理交互层面的卡顿。因为加载性能是交互性能的前提，数据都没到，JS 再快也是白搭。最终的改造顺序也验证了这个判断：首屏数据链路的优化收益最大，其次是图片，最后才是缓存和预取带来的增量。

2. 首屏数据链路：从多请求串行到一次性交付

2.1 接口层面的剪枝与聚合

很多详情页慢，不是慢在渲染代码，而是慢在请求链路上。我们原来一个详情页要依次调这类接口：商品基础信息、价格、SKU 列表、库存、店铺信息、推荐位、优惠券。这些接口在服务端分散在不同模块里，前端只能在页面挂载后逐个请求。

我把这个链路画出来看的时候，发现两个问题。第一，大部分接口之间其实没有严格的依赖关系，完全可以用并发请求；第二，前端发多次请求，每一个都有 DNS、TCP、TLS 以及请求头的开销，在弱网环境下这些时间会被成倍放大。于是我们把网关层加了一个聚合接口，服务端内部并行去请求商品信息、价格、SKU、店铺、推荐等数据，前端只调用一次，拿到完整的数据对象。

这么改完之后，详情页的首屏请求数从 8 个降到了 3 个，剩下的 3 个里还有一个是受限的埋点上报。聚合接口带来的收益不仅在网络层，还让前端代码里的 loading 状态处理简化了很多。如果你们的后端暂时不具备聚合改造条件，退一步也可以先用 Promise.all 做客户端并发，把串行等待变成并行等待，效果会比原来好不少，只是网络连接上的开销省不掉。

2.2 SSR 只做首屏，数据注入避免二次请求

原来的详情页是纯 SPA，页面加载后先显示空白，等 JS 执行完才开始渲染。这个架构在弱网和低端机上非常吃亏，JS 文件还没下载完，用户看到的就是一个白屏。

我们没有把整个详情页全部改成 SSR，而是做了一个折中：首屏用 SSR 先输出可读的 HTML，包含商品名、价格、主图 URL、面包屑这些关键信息，详情区和推荐区仍然保留客户端渲染。这样至少用户在等待 JS 的时候已经能看到商品内容了，LCP 不再被 JS 执行时间绑架。

这个方案里最容易踩坑的是数据重复请求。SSR 已经在服务端把商品信息渲染进 HTML 了，前端 hydration 之后如果又按原来的逻辑重新请求一次，等于白干。我们的做法是：SSR 时把当前初始数据以 JSON 形式注入到页面，前端初始化时先读取这份数据，命中就直接跳过第一轮请求。注入数据要注意 XSS 转义，内容里带引号和 HTML 标签都要安全处理，不能直接拼进 script 标签。另外，服务端渲染组件时要防御 window、document 这些浏览器对象不存在的情况，所有依赖 DOM 的逻辑都要放到 useEffect 或者 mounted 之后再执行。

2.3 超时降级与骨架屏策略

SSR 不是永远可靠的。服务端负载高、接口超时、缓存失效，各种情况都可能让 SSR 变慢甚至失败。我们的处理策略是给 SSR 设置一个超时阈值，超过 500ms 就降级成客户端渲染，保证页面不会因为服务端慢而整体打不开。

同时给详情页做了分区骨架屏，顶部信息区、轮播图区、详情区、推荐区各一个骨架模块，用简单的渐变 shimmer 动画告诉用户"内容正在来"。骨架屏的位置和尺寸要尽量贴近真实模块，否则内容加载出来的时候会明显跳动。如果接口彻底失败，客户端会尝试展示上一次访问时的缓存版本，顶部加一条轻提示说明数据可能不是最新，而不是直接给用户一个崩溃页。这套降级策略后来在线上救过我们好几次，至少用户不会因为 SSR 偶发超时就什么都看不到。

3. 商品图加载：服装电商最值的一刀

3.1 轮播主图的优先级与尺寸控制

服装详情页的主图轮播是首屏最大元素，通常也是 LCP 的定位点。原来的实现直接把原图地址放进轮播组件，一张原图动辄 1MB-3MB，用户首屏什么都没干就先下载一张大图，体验自然好不了。

我们给图片服务加了一套动态处理能力，根据场景输出不同宽度和质量参数。移动端轮播首图默认请求约 1500px 宽、质量 75 的版本，不再直接打原图。关键改动是给首图加上了 fetchpriority="high" 和 loading="eager"，告诉浏览器这是当前视口内优先级最高的资源，不要等最后再加载。轮播里后面的图仍然用懒加载，用户滑到哪张再加载哪张。

这里有个容易搞混的点：为什么不直接用 preload。preload 适合静态确定要加载的资源，但轮播图真正的图片地址往往需要拿到商品数据后才拼接出来，而且优先级最高的只有当前显示的这一张。用 fetchpriority 动态控制一个 img 的加载优先级，比 preload 更灵活。同时给图片加 decoding="async"，让浏览器不用等解码图片就能继续解析后续内容。

3.2 图片格式与响应式方案的兼容处理

图片格式这块，我们最终用了嵌套的 picture 方案，让浏览器自己选择能识别的最优格式：

<picture> <source srcset="https://cdn.example.com/goods/main.avif?w=1500" type="image/avif" /> <source srcset="https://cdn.example.com/goods/main.webp?w=1500" type="image/webp" /> <img src="https://cdn.example.com/goods/main.jpg?w=1500" alt="商品主图" fetchpriority="high" decoding="async" /> </picture>

<img srcset=" https://cdn.example.com/goods/main.jpg?w=750 750w, https://cdn.example.com/goods/main.jpg?w=1500 1500w " sizes="100vw" src="https://cdn.example.com/goods/main.jpg?w=1500" alt="商品主图" fetchpriority="high" decoding="async" />

不过我要特别说一句：AVIF 不是所有场景都无脑好用。我们在实测中发现，材质纹理和颜色过渡细腻的服装细节图，用 AVIF 偶尔会出现肉眼可见的噪点和色斑，尤其是在暗部。最后我们给主图和细节图保留 WebP，详情长图这种对颜色精度要求相对低一点的场景才用 AVIF。经验就是：格式压缩率重要，但不要牺牲商品展示的还原度，做服装平台最重要的事情是让用户看图片觉得"这衣服没有色差"。

3.3 详情长图切片后按需懒加载

服装详情页最后一块往往是一张很长的图，模特上身图、局部做工图、尺码表全拼在一张图里。之前为了省事，前端把整张长图一次性加载，结果一个详情页额外多出好几 MB 的流量，用户滚动到那一块之前根本不需要这些数据。

我们改造了图片服务，让它能把一张超长图按高度切成若干个切片，每段约 1200px。前端用一个懒加载容器，通过 IntersectionObserver 观察视口位置，只加载当前屏幕附近的两到三段切片，更远的切片等用户快滚动到的时候再请求。这里要注意不要把切片切得太短，否则 HTTP 请求数量会大幅增加，反而拖慢速度。我们对一张 30000px 高的长图大概切成 25 段，但一次只会请求最近的两三段，实际网络传输量下降非常明显。

切片加载失败的兜底也要提前做。有的图片切片可能生成失败，前端要能显示一个中性背景色块，而不是出现一张空白的破图。监听加载状态、增加重试次数、超过阈值就降级为整图请求，这三个策略我们最后都做了。

3.4 字体和图标的小体积改造

之前的详情页为了品牌调性加载了两套自定义字体，一套常规字重一套数字字体，加起来接近 400KB。这个开销在移动端非常不合算。我们把详情页的自定义字体全部去掉，价格、库存、尺码这些数字使用系统字体栈，只在运营活动落地页保留品牌字体。如果确实要用自定义字体，至少给字体文件做子集化，只保留页面上实际用到的字符，再用 font-display: swap 避免文字不可见。

图标部分同样做了减法。原来详情页用了一套图标字体，几十个图标里真正用到的不到十个。我们改成内联 SVG sprite，把需要的图标直接打包进组件里，请求数和文件体积同时降下来。这类改造放在所有大优化做完之后，收益看起来不那么震撼，但每一个小改动都在给低端机用户叠加体验优势。

4. SKU 交互与滚动细节：让页面"点着不卡"

4.1 SKU 可售矩阵计算的剪枝优化

服装类目的 SKU 结构比普通标品复杂不少。一件衣服通常有颜色、尺码、版型三个维度，颜色可能二三十种，尺码十几个，组合出来就是几百个 SKU。原来我们每次点击一个属性，都会把整个 SKU 列表重新遍历一遍，把所有可售组合重新算出来，再刷新界面。SKU 一多、点击频率一高，卡顿就特别明显。

改造思路是分步剪枝而不是全量遍历。预先构造一张颜色到尺码、尺码到颜色的索引，用户选中一个颜色后，只在对应的尺码集合里继续过滤，而不是把几百个组合全查一遍。同时把已经算出来的可选集合缓存起来，同一个选择组合不重复计算。实测从十几毫秒降到 1 毫秒以内，虽然数字不大，但用户反复点选尺码、颜色时，体感从"卡一下"变成了"瞬间响应"。

这里还要注意置灰逻辑的边界情况。比如用户先选了颜色，再选尺码，有些颜色会因为当前尺码不可售而变成灰色；反过来也一样。算法要同时处理正向可选和反向置灰，否则用户会看到能点的组合却提交不了，那种体验比慢更糟。

4.2 长列表渲染与事件委托

详情页页面往下走还有相关推荐、搭配组合、评论区，这些区域的数据量都不小。一开始是拿数组循环生成一堆 DOM，再给每个节点绑事件，节点一多 JavaScript 的执行时间明显上升。

我们做了这样几个优化。事件委托：只在详情页容器上绑一个 click 处理器，通过>变化FCP2.3s0.9s-61%LCP2.6s1.0s-62%CLS0.280.03-89%TBT320ms80ms-75%首屏请求数8 个3 个-5

线上抽样数据同样有改善，移动端详情页 LCP 的 p50 从 2.9s 降到 1.4s，跳出率从 41% 左右降到 32% 左右，加购转化率相对提升也在可量化的范围内。需要说明的是，业务指标不完全由性能决定，同期还做了一些页面交互简化，所以不能把转化率的提升全部归功于性能优化，但性能数据本身的变化是实打实的。

6.3 回归测试清单与持续兜底

性能优化最容易伤到功能，我们整理了一份详情页回归清单，每次发版之前都会跑一遍：

后来我们还把性能基线挂到了发布流水线上，LCP 和 TBT 超过设定阈值就自动告警，严重时可以阻止发布。这样后续团队再改详情页，性能不会因为一次无意识的改动又退回去。

最后再说一个执行层面的体会。性能优化这种事，最怕的从来不是没有方案，而是方案做完没人跟进验证。我们这次把关键路径的性能阈值变成了发布流水线的一环，才真正把成果守住。下一轮我准备把同一套思路搬到搜索列表页，那边的图片密度更高，可以优化的空间可能比详情页还大。如果你们也在做类似的事情，强烈建议从首屏数据链路下手，那是最先能看到回报的一刀。