网站打开慢怎么优化：从首字节到首屏

一、网站打开慢先定位：别凭感觉改，要先测出慢在哪

打开慢是一个结果描述，不是原因。绝大多数人遇到这个问题时的第一反应是「服务器配置不够就升级」，这个判断有五成以上是错的。实际排查下来，慢的来源分布大致是：前端资源体积和未做缓存优化占三成以上，服务端响应慢（TTFB 高）占两成左右，图片未压缩未用现代格式占两成，第三方脚本拖慢占一成，其余才是真正的算力不足。

延伸对照：cloudcone 的公开机型与线路说明，可结合本节的判断标准自行核对。

更关键的是，不同用户感受到的「慢」可能完全不同。首次访问的用户要下载全部资源，缓存全冷，体感最慢；回访用户命中缓存，体感正常，但你的跳出率统计可能显示大部分用户「很快」。所以第一个动作不是优化，而是用真实数据确定你面对的是哪一类慢。

判断自己的网站是不是真的慢，看核心网页指标（Core Web Vitals）最直接。这三个指标由浏览器实测得出，是搜索引擎评估页面体验的主要依据：LCP（最大内容绘制）衡量首屏主要内容何时可见，标准是 2.5 秒以内；INP（交互到下一次绘制）衡量点击后多久有响应，标准是 200 毫秒以内；CLS（累积布局偏移）衡量页面元素是否乱跳，标准是 0.1 以内。

先在自己的机器上跑一次基线测试。Chrome 开发者工具的 Lighthouse 或者命令行版本都可以：

# 用 Lighthouse 命令行跑一次性能审计，输出 JSON 便于对比
npx lighthouse https://your-site.com \
  --preset=desktop \
  --output=json --output-path=./lh-before.json \
  --chrome-flags="--headless --no-sandbox"

判读方式：打开输出的 JSON，看 audits 里 largest-contentful-paint、total-blocking-time、cumulative-layout-shift、speed-index 四项的 score 和 numericValue。记下这些数字作为基线，后面每做一项优化就重跑一次对比。没有基线的优化等于没优化，因为你无法证明改动是否有效。

测量的同时要注意一个容易被忽略的前提：测试结果受网络位置影响极大。同一个站点，从本地机房测和从用户所在的三四线城市测，TTFB 可能差三倍以上。选一台和目标用户相近的机器测，或者用多个监测点测，否则测出来的数字对你没有参考价值。

二、TTFB：服务器多久才开始返回数据

TTFB（Time To First Byte）是浏览器发出请求到收到服务器第一个字节的时间，它包含了 DNS 解析、TCP 握手、TLS 握手、服务器处理这四段。在移动网络环境下，这四段里 DNS 和 TLS 往往是主要开销。

延伸对照：digitalocean 的公开机型与线路说明，可结合本节的判断标准自行核对。

一个经验参考值：静态页面 TTFB 在 200 毫秒以内算好，200 到 600 毫秒可接受，超过 1 秒就是明确的问题。而动态页面（PHP、Node、数据库查询）会比静态页面多出后端处理时间，500 毫秒以下算正常水平。

先测出你当前的 TTFB：

# 从国内网络测 TTFB，包含 DNS、连接、TLS 三段耗时
curl -o /dev/null -s -w \
  "dns:%{time_namelookup}s connect:%{time_connect}s tls:%{time_appconnect}s ttfb:%{time_starttransfer}s total:%{time_total}s\n" \
  https://your-site.com

# 连续测 20 次看稳定性，判断是否有抖动
for i in $(seq 1 20); do
  curl -o /dev/null -s -w "%{time_starttransfer}\n" https://your-site.com
done | sort -n | awk 'NR==1{min=$1} {a[NR]=$1} END{print "min="min, "median="a[int(NR/2)], "max="a[NR]}'

判读方式：看三段耗时的差值。如果 dns 很大（超过 100 毫秒），问题在 DNS，应换用更快的解析服务或预解析。如果 connect 到 tls 之间耗时长，是 TLS 握手问题，检查是否启用了 TLS 1.3，是否因为证书链太长或启用了不合适的加密套件。如果 tls 到 ttfb 之间耗时长，才是服务器处理慢，回到后端优化。

按这个口径，最常见的 TTFB 优化手段有三个。第一是应用层缓存，把不常变的页面结果缓存起来，Redis 或内存缓存都能把动态页面的 TTFB 从数百毫秒压到几十毫秒。第二是数据库查询优化，加索引、消除 N+1 查询、避免在渲染时做外部 API 调用。第三是让静态资源不经过应用服务器，直接由 Nginx 或 CDN 返回。

Nginx 层的静态资源配置示例：

server {
    listen 443 ssl http2;
    server_name your-site.com;

    # 静态资源直接由 Nginx 返回，不进 PHP
    location ~* \.(jpg|jpeg|png|gif|webp|avif|css|js|woff2|svg)$ {
        root /var/www/html;
        expires 30d;
        add_header Cache-Control "public, max-age=2592000, immutable";
        access_log off;
    }

    # 动态页面交给 PHP-FPM，并把 FastCGI 缓存打开
    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=pagecache:50m
                      max_size=500m inactive=10m use_temp_path=off;
        fastcgi_cache pagecache;
        fastcgi_cache_valid 200 10m;
        fastcgi_cache_key "$scheme$request_method$host$request_uri";
        fastcgi_cache_min_uses 1;
        fastcgi_cache_lock on;
        add_header X-Cache-Status $upstream_cache_status;
    }
}

判读方式：加上 X-Cache-Status 响应头后，用 curl -I https://your-site.com 看返回的是 HIT 还是 MISS。HIT 说明命中缓存，MISS 说明回源了。注意 fastcgi_cache 只对 GET 和 HEAD 生效，带 cookie 的请求默认不缓存，这类场景可以用 fastcgi_cache_bypass 按需放行。

三、开启 gzip 和 brotli：最省事的收益

压缩是投入产出比最高的一项优化，通常能让 HTML、JS、CSS 的传输量下降 60% 到 80%，而服务器 CPU 开销增加有限。HTML 页面体积大、重复内容多，压缩收益尤其明显。

延伸对照：hostwinds 的公开机型与线路说明，可结合本节的判断标准自行核对。

gzip 和 brotli 的区别在于压缩率与速度的取舍。gzip 是通用标准，兼容性最好，压缩率中等；brotli 是更新的算法，同样压缩级别下体积比 gzip 小 10% 到 20%，而且对文本类内容效果更好。brotli 的支持度现在已经很普遍，主要老旧浏览器需要保留 gzip 兜底。

正确做法是两者同时开启：优先返回 brotli，不支持时回退 gzip。

# Nginx 开启 gzip 与 brotli
gzip on;
gzip_vary on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_proxied any;
gzip_types text/plain text/css text/xml application/json
           application/javascript application/xml application/xml+rss
           text/javascript image/svg+xml;

# brotli 模块需要先安装 ngx_brotli
brotli on;
brotli_comp_level 5;
brotli_min_length 256;
brotli_types text/plain text/css text/xml application/json
            application/javascript application/xml application/xml+rss
            text/javascript image/svg+xml;

开启后必须验证真的生效了：

# 对比压缩前后体积，并确认响应头
curl -s -o /dev/null -H "Accept-Encoding: gzip" \
  -w "gzip 大小:%{size_download} 字节\n" https://your-site.com/style.css
curl -s -o /dev/null -H "Accept-Encoding: br" \
  -w "brotli 大小:%{size_download} 字节\n" https://your-site.com/style.css
curl -s -o /dev/null -H "Accept-Encoding: gzip" \
  -D - https://your-site.com/style.css -o /dev/null | grep -i "content-encoding"

判读方式：响应头里出现 Content-Encoding: gzip 才算生效。如果 curl 显示的大小和 gzip 后的一样大，说明压缩没生效，通常是 gzip_min_length 设得太大（文件低于阈值不压缩），或者类型不在 gzip_types 列表里。图片、视频、字体这类已经压缩过的格式不需要再 gzip，重复压缩会白费 CPU。

还有一个常被忽略的点：不要压缩已经压缩过的格式。JPEG、PNG、MP4、ZIP、GZIP 本身是压缩格式，再套一层 gzip 基本不缩小体积，反而增加服务器负担。

四、DNS 解析与协议层：容易被忽略的前置开销

TTFB 里还藏着两段和后端无关的开销：DNS 解析和协议握手。首次访问的用户没有 DNS 缓存，解析一次可能要几十到几百毫秒；协议层面如果只支持 HTTP/1.1 并开启了 TLS 1.2，每个域名的并发请求都要单独握手。

延伸对照：interserver 的公开机型与线路说明，可结合本节的判断标准自行核对。

先看 DNS 解析耗时：

# 用 dig 查 DNS 解析耗时，区分首次查询与缓存命中
dig your-site.com +stats | grep "Query time"
# 连续查 3 次，第一次通常最慢，后面走缓存
for i in 1 2 3; do
  dig your-site.com +stats | grep -o "Query time: [0-9]* msec"
done

判读方式：Query time 超过 100 毫秒说明解析服务偏慢或响应链路长，可以考虑接入更快的公共解析服务，或在权威 DNS 上开启预解析。对海外站点还要注意，解析服务器本身在境外会导致国内用户解析慢，这时用国内权威 DNS 托管 CNAME 会更稳。

协议层的检查方法：

# 查看服务端支持的 HTTP 协议版本
curl -s -o /dev/null -w "%{http_version} %{ssl_verify_result}\n" https://your-site.com
# HTTP/2 或 HTTP/3 时 http_version 返回 2 或 3
openssl s_client -connect your-site.com:443 -tls1_3 </dev/null 2>/dev/null | grep "Protocol"

判读方式：http_version 返回 1.1 说明还在用 HTTP/1.1，浏览器对同域名的并发请求数被限制在 6 个，这是资源多时加载慢的一个重要原因。启用 HTTP/2 后并发限制被解除，多资源页面的加载时间常有明显改善。

启用 HTTP/2 只需要在 Nginx 里加协议参数：

server {
    listen 443 ssl http2;
    server_name your-site.com;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
}

判读方式：curl -I --http2 https://your-site.com 能正常返回即说明支持。HTTP/2 迁移后最常见的问题是有个别老客户端不兼容，表现为特定浏览器加载异常，这类情况可以在 Nginx 里对异常 User-Agent 单独降级处理。

五、浏览器缓存：让回访用户几乎不下载

缓存的收益远大于前面所有前端优化，因为回访用户能跳过绝大部分资源下载。对内容站或电商站来说，缓存命中率高的页面 LCP 可以从 3 秒降到 1 秒以内。

延伸对照：itldc 的公开机型与线路说明，可结合本节的判断标准自行核对。

缓存策略的核心是给文件「加指纹」。文件名里带上内容哈希或版本号，内容变了文件名就变，浏览器就知道要重新下载；内容没变就继续用缓存。这样你才能放心地把缓存时间设得很长，通常是一年。

具体的做法有两种。一种是构建时生成指纹文件名，比如 app.3f2a1b.js，配合 Nginx 的 immutable 指令。另一种是保持文件名不变，用 ETag 让浏览器做条件请求，未变更时服务器返回 304，节省的是带宽但仍有一轮请求往返。

# 带指纹的静态资源：长缓存 + immutable
location ~* \.(js|css|woff2|png|jpg|webp)$ {
    root /var/www/html;
    expires 1y;
    add_header Cache-Control "public, max-age=31536000, immutable";
    add_header Accept-Ranges bytes;
}

# HTML 入口文件：不缓存，保证发版后立即生效
location = /index.html {
    add_header Cache-Control "no-cache, must-revalidate";
}

# 未带指纹的图片：短缓存
location ~* \.(png|jpg|jpeg|gif)$ {
    root /var/www/html;
    expires 7d;
    add_header Cache-Control "public, max-age=604800";
}

判读方式：用 curl -I 检查响应头。带指纹的资源应返回 Cache-Control: public, max-age=31536000, immutable；HTML 应返回 no-cache。然后在浏览器开发者工具的 Network 面板勾选 Disable cache 再刷新一次，对比两次请求的 Size 列：第一次是实际传输大小，第二次应显示 (disk cache) 或 (memory cache)，说明缓存正常工作。

缓存还有一个容易踩的坑：CDN 和浏览器的缓存时间不一致时会出现「更新不生效」。用户看到的 HTML 是新的，但引用的 JS 是旧的，导致页面报错或样式错乱。解决办法是发布流程里把 HTML 的缓存时间设为短，静态资源设为长，两者配合发布。

六、图片优化：往往是最大的单点收益

图片通常是页面里最大的传输块。一个未经优化的商品页可能有 20 张 2MB 的原图，总计 40MB，这一个文件类型就吃掉了绝大部分加载时间。图片优化的收益经常超过所有其他手段的总和。

延伸对照：iwebfusion 的公开机型与线路说明，可结合本节的判断标准自行核对。

四个关键动作：按显示尺寸压缩、用 WebP 或 AVIF 替代 JPEG 和 PNG、给图片加尺寸属性防止布局偏移、用懒加载推迟非首屏图片。

尺寸属性这一条容易被漏掉。浏览器在图片加载前不知道它的宽高，图片到达后会撑开或挤压已渲染的内容，产生布局偏移（CLS），既影响体验也影响 SEO 评分。加上 width 和 height 属性，浏览器就能预留空间。

<!-- 错误：没有尺寸属性，会造成布局偏移 -->

<!-- 正确：显式声明尺寸，配合 srcset 做响应式 -->
     srcset="/img/product-400.avif 400w,
             /img/product-800.avif 800w,
             /img/product-1600.avif 1600w"
     sizes="(max-width: 640px) 100vw, 50vw"
     width="800" height="600"
     loading="lazy" decoding="async"
     alt="商品图">

loading="lazy" 让浏览器推迟加载视口外的图片，首屏之外的图片可以省掉。decoding="async" 让解码不阻塞主线程。首屏的那张图不要加 lazy，它应该立刻加载。

图片格式转换可以用命令行批量做：

# 用 cwebp 转 WebP，质量 75 通常肉眼无损、体积降 60% 以上
for f in images/*.jpg; do
  cwebp -q 75 -m 6 "${f%.jpg}.webp"
done
# 用 avifenc 转 AVIF，压缩率更高但编码慢
for f in images/*.jpg; do
  avifenc -q 50 --speed 4 "${f%.jpg}.avif"
done
# 批量生成多尺寸，配合 srcset 使用
for f in images/*.jpg; do
  for w in 400 800 1600; do
    convert "${f}" -resize ${w}x -quality 78 "images/$(basename "${f%.jpg}")-${w}.jpg"
  done
done

判读方式：转换后对比体积和画质。WebP 质量 75 通常比同画质 JPEG 小 25% 到 40%；AVIF 比 WebP 再小 15% 到 30%，但编码耗时明显更长，适合在构建阶段离线处理而不适合在请求时动态转。

七、CDN 策略：什么时候该上，上哪种

CDN 的作用是把静态资源缓存到离用户更近的边缘节点，解决的是「距离」问题。用户在河南，源站在美西，走公网要 180 毫秒以上；把资源缓存到就近节点后，取回时间可能只有 20 毫秒。对以静态资源为主的站点，CDN 通常能把 LCP 从 2.5 秒以上压到 1.5 秒以内。

延伸对照：racknerd 的公开机型与线路说明，可结合本节的判断标准自行核对。

但 CDN 不是万能的，有三个前提要确认。第一，你的目标用户主要在国内还是海外，如果用户主要在东南亚，CDN 节点覆盖和回源线路要重新评估。第二，源站本身 TTFB 高的话，CDN 回源会把这个延迟带进来，回源请求数决定了缓存命中率能否维持。第三，CDN 会引入缓存失效的复杂度，发布时需要考虑刷新策略。

选择 CDN 类型时，考虑三种：静态资源加速适合纯 CSS、JS、图片、字体，配置最简单；动态加速针对动态请求做 TCP 连接复用和路由优化，能降低回源握手成本；全站加速带边缘规则，可做部分边缘计算，但配置复杂度和成本也更高。

# 带指纹的静态资源：长缓存，回源时用 no-cache 校验新鲜度
location ~* \.(js|css|woff2|avif|webp|png|jpg)$ {
    root /var/www/html;
    expires 1y;
    add_header Cache-Control "public, max-age=31536000, immutable";
    # 告诉 CDN 回源时不要用缓存，但允许返回 304
    add_header CDN-Cache-Control "public, max-age=31536000, immutable";
    add_header Surrogate-Control "max-age=31536000";
}

判读方式：接入 CDN 后用 curl -I 看响应头里有没有 X-Cache: HIT 或类似标识，HIT 表示边缘命中，MISS 表示回源。再用 curl -s -o /dev/null -w "%{time_starttransfer}" 对比接 CDN 前后的 TTFB。如果 MISS 比例很高，说明缓存规则没配对（常见于 URL 带随机参数）。

八、数据库调优：后端慢的真正来源

前面几节都是前端和传输层。如果你的 TTFB 仍然偏高，就需要往下查数据库。动态站点的响应时间分布通常是：数据库查询占 50% 到 70%，应用层计算占 20% 左右，网络和框架开销占剩下的部分。

延伸对照：zenlayer 的公开机型与线路说明，可结合本节的判断标准自行核对。

最常见的问题是缺索引和 N+1 查询。N+1 的特征是代码里有一个循环，循环体里执行一次 SQL，循环 100 次就是 100 条查询。

打开慢查询日志是最有效的第一步：

# MySQL 开启慢查询日志，阈值 1 秒
sudo mysql -e "SET GLOBAL long_query_time = 1;"
sudo mysql -e "SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';"
sudo mysql -e "SET GLOBAL slow_query_log = 'ON';"

# 查看当前最耗时的 20 条查询
sudo mysqldumpslow -s t -t 20 /var/log/mysql/slow.log

判读方式：看输出里的 Count（执行次数）、Time（总耗时）、Average（平均耗时）。Count 很高而 Average 不高，就是典型的 N+1。Average 很高说明有单条慢查询，需要看执行计划。

用执行计划定位问题：

-- 看查询实际走了哪个索引、有没有全表扫描
EXPLAIN ANALYZE SELECT o.id, o.amount, u.name
FROM orders o JOIN users u ON u.id = o.user_id
WHERE o.created_at > '2026-10-01'
ORDER BY o.amount DESC LIMIT 20;

-- 给高频筛选列建索引
CREATE INDEX idx_orders_created_at ON orders (created_at);

-- 复合索引按查询的过滤顺序排，前提是高区分度的列在前
CREATE INDEX idx_orders_user_status ON orders (user_id, status);

判读方式：执行计划里 type 出现 ALL 就是全表扫描，数据量大时必须加索引。rows 是预估扫描行数，如果远大于实际返回行数，说明索引选择性不好。Extra 出现 Using filesort 或 Using temporary 说明还有排序或临时表开销，值得进一步优化。

复合索引有个常被搞错的规则：最左前缀原则。索引 (user_id, status) 能加速 WHERE user_id = ? 和 WHERE user_id = ? AND status = ?，但不能加速单独的 WHERE status = ?。因为跳过了最左列，索引就失效了。

连接池也要配。PHP-FPM 或 Node 的数据库连接数如果低于并发请求数，请求会排队等待：

; PHP-FPM 池配置
pm = dynamic
pm.max_children = 20        ; 子进程数，建议约为 CPU 核数的 2 倍
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10
; 每个进程最多持有的数据库连接
pm.max_requests = 500

判读方式：pm.max_children 乘以每个应用的数据库连接数，不要超过数据库的 max_connections。用 SHOW STATUS LIKE 'Threads_connected' 看当前连接数，接近上限时会出现 Too many connections 错误。

九、JavaScript 执行：主线程被占住的时间

总阻塞时间（TBT）反映的是主线程被 JavaScript 占住的总时长，这是 INP 指标变差的主要原因。很多用户说「网站打开慢」，实际是首屏渲染出来了，但点了任何东西都没反应，这才是 TBT 偏高。

延伸对照：justg 的公开机型与线路说明，可结合本节的判断标准自行核对。

四个有效的处理手段：延后加载非必要脚本、把不需要的第三方脚本换成轻量版本、把长任务拆成可分片执行、用 Worker 挪出主线程。

最容易被忽视的是脚本的加载时机。带有 async 的脚本会并行下载但执行顺序不确定，defer 的脚本并行下载且按顺序在 DOM 解析完成后执行。对于不是首屏必需的脚本，应该直接延后到用户交互时再加载：

<!-- 不阻塞渲染：延后到浏览器空闲时执行 -->
<script defer src="/app.js"></script>

<!-- 第三方统计脚本：延后加载，不阻塞首屏 -->
<script>
  window.addEventListener('load', function () {
    var s = document.createElement('script');
    s.src = 'https://analytics.example.com/t.js';
    s.async = true;
    document.head.appendChild(s);
  });
</script>

<!-- 长任务分片：每处理一批就让出主线程 -->
async function processQueue(items) {
  const CHUNK = 50;
  for (let i = 0; i < items.length; i += CHUNK) {
    const slice = items.slice(i, i + CHUNK);
    await new Promise(r => setTimeout(r, 0));
    handle(slice);
  }
}

判读方式：在 Chrome 开发者工具的 Performance 面板录制一次，看底部时间轴上的红色三角（长任务）有多少个、每个多长。单个任务超过 50 毫秒就会造成掉帧，超过 200 毫秒用户就能明显感知到卡顿。

在服务器上可以做粗略的量化：

# 用 Chrome Headless 采集性能指标
npx puppeteer browsers install chrome
cat > measure.js <<'EOF'
const puppeteer = require('puppeteer');
(async () => {
  const browser = await puppeteer.launch({args:['--no-sandbox']});
  const page = await browser.newPage();
  await page.setViewport({width: 390, height: 844});
  await page.goto('https://your-site.com', {waitUntil: 'networkidle0'});
  const m = await page.evaluate(() => {
    const nav = performance.getEntriesByType('navigation')[0];
    const fcp = performance.getEntriesByName('first-contentful-paint')[0];
    return {
      ttfb: Math.round(nav.responseStart),
      domContentLoaded: Math.round(nav.domContentLoadedEventEnd),
      load: Math.round(nav.loadEventEnd),
      fcp: fcp ? Math.round(fcp.startTime) : null,
      transferSize: nav.transferSize,
    };
  });
  console.log(JSON.stringify(m, null, 1));
  await browser.close();
})();
EOF
node measure.js

判读方式：ttfb 大于 800 毫秒说明服务端要查，fcp 减去 ttfb 很大说明前端资源加载慢，load 减去 fcp 很大说明脚本执行或后置请求慢。三个差值分别指向不同的优化方向。

十、字体加载与第三方脚本：两个隐形的时间黑洞

CSS 里的字体声明是渲染阻塞的常见来源。当页面上缺少 font-display: swap 的中文字体时，浏览器会等待字体文件下载完成才显示文字，这段时间里用户看到的是空白。

延伸对照：spinservers 的公开机型与线路说明，可结合本节的判断标准自行核对。

中文网页最常见的问题是用了几百 KB 的中文字体文件来显示标题。解决办法有三条，按优先级排：能用系统字体就用系统字体；必须用自定义字体就做子集化，只保留实际用到的字形；给字体加 font-display: swap，让文字先用后备字体渲染。

/* 字体优化：swap 避免文字白屏，自托管避免第三方域名握手 */
@font-face {
  font-family: "Brand Sans";
  src: url("/fonts/brand-sans.woff2") format("woff2");
  font-display: swap;
  unicode-range: U+4E00-9FFF;
}

/* 预加载关键字体，减少发现延迟 */
<link rel="preload" href="/fonts/brand-sans.woff2" as="font"
      type="font/woff2" crossorigin>

判读方式：用 Chrome 开发者工具的 Network 面板过滤 Font，看字体请求的 Start Time。字体是后置发现的资源，如果它在 HTML 下载完成之后才开始请求，就白白浪费了几百毫秒。用 rel="preload" 提前发起请求能把这段时间省下来。

第三方脚本是另一个时间黑洞。统计、客服、广告、社交分享这些脚本通常来自外部域名，每一个都要单独做 DNS 解析和 TLS 握手，而且它们的加载完全不受你控制。

统计每个第三方脚本的实际耗时：

# 用 curl 分别测各第三方资源的连接与首字节耗时
for u in "https://analytics.example.com/t.js" \
         "https://widget.example.com/chat.js" \
         "https://ads.example.com/pixel.js"; do
  printf "%-50s " "$u"
  curl -s -o /dev/null -w "dns=%{time_namelookup}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s\n" "$u"
done

判读方式：任何一个第三方脚本的 TTFB 超过 500 毫秒，就应该考虑替换或延后加载。处理顺序是：先删掉没有实际用途的脚本，其次把非关键脚本延后到 load 事件后加载，最后对确实需要的做自托管或代理转发。自托管第三方脚本时要注意合规问题，部分服务条款不允许。

还有一个隐蔽的损耗：CSS 里的 @import 会让样式串行加载。多个 @import 叠加起来，渲染阻塞时间成倍增加。正确做法是把所有 @import 提到主 CSS 文件顶部合并，或者直接在 HTML 里用多个 <link> 并行引入。

<!-- 错误：CSS 内部 import 串行阻塞 -->
<link rel="stylesheet" href="/css/main.css">

<!-- 正确：多个 link 并行下载 -->
<link rel="stylesheet" href="/css/base.css">
<link rel="stylesheet" href="/css/components.css">

十一、实测工具：建立你的性能监控体系

单次手工测试只能告诉你现在的状态，建立不了趋势。真正的性能优化需要持续监控，指标变差时能第一时间发现。

延伸对照：ethernetservers 的公开机型与线路说明，可结合本节的判断标准自行核对。

常用的免费工具组合：命令行用 Lighthouse 做定期审计，用 WebPageTest 拿到多节点的加载过程瀑布图，用 Chrome DevTools Protocol 自己采集真实用户数据。免费的服务端方案有 Uptime Kuma（监控可用性）和 Beszel（监控资源占用）。

自己搭一套采集脚本，成本很低但价值很高：

#!/bin/bash
# 每 15 分钟采集一次站点性能，追加到 CSV 并在劣化时告警
URL="https://your-site.com"
OUT="/var/log/perf/metrics.csv"
mkdir -p "$(dirname "$OUT")"
[ -f "$OUT" ] || echo "timestamp,ttfb,fcp,load,ttfb_p90" > "$OUT"

for i in 1 2 3; do
  R=$(curl -s -o /dev/null -w "%{time_starttransfer},%{time_starttransfer},%{time_total}" "$URL")
  echo "$(date +%FT%T),$R" >> "$OUT"
  sleep 2
done

# 计算最近 20 次的 P90
P90=$(tail -20 "$OUT" | cut -d, -f2 | sort -n | awk '{a[NR]=$1} END{print a[int(NR*0.9)]}')
THRESHOLD=0.8
awk -v p="$P90" -v t="$THRESHOLD" 'BEGIN{
  if (p+0 > t+0) {
    print "性能劣化: P90 TTFB=" p "s 超过阈值 " t "s";
    exit 1
  }
  print "性能正常: P90 TTFB=" p "s"
}'

判读方式：看 P90 而不是平均值。平均 TTFB 300 毫秒但 P90 达到 2 秒，说明存在偶发严重慢请求，这往往比平均值高更值得排查。可用性监控要设成外部探测，因为服务器自己探测自己永远正常。

有了监控数据，优化就能按收益排序。以下是实测中常见的收益量级（基于常见站点类型的估算区间，具体收益需在自己的站点上实测确认）：

优化项	典型收益	实施成本	见效速度
开启 gzip 或 brotli	传输量降 60%–80%	很低，改几行配置	即时
图片转 WebP/AVIF 并按尺寸压缩	首屏图片体积降 50%–70%	低，批量脚本处理	即时
静态资源加指纹长缓存	回访用户 LCP 可降至 1 秒内	低，构建流程改动	即时
后端加缓存层	动态页面 TTFB 降 60% 以上	中，需要设计缓存键和失效	1–2 天
数据库补索引与消除 N+1	查询耗时降一个数量级	中，需代码与 SQL 改动	1–3 天
接入 CDN	静态资源取回时间降 70% 以上	中，需备案与配置	1–3 天
延后第三方脚本	INP 明显改善	低，改脚本加载时机	即时
更换服务器线路或升级配置	视原线路质量而定	高，需迁移与停机	3 天以上

这张表的用法很直接：先做成本低、见效快的三项（压缩、图片、缓存），它们通常能解决七成问题；再根据监控数据看瓶颈在哪一端，决定是加缓存层还是优化数据库；CDN 和换机器放在最后，因为它们成本和复杂度最高，收益也最依赖具体场景。

十二、常见问题

网站打开慢是不是服务器配置不够？ 不一定，先测 TTFB 再下结论。配置不足的典型特征是 TTFB 高且 CPU 使用率接近 100%，而 CPU 使用率只有百分之几但 TTFB 依然高，说明瓶颈在数据库查询、缓存缺失或外部接口调用上，这时候升级机器基本无效。

已经加了 gzip，为什么体积还是没变小？ 用 curl -I 看响应头有没有 Content-Encoding: gzip。没有的话通常是三个原因：gzip_min_length 阈值设得比文件还大；文件的 MIME 类型不在 gzip_types 列表里；或者你的文件本身已经是压缩格式（JPEG、PNG、ZIP），再压缩几乎没有收益。

缓存设置了但用户还看到旧内容？ 典型的缓存层级不一致问题。HTML 设了长缓存而 JS 设了短缓存或反过来，发布时就会出现新旧混用。正确做法是 HTML 用 no-cache 保证每次校验，静态资源用带指纹文件名加一年缓存，发布流程里两者一起生效。

图片已经压缩过了还需要优化吗？ 需要。「压缩过」通常指 JPEG 质量调到 75，而 WebP、AVIF 格式在同画质下还能再小 30% 到 50%，同时按实际显示尺寸提供多分辨率版本还能避免加载原图。另外给图片加上 width、height 属性解决布局偏移，这部分和压缩同样重要。

用了 CDN 为什么 TTFB 没降？ 先确认是否真的命中缓存，用 curl -I 看 X-Cache 或类似响应头。如果一直是 MISS，检查 URL 是否带了随机参数、时间戳这类导致缓存键每次都不同。同时注意 CDN 只能加速静态资源，动态请求仍然要回源，如果你的瓶颈在 PHP 或数据库，CDN 帮不上忙。

INP 很差但 LCP 正常，该怎么查？ 这说明首屏渲染没问题，但用户点击后响应慢，通常是主线程被长任务占住。在 Chrome 开发者工具的 Performance 面板录制交互过程，看红色长任务的分布，找出是哪个脚本在阻塞。常见原因是第三方脚本、未分片的大数据处理循环、或者主线程上的同步 XHR。

优化后为什么感觉没变快？ 很可能存在缓存混淆：你在测试时命中了浏览器缓存，看到的是旧版本；或者优化的是首屏之外的资源，而用户抱怨的是某个具体交互卡顿。要区分首屏慢和交互慢，前者看 LCP，后者看 INP。另外建议用真实用户监测数据验证，实验室数据和真实体验经常不一致。

哪些优化项目前不值得做？ 日访问量很低且图片为主的站点不必急着上 CDN，先做压缩和图片优化就能拿到大部分收益。反过来，PV 已经很大的站点如果还没做缓存分层，那是最该优先补的短板。另外，HTTP/2 和 HTTP/3 升级属于基础设施层面的事，多数站点开启服务器的 HTTP/2 支持即可，HTTP/3 的实际收益需要实测再决定。

该从什么时候开始做优化？ 站点有真实流量之后就开始，不要在零流量阶段做过度优化。优化前必须先建立监控基线，否则你无法判断哪些改动有效、哪些是白费功夫。优先级永远是：先测量、再定位瓶颈、然后按收益排序动手、最后持续监控防止退化。

服务端渲染和静态化应该选哪个？ 视页面类型决定。内容型页面（文章、商品详情、文档）适合静态化或增量静态生成，构建期就把 HTML 生成好，运行时零数据库开销，TTFB 能压到一百毫秒以内。交互型页面（搜索结果、个性化推荐、购物车）必须服务端渲染，此时更依赖缓存层和数据库优化。折中做法是把页面的静态外壳静态化、只对数据部分做客户端请求，这类架构的首屏快、交互也不至于空白。

预加载和预连接该怎么用？ 预连接 preconnect 用于提前完成目标域名的 DNS 和 TCP 握手，适合页面里有多个第三方域名的情况，一般只加两三个，多了反而浪费连接数。预加载 preload 用于提前拉取当前页面一定会用到的关键资源，比如首屏主图和主字体。用错了会有副作用：预加载了实际不用的资源会白白占用带宽，优先级还可能低于页面自身的资源。判断是否有效的方法是在 Network 面板看资源请求的 Priority 和 Start Time 字段。

需要定期做性能审计吗？ 建议每周一次自动审计并保留报告，历史数据能直接告诉你哪些指标在退化。审计要覆盖移动端和桌面端两套配置，因为两者的瓶颈常常不同：移动端受网络和图片影响大，桌面端更多是脚本执行和缓存策略问题。

飞翔声明：飞翔网登载此文出于传递更多信息之目的，并不意味着赞同其观点或证实其描述。