About the client
We build and maintain a content-heavy web app for an agency client. Editors publish long buying guides in a headless CMS, and each guide carries dozens of products with their own photos and details. Monthly visits hover around 500K, from more than 160 countries. Most readers arrive from Google, and more than half of them are on their phones.
The challenge
A growing audience meant a growing bill.
Every page is put together from CMS content: the guide, the products in it, and the menus and footer around it. Each visit asked the CMS for that content again and loaded the images from the CMS’s own CDN. The CMS bills for bandwidth, so the bill grew with the audience. It usually ran to a few hundred dollars a month, and in busy months it went past $1,000. Yup, we are talking about terabytes of data.
The pages were heavy too, and the server built each one from scratch on every visit. Readers had to wait for it, and every traffic peak landed directly on the server.
The solution
Doing more with Cloudflare.
The site has run on Cloudflare from the start, and as traffic grew we moved more of the work onto it. Cloudflare runs data centers all over the world and can keep copies of content in each of them, so a reader gets a page from a location near them instead of from one server far away. Hosting, data storage, image resizing and protection for the staging site now all run on that one platform, which costs a fraction of what the CMS charged for bandwidth.
What we did
01
Content stored at the edge
CMS content is kept in Cloudflare’s storage and read from there. The CMS is only asked again when an editor publishes a change.
02
Images resized by Cloudflare
Cloudflare resizes every image to fit the reader’s screen, converts it to a lighter format and keeps the result in its cache. Repeat views come from that cache, so the CMS’s CDN is asked far less often.
03
Whole pages served from the edge
Finished pages are cached across Cloudflare’s network, and a cached page reaches the reader from a nearby data center without touching the server. When an editor publishes, the site works out which pages use the changed content and refreshes only those, shortly after the change goes live.
Performance
Faster and steadier.
Because the cache is spread across Cloudflare’s network, cached pages, images and scripts come from a data center close to each reader. Traffic peaks are absorbed the same way. A busy day sends more requests to Cloudflare, while the server and the CMS only see the requests the cache can’t answer.
Workflow
Built to change safely.
Development, staging and production are separate environments, and every new feature gets its own preview link. Staging is protected with Cloudflare Access, and QA and UAT happen there before each release reaches production. The site is built with Next.js and React and deployed to Cloudflare Pages, so the same platform runs the app and its cache.
Security
Security at the edge.
Cloudflare’s bot protection is on for the live site, so bad bots are challenged or blocked before they reach the app, while search engine crawlers such as Google’s still get through. Development and staging sit behind Cloudflare Zero Trust. Only approved people can open them after signing in, and automated tests get in with their own service token. Unfinished work stays private, and the test environments stay out of search results.
Results
90+
Lighthouse performance score
~3 of 4
requests are served by the cache
ms
To deliver a cached page, down from seconds
01
Minimized expenses
The CMS now runs on a smaller plan, and Cloudflare costs a fraction of what we used to pay for bandwidth. Before, the CMS alone cost a few hundred dollars a month and once went past $1,000.
02
Maximized performance
In our tests, a cached page reaches the browser in milliseconds instead of seconds, and the Lighthouse performance score moved into the 90s. Cloudflare’s cache holds tens of gigabytes of images and scripts and answers nearly three out of four requests for them.
