Craft CMS and Core Web Vitals: What Slows Sites Down and What It Costs You in Search
Poor Core Web Vitals scores on a Craft CMS site directly affect search rankings. Here is what causes them and what is involved in fixing them.
We see the same thing on a lot of the ExpressionEngine and Craft sites we take on. Cloudflare is switched on, someone set it up a year or two ago, and it is doing almost none of what it was meant to do. Pages are not being served any faster, the security settings are on their defaults, and nobody has looked at it since.
The assumption is that an account plus a domain pointed at Cloudflare means it is working. On a content-managed site there is a configuration step after that, and it is often the step that gets skipped. When it does, you are paying the setup cost and getting none of the return.
What Cloudflare is meant to do
Cloudflare sits between your visitors and your web server. Configured properly, it does four things that matter to a business-critical site.
- Faster pages. It keeps copies of your pages in data centres around the world and serves them from the one nearest each visitor, without the request reaching your server. This is one of the levers in a wider Core Web Vitals improvement.
- Less load on your hosting. When most page views are answered by Cloudflare, your server handles a fraction of the traffic it did before.
- Protection. It filters out a large amount of automated attacks, scrapers, and junk traffic before any of it reaches the site.
- Staying up under pressure. If you get a sudden spike, a marketing campaign, a press mention, or a deliberate attack, Cloudflare absorbs most of it and the site stays up when it would otherwise fall over.
Cloudflare lowers the volume of malicious traffic hitting the site. It does not patch the CMS for you, and an out-of-date ExpressionEngine or Craft core is still the bigger exposure, but it takes a lot of the daily noise off the table.
Why it often does nothing on a CMS site
A plain brochure site can be handed to Cloudflare with caching turned up and left alone. A site run through ExpressionEngine or Craft is different. Most pages have logic behind them, and some of them must never be cached or shown to more than one visitor. A contact form, a logged-in account area, a basket page: these have to be built fresh every time.
So Cloudflare has to be told which pages are safe to cache and which are not. There is also a problem specific to these platforms. Out of the box, ExpressionEngine tells every browser not to cache the page, through a couple of headers it sends automatically. Cloudflare reads those headers and decides the page is not cacheable, so it stores nothing, even when the caching rules look right. Craft and Laravel applications have their own versions of the same issue.
The result is a site with Cloudflare in front of it, caching rules that appear to be set up, and every visitor still being sent all the way back to the origin server. The rules exist and nothing gets cached.
A recent example
We did this work recently for a UK mental health charity with a form-heavy ExpressionEngine site. The brief was to make the site faster without putting any of its enquiry or assessment forms at risk. That meant moving the domain onto Cloudflare with no interruption to the site or email, going through years of old DNS records and clearing out the ones that no longer pointed anywhere, and setting up caching that served the content pages quickly while leaving every form and every page that collected personal information to build fresh on each visit.
It also meant catching what could go wrong. One page mixed personal information into an otherwise cacheable template. Left as it was, Cloudflare would have stored that page and could have shown one person's details to the next visitor. We found it during the review and kept it out of the cache before anything went live.
What a proper setup covers
If you are having this looked at, whether that means a Cloudflare setup from scratch or a review of what a previous agency left behind, the work should cover:
- The domain move, done so the site keeps serving throughout and email keeps working, with a full check of your DNS records first.
- Caching rules that are fast for content pages and never touch forms, logins, baskets, or anything personalised.
- The platform-specific fixes that stop ExpressionEngine and Craft blocking the cache.
- Automatic cache clearing, so when your team publishes a change it appears on the live site straight away instead of waiting for the cache to expire.
- Security settings chosen for a business-critical site and checked, rather than left on defaults.
- A check of every page that carries private data, against the actual templates, so none of it can end up cached.
The account should be in your name
One more thing worth knowing. The Cloudflare account should be in your name, with your billing, not sitting inside an agency's account. Your domain's DNS is controlled from there. If that control sits with a supplier and the relationship ends, getting it back can be slow and awkward at exactly the point you need it to be quick.
Worth a look
If your site runs on ExpressionEngine or Craft and you are not sure whether Cloudflare is doing anything for it, that is worth checking. We can tell you what is actually configured and what is worth changing. See Cloudflare setup and optimisation, or get in touch with Karl for a straight assessment.
Topics
{categories}
{category_name}
{/categories}
