This is post number 8 in my 100 Days To Offload challenge. View all posts or subscribe via RSS.

Today I caught up for coffee with a good friend, Renlord. He’s convinced me to move this blog to Cloudflare Pages.

Earlier in the year, I wrote about migrating to Vercel to improve performance by caching my blog at the “edge”.

Vercel is great, and feels pretty seamless to use. I can push commits and see them deployed in about close to a minute, and load times are fast no matter where you are.

From an integration perspective, Cloudflare Pages and Vercel are quite similar. You authenticate with GitHub, choose the repositories you want to share, and Cloudflare Pages will pick up on your static site generator (in my case, hugo), and offer a build command.

Where I think Cloudflare Pages shines is in further optimisation of content being served. When adding a custom domain to Cloudflare, you can enable auto minification of files JavaScript, CSS, and HTML, turn on Brotli compression 1.

Lighthouse performance on web.dev seems to be equivalent between both services, but there’s a noticeable difference when loading from the local PoP2.

Here is performance from my browser via Vercel: Lighthouse performance for Vercel

Here is the same test against, but against Cloudflare Pages: Lighthouse performance for Cloudflare Pages

We save about 0.2s on a few metrics, which isn’t bad!

Now, I know what you’re thinking, this is total overkill for a static site, and there’s no noticeable performance improvement moving from Vercel to Cloudflare Pages for the average website. That’s true. I just like improving performance and playing with new technology/services at the same time. This was a great way to spend a few hours this afternoon.

Expect a follow-up post on using Cloudflare Tunnel to proxy traffic to my home Kubernetes cluster.

This post was not sponsored by Cloudflare.

  1. You can read more about this here. ↩︎

  2. A PoP is a Point of Presence. Cloudflare has a page dedicated to their network here. ↩︎