Cloudflare 性能优化教程｜2026最新版

Cloudflare 早已不只是一个“免费 CDN”。在 2026 年，Cloudflare 更像是一套面向网站、API、应用与边缘计算的性能与安全平台：它可以帮你做 DNS 加速、全球 CDN 缓存、图片优化、静态资源压缩、HTTP/3 传输、智能路由、DDoS 防护、Bot 管理、WAF 防护，甚至还可以通过 Workers 在边缘节点执行代码。

对于大多数网站来说，接入 Cloudflare 之后，最直接的收益是：访问速度更快、源站压力更小、抗攻击能力更强、全球用户体验更稳定。但如果只是简单把域名 NS 改到 Cloudflare，而不做系统化配置，很多性能潜力其实没有被释放出来。

本文将从基础配置、缓存策略、图片优化、协议优化、规则配置、源站优化、监控排错等方面，系统讲解 Cloudflare 的性能优化方法，适合个人博客、WordPress 网站、企业官网、跨境电商、SaaS 应用以及 API 服务参考。

一、Cloudflare 性能优化的核心思路

在开始具体配置之前，需要先理解 Cloudflare 的性能优化逻辑。

Cloudflare 的主要作用不是“让源站服务器本身变快”，而是通过以下方式提升整体访问体验：

1. DNS 更快
   Cloudflare 提供 Anycast DNS，全球解析速度通常较快，可以减少 DNS 查询耗时。

2. 静态资源就近缓存
   图片、CSS、JS、字体、视频片段等静态资源可以缓存在 Cloudflare 全球节点上，用户无需每次都访问源站。

3. 减少源站请求压力
   缓存命中率越高，回源请求越少，源站 CPU、带宽、数据库压力越低。

4. 优化网络传输协议
   支持 HTTP/2、HTTP/3、TLS 1.3、0-RTT 等现代协议，降低连接建立和传输成本。

5. 压缩与资源优化
   通过 Brotli、Auto Minify、图片压缩、Polish、Mirage 等功能减少传输体积。

6. 边缘规则精细控制
   使用 Cache Rules、Configuration Rules、Transform Rules、Origin Rules 等规则，对不同路径、文件类型、国家地区、设备类型进行差异化优化。

7. 智能流量调度
   付费方案可使用 Argo Smart Routing、Load Balancing 等功能，优化跨网络访问路径和多源站容灾。

简单来说，Cloudflare 优化的关键是：让能缓存的内容尽量在边缘节点返回，让不能缓存的动态请求尽量以更低延迟、更安全、更稳定的方式回源。

二、接入 Cloudflare 前的准备工作

在正式配置 Cloudflare 之前，建议先做好以下准备。

1. 确认网站架构

你需要明确自己的网站属于哪一种：

• 静态网站：HTML、CSS、JS、图片为主；
• WordPress / CMS 网站：有后台、有数据库、有动态页面；
• 电商网站：购物车、订单、支付等动态交互较多；
• API 服务：JSON、GraphQL、移动端接口；
• SaaS 应用：登录、控制台、实时数据较多；
• 文件下载站：大文件、软件包、压缩包等；
• 图片站 / 媒体站：图片、视频资源多。

不同类型的网站缓存策略完全不同。例如，静态网站可以尽量全站缓存；电商网站则要谨慎处理购物车、用户中心、订单页；API 服务通常需要根据接口类型判断是否缓存。

2. 检查源站性能

Cloudflare 可以显著改善边缘访问体验，但如果源站本身非常慢，动态请求依然会受到影响。建议先检查：

• 源站服务器 CPU、内存是否充足；
• 数据库查询是否过慢；
• PHP、Node.js、Java、Go 等应用服务是否稳定；
• 是否开启服务器端缓存；
• 静态资源是否合理分离；
• TLS 证书是否正常；
• 源站是否支持 HTTP/2；
• 源站防火墙是否允许 Cloudflare IP 回源。

3. 备份 DNS 记录

接入 Cloudflare 时，需要将域名 NS 修改为 Cloudflare 提供的名称服务器。修改前建议导出或截图原 DNS 记录，包括：

• A 记录；
• AAAA 记录；
• CNAME 记录；
• MX 邮件记录；
• TXT 记录；
• SPF、DKIM、DMARC；
• 子域名解析；
• 第三方服务验证记录。

特别注意：邮件相关记录不要随意代理。 邮件服务通常不应开启 Cloudflare 橙云代理，MX 指向的主机名也应保持 DNS Only。

三、DNS 优化：打好性能基础

Cloudflare DNS 是性能优化的第一步。虽然 DNS 查询只占一次访问中的很小部分，但对于全球访问、多子域名、移动网络用户来说，DNS 解析速度依然会影响首屏体验。

1. 开启代理模式

在 DNS 页面中，Cloudflare 记录通常有两种状态：

• Proxied：橙色云朵，流量经过 Cloudflare；
• DNS Only：灰色云朵，只做 DNS 解析，不经过 Cloudflare。

对于网站访问域名，例如：

example.com
www.example.com
static.example.com
api.example.com

通常可以根据业务需要开启 Proxied。开启后，Cloudflare 才能提供 CDN、WAF、缓存、压缩、协议优化等能力。

但以下记录建议保持 DNS Only：

mail.example.com
smtp.example.com
imap.example.com
ftp.example.com
部分验证用 CNAME/TXT

2. 合理设置子域名

建议将不同类型资源拆分到不同子域名，便于做独立规则：

www.example.com       主站
static.example.com    静态资源
img.example.com       图片资源
api.example.com       API 接口
download.example.com  下载资源

这样可以针对不同子域名设置不同缓存策略。例如，static.example.com 可以设置长缓存，api.example.com 则通常关闭缓存或只缓存特定 GET 接口。

3. 避免 DNS 记录冲突

常见错误包括：

• 同一个主机名同时配置 A 和 CNAME；
• 根域名 CNAME 配置不当；
• 邮件记录开启代理；
• 源站 IP 暴露在历史记录中；
• CDN 套 CDN 导致回源异常；
• IPv6 记录配置错误导致部分用户访问失败。

Cloudflare 支持 CNAME Flattening，可以让根域名使用类似 CNAME 的能力，但配置时仍要确保目标稳定可靠。

四、SSL/TLS 优化：安全与速度兼顾

TLS 配置错误是 Cloudflare 使用中最常见的问题之一。为了性能与安全，建议重点配置以下内容。

1. SSL 模式选择 Full 或 Full Strict

Cloudflare 的 SSL/TLS 加密模式常见有：

• Off；
• Flexible；
• Full；
• Full Strict。

生产环境强烈建议使用：

Full (Strict)

也就是浏览器到 Cloudflare、Cloudflare 到源站都使用 HTTPS，并且源站证书有效。

不要长期使用 Flexible 模式。Flexible 会导致 Cloudflare 到源站走 HTTP，容易出现：

• 后台登录异常；
• WordPress 无限重定向；
• Cookie Secure 问题；
• HSTS 配置冲突；
• 安全性不足。

如果源站没有证书，可以使用 Cloudflare Origin Certificate，也可以使用 Let’s Encrypt。

2. 开启 TLS 1.3

在 SSL/TLS 设置中，建议开启 TLS 1.3。TLS 1.3 相比 TLS 1.2 握手更快，安全性更高，对于移动网络、高延迟地区用户尤其有帮助。

3. 启用 HTTP/2 与 HTTP/3

建议开启：

HTTP/2：开启
HTTP/3：开启
QUIC：开启

HTTP/2 可以提升多资源并发加载效率，HTTP/3 基于 QUIC，在弱网、丢包、高延迟环境下通常表现更好。

不过需要注意，HTTP/3 的实际效果取决于浏览器、网络环境和运营商支持情况。开启通常没有坏处，但也应通过真实用户监控观察效果。

4. 谨慎使用 0-RTT

0-RTT 可以减少重复连接的握手延迟，但存在重放风险。对于普通静态网站可以考虑开启；对于涉及支付、下单、敏感 API 的网站，需要谨慎评估。

五、缓存优化：Cloudflare 性能提升的关键

缓存是 Cloudflare 性能优化中最重要的部分。缓存做得好，网站速度和源站稳定性都会明显提升；缓存做错，则可能导致用户看到旧内容、登录状态错乱、购物车异常等问题。

1. 理解缓存命中状态

通过浏览器开发者工具或 curl 查看响应头，可以看到类似信息：

cf-cache-status: HIT
cf-cache-status: MISS
cf-cache-status: BYPASS
cf-cache-status: DYNAMIC
cf-cache-status: EXPIRED
cf-cache-status: REVALIDATED

常见含义：

优化目标不是让所有请求都 HIT，而是让应该缓存的资源尽可能 HIT，同时避免动态内容被错误缓存。

2. 静态资源缓存策略

对于 CSS、JS、图片、字体等静态资源，建议设置较长缓存时间。

常见静态文件扩展名：

css, js, jpg, jpeg, png, gif, webp, avif, svg, ico, woff, woff2, ttf, eot, mp4, webm

推荐策略：

Browser Cache TTL：1个月到1年
Edge Cache TTL：1个月到1年

如果你的静态资源文件名带版本号，例如：

app.20260101.css
main.8f3a9c.js
logo.v2.webp

可以放心设置更长缓存，例如 1 年。更新资源时通过修改文件名解决缓存刷新问题。

3. HTML 页面缓存策略

HTML 页面是否缓存，需要根据网站类型决定。

静态网站

如果是纯静态网站，可以缓存 HTML：

Cache Everything
Edge Cache TTL：1小时到1天
Browser Cache TTL：几分钟到数小时

如果内容更新不频繁，也可以设置更长时间，并在发布时主动清理缓存。

WordPress 网站

WordPress 需要谨慎。可以缓存文章页、分类页、首页，但应排除：

/wp-admin/*
/wp-login.php
/cart*
/checkout*
/my-account*
/wp-json/*
带有登录 Cookie 的请求

对于 WordPress，建议配合页面缓存插件，例如：

• WP Rocket；
• LiteSpeed Cache；
• W3 Total Cache；
• FlyingPress；
• Cloudflare APO。

如果使用 Cloudflare APO，WordPress 的 HTML 缓存效果通常更好，适合博客、内容站、资讯站。

电商网站

电商网站不要简单开启全站 Cache Everything。必须排除：

/cart
/checkout
/order
/account
/user
/payment

同时要根据 Cookie 判断登录状态、购物车状态。缓存策略应以“商品详情页、分类页、静态资源”为主，交易流程页面不应缓存。

4. 使用 Cache Rules 替代旧 Page Rules

Cloudflare 新版更推荐使用 Cache Rules，而不是传统 Page Rules。Cache Rules 可以基于更多条件进行精细匹配，例如：

• Hostname；
• URI Path；
• Query String；
• Cookie；
• HTTP Method；
• File Extension；
• Country；
• Device Type；
• Request Header。

示例：缓存静态资源

If:
Hostname equals static.example.com
or File extension is css/js/png/jpg/webp/avif/svg/woff2

Then:
Cache eligibility: Eligible for cache
Edge TTL: 1 month
Browser TTL: 1 month

示例：排除后台和登录页

If:
URI Path starts with /wp-admin
or URI Path equals /wp-login.php

Then:
Bypass cache

示例：缓存匿名用户 HTML

If:
URI Path does not start with /wp-admin
and Cookie does not contain wordpress_logged_in

Then:
Cache eligible
Edge TTL: 1 hour

5. Query String 缓存策略

很多网站 URL 会带查询参数，例如：

/style.css?v=2026
/product?id=123
/article?utm_source=google

对于静态资源，?v=版本号 通常可以作为缓存区分依据；但对于 utm_source 这类营销参数，如果每个参数都生成一个缓存副本，会降低命中率。

建议：

• 静态资源保留版本参数；
• 页面 URL 尽量规范化；
• 对 UTM 参数做重定向或规则忽略；
• 避免无意义参数污染缓存。

六、压缩与前端资源优化

Cloudflare 可以帮助减少资源传输体积，但不能完全替代前端工程优化。

1. 开启 Brotli

Brotli 对文本资源压缩效果通常优于 Gzip，建议开启。适合压缩：

HTML
CSS
JavaScript
JSON
SVG
XML
字体文件

图片、视频、压缩包通常不需要重复压缩。

2. Auto Minify 谨慎开启

Auto Minify 可以压缩 HTML、CSS、JS，减少空格、注释和部分冗余字符。

建议：

• CSS 可以开启；
• HTML 可以开启；
• JS 谨慎开启。

因为部分复杂 JavaScript 经过自动压缩后，可能出现兼容性问题。如果你的网站已经通过 Vite、Webpack、Rollup、Terser 等工具构建压缩，Cloudflare Auto Minify 的收益有限，可以不开启或只开 HTML/CSS。

3. Rocket Loader 谨慎使用

Rocket Loader 会尝试延迟加载 JavaScript，以提升首屏渲染。但它可能影响：

• 表单；
• 统计代码；
• 广告脚本；
• 第三方登录；
• 支付组件；
• 复杂前端框架。

对于现代前端应用，如 Vue、React、Next.js、Nuxt、SvelteKit 等，通常不建议盲目开启 Rocket Loader。更推荐通过构建工具做代码分割、懒加载和预加载。

七、图片优化：提升首屏速度的重点

图片通常是网页体积最大的部分。Cloudflare 在图片优化方面提供多种能力，不同套餐可用功能有所差异。

1. 使用 WebP 和 AVIF

现代浏览器普遍支持 WebP，越来越多浏览器支持 AVIF。相比 JPEG、PNG，WebP 和 AVIF 在相似画质下体积更小。

推荐策略：

• 普通图片优先使用 WebP；
• 对体积要求更高的场景可使用 AVIF；
• 保留 JPEG/PNG 作为兼容备用；
• 图片文件名和缓存策略配合版本化。

2. Polish 图片优化

Cloudflare Polish 可以自动压缩图片，并在支持的浏览器中提供 WebP。适合图片较多的网站。

常见模式：

• Lossless：无损压缩；
• Lossy：有损压缩，体积更小；
• WebP：自动输出 WebP。

如果是摄影作品、设计作品、品牌图片，对画质要求较高，应谨慎使用 Lossy。普通博客、资讯、电商缩略图可以考虑有损压缩。

3. Mirage 与移动端优化

Mirage 主要用于移动设备和弱网环境，可以延迟加载图片、优化图片加载顺序。对于图片密集型页面可能有帮助。

但如果你的网站已经实现了：

并且前端已经做好响应式图片，例如：

那么 Mirage 的提升可能有限。

4. Cloudflare Images 与 Image Resizing

对于图片业务较重的网站，可以考虑使用 Cloudflare Images 或 Image Resizing，实现：

• 图片上传；
• 自动缩放；
• 格式转换；
• 质量控制；
• 按设备输出不同尺寸；
• 边缘缓存。

例如电商商品图、用户头像、文章封面、图库网站，都适合使用按需裁剪和尺寸优化。

八、Argo Smart Routing 与全球访问优化

如果你的网站面向全球用户，尤其是跨境电商、海外 SaaS、国际内容站，可以考虑开启 Argo Smart Routing。

Argo 的作用是通过 Cloudflare 的网络数据，选择更快、更稳定的路径回源，减少跨运营商、跨地区网络抖动。

适合场景：

• 源站在美国，用户分布在亚洲、欧洲；
• 源站在新加坡，用户访问来自全球；
• API 请求不能缓存，但需要降低延迟；
• 动态请求较多；
• 跨境网络质量不稳定。

需要注意：Argo 是付费功能，并不是所有网站都必须开启。如果你的网站大部分请求都能命中边缘缓存，Argo 的收益可能有限；如果动态请求占比高，Argo 的价值会更明显。

九、源站优化：Cloudflare 之外同样重要

很多人误以为用了 Cloudflare 就不需要优化源站，这是错误的。Cloudflare 能缓存静态内容，但动态页面、登录请求、后台操作、API 调用仍然依赖源站。

1. 开启源站缓存

不同技术栈可以使用不同缓存：

• Nginx FastCGI Cache；
• LiteSpeed Cache；
• Redis Object Cache；
• Varnish；
• Node.js 内存缓存；
• 数据库查询缓存；
• 应用级页面缓存。

对于 WordPress，建议至少使用：

• 页面缓存；
• 对象缓存；
• 数据库优化；
• 图片懒加载；
• 减少插件数量。

2. 优化数据库

动态网站慢，很多时候不是 CDN 问题，而是数据库慢。建议关注：

• 慢查询；
• 索引是否合理；
• 无用数据表；
• 自动草稿和修订版本；
• 大量插件写入；
• 评论垃圾数据；
• WooCommerce 订单表压力。

3. 源站只允许 Cloudflare 回源

为了安全和性能，建议源站防火墙只允许 Cloudflare IP 访问 80/443 端口，避免攻击者绕过 Cloudflare 直接打源站。

同时可以配置：

• Authenticated Origin Pulls；
• Cloudflare Origin Certificate；
• WAF 规则；
• Rate Limiting；
• Bot Fight Mode 或 Bot Management。

4. 合理设置源站响应头

Cloudflare 的缓存策略会受到源站响应头影响，例如：

Cache-Control
ETag
Last-Modified
Expires
Vary

建议静态资源设置：

Cache-Control: public, max-age=31536000, immutable

动态页面设置：

Cache-Control: no-cache

需要禁止缓存的页面设置：

Cache-Control: private, no-store

如果源站响应头混乱，Cloudflare 缓存行为也可能不符合预期。

十、规则配置最佳实践

Cloudflare 规则系统越来越强大，合理使用规则可以大幅提升性能和可维护性。

1. 静态资源长缓存规则

条件：
File extension in css, js, png, jpg, jpeg, webp, avif, svg, ico, woff, woff2

动作：
Cache eligible
Edge Cache TTL: 1 month 或 1 year
Browser Cache TTL: 1 month 或 1 year

2. 后台路径跳过缓存

条件：
URI Path starts with /admin
or URI Path starts with /wp-admin
or URI Path equals /wp-login.php

动作：
Bypass cache
Disable performance features if necessary

3. API 接口不缓存

条件：
Hostname equals api.example.com
or URI Path starts with /api

动作：
Bypass cache

如果有公开 GET 接口可以缓存，例如文章列表、商品列表，可以单独创建更精细规则。

4. 下载资源缓存

条件：
URI Path starts with /downloads
or File extension in zip, tar, gz, dmg, exe, apk

动作：
Cache eligible
Edge Cache TTL: 1 week 或 1 month

5. 国家和地区差异化

如果某些地区访问源站较慢，可以针对国家/地区启用更激进的缓存策略。但要注意不要影响登录和个性化内容。

十一、WordPress 网站 Cloudflare 优化方案

WordPress 是 Cloudflare 用户中非常常见的类型。这里给出一个较稳妥的配置方案。

1. 基础设置

SSL/TLS：Full Strict
Always Use HTTPS：开启
HTTP/2：开启
HTTP/3：开启
Brotli：开启
Auto Minify：HTML/CSS 可开启，JS 谨慎
Rocket Loader：默认关闭

2. 缓存规则

静态资源长缓存：

/wp-content/uploads/*
/wp-content/themes/*
/wp-content/plugins/*

后台跳过缓存：

/wp-admin/*
/wp-login.php
/wp-json/*
/xmlrpc.php

如果使用 WooCommerce，继续排除：

/cart*
/checkout*
/my-account*
/wc-api/*

3. 推荐插件配合

可以选择：

• Cloudflare 官方插件；
• WP Rocket；
• LiteSpeed Cache；
• FlyingPress；
• Redis Object Cache。

如果预算允许，可以考虑 Cloudflare APO。APO 对 WordPress HTML 页面缓存比较友好，尤其适合文章站、博客、内容站。

十二、API 服务优化方案

API 服务与普通网站不同，不能简单追求缓存命中率。

1. 根据接口类型分类

API 可以分为：

• 公开 GET 接口：可缓存；
• 用户相关接口：不缓存；
• 写操作接口：不缓存；
• 实时数据接口：谨慎缓存；
• 配置类接口：可短时间缓存。

例如：

GET /api/posts
GET /api/products
GET /api/categories

可以缓存 30 秒到几分钟。

而以下接口不应缓存：

POST /api/login
POST /api/order
GET /api/user/profile
GET /api/cart
POST /api/payment

2. 使用 Cache-Control 控制

API 响应可以明确返回：

Cache-Control: public, max-age=60

或：

Cache-Control: private, no-store

让 Cloudflare 和客户端都能正确理解缓存意图。

3. 开启速率限制

API 容易被刷，可以使用：

• Rate Limiting；
• WAF Custom Rules；
• Bot Management；
• Turnstile；
• mTLS；
• API Shield。

性能优化不只是让请求更快，也包括减少恶意请求和无效请求。

十三、常见问题与排查方法

1. 为什么 cf-cache-status 一直是 DYNAMIC？

可能原因：

• 请求是 HTML 动态页面；
• 没有设置 Cache Everything；
• 源站返回 no-cache；
• 请求带有 Cookie；
• 使用了 POST 方法；
• 规则没有匹配；
• 文件扩展名不在默认缓存列表。

解决方法是检查 Cache Rules、响应头和请求路径。

2. 为什么开启 Cloudflare 后网站变慢？

可能原因：

• 源站到 Cloudflare 回源慢；
• 缓存命中率低；
• SSL 模式配置错误；
• 套了多个 CDN；
• Rocket Loader 影响 JS；
• WAF 规则过重；
• 源站阻止了 Cloudflare IP；
• 某些地区到 Cloudflare 节点路由不佳。

建议使用 WebPageTest、Chrome DevTools、Cloudflare Analytics、服务器日志一起排查。

3. 为什么更新内容后用户看到旧页面？

这是缓存未清理或 TTL 过长导致的。解决方式：

• 手动 Purge Cache；
• 按 URL 清理缓存；
• 发布时调用 API 清理；
• 静态资源使用版本号；
• HTML 设置较短 Edge TTL；
• 合理配置 Cache-Control。

4. 为什么后台登录异常？

常见原因：

• Flexible SSL 导致重定向循环；
• 后台页面被缓存；
• Rocket Loader 影响脚本；
• WAF 拦截登录请求；
• Cookie 被错误处理；
• WordPress 地址配置不一致。

建议后台、登录、用户中心一律跳过缓存，并使用 Full Strict SSL。

十四、性能测试与监控

优化不能只靠感觉，必须通过数据验证。

1. 推荐测试工具

可以使用：

• Google PageSpeed Insights；
• Lighthouse；
• WebPageTest；
• GTmetrix；
• Chrome DevTools；
• Cloudflare Analytics；
• Cloudflare Observatory；
• Real User Monitoring；
• 服务器访问日志；
• APM 工具，如 New Relic、Datadog、Grafana。

2. 重点关注指标

核心指标包括：

Cloudflare 优化通常最直接影响 TTFB、资源加载时间、带宽消耗和源站请求量。LCP、INP、CLS 还需要结合前端代码、图片尺寸、字体加载、JS 执行等一起优化。

十五、2026 年推荐配置清单

下面给出一套通用配置清单，适合作为起点。

基础配置

DNS：网站域名开启 Proxied
SSL/TLS：Full Strict
Always Use HTTPS：开启
TLS 1.3：开启
HTTP/2：开启
HTTP/3：开启
Brotli：开启
IPv6 Compatibility：开启

缓存配置

静态资源：Edge TTL 1个月到1年
HTML 页面：根据业务决定是否缓存
后台/登录/用户中心：Bypass Cache
API：默认 Bypass，公开 GET 接口可短缓存
图片资源：长缓存并启用现代格式

图片配置

优先使用 WebP/AVIF
图片懒加载
响应式图片
必要时启用 Polish / Image Resizing

WordPress 配置

使用 Full Strict
后台跳过缓存
静态资源长缓存
配合缓存插件
可考虑 APO
WooCommerce 必须排除购物车和结账页

安全与源站

源站只允许 Cloudflare IP
开启 WAF
配置 Rate Limiting
开启 Authenticated Origin Pulls
定期检查源站日志

十六、总结

Cloudflare 性能优化并不是打开几个开关就结束，而是一套系统工程。真正有效的优化，需要同时处理 DNS、TLS、缓存、图片、前端资源、源站性能、安全规则和监控分析。

对于大多数网站，优化优先级可以按以下顺序执行：

1. 正确接入 Cloudflare，并使用 Full Strict SSL；
2. 开启 HTTP/2、HTTP/3、TLS 1.3、Brotli；
3. 为静态资源设置长缓存；
4. 为动态页面、后台、登录、购物车设置缓存排除；
5. 优化图片格式、尺寸和懒加载；
6. 检查源站响应头和服务器性能；
7. 使用规则精细控制不同路径；
8. 通过数据监控缓存命中率、TTFB 和核心 Web 指标；
9. 根据业务需要启用 APO、Argo、Image Resizing 等高级功能。

如果你是个人博客或内容站，重点应放在 HTML 页面缓存、图片优化和静态资源长缓存上；如果你是电商网站，重点应放在商品页缓存、交易流程排除、图片压缩和源站稳定性上；如果你是 API 或 SaaS 服务，重点应放在协议优化、动态请求延迟、安全防护和速率限制上。

最终目标不是盲目追求所有请求都缓存，而是做到：静态内容尽量边缘返回，动态内容稳定快速回源，敏感内容绝不错误缓存，源站压力持续降低，用户体验持续提升。