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 75^th 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 90^th 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