If your website is on Cloudflare and the HTML is not served from edge cache,
your Time to First Byte (TTFB) is probably high for some/many users.
High TTFB is bad for user experience and SEO (Core Web Vitals).
There are many ways to solve high TTFB problems on Cloudflare and Speculation Rules is a new option to explore.
Speculation Rules is a browser API to prefetch/prerender the page that is likely visited next, and it’s coming full to Chrome/Edge browsers soon.
Speculation Rules can help speed up any website on any CDN, not just Cloudflare.
This article is a case study of how Speculation Rules improved the TTFB of the CDN Planet website by hundreds of milliseconds for ~20% of pageviews for non-landing pages 🥳
Read on to learn how to improve TTFB on Cloudflare with Speculation Rules.
High TTFB on Cloudflare Workers Sites
The CDN Planet website has many pages (thousands) and a truly global audience.
We use Eleventy to generate our static site and push all site resources to Cloudflare using Workers Sites, the predecessor of Cloudflare Pages.
All site resources are stored in Workers KV, Cloudflare’s distributed key-value store.
The Cloudflare Docs site describes how KV works:
KV is a global, low-latency, key-value data store. It stores data in a small number of centralized data centers, then caches that data in Cloudflare’s data centers after access.
…
While reads are periodically revalidated in the background, requests which are not in cache and need to hit the centralized back end can experience high latencies.
And high latencies we have.
Our HTML may be stored in edge cache for up to an hour, but due to the long tail nature of our content, users across the globe and Cloudflare’s many POP locations, the cache hit ratio for HTML is only ~35% 😞
We measure how long it takes to read the HTML from KV or edge cache from within our Worker:
in the past 3 weeks, the daily average ‘edge read time’ varied between 108 ms and 288 ms and that time goes straight into TTFB and Largest Contentful Paint.
That average is based on edge cache reads and reads from KV and assuming edge cache reads are very fast, the average ‘KV read time’ is surely higher than those 108 and 288 ms.
Cloudflare Pages uses KV as storage/origin too, so this case study is relevant to websites running on Pages too.
Our TTFB on Desktop and Mobile
The Chrome UX Report (known as CrUX) is a public dataset of real user experience data on millions of websites.
Data is collected by the Chrome browser on mobile and desktop and is constantly updated.
The most talked about data in CrUX are the Core Web Vitals, but there is more, including TTFB.
You can access the CrUX data in many ways.
We often use Treo because of the beautiful visualizations.
In September 2023, our TTFB on desktop was 0.4 seconds at the 75th percentile and ~11% of pageviews had a TTFB that Google considers Moderate or Poor.
On mobile (second chart below), the TTFB picture looks much worse: TTFB was Moderate or Poor for more than 21% of pageviews.
TTFB on mobile is 1.3s at the 90th percentile, meaning 10% of pageviews had a TTFB higher than 1.3 seconds. Ouch.
The CDN Planet website has many users on mobile (43%) and no less than 33% of mobile users are on a slow 3G connection.
Improving TTFB is especially important for those 3G users, so what can we do?
Five Ways to Improve TTFB on Cloudflare Workers Sites
Some brainstorming led to five ideas for solving our high TTFB on Cloudflare problem:
Solution | Thoughts |
---|---|
Increase edge cache-control | Easy to implement but unlikely the speed gains are significant |
Put HTML of popular pages in edge cache | Small code change in our Worker and probably somewhat effective |
Switch to Cloudflare Pages | Pages uses KV for storage too, so no speed gains expected |
Use Speculation Rules to prefetch next page | Speculation Rules seems easy to implement, configurable and can do not only prefetch but also full page prerendering |
Move from KV to multi-region origin | Stop using KV and instead store our static site in multiple datacenters across the globe, using something like Fly.io. Probably very effective, but a big project |
We decided on using Speculation Rules to improve TTFB for our website on Cloudflare,
mainly because it allows for starting with prefetch and later upgrading to full page rendering for instant loading of the next page.
Introduction to Speculation Rules
The best place to learn all about the what, why and how of the Speculation Rules API is the Chrome for Developers website where
Barry Pollard, a Web Performance Developer Advocate for Google, published two great articles: Prerender pages in Chrome for instant page navigations and Debugging speculation rules.
I’ll provide a brief overview here.
The Speculation Rules API provides a new way for website builders to reduce user-visible latency (= improve TTFB and LCP).
The API allows a web page to declare which URLs the user may navigate to next, so the browser can combine this information with its own heuristics to decide whether to speculatively prefetch or prerender pages. The rules are hints and the browser may decide not to act upon them.
The rules are expressed as a JSON object included within a script tag. In the future, the browser may load external rule sets that are served with the Speculation-Rules
header. The script tag can statically exist in the page or be dynamically injected by JavaScript.
The prefetched/prerendered page is held in memory and so will be available quicker to the browser once needed.
Browsers cache prefetched pages for a short time before discarding them (max 5 minutes in Chrome 118).
If the user navigates to the URL while the prefetch/prerender is still in-flight, the browser will use the in-flight fetch/render and continue from th