网站速度优化实践：CDN + 缓存策略最佳配置指南

网站速度优化实践：CDN + 缓存策略最佳配置指南

网站加载速度直接影响用户体验、SEO 排名和转化率。数据显示，页面加载时间每增加 1 秒，转化率平均下降 7%。本文将分享经过多个项目验证的 CDN + 缓存优化方案。

一、性能基线测量

在开始优化前，先建立性能基线：

核心 Web 指标（Core Web Vitals）

测量工具

• Lighthouse：Chrome DevTools 内置，给出具体优化建议
• PageSpeed Insights：Google 官方工具，模拟真实用户环境
• WebPageTest：多地点、多设备测试
• GTmetrix：可视化性能报告

二、CDN 优化策略

2.1 选择合适的 CDN 配置

# Nginx 配置片段 - 针对 CDN 优化
# 开启 Brotli 压缩（比 Gzip 压缩率高 20-30%）
brotli on;
brotli_types text/plain text/css application/javascript application/json image/svg+xml;

# 设置缓存头
location ~* \.(jpg|jpeg|png|gif|ico|webp|svg)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
    add_header Vary "Accept-Encoding";
}

location ~* \.(css|js)$ {
    expires 7d;
    add_header Cache-Control "public, immutable";
}

location / {
    # HTML 不缓存或短时间缓存
    add_header Cache-Control "no-cache, must-revalidate";
}

2.2 缓存层级优化

合理的缓存策略需要多个层级配合：

浏览器缓存 → CDN 边缘节点缓存 → CDN 中间层缓存 → 源服务器
    ↓              ↓                    ↓                ↓
  短期缓存      长期缓存             短期缓存         实时数据

层级说明：

1. 浏览器缓存：通过 Cache-Control 和 Expires 头控制
2. CDN 边缘节点：离用户最近的节点，存储热数据
3. CDN 中间层：回源前的缓存层，减少源站压力
4. 源服务器：最新数据的源头

2.3 CDN 预热

大更新后，提前通知 CDN 将内容缓存到边缘节点：

# Cloudflare 预热（通过 Cache Rules）
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache" \
  -H "Authorization: Bearer {token}" \
  -H "Content-Type: application/json" \
  --data '{"prefixes":["https://example.com/assets/"]}'

三、缓存策略细节

3.1 静态资源缓存策略

3.2 动态内容缓存

对于 API 响应，使用 CDN 缓存需要注意：

# 带认证的请求不缓存
location /api/ {
    if ($http_cookie ~* "session|token") {
        set $no_cache 1;
    }
    proxy_no_cache $no_cache;
    proxy_cache_bypass $no_cache;
}

# 对公开 API 设置短缓存
location /api/public/ {
    add_header Cache-Control "public, max-age=60";
}

四、图片优化（最关键）

图片占网页总大小的 60-70%，优化图片是性价比最高的加速手段：

4.1 图片格式选择

4.2 图片 CDN 处理

使用 CDN 的图片处理功能：

<!-- Cloudflare Image Resizing -->
<img src="/cdn-cgi/image/width=800,quality=80,format=auto/photo.jpg" />

<!-- 阿里云图片处理 -->
<img src="/photo.jpg?x-oss-process=image/resize,w_800/quality,q_80/format,webp" />

4.3 懒加载

<!-- 原生懒加载（现代浏览器） -->
<img src="photo.jpg" loading="lazy" alt="..." />

<!-- 结合 Intersection Observer -->
<img data-src="photo.jpg" class="lazy" alt="..." />

五、性能优化进阶

5.1 HTTP/2 与 HTTP/3

• HTTP/2：多路复用、头部压缩、服务器推送
• HTTP/3：基于 QUIC 协议，连接建立更快、弱网环境更稳定

确保 CDN 和源服务器都开启 HTTP/2/3：

# Nginx 配置
listen 443 ssl http2;
listen 443 quic reuseport;

5.2 资源合并与压缩

将多个小文件合并，减少 HTTP 请求数：

# 合并 CSS
cat reset.css layout.css style.css > combined.css

# 使用构建工具（Webpack/Vite）自动完成

5.3 预加载关键资源

<!-- 预加载关键 CSS -->
<link rel="preload" href="critical.css" as="style" />

<!-- 预加载字体 -->
<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin />

<!-- 预连接第三方域名 -->
<link rel="preconnect" href="https://fonts.googleapis.com" />

5.4 一个真实的调优案例

某个资讯站首页有大量图片和接口请求，最初缓存命中率只有约 55%，首屏 LCP 在 4 秒左右。团队按下面的顺序调整：先给所有图片加 Cache-Control: public, max-age=31536000, immutable 并做 URL hash，图片命中率升到 98%；再给资讯列表接口设置 max-age=60 的短缓存，并加上 s-maxage 让 CDN 缓存、浏览器不缓存；最后把热门频道的 HTML 在 CDN 缓存 5 分钟。两周后 LCP 降到 1.8 秒，回源流量减少约 70%。这个案例里没有高深技巧，关键是区分"该缓存的"与"不能缓存的"，并给每类资源一个明确的 TTL。

六、常见问题

命中率很高但页面还是很慢？

命中率高只说明边缘返回缓存的比例高，不代表字节量小。如果大图没压缩、HTML 里有大量同步脚本，首屏依然会慢，要把命中率和资源体积、TTFB 放在一起看。

HTML 到底该不该缓存？

公开且更新不频繁的页面可以缓存几十秒到几分钟；登录态、购物车这类个性化页面不能缓存，或要用 Cache Key 区分用户。

改版后用户为什么还看到旧页面？

资源 URL 没变时浏览器和 CDN 会一直用旧缓存。发布时给文件名加 hash（如 app.8f3c.css），或主动清除 CDN 缓存。

缓存与 SEO 冲突吗？

不冲突。缓存的只是响应副本，不影响内容抓取；只要正确返回 200/304 且不缓存认证页面即可。

七、移动端优化

移动端网络环境更复杂，需要额外优化：

1. AMP（Accelerated Mobile Pages）：Google 的移动端加速方案
2. PWA（Progressive Web App）：离线缓存 + 快速加载
3. 响应式图片：根据屏幕尺寸加载不同大小图片
4. 减少第三方脚本：第三方脚本是移动端性能杀手

八、性能优化检查清单

• 启用 CDN 并正确配置缓存
• 图片使用 WebP/AVIF 格式
• 开启 Brotli/Gzip 压缩
• 启用 HTTP/2 或 HTTP/3
• 资源文件带版本号或 hash
• 关键 CSS 内联加载
• 非关键资源异步加载
• 使用资源提示（preload/preconnect）
• 启用浏览器缓存
• 移除未使用的 CSS/JS
• 减少重定向
• 优化 TTFB（首字节时间）

九、总结

网站速度优化是一个持续的过程，不是一次性工作。CDN + 缓存 + 图片优化是投入产出比最高的三项优化措施，通常可以在短时间内看到显著效果。建议定期使用 Lighthouse 检测性能得分，持续迭代优化。

参考：MDN HTTP 缓存文档 https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching；Cloudflare Cache Rules 文档 https://developers.cloudflare.com/cache/how-to/cache-rules/