目录

如何免费使用 Cloudflare R2 对象存储以提升网站加载速度

使用 Cloudflare R2 + Worker 承载图片资源,并通过 CDN 强缓存分发,减少服务器压力,让 WordPress 网站在图片增多后依然保持稳定的加载性能。

如果你的网站图片多、文章多、页面越来越重,那你迟早会遇到一个问题:

服务器不慢,但图片拖慢了一切。

尤其是 WordPress 站点,wp-content/uploads 目录一大,哪怕你服务器性能不错,首屏和 LCP 也会被图片狠狠拖住。

这篇文章,我会分享这样一套方法:

Cloudflare R2 + Worker + CDN 强缓存

利用 Cloudflare 给的“免费额度”,把图片请求从服务器上彻底拿走,从而提升网站性能。

一、为什么“图片”才是性能瓶颈?

在大多数内容型网站里:

  • HTML:几十 KB
  • CSS / JS:可压缩、可合并
  • 图片:几百 KB~几 MB,且数量多

而 WordPress 默认的图片路径是:/wp-content/uploads/年/月/xxx.webp

问题在于:

  • 每张图片都要命中服务器
  • 高并发时服务器 I/O 被图片拖垮
  • 即使开了页面缓存,图片依然是独立请求

所以,真正有效的优化,一定是:让图片彻底不再访问你的服务器。

二、Cloudflare R2 是什么?为什么说“有羊毛”

简而言之:R2 是 Cloudflare 提供的对象存储,专为 CDN 场景设计。它和 S3 很像,但有一个关键区别:R2 出站流量不收费。

这就意味着:

  • 图片放在 R2
  • 用户从 Cloudflare CDN 节点取
  • 你不为流量付钱

而且 Cloudflare 还给了免费存储额度(10GB 起)和免费 Workers 调用额度,对中小站点、博客、企业官网来说,完全够用。

三、最终架构长什么样?

在动手之前,先明确目标架构:

				
					用户浏览器
    ↓
img.yoursite.com(Cloudflare CDN)
    ↓
Cloudflare Worker
    ↓
Cloudflare R2
(仅首次)

				
			

关键点:

  • 图片使用独立子域(如 img.example.com
  • Worker 只负责“取对象 + 设置缓存头”
  • CDN 强缓存 1 年,不回源

四、前置条件

在开始之前,你需要确认 4 件事:

(1) 域名已接入 Cloudflare

免费计划即可,NS 指向 Cloudflare 就够了,不需要 Pro。

(2) 图片 URL 是稳定的

也就是说,图片是:

  • 不带 token
  • 不带签名
  • 不会频繁变更内容

例如这是好 URL:/images/wp/2024/04/example.webp

(3) 图片允许被 CDN 强缓存

你不会打算:

  • 每天替换同一个图片文件
  • 用同一个 URL 承载不同内容

(4) 图片与用户身份无关

图片是公共资源,不涉及权限判断。

五、开始设置

Step 1:创建 R2 Bucket

(1) 登录 Cloudflare Dashboard,点击在左侧边栏快速搜索并搜索 R2 ,并选择“R2对象存储”。

(2) 创建一个存储桶,自定义一名名称,例如:site-images。

**注意:Cloudflare会要求先绑定一个付款方式(例如信用卡),否则将无法创建存储桶。R2 对象存储有10 GB 免费存储额度,对于大部分中小站已经够用了,超出部分会从绑定的信用卡自动扣款,收费标准以 Cloudflare 公示为准。

(3) 添加目录,并构建一个目录结构,例如我构建的结构是 wp-content/images/xxxxxx.webp,并从本地上传图片。**注意:图片文件名不要包含中文及空格,最好仅包含英文格式的字母、数字、横线

Step 2:创建 Cloudflare Worker

(1) 在 Cloudflare Dashboard 左侧边栏搜索 Worker,选择 Workers & Pages,并 Create Application

(2) 选择 Start with Hello World,为这个 Worker 命名,并点击部署

Step 3:绑定 R2 Bucket 到 Worker

(1) 点击 Add binding ,选择 R2 bucket,点击 按钮 Add binding

(2) 在右侧边栏会滑出一个对话框,创建一个 Variable name(例如 images),并选择之前我们已经创建的 R2 bucket,点击最下方的按钮 Depoly

(3) 点击右上角 Edit code

将下面这段代码粘贴进去:

				
					export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const key = url.pathname.replace(/^\/+/, ""); 

    if (!key) return new Response("No object specified", { status: 400 });

    const obj = await env.images.get(key);
    if (!obj) return new Response("Not Found", { status: 404 });

    return new Response(obj.body, {
      headers: {
        "Content-Type": obj.httpMetadata?.contentType || "application/octet-stream",
        "Cache-Control": "public, max-age=31536000, immutable",
      },
    });
  },
};
				
			

(4) 测试:

  • 在 Cloudflare Dashboard 左侧边栏进入 Workers & Pages 并找到你的 Worker 的链接。
  • 在 Cloudflare Dashboard 左侧边栏 R2 object storage – Overview 并随意找一张图片,找到这张图片的 path。
  • 将两者结合起来,例如:https://bdwebtek-img.dannnii0722.workers.dev/wp-content/images/cf-1-search-r2.webp
  • 可以在浏览器显示图片即表示成功

Step 4:绑定到二级域名

(1) 进入 Worker,找到右边的 Connect a custom domain 后:

  • 点击 Add
  • 选择 Custom domain
  • 填入一个二级域名:img.yourdomain.com
  • 看到 Cloudflare 自动跳出来的提示后,点击最下方 Add domain,Cloudflare 会自动帮你处理证书(HTTPS)。

(2) 获取图片 URL 并在网站上使用:

  • 在 Cloudflare Dashboard 左侧边栏,进入 R2 object storage,在目录下找到图片的 path,例如  images/wp/cf-1-search-r2.webp
  • 在图片的 path 前加上自定义的二级域名,组合成一个完整的图片 URL,例如:https://img.yourdomain.com/images/wp/cf-1-search-r2.webp,将这个完整的图片 URL 插入网站即可使用

六、总结

通过 Cloudflare R2 + Worker + CDN 强缓存这一套:

  • 图片不再命中服务器
  • 页面缓存和图片缓存彻底解耦
  • 并发上来时,服务器压力不会线性增长
  • LCP、首屏速度的瓶颈被移走

更重要的是,这套方案不是插件技巧,也不是 WordPress 专属优化,而是一套通用的架构思路。对中小站点来说,Cloudflare 给出的免费额度,已经足够你把图片这个性能变量控制住。

如果你的网站还在增长、文章还在增加,那么越早把图片从服务器中剥离出来,后面遇到的问题就越少。

七、最后的一些实际建议

1. 对已经有一定 SEO 成效的老站点,不建议一次性、大规模迁移图片

如果你的网站已经有稳定的搜索流量、图片本身也在参与排名(尤其是 Google Image、Discover 或长尾搜索),一次性替换大量图片 URL,本质上等于对搜索引擎发起了一次「资源结构重建」。

即便页面本身不变,搜索引擎也需要重新抓取、重新理解图片资源之间的关系,这在短期内有可能对 SEO 表现产生波动。

更稳妥的方式是:

  • 新文章、新页面优先使用 R2 图片
  • 老文章逐步替换,而不是“一刀切”
  • 或者仅迁移体积大、访问频繁的图片资源

2. 新站点可以毫无心理负担地从一开始就使用这套方案

如果你的网站还在早期阶段,页面数量不多、URL 结构尚未被搜索引擎“记住”,
那直接把图片放在 R2 + Worker + CDN 上,反而是一个非常干净、长期友好的选择。

你等于从第一天起就避免了:

  • 图片请求拖慢服务器
  • 后期再迁移图片带来的结构调整
  • 因图片增长导致的性能退化

从长期维护角度看,这是一次到位的方案。

3. 并不一定要把“所有图片”都放进 R2

这套方案的目标,是解决真正的性能瓶颈,而不是追求“技术上看起来最极致”。

在实际使用中,可以根据情况取舍:

  • 文章内容图、产品图、展示图 → 非常适合放 R2
  • 后台上传频繁、临时性强的图片 → 未必值得迁移
  • 小体积、低访问频率的图片 → 性能收益可能并不明显

是否迁移,应该综合考虑:

  • 操作成本
  • 维护复杂度
  • 实际访问量
  • 性能收益是否足够明显

技术方案的价值,从来不在于“能不能做”,而在于“值不值得做”。

author avatar
Danny SEO
Danny Ni是一位经验丰富的SEO专家,专注于WordPress和数字营销。目前,他在一家公司负责SEO优化、网站开发,并兼顾多个社交媒体平台的管理。凭借在SEO、WordPress和数字营销方面的专业知识,Danny Ni帮助企业提升在线曝光度,拓展数字业务。

Share on:

Share on: