Build1 publisher2 min readPublished
Render delay and server wait separate slow pages from fast ones in Cloudflare's BEACON data
Cloudflare's BEACON real-user data from about 10,000 large sites shows poor-LCP pages spending 1,891ms waiting for HTML and 2,002ms in render delay. Good pages spend 598ms and 157ms there, so sites like the sample should fix the server and rendering before they compress images.
The Engineer · Build desk
What happened
- Download time for the LCP resource itself, called load duration, barely moves between the good, needs-improvement and poor buckets.
- Cloudflare publishes BEACON's records as histograms refreshed daily in Google BigQuery, so users can compute their own percentiles.
- Domain names and URL paths are stripped, and any group with fewer than five data points is dropped from the published data.
- The dev.to author has not yet run BEACON's BigQuery queries against client sites and offers the fix order as a reading of Cloudflare's numbers plus opinion.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision On sites that resemble the sample, image size moves to last place in the tuning queue, behind server response, resource discovery and render delay.
- constraint A server as slow as the poor-bucket figure uses about 76% of the 2.5-second LCP budget before the first byte of HTML arrives, so image work alone cannot bring those pages under the line.
- capability The web-vitals attribution build reports the same four LCP parts per page view, so a site can test BEACON's pattern on its own users without BigQuery.
Cloudflare publishes the LCP breakdown separately for good, needs-improvement and poor pages [5]. Subtract the good bucket from the poor one, using the figures as the post's author reads them [6][7][8]. Server wait grows by 1,293ms [1], load delay by 1,409ms [2] and render delay by 1,845ms [3]. The three gaps add up to about 4.5 seconds [4]. On poor pages those three parts total roughly 5.4 seconds with the download left out [6]. The good-LCP threshold is 2.5 seconds at the 75th percentile of page loads [4].
Each part has its own cause. Load delay is the gap between the HTML arriving and the browser starting to fetch the LCP image or font [22]. The author's most common culprit is a hero image set as a CSS background. The browser cannot see it until the stylesheet has been parsed [15]. The post's fix puts the image in the markup as `<img src="/hero.webp" width="1200" height="600" fetchpriority="high">` [16]. In the author's experience, render delay usually comes from a blocking script or a client-side framework that has not hydrated [17].
The author opens by admitting to a habit of fixing whatever Lighthouse lists first, usually an image 40KB too big [20]. Most of us have billed for that afternoon. Cloudflare got the data format right. The author wrote that most of the average page speed charts found online are averages of averages [21]. Google grades at the 75th percentile [4]. An average of averages cannot answer that question, and a histogram can.
Whether the order carries over to your site depends on whether its traffic looks like Cloudflare's sample of large sites [1]. "Ten thousand big sites on one CDN is not the web," the author wrote [11]. "A five-page brochure site on shared hosting has different problems from a site big enough to be in this sample" [12]. The post's test for whether the table applies is a week of a site's own attribution data: "Collect a week of that, sort by the 75th percentile of each field, and the biggest one is your afternoon" [14].
Cloudflare says BEACON covers every major browser engine [1]. The author's summary advice tells readers to stop testing only on Chrome [19]. The bucket figures quoted here are not split by engine. They do not show how far users on other engines diverge from Chrome users.
What to watch
- Per-engine BEACON histograms showing whether LCP or INP differ enough between browser engines to justify test runs beyond Chrome.
- A follow-up in which the author runs BEACON's BigQuery queries against client sites and checks the quoted bucket figures.
- Attribution data from small shared-hosting sites outside the sample, showing whether server wait still dominates there.