「网站慢」是一个症状，不是一个原因。乱装缓存插件常常越优化越慢。按下面的顺序排查，绝大多数外贸站的问题都会在前两步被定位。
先说跑分这件事
Lighthouse 分数是给开发者看的体检指标，不是你的收入指标。移动端 60 分和 85 分，客户感知可能一模一样；而 95 分的站只要 TTFB 抖到两秒，该跳还是跳。真正该盯的是三个字段：服务器响应时间、首屏最大内容绘制时间、以及用户实际会不会等不下去。
测的时候用无痕窗口、关掉所有扩展、多测几次取中位数，并且分别测移动端和桌面端。
第一站：服务器响应（TTFB）
在开发者工具 Network 里看那条对 HTML 文档的请求的 Waiting 时间。这一步决定问题是不是你的代码能解决的。
- 未开缓存时稳定在 300 毫秒内：主机正常，往下查
- 经常超过 800 毫秒或忽高忽低：主机超载或数据库慢，先换或升级主机，做什么都白搭
- 只有后台慢、前台正常：插件太多或内存不够，先查第六步
数据库层面的一个常见杀手是 autoload 过大的选项，以及一条查询循环里打几十次数据库。这两类问题靠换主题或删插件是碰不到的，需要在 Query Monitor 里看。
第二站：图片
外贸站的图片体积问题比所有人想的都严重。首页放一张 4MB 的 2560 宽横幅，是「首屏白一下再出来」的头号原因。
- 上传前按显示宽度缩好：内容区显示 1120 宽，就不要传 2000 宽
- 照片用 WebP（或 AVIF），JPEG 只做兜底；图标和 logo 用 SVG
- 批量压缩一次，之后靠上传时自动出多尺寸和 WebP 的插件维持
- 首屏那张图不要设懒加载，其余的设上
图片的 SEO 侧做法（文件名、ALT）见 图片 SEO，和速度是同一批文件，一次改完。
第三站：缓存
缓存的思路是把 PHP 生成的 HTML 存成静态文件，跳过数据库查询。三个层次，按性价比从上往下做：
| 层次 | 做什么 | 注意 |
|---|---|---|
| 页面缓存 | 插件生成静态 HTML，或主机层开缓存 | 购物车、结账、表单页要排除 |
| 浏览器缓存 | 给静态资源加有效期与版本号 | 改完样式记得清缓存再看 |
| CDN | 静态资源就近分发 | 只解决远程访客，不解决 TTFB |
一个坑：缓存插件加 JS/CSS 合并压缩，经常和构建器打架。Bricks 或 Elementor 的编辑器打不开、样式错乱，先关缓存再复现，见 编辑器加载失败的排查。
第四站：构建器产物
同一个页面，Elementor 常带几十到上百个 CSS 文件与一大坨嵌套 DOM，Bricks 通常只输出实际用到的样式。这是两种路线的真实差距，也是很多站「图片压过了、缓存开了还是慢」的原因。
检查方法：看 Network 里本站 CSS/JS 请求的条数。超过三十条就值得动手，合并无关紧要，砍掉没用的插件资源才有效。
第五站：第三方脚本
- Google 字体：改成托管在本地，用 woff2 并开子集，别在每个页面都从外网拉
- 统计与像素：GA4、Meta Pixel、TikTok 这些异步加载，别放在 head 里同步阻塞
- 聊天与客服挂件：延迟到用户滚动或空闲后再注入
- 外链的地图、YouTube：用封面图点击再加载
第六站：插件
判断标准不是数量而是体积：一个只在后台用的插件对前台没影响，一个给每个页面都注入脚本和样式的插件就有。逐个禁用测试太慢，用 Query Monitor 看前台加载了哪些插件的资源，把没在用的 SEO、滑块、分享、评论类插件的资源禁用或删掉。
做完的顺序建议
- 测一次，记下数字
- 看 TTFB，决定要不要换主机
- 压图片，处理首屏
- 开页面缓存
- 本地化字体、延迟第三方脚本
- 清插件资源
- 再测一次，对比数字
每一步只改一类东西并复测。一次改五项，快了你不知道为什么快，慢了你也不知道是谁干的。