B2B 外贸官网 TTFB 从 17.96s 到 0.94s：我们怎么做的

接手一个 LED 照明制造商的外贸官网性能优化时，第一次打开首页我们等了十几秒。不是网络问题，是网站本身：服务器在德国，数据库在香港，首页 banner 是一个近 40MB 的视频，图片没有做响应式处理。移动端首屏要等数十秒，后台部分查询直接超时 502。

这类问题在 PHP 外贸站里很常见，而且大多数不需要重做网站。下面把我们的排查和处理顺序完整写一遍，读者可以对照自己的站点逐项检查。

先说我们在量什么

我们围绕 Core Web Vitals 做优化。这是 Google 衡量真实用户体验的一组核心指标：LCP（最大内容绘制，首屏主要内容出现的时间）、INP（交互到下一次绘制，点击后的响应速度）、CLS（累计布局偏移，页面有没有跳动）。再加上 TTFB（首字节时间），四个指标基本能定位问题出在服务端、资源体积还是前端代码。它们直接影响跳出率和转化率，也是搜索排名的参考因素之一。

工具方面，Lighthouse 和 PageSpeed Insights 做实验室测试，Chrome UX Report 和真实用户监控（RUM）看线上真实数据。实验室数据用来定位问题，真实用户数据用来确认业务影响，两者都要看。

第一步：先量，再动手

不要凭感觉改。我们先用 Lighthouse 对首页和产品详情页各跑 3 次取中位数，建立基线：

• 首页桌面端 56 分，LCP 6.5s
• 产品详情页桌面端 44 分，CLS 0.287
• 首页 TTFB 17.96s
• 首页移动端图片下载量 22.7MB
• 首页视频体积 38.8MB

有了这组数字，后面每一步才能判断值不值得做、做完有没有效果。

第二步：TTFB 太高，先看服务端链路

TTFB（Time To First Byte）接近 18 秒，说明问题在浏览器收到第一个字节之前，和前端资源无关。我们查了请求链路，发现网站部署在德国服务器，但 MariaDB 数据库在香港。每一次页面请求都要跨洲查询数据库，而一个页面可能发起几十次查询，延迟全部叠加。

处理方式很直接：把数据库迁到德国服务器本机，消除跨洲往返。这一步做完，首页 TTFB 从 17.96s 降到 0.94s，后台 10 个请求的总耗时从 208.7s 降到 12.1s，原先超时 502 的查询恢复到 1.43s。

经验：如果你的 TTFB 超过 1 秒，先查数据库和应用服务器是不是在同一个机房，再查慢查询。很多外贸站是分批建的，服务器搬过家而数据库没跟着走。

第三步：视频是最大的单个资源

首页 banner 视频用 HEVC 编码，体积 38.8MB。HEVC 在部分浏览器上兼容性不好，体积也没有因此变小。我们把它转码为 H.264 720p，加上封面图（poster）和懒加载，移动端视频体积降到 2.73MB。

要点有三个：

1. 分辨率按实际展示尺寸定，banner 不需要 4K
2. 一定要有封面图，否则 LCP 会等视频第一帧
3. 视频不在首屏时才加载，首屏用封面图占位

第四步：图片做响应式，而不是一张图走天下

移动端首页图片下载量 22.7MB，原因是手机也在下载桌面端的原图。处理方案：

• 用图片 CDN 做动态缩放，按请求参数输出不同尺寸
• 用 srcset 让浏览器按屏幕宽度选图
• 输出 WebP 格式
• 补齐 width / height 占位，避免图片加载完成后页面跳动（这是 CLS 的主要来源）
• 进入视口才加载

做完后移动端首页图片下载量从 22.7MB 降到 241KiB，减少 99%。产品详情页 CLS 从 0.287 降到 0.008，主要就是靠宽高占位。

第五步：JS、缓存与字体

剩下的是常规前端治理：

• 17 个 JS 文件合并为 4 个，并加 defer，避免阻塞渲染
• 静态资源按文件修改时间加版本号，配合 CDN 长缓存。这样既能长期缓存，又不会在更新后让用户拿到旧文件
• 恢复 font-display: swap，让文字先用系统字体显示，自定义字体加载完再替换，不要让用户盯着空白等字体
• 服务端开启 Brotli 压缩

另外我们扫描了全站 187 个页面的桌面端和移动端 JS 报错。性能优化过程中改动较多，报错扫描是防止「优化了速度、弄坏了功能」的兜底。

结果

Lighthouse 桌面端（3 次取中位数）：

• 首页 56 → 88 分，LCP 6.5s → 1.5s
• 产品详情页 44 → 91 分，CLS 0.287 → 0.008

整个过程没有重做网站，技术栈仍然是 PHP + ThinkPHP + MariaDB + Nginx，只是把每一层的问题逐个处理掉。

优化完成之后：防止回退

性能优化最常见的结局是三个月后又慢回去了：运营上传了一张 5MB 的原图，开发加了一个新的第三方脚本。所以我们在交付时会把基线报告和优化后报告一起留存，并建议客户把 Lighthouse 跑分放进上线流程，每次发布前后对比一次。真实用户监控数据则按周看一眼，指标下滑时能及时找到是哪次改动引起的。

衡量效果也不只看测试分数。优化前后的 LCP、INP、CLS、TTFB 要结合转化漏斗数据一起看，确认速度提升确实带来了业务上的变化。

Shopify 店铺同样适用

这套方法不限于 PHP 自建站。Shopify 店铺常见的性能问题来自主题代码、过多的第三方 App 脚本和未优化的图片，这些都能在主题层面治理，不需要换平台。排查顺序也一样：先量基线，再看最大的资源，再处理脚本和布局偏移。

自己检查的顺序

如果你想先自查，建议按这个顺序：

1. 用 PageSpeed Insights 或 Lighthouse 跑 3 次，记下 TTFB、LCP、CLS 和总下载体积
2. TTFB 超过 1 秒：查数据库位置、慢查询、服务器配置
3. 看瀑布图里最大的几个资源：通常是视频和原图
4. 看 CLS：找没有宽高的图片、晚加载的字体和广告位
5. 看 JS：有没有阻塞渲染的脚本、能不能合并和延迟
6. 最后设置缓存策略和压缩

每做完一项就重新量一次，确认方向对了再做下一项。

---

绯星科技（深圳）是一家电商技术服务商、Shopify Partner，提供 Shopify / Shopify Plus 开发、Headless 电商独立站、网站性能优化（Core Web Vitals）和跨境 VAT 合规系统搭建。本文案例详情见 https://www.feixingtech.cn/cases/#b2b-site-performance ，性能优化服务说明见 https://www.feixingtech.cn/wpo/ 。