The Components of Time to First Byte  ## Metadata - Author: [[oandre.gal]] - Full Title: The Components of Time to First Byte - Category: #articles - Document Note: --- tags: - #wordpress - #performance - #webvitals Author: oandre.gal Source: Personal website (article) Reference: https://oandre.gal/the-value-of-time-to-first-byte/ date created: 2025-08-21 00:00 --- # Title: The components of Time To First Byte ## Table of Contents: - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB (Diversity, Equity, Inclusion, and Belonging) Assessment](#-deib-diversity-equity-inclusion-and-belonging-assessment) - [✅ Logical validity](#-logical-validity) - [🔍 DARVO Analysis](#-darvo-analysis) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) ### References: - web.dev: Time To First Byte (definition and guidance) — see “Time To First Byte, as defined by web.dev” - Felix Arntz: “Rebuilding my website using a block theme” (block vs classic theme performance comparison) - WordPress Core Performance team discussions and hallway hangouts (WordPress 6.2 cycle) ## 📝 Summary: The article argues that Time To First Byte (TTFB) is a useful but incomplete performance metric. While WordPress 6.2 significantly improves server-side performance—especially TTFB for both block and classic themes—the author shows why TTFB alone doesn’t capture user-perceived performance. Network, server, and application components all influence TTFB, and factors like client-side rendering and caching can decouple TTFB from real user experience. A holistic performance view must include user-centered metrics such as Largest Contentful Paint (LCP) and derived metrics like LCP minus TTFB (LCP‑TTFB). Key takeaways: - WordPress 6.2 improved TTFB broadly (+25% block themes, +10% classic themes at p75). - TTFB varies due to network, server, and app layers; “lab” TTFB can proxy server-side changes but misses real-world variance. - Server doing “more work” (e.g., tree-shaken CSS for block themes) can worsen TTFB while improving LCP. - Caching can commoditize server time, making TTFB less relevant to user-perceived performance. - Use LCP and LCP‑TTFB to gauge client-side impact and prioritize performance work. ## 📖 Main Content: The author opens with positive results from the WordPress 6.2 release: measurable server-side gains in TTFB for both block and classic themes. They then contextualize TTFB as a composite influenced by three layers: - Network (DNS, CDNs) - Server (web server, configuration, runtime versions, load balancing) - Application (code paths, theme architecture) The article distinguishes “field” (real users) vs “lab” (controlled environment) measurements. Field TTFB is confounded by network/server variability; lab TTFB can isolate application performance but misses real-world noise. Two caveats demonstrate why TTFB can diverge from user experience: 1) “Server does more, UX gets better”: Block theme CSS “in-use only” loading adds server computation (hurting TTFB) but reduces bytes and improves LCP. Early data from experiments and Gutenberg dashboard metrics (LCP‑TTFB) indicates block themes can outperform classic themes in user-centered metrics. 2) Caching “commoditizes” server time: With full-page caching, TTFB reflects cache speed rather than WordPress processing, breaking any direct link between server-side work and user-perceived performance. The coda urges teams to keep improving TTFB while adopting user-centered metrics—particularly LCP and LCP‑TTFB—to understand and prioritize impactful changes. ### 🗒️ Notes - WordPress 6.2 performance impact - +25% TTFB improvement for block themes; +10% for classic themes (p75) - First release with broad server-side gains “across the board” - TTFB components - Network: DNS, CDNs, routing latency - Server: Apache vs Nginx, configs, PHP version, load balancers - Application: theme and plugin code paths, rendering work - Field vs Lab - Field: realistic, confounded by network/server variability - Lab: isolates application effects; useful for regression testing and benchmarking - Caveats to TTFB - More server work can help users: - Block theme style optimization: ship only CSS in use → smaller payloads, better LCP despite slightly worse TTFB - Early data: TwentyTwentyThree faster than classic themes in LCP and LCP‑TTFB - Caching breaks the link: - Full-page caching returns pre-rendered HTML; TTFB reflects cache performance - Theme architecture differences may become less visible in TTFB - Metrics to track - LCP (user-perceived) - LCP‑TTFB (client-side component of LCP after server responds) - Continue improving server-side TTFB, but prioritize user-impact metrics - Ecosystem discourse - Challenges “classic themes are faster than block themes” based on emerging data - Ongoing 6.3 work expected to narrow any remaining gaps ## 📖 References: - Time To First Byte (web.dev): foundational definition of TTFB - Felix Arntz, “Rebuilding my website using a block theme”: practitioner evidence that block themes can be faster in real metrics - WordPress Core Performance hallway hangouts: methodology and metrics discussions ## 🗣️ Paraphrase: 1) Original idea: “TTFB is influenced by three things: network, server, and application. Field TTFB is heavily impacted by factors outside app developers’ control; lab TTFB can isolate app performance.” Paraphrase: The time to first byte emerges from a stack of influences—routing and DNS, the hosting runtime, and the app code itself. Real-user measurements blend all three, often masking app changes behind network or server variability. By contrast, controlled tests can neutralize network/server effects to reveal application-level performance clearly. 2) Original idea: “Server can do more while user-perceived performance improves; shipping only CSS in use worsens TTFB but improves LCP.” Paraphrase: Sometimes extra computation on the backend yields a faster experience for people. For example, analyzing blocks to load only necessary styles adds server time but reduces front-end bytes, improving the Largest Contentful Paint—even if the server’s first response arrives a bit later. ## 📰 Newsletter: This week in web dev and WordPress, we’re talking performance with nuance. WordPress 6.2 delivered real server-side wins—TTFB improved broadly for both block and classic themes. But here’s the twist: TTFB alone doesn’t tell the user story. Network hops, server config, and caching all skew TTFB. Meanwhile, user-centered metrics like LCP—and the handy LCP‑TTFB—reveal where the UX truly speeds up. What to watch: - Block themes aren’t the bad guys. With “CSS-in-use” loading, they may add a smidge of server work but still win on LCP. - Full-page caching? Your TTFB probably reflects cache speed more than PHP magic. Measure what users feel. Try this: audit LCP and LCP‑TTFB alongside TTFB to prioritize work that improves real experiences. For background, see the TTFB definition on [web.dev’s performance guidance](https://web.dev/ttfb/) and Felix Arntz’s field notes in [Rebuilding my website using a block theme](https://felixarntz.dev/). Plugins and tools: consider observability setups that capture Core Web Vitals in production. Bonus points if your stack correlates theme changes to LCP shifts. Keep building fast—and measuring smarter. ## ✅ Action Items: Prompt for aligning articles with your role (Developer Advocate at GoDaddy; OSS/WordPress; educator; aspiring OSPO director): “Analyze how this article advances open-source performance literacy in the WordPress ecosystem and supports contributor engagement. Map the article’s arguments about TTFB, LCP, and LCP‑TTFB to: - Open-source advocacy: How does it promote transparent metrics, responsible benchmarking, and data-driven decisions? - Contributor onboarding: Which parts translate into beginner-friendly contribu - Summary: For a holistic perspective on performance, we need to track user-perceived performance (LCP) and add client-side metrics to the mix (LCP-TTFB). - URL: https://oandre.gal/the-value-of-time-to-first-byte/ [WordPress 6.2 “Dolphy”](https://wordpress.org/news/2023/03/dolphy/) was released a few days ago. It is the first release where I was involved in performance work, as per my role of [core contributor](https://profiles.wordpress.org/oandregal/). It is also the first release that has had a positive impact across the board, improving all kind of themes, classic and block ones: > The server-side performance of WordPress 6.2.0 entails a +25% improvement for block themes and 10% for classic ones compared to 6.1.1. > > — [Evolution of WordPress TTFB: 5.6 to 6.2](https://oandre.gal/evolution-of-wordpress-ttfb-5-6-to-6-2/) This is accounting for the 75th percentile — a common industry standard that is also used for measuring [web vitals](https://web.dev/vitals/) and the [HTTP Archive](https://httparchive.org/). [](https://oandre.gal/evolution-of-wordpress-ttfb-5-6-to-6-2/) It is impressive, isn’t it? It really is. At the same time, by contributing to WordPress, I learned that server-time is a partial picture and often a distorted one. That is what this post is about. > Time To First Byte (TTFB) is a metric that measures the time between the request for a resource and when the first byte of a response begins to arrive. > > — [Time To First Byte, as defined by web.dev](https://web.dev/ttfb/) In essence, TTFB can be influenced by three things: * **The network**. The time it takes packets to communicate between client and server: DNS propagation, whether you use CDNs, etc. * **The server**. Things that fall into this bucket are: whether you use Apache or ngnix and its configurations, balance loaders, which version of the language is in use, etc. * **The application**. How performant the application is. Those are the components that affect [TTFB measured in the field](https://almanac.httparchive.org/en/2022/cms#cms-user-experience) — this is, data from real users. A lot of the TTFB is influenced by things out of the control of application developers. For example, the same WordPress website will be faster or slower depending on the PHP version provided by the hosting company. A different dataset results of measuring TTFB “in the lab”, which stands for measuring a non-production environment. Important components, such as the network, are very difficult to replicate in the lab. The lab also has advantages: it allows you to evaluate the impact of some components in isolation from others more easily. Let’s say that you are able to set up an environment where the effects of the network & server can be discarded. Perhaps they don’t contribute much, and you can ignore them. Or perhaps they don’t change, so any difference can be attributable to the application. That’s useful. That’s how **TTFB, in the lab, can serve as a proxy for the server-side performance of your application**. #### Caveats of Time To First Byte Variations to Time To First Byte do not always match variations to user-perceived performance. That’s why TTFB is not part of the [Core Web Vitals](https://web.dev/learn-core-web-vitals/) and other metrics such as Largest Contentful Page (LCP) are. I’ll share two concrete examples related to WordPress. ##### The server can do more while the user-perceived performance is improved If your WordPress site uses a block theme, one of the things the server does is inspecting the blocks in use by the page. This takes more time than not doing it. It’s worse TTFB. With the extra processing, the server identifies which styles are necessary for the page, and enqueues only those instead of the whole block library stylesheet. **By shipping only the CSS in use, the overall performance improves for the user.** [This feature](https://make.wordpress.org/core/2021/07/01/block-styles-loading-enhancements-in-wordpress-5-8/) was shipped in WordPress 5.8, before we tracked any metrics. During the WordPress 6.2 cycle, I partly focused on clarifying the relationship between TTFB and other user-centered metrics. I raised the topic of metrics and methodology everywhere I could, specially in [the first](https://make.wordpress.org/core/2022/12/16/hallway-hangout-performance-considerations-for-block-themes/#comment-44278) and in [the second](https://make.wordpress.org/core/2023/02/03/hallway-hangout-performance-improvements-for-wordpress-6-2/) hallway hangouts about performance. Some of the early data points I was able to gather are: * [This experiment](https://github.com/WordPress/gutenberg/pull/48728). It analyzes the impact of shipping only the CSS in use. This data point tells us that TwentyTwentyThree (block theme) is faster than TwentyTwenty (classic theme), as reported by a user-centered metric such as LCP: 198.60ms vs 208.35ms. * The [Gutenberg dashboard](https://www.codevitals.run/project/gutenberg). It now reports some front-end metrics for themes. The data says that TwentyTwentyThree is faster than TwentyTwentyOne in the client, as reported by LCP-TTFB: 30.26ms vs 38.26ms Even if in early stages, the data points above challenge the common discourse of many in the WordPress ecosystem (“*classic themes are faster than block themes*“). I believe TTFB improvements are great, and we need more of them. The [WordPress core dashboard](https://www.codevitals.run/project/wordpress) shows how close block & classic themes are already: 74.57ms vs 58.72ms. They’ll be even closer in WordPress 6.3, as per some [ongoing work](https://github.com/WordPress/wordpress-develop/pull/4097). But TTFB is not the full picture. ##### Your site can be cached, commoditizing server time The nitty-gritty of measuring server-time was a lot of fun. It was enlightening as well. However, there is a bigger use case in which server-time doesn’t correlate to user-perceived performance: caches. Does your site use a full-page cache plugin? If it does, the time it takes WordPress to process anything in the server becomes the time it takes the cache to return the page. No matter which kind of theme you use. This is a very common setup. One of the best examples I’ve seen discussing this topic is Felix Arntz’s “[Rebuilding my website using a block theme](https://felix-arntz.me/blog/rebuilding-my-website-using-a-block-theme/)“. Felix was the performance release lead for WordPress 6.2, and he’s heavily involved in WordPress performance team. He knows a few things! Go there and [read his essay](https://felix-arntz.me/blog/rebuilding-my-website-using-a-block-theme/), it’s an account of how **block themes are already faster than classic themes in some scenarios**. According to [his data](https://felix-arntz.me/blog/rebuilding-my-website-using-a-block-theme/), his new block theme improves (or matches) the old classic theme in every metric that can be tracked. It’s actually 45% faster than the old classic theme he was using: [](https://felix-arntz.me/blog/rebuilding-my-website-using-a-block-theme/) #### Coda The improvements of Time To First Byte in the WordPress 6.2 cycle have had a great impact on performance across the board. According to [this data](https://oandre.gal/evolution-of-wordpress-ttfb-5-6-to-6-2/), it’s the first release that improves server-time performance for all kind of themes — classic and blocks. It’s great progress. At the same time, Time To First Byte is only a partial picture and, in many scenarios, a distorted one. For a holistic perspective on performance, we need to track user-perceived performance (LCP) and add client-side metrics to the mix (LCP-TTFB). By understanding the full impact of our work, we will be able to prioritize our work based on impact., The Components of Time to First Byte, oandre.gal, 01gxs7wnmkn5h781jr33eacvh0.