Designing a distributed web performance architecture

This guide describes a comprehensive layer 7 (L7) Application Performance strategy for architects and developers. In today's competitive digital landscape, application performance is a critical business differentiator. However, the ultimate objective is finding the performance-security equilibrium point.

While this guide focuses on maximizing speed and user experience (UX), performance cannot come at the expense of security. Architects must balance latency reduction against the necessary processing overhead of rigorous security controls, such as DDoS protection, WAF and Bot Management.

In high-risk scenarios, security must take precedence, where the "latency budget" gained from these performance optimizations is strategically reinvested to power essential protections, ensuring the application remains both fast enough to convert users and secure enough to protect the business.

Measuring the Impact: While marketing dashboards (for example, Google Analytics) track business outcomes, Cloudflare Web Analytics and Observatory measure the performance drivers. Use them to correlate real-time Core Web Vitals (CWV) and Real User Monitoring (RUM) improvements directly with reduced bounce rates and higher conversions, without compromising privacy or relying on heavy client-side scripts.

By following this architecture, organizations can expect:

• Improving Core Web Vitals (CWV) like LCP and INP, which can help reduce bounce rates and drive sales.
• Maximizing Cache Hit Ratio, which offloads traffic from the origin, reducing infrastructure spend, and overall lowering operational costs.
• Ensuring high uptime/availability and business resiliency even during traffic spikes.

Measuring performance is tricky ↗︎, and it serves a broader business context where Security and Compliance ↗︎ are often non-negotiable prerequisites. Organizations frequently validate that their architecture meets regulatory standards (such as data residency ↗︎ or encryption protocols, including Post-Quantum Cryptography (PQC)) before unlocking performance capabilities.

Once these security and compliance baselines are secured, effective optimization starts with measuring the “right” things - which interestingly is slightly different for everyone. Nonetheless, most people would agree to focus on user-centric metrics for website performance, using TTFB as a diagnostic tool ↗︎ for server responsiveness, but prioritizing Core Web Vitals (CWV) ↗︎ for measuring user experience.

Successful implementation is measured by these metrics:

The 75th percentile target is based on previous analysis ↗︎ for reasonable balance.

To benchmark against real-world data, use BEACON ↗︎, an anonymized RUM dataset of Core Web Vitals and their sub-parts from 10,000 of the largest websites on Cloudflare's network. BEACON publishes full histograms, so you can examine the long tail beyond P75. Its data shows that most page views missing the "Good" LCP threshold gain more from discovering the LCP resource sooner and unblocking its render than from a faster download.

This diagram illustrates the request lifecycle, highlighting how Cloudflare's layers/phases - Network, Optimization, Caching, and Origin connectivity - work together to minimize latency.

For demonstration purposes, the architecture is organized into four logical layers and follows specific phases. Optimizing every step in this chain is required to achieve the best aggregate performance.

The performance journey begins at the client's device. Device hardware, browser ↗︎, network quality and topology determine initial responsiveness. The goal here is to establish the fastest possible connection to the Cloudflare network.

• DNS Resolution: The client device queries the domain, going through both a public DNS resolver and, ultimately, to an authoritative DNS server. Cloudflare's global anycast network ↗︎ routes requests to the nearest Point of Presence (PoP), with global DNS ↗︎ resolution ensuring minimal lookup latency, including the possibility to expand to mainland China.
• Connection Establishment: The client establishes a connection via IPv4/IPv6 using HTTP/3 (QUIC) and TLS 1.3 - this also allows for Post-Quantum Cryptography (PQC). If the client has visited before, 0-RTT Connection Resumption eliminates round-trips during the handshake. Additionally, HTTP Strict Transport Security (HSTS) enforces browser-side redirects to HTTPS, removing unnecessary server round-trips. It is generally recommended to enforce HTTPS connections. Furthermore, by using L4 transport telemetry available directly on request.cf — including clientTcpRtt (TCP connections), clientQuicRtt (QUIC/HTTP/3 connections), and edgeL4.deliveryRate (bytes per second) — and their corresponding Ruleset Engine fields cf.timings.client_tcp_rtt_msec, cf.timings.client_quic_rtt_msec, and cf.edge.l4.delivery_rate, you can implement adaptive performance strategies based on real-time connection quality — without any client-side changes.
• Browser Optimization: Features like Speed Brain (Speculation Rules API) proactively prefetch resources, while Early Hints send link headers to the browser during "server think time", speeding up page rendering.
• Third-Party Offloading: Zaraz offloads third-party tools (like Google Analytics 4 or Mixpanel) to the cloud. This reduces main thread blocking on the device, significantly improving INP.
• Web Analytics (RUM): Leverage Cloudflare Web Analytics to collect privacy-first, cookie-less performance data directly from the user's browser. This lightweight JavaScript beacon provides real-world insights into Core Web Vitals (LCP, INP, CLS) without tracking users or storing client-side state.

Once the request reaches the network edge, Cloudflare processes and optimizes the content before it is served or fetched from the cache.

• Traffic Management: The request is inspected. URL Normalization ensures consistency, while Redirect Rules or Transform Rules handle path modifications efficiently. Waiting Room protects the backend during massive traffic surges, maintaining availability.
• Programmatic Customization: For advanced use cases where standard rules are insufficient, Snippets and Workers allow for programmatic customization. This enables executing custom code logic to modify headers, rewrite URLs, image optimizations, or implement unique caching logic directly at the edge. When multiple Workers need to interoperate, use Service Bindings for low-latency, zero-overhead Worker-to-Worker communication. Use the cf.timings.worker_msec Ruleset Engine field to measure wall-clock Worker execution time per request — useful for identifying slow Worker paths, setting up performance-regression alerts, or injecting processing-time headers for downstream observability.
• Content Optimization: Text assets are compressed using Compression Rules (Brotli/Gzip). For significantly greater transfer-size reductions on repeat visits, Shared Dictionaries (beta) let your origin send only the difference between asset versions using dcb (Dictionary-Compressed Brotli) and dcz (Dictionary-Compressed Zstandard) encodings. In passthrough mode, your origin produces the delta-compressed responses, while Cloudflare forwards the dictionary headers and caches each variant correctly. Browsers without dictionary support continue to receive standard compression. Images are processed on-the-fly via Image Transformations or Polish to ensure they are served in the optimal format (AVIF/WebP) and size for the device, significantly improving LCP and CLS.
• Font & Tag Optimization: Cloudflare Fonts eliminates DNS lookups and TLS connections to Google Fonts by serving them inline from the domain. Google Tag Gateway improves ad signal measurement and privacy.
• Routing, Availability & Protocol Intelligence: Cloudflare operates one of the most interconnected networks ↗︎ in the world, peering with over 13,000 networks, operating a global backbone ↗︎, and participating in a leading number of Internet Exchange Points (IXPs) ↗︎ globally. We leverage the unique intelligence ↗︎ derived from this massive dataset to dynamically optimize Congestion Control (CC) at the protocol level - automatically selecting the optimal algorithm and tuning adequate parameters for every connection based on real-time network conditions. For dynamic requests that cannot be cached, Argo Smart Routing finds the fastest path through the network to the origin. Custom Errors provide a consistent brand experience during failures.

Cloudflare can be organized into a specific topology. This layer handles content retention and retrieval. It acts as a shield for the origin and a high-speed store for the client.

• Cache Logic: Origin Cache Control Headers, Cache Rules and Caching Levels allow precise control over TTL and query string handling. Cache Response Rules modify origin responses before they are cached, without changing the origin. Use them to adjust Cache-Control directives, strip Set-Cookie headers that make static assets uncacheable, set different edge and browser TTLs, or convert another CDN's cache tag header during a migration. For more information, refer to Introducing Cache Response Rules ↗︎. When the origin serves different variants of the same URL (for example, by language or format), enable Vary support in Cache Rules and normalize header values to avoid fragmenting the cache. Implement Cache Normalization strategies to consolidate requests with variable URLs - such as those with distinct marketing or SEO parameters - into a single Cache Key, significantly improving cache hit ratios. Prefetch URLs can pre-populate the cache with critical assets via manifest files to further reduce latency. Asynchronous stale-while-revalidate serves stale content immediately while revalidating in the background, so no visitor waits on the origin after expiry. Note the default caching behavior and limits.
• Tiered Caching: If the content is not on the local PoP, Cloudflare checks an upper-tier cache topology. Smart Tiered Caching and Regional Tiered Cache centralize connections, increasing cache hit ratios and reducing global origin load. For origins hosted on public cloud providers (AWS, GCP, Azure, Oracle Cloud), set a cloud region hint so Smart Tiered Cache can select the optimal upper-tier data center for your cloud region, bypassing latency-probing limitations caused by anycast or regional unicast networking. For a more customized approach, Enterprise customers can opt for a Custom Tiered Cache topology.
• Workers Cache: For responses generated by Workers, turn on Workers Cache to serve cached responses without running the Worker. Cache hits skip Worker execution, which reduces latency and CPU usage. Workers Cache is tiered by default and controlled with standard Cache-Control, Vary, and Cache-Tag headers, with purges issued from code. The cache belongs to the Worker rather than the zone, so zone-level settings such as Cache Rules do not apply. For more information, refer to Your Worker can now have its own cache in front of it ↗︎.
• Dedicated long-term Cache: Cache Reserve extends the life of large, infrequently accessed assets (for example, images, archived video, software updates, or static AI models) by moving infrequently accessed content to persistent object storage backend (powered by R2). This prevents eviction due to Least Recently Used (LRU) algorithms and avoids latency-inducing origin fetches, while simultaneously supporting storage redundancy and resilience requirements.
• Instant Purge: Leverage Cloudflare's decentralized purging architecture ↗︎ to invalidate content globally in approximately 150ms. This Instant Purge capability supports various granular approaches - including Purge by URL, Tag, Prefix, or Hostname - ensuring users receive fresh content immediately without waiting for TTL expiration. When only some assets in a group have changed, invalidate instead of purging: content is marked stale and revalidated with the origin, and unchanged assets (304 Not Modified) are reused rather than downloaded again. This also applies to Cache Reserve content, where a purge forces a full origin fetch.
• Cloud Connectivity: Cloud Connector Rules simplify routing traffic to public cloud providers (AWS, Azure, GCP, Oracle Cloud) for specific object storage or origin requirements. For private infrastructure, Workers VPC enables direct connectivity to private storage endpoints or databases on public clouds (for example, AWS, Azure) without exposing them to the public Internet.
• Static Asset Hosting: Entire parts of an application (frontend assets, images, including large media files, software packages) can be stored directly in R2 Object Storage or Workers Static Assets, serving them from the edge without ever hitting a traditional origin server. Additional storage options are available.

For requests that must traverse the full path (that is, dynamic content or cache misses), the origin configuration determines the final latency impact. Architects have two primary paths here: adopting the performant, resilient serverless model (also known as originless), or optimizing connectivity and security for a traditional Origin Server.

Serverless: Cloudflare's Developer Platform achieves the optimal performance tier by enabling an "originless" model. Fullstack applications are built and deployed directly on the global edge network worldwide, eliminating the full path traversal to a distant origin. Dynamic requests execute at the nearest Cloudflare PoP and provide direct access to integrated edge storage solutions like R2 Object Storage and D1 Serverless SQLite Database. With Workers Cache, repeated requests for the same dynamic response are served from cache without running the Worker. This drastically reduces TTFB and contributes significantly to aggressive CWV targets. Furthermore, this Originless model, built on Workers and R2, is the optimal design for high-performance file distribution, eliminating the need for a traditional backend server to deliver large datasets and media.

Traditional Origin Optimization: For applications that cannot be refactored or modernized ↗︎ to an originless model, the following optimizations are required to minimize the resulting latency impact of traditional infrastructure:

• Connectivity: Cloudflare connects using HTTP/2 to Origin, using Connection Reuse to multiplex requests over a single persistent connection, reducing TCP/TLS overhead. Automatic key exchange predicts the origin's preferred TLS 1.3 key agreement — preferring post-quantum hybrid key agreement where supported — to avoid an extra round trip on new origin connections. For enhanced reliability and security, Cloudflare Network Interconnect (CNI) allows you to connect your network infrastructure directly to Cloudflare - bypassing the public Internet - for a more performant and secure experience. Additionally, the Bandwidth Alliance ↗︎ (including partners like Microsoft Azure Routing Preference ↗︎) can significantly reduce or waive data egress fees.
• Private Infrastructure: Workers VPC and Cloudflare Tunnel enable direct connectivity to private storage endpoints or databases on public clouds without necessarily exposing them to the public Internet.
• Load Balancing: Traffic is distributed across healthy servers using Cloudflare Load Balancing. If an origin fails, traffic is instantly rerouted to healthy server pools. Alternatively, Round-Robin DNS can be used for simpler distribution strategies.

Continuous monitoring and testing verify each optimization. Measurement and logging confirm real gains, surface regressions early, and reveal edge cases long before they affect clients.

When analyzing this data, it is important to take into account connection limits and TCP connection behavior, while also accounting for Cloudflare crawlers and the /cdn-cgi/ endpoint, as well as potential data discrepancies between Cloudflare and Google Analytics.

• Cloudflare Observatory ↗︎: The primary dashboard for performance. It combines Synthetic tests (Google Lighthouse) for standardized baselines with Real User Monitoring (RUM) to capture actual user experiences across different devices and regions.
• GraphQL Analytics API: Use this for Trends and Timing Insights ↗︎. Query specific metrics like edgeDnsResponseTimeMs versus originResponseDurationMs to pinpoint exactly where latency is introduced.
• Web Analytics: Specific for privacy-first, edge-based RUM analytics.
• Cache Analytics: Critical for analyzing Cache Hit Ratio (CHR) and "Requests by Cache Status" to find uncached content that causes origin load.
• Ruleset Engine: Review and use the extensive library of fields to implement precise custom logic for routing, caching, and security based on real-time connection properties. Key telemetry fields include: cf.timings.worker_msec (Worker execution time, for performance-regression rules), cf.timings.client_tcp_rtt_msec and cf.timings.client_quic_rtt_msec (client round-trip time per transport protocol), and cf.edge.l4.delivery_rate (L4 delivery rate in bytes per second, for adaptive content or routing decisions on constrained connections).
• Logging & Forensics:
  • Log Explorer: For ad-hoc querying of request logs directly in the dashboard. Use Custom Log Fields to log additional request headers, response headers, and cookies.
  • Logpush: For exporting logs to third-party SIEMs with optional Log Output Options, supporting formats such as CSV or JSON. Essential for analyzing custom fields and long-term trends, as well as calculating the Download Success Rate and analyzing Download Throughput for large files.
  • Instant Logs: Real-time traffic inspection for immediate debugging.
  • Network Error Logging (NEL): Captures client-side connectivity issues that the server might never see.

• Cloudflare Telescope ↗︎: An open-source, cross-browser front-end testing agent capable of running tests in all major browsers. Use this to automate performance regression testing in your CI/CD pipeline.
• Cloudflare Speed Test ↗︎: Measures realistic Internet connection quality - including loaded latency, jitter, and packet loss - by simulating real-world usage on Cloudflare's global network using predefined data blocks, rather than simply testing for peak throughput saturation.
• BEACON ↗︎: An anonymized RUM dataset on Google BigQuery, updated daily. Use it to compare your Core Web Vitals against real-world distributions by country, browser, and protocol.
• Cloudflare Prometheus Exporter ↗︎: Scrapes metrics from the GraphQL Analytics API and exposes them in a Prometheus-compatible format, allowing you to visualize Cloudflare performance data alongside your infrastructure metrics in Grafana or similar tools.

While Cloudflare provides internal metrics, external (third-party) tools are vital for independent validation and deep-dive analysis of the critical rendering path.

• WebPageTest ↗︎: Detailed waterfall charts and deep analysis of loading behavior.
• Google PageSpeed Insights ↗︎: The standard for Core Web Vitals assessment (Field & Lab data).
• DebugBear ↗︎: Excellent for continuous monitoring and tracking speed history.
• Pingdom ↗︎: Useful for simple, geographic-based availability and speed testing.
• Treo.sh ↗︎: Fast, historical visualization of Chrome User Experience Report (CrUX) data.