正文

网站优化注意，从4.8s LCP到1.6s的实测配置清单

程序员老王
程序员老王 V管理员 /732阅读/0评论
1029
文章最后更新时间2026年10月29日，若文章内容或图片失效，请留言反馈！
网站优化注意，加载性能优先于视觉样式，本文围绕LCP、TTFB等核心网页指标，通过资源压缩、缓存、CDN与服务器配置，实测将LCP从4.8s降至1.6s、TTFB从820ms降至175ms，有效降低移动端跳出率。

网站优化注意，首要问题是加载性能，而不是视觉样式，我们在一台典型 2C4G Nginx+PHP-FPM+MySQL 环境上测得：优化前页面总重 2.83MB，请求数 96 个，LCP 4.8s，TTFB 820ms，移动端跳出率高出均值约 11 个百分点，把诊断、资源压缩、缓存、CDN、服务器配置五项全部落地后，同等测试条件下 LCP 降至 1.6s，TTFB 降至 175ms,下面按可复现的步骤展开。

网站优化注意，从4.8s LCP到1.6s的实测配置清单

网站优化注意，从4.8s LCP到1.6s的实测配置清单

网站速度诊断方法

先建立核心指标基线

不要只盯着 PageSpeed 分数，先记录 Core Web Vitals 和关键传输指标：LCP、CLS、INP、TTFB、请求数、页面总重,推荐工具组合：

  • Lighthouse：实验室数据,适合本地快速回归。
  • WebPageTest：用 4G 中端机模拟,看完整瀑布图。
  • CrUX / Search Console：现场用户数据,判断真实分布。

从瀑布图定位瓶颈

在 Chrome DevTools Network 面板或 WebPageTest 中按时间排序,重点观察：

  • DNS + TCP + TLS 耗时是否超过 300ms。
  • 等待 TTFB 是否超过 600ms。
  • 首屏图片、CSS、JS 是否阻塞 LCP 元素。
  • 是否有第三方脚本长时间占用主线程。

判断逻辑很直接：TTFB 高，先优化服务器与回源；TTFB 正常但 LCP 高，重点处理资源体积、阻塞加载和首屏图片。

建议诊断阈值

指标 需要关注 需要立即处理
页面总重 > 1.5MB > 2.5MB
请求数 > 60 > 90
图片总重 > 800KB > 1.5MB
JS 总重 > 500KB > 1MB
TTFB > 600ms > 1s
LCP > 2.5s > 4s
CLS > 0.1 > 0.25

图片 / JS / CSS 压缩和合并技巧

图片：先减量，再换格式

图片通常是页面体积最大的部分，实测一张 1.2MB 的 JPG 转 WebP 后约 420KB，转 AVIF 后约 280KB,处理顺序建议：

  • 不要让 3000px 宽度图片只用 CSS 缩放到 400px 展示，导出图片时使用实际显示尺寸的 2 倍即可。
  • 使用 srcset + sizes 为移动端输出小尺寸。
  • 使用 loading="lazy" 与 decoding="async",将非首屏图片延迟加载。
  • 优先使用 WebP/AVIF，可配合 CDN 图片处理参数动态生成。

JS：压缩、Tree Shaking 与分包

生产构建必须开启压缩，使用 esbuild、terser 或 Vite/Webpack 的生产模式,进一步建议：

  • 开启 Tree Shaking,删除未使用导出。
  • React/Vue 路由级页面使用动态 import() 分包，首屏只加载必要 JS。
  • 非关键第三方 SDK，例如统计、客服、广告脚本，延后注入或 defer 加载。
  • 不要把所有 JS 打成单个大包，HTTP/2 下，按变更频率拆成 vendor、common、page 更利于缓存复用。

CSS：压缩并移除未使用规则

CSS 体积虽然通常小于 JS,但很容易阻塞渲染：

  • 使用 cssnano 压缩。
  • 使用 PurgeCSS 移除未使用的类名。
  • 首屏关键 CSS 可以内联，非关键 CSS 使用异步加载方式。
  • 避免 @import,它会增加链路耗时。

合并策略：不要盲目合并

HTTP/1.1 时代合并 JS/CSS 是为了减少请求数，但 HTTP/2 多路复用下，请求数不再是主要瓶颈，盲目合并会导致缓存失效范围扩大、首屏执行时间变长，更合理的策略是：按模块和变更频率拆分，按页面加载需求引入。

缓存配置方案

浏览器缓存：给静态资源长缓存

带指纹的静态资源可以使用一年级强缓存：

location /assets/ {
  expires 1y;
  add_header Cache-Control "public, immutable";
  try_files $uri =404;
}

HTML 文档则不能长缓存,否则用户会拿到旧页面结构：

location = /index.html {
  add_header Cache-Control "no-cache";
}

no-cache 配合 ETag 可以每次校验，命中 304 时响应体为 0 字节。

服务端缓存：减少重复计算

服务端缓存直接影响 TTFB：

  • Nginx 可启用 fastcgi_cache 缓存动态页面。
  • PHP 启用 OPcache,生产环境关闭时间戳校验。
  • Redis 做对象缓存和热点数据缓存,减少数据库查询。
  • 数据库慢查询日志建议设置 long_query_time=0.5,持续优化高频慢查询。

Service Worker 作为可选增强

Service Worker 对弱网用户收益明显，但会引入更新策略复杂度，建议只预缓存关键静态文件，运行时缓存图片和字体，避免缓存 API POST 请求。

CDN 加速部署建议

静态资源与整站加速

将图片、CSS、JS、字体等静态资源全部接入 CDN，动态页面也可以做整站加速,但需要正确配置回源和缓存键。

关注缓存命中率与回源策略

CDN 缓存命中率低于 85% 时,需要检查：

  • Cache-Control 头是否合理。
  • 缓存键是否包含多余参数。
  • 回源是否频繁失败或超时。

开启现代协议与压缩

CDN 侧建议开启：

  • Brotli 压缩，文本资源通常比 Gzip 再小 15%-25%。
  • HTTP/3，降低握手耗时,弱网下更稳定。
  • TLS 1.3，减少 TLS 往返次数。

图片走 CDN 处理

很多 CDN 支持 URL 参数裁剪、格式转换，例如请求原图时自动输出 WebP/AVIF,可以避免本地维护多套图片格式。

服务器配置优化要点

Nginx 基础参数

sendfile on;
tcp_nopush on;
keepalive_timeout 20;
gzip on;
gzip_types text/plain text/css application/json application/javascript image/svg+xml;
http2 on;
open_file_cache max=10000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 1;

PHP-FPM 与运行时

  • pm.max_children 按可用内存计算，避免进程数过高导致 swap。
  • pm.max_requests=1000 可缓解内存泄漏。
  • PHP 8.x 相比 PHP 7.4 通常有 20%-40% 的执行性能提升,建议升级。

数据库查询与对象缓存

MySQL 8 不再推荐开启 Query Cache，应使用 Redis 缓存高频查询结果，重点关注慢查询：没有索引的大表排序、重复查询、N+1 查询都会直接抬高 TTFB。

TLS 与连接复用

开启 OCSP Stapling、TLS session cache，减少重复 HTTPS 握手成本，CDN 与源站之间的 TLS 同样要配置连接复用和高版本协议。

实测数据对比

测试环境：2C4G 云服务器，Nginx 1.24，PHP 8.2，MySQL 8.0，移动端 4G 模拟，WebPageTest 中端设备。

指标 优化前 优化后 变化
页面总大小 83MB 92MB -67.5%
请求数 96 34 -64.6%
图片总大小 68MB 31MB -81.5%
TTFB 820ms 175ms -78.7%
LCP 8s 6s -66.7%
CLS 24 02 -91.7%
TTI 1s 2s -63.9%
Speed Index 3s 9s -64.2%

网站优化注意不能只看单一分数，要围绕 TTFB、LCP、请求数、缓存命中率形成闭环，每一项修改都在 staging 环境用同一组测试条件回归，确认收益后再上线,才能避免负优化。