If you reached this blog, then chances are you've heard of Cloudflare. CDN solution might be the first that comes to mind, but their focus is even broader. However, it stops at Core Web Vitals.
Luckily, that still strive to make your website fast, but have issues making their own website fast as well. This surprised me, so I dived into some data and code.
Founded back in 2009 and having a revenue of $287 million in 2019, Cloudflare is used quite a lot. For example, Cloudflare is being used by more than 26 million websites, resulting in processing more than 1 billion ip-addresses a day. And, a bit old by now, they turned out to be the fastest as well in 2018.
Although not going into detail about what each of their services mean, they offer the following solutions:
- Content Delivery Network (CDN);
- Domain Name System (DNS);
- Load Balancing;
- Accelerated Mobile Pages (AMP);
- Video Streaming;
- DDoS protection;
- Web application firewall (WAF);
- SSL/TLS support;
- Domain registrar;
Quite a list, helping build a better Internet for sure. But is their own website good publicity for their services
Cloudflare's own pagespeed results
Not really, unfortunately. We can all draw this conclusion when using PageSpeed Insights. You could head over there to see their current result, or see the screenshot below.
This is displaying user experience metrics of real users, visiting cloudflare.com on their mobile devices. The numbers aligned to the right, is the 75th percentile per metric.
Field data displayed in PageSpeed Insights is coming from CrUX, where 3 out of 4 metrics are part of Core Web Vitals. Only pageviews via Google Chrome browsers are part of Core Web Vitals.
PageSpeed Insights explained
The following can be seen:
- The homepage FCP is 2.6 seconds, while the overall FCP is 3.7 seconds;
- First Input Delay seems to be quite ok, and at least within the threshold of 100 milliseconds;
- The homepage FCP is 3 seconds, while the overall LCP is 3.7 seconds;
- Layout Shifts only seems to be a significant bottleneck on the homepage.
What I'm usually seeing is that the FCP bottleneck is bigger on the homepage. Huge layout shifts only seems to be happening on the homepage. This corresponds with what you would see when visiting their website and clicking around:
- On my testing device, the impact is around 13%. But this could be less on larger mobile screens;
- As a result, there are still users which are in the green bucket. Apparently, 45% of homepage pageviews are not exceeding the CLS threshold of 10%;
- The reason some even have a CLS experience of more than 25%, can be explained by uncached homepage pageviews. Their homepage seems to be one of the few pages with an image being visible above the fold, within the initial viewport. While lacking width and height attributes, this is pushing underlying textnodes down once the image was loaded.
Historic Cloudflare CrUX data
Looking at historic data, issues even grew towards the end of 2020.
Time to First Byte
Largest Contentful Paint
What surprises me is that they seem to be having a TTFB challenge themselves. Not even 30% of pageviews are resulting in a TTFB lower than 300ms.
Luckily, TTFB isn't part of Core Web Vitals, but while a good TTFB don't necessarily result in a good LCP, it does work the other way around. A bad TTFB will push back your FCP and LCP metrics as well. Although Cloudflare had a huge negative LCP spike in September, when looking at the poor LCP experiences, you can see that is closely correlates with the TTFB trend.
How Cloudflare could speed up
It wasn't really my plan to do a Cloudflare pagespeed audit, but being both a pagespeed consult and developer, I could not not look at their source code at all, obviously.
Time to First Byte
Looking at the headers of the Cloudflare pages, one can tell that my request went via a data center in Amsterdam. The homepage is returning
cf-cache-status: HIT, but other pages are returning
I first thought that the FCP difference within PageSpeed Insights field data and origin summary could be caused by cached versus uncached pageviews, and maybe underlying pages getting the most first pageviews within a session when someone is searching for Cloudflare's specific solutions. But looking at their response headers, I now have to change this assumption.
The mobile FCP for the homepage (2.6 seconds) is quite a bit better than the overall FCP (3.7 seconds) and might actually be explained by the difference in cache status responses for homepage versus non-homepages.
First and Largest Contentful Paint
head section of the HTML document. Cloudflare is using system fonts, meaning no (Google) fonts can be responsible for triggering a new LCP. But looking at their source, I didn't even needed to look any further into their FCP and LCP bottleneck:
Cumulative Layout Shift
As we already discussed the causes of CLS, we now know that CLS is easy to fix:
- they should be using width and height attributes for their images, especially for above-the-fold images;
- it would be better if they used a sticky notice for latest news, instead of a notice pushing other contents down on runtime.
Meaning, the CLS will be the easiest to fix.
Does this mean you should not be using Cloudflare in order to achieve optimal pagespeed and maybe even passing Core Web Vitals? Obviously not. There are even SEO agencies out there that write about Core Web Vitals, but don't actually pass Core Web Vitals, despite Core Web Vitals becoming a ranking factor upcoming May.
Missed opportunity for sure to not align website technique with overall niche, but agencies and companies might still excel in other SEO or performance sub niches.
When considering using Cloudflare products and solutions, be sure to not just enable Cloudflare Rocketloader and call it a pagespeed-day. Enabling it might do more harm to real user experience and to your Core Web Vitals status. Doubts about how to move forward instead? Get in touch.