Cloudflare Application Performance
How Cloudflare makes applications fast
Cloudflare Application Performance
2026-07-23
Open the session. This is an internal enablement talk on how Cloudflare makes applications faster. Set expectations: we will build from first principles (the proxy and the life of a request) up to the specific products and finish with how to troubleshoot performance in the field.
What we'll cover today
2026-07-23
Walk the audience through the arc of the talk. Foundation first, then the three big product levers, then measurement and troubleshooting. Reassure them that every product we cover maps back to one simple idea: reduce the time and distance between a user and the bytes they asked for.
A simple model: get closer, do less, send less
2026-07-23
This is the mental model to carry through the whole deck. Every performance product is one of three moves: get closer (proximity), skip the work (avoidance via cache), or make the payload cheaper (optimization). When a customer asks "which feature do I need?", diagnose which lever is missing.
The L7 proxy and the life of a request
2026-07-23
Transition into the foundation. Before we get into any product, everyone should be able to explain what actually happens to a request. Everything downstream depends on understanding the proxy and the request lifecycle.
The network is the head start
2026-07-23
Ground the story in the network. Proximity is free and automatic because of Anycast and the size of the network. These numbers are the reason the edge is fast before we turn anything on. Keep the figures directional, not exact - the point is scale and reach.
Life of a request: eyeball to origin and back
2026-07-23
Walk the diagram left to right. DNS plus Anycast decide WHERE the request lands, the nearest colo terminates TLS, and FL2 runs the product pipeline as ordered stages - security, rules, cache, Workers. Trace the two return paths: a cache HIT short-circuits straight back to the user from the edge (dotted orange), while a MISS travels on to origin (dashed) and the response is optimized on the way home (muted return path). The single takeaway: origin is the exception, not the rule.
Inside the proxy: meet FL2
2026-07-23
Explain the proxy itself. FL2 is the Rust rewrite of the original Lua-on-NGINX proxy, built on Oxy and Pingora. The takeaway is not the language - it is that a modular, well-ordered pipeline gives predictable behavior and far better per-request observability, which is exactly what powers the tracing tools at the end.
Traffic sequence: order is everything
2026-07-23
Order is everything. Security runs first, then the Rules engine in a fixed order, then cache, Workers, and origin. Most "my rule didn't work" or "my Worker saw the wrong header" tickets are ordering problems. Have the audience internalize the sequence so they can debug by elimination.
Argo Smart Routing
2026-07-23
Move to the first paid performance lever: proximity to origin. Argo is about the path between the edge and the origin, not the path to the user.
Default Routing vs Argo
2026-07-23
Contrast default BGP routing with Argo. The public Internet optimizes for hop count and policy, not latency, and it is subject to congestion and peering detours. Argo uses live latency intelligence to steer each request over the fastest path across Cloudflare's backbone. This matters most for traffic that can't be cached.
How much faster is Argo?
2026-07-23
The headline number: roughly 30% average latency reduction. Be honest that results vary by origin location and traffic pattern - the biggest wins are for dynamic, non-cacheable traffic and distant origins. Also mention smoother tail latency and fewer connection errors.
When to use Argo
2026-07-23
Qualify the opportunity. Great fit: dynamic/API traffic, single or distant origin, global users hitting one region. Clarify the Argo vs Orpheus distinction - Orpheus is reliability (routing around origin failures, on by default) while Argo is the paid speed layer. Note Argo includes Tiered Cache.
Tiered Cache and Regional TC
2026-07-23
Pivot to avoidance - the biggest lever of all. Framing: the fastest origin request is the one you never make.
Caching 101
2026-07-23
Caching fundamentals. Teach the cf-cache-status header cold: HIT, MISS, EXPIRED, DYNAMIC, BYPASS. Static is cached by default; HTML and dynamic content need Cache Rules or APO. Always respect origin Cache-Control. Stress why caching dominates: every HIT is load and egress origin never sees.
Tiered Cache
2026-07-23
Explain the problem tiering solves: without it, every one of hundreds of data centers that misses goes straight to origin. Tiered Cache organizes colos into lower and upper tiers so a lower-tier miss checks an upper tier first. Result: higher hit ratio, dramatically less origin load, warmer upper tier closer to origin.
Tiered Cache topologies
2026-07-23
Cover the three topologies. Smart Tiered Cache is the zero-config default and the right answer for most zones. Generic Global gives broad coverage. Custom Topology is Enterprise-only for teams that want to pin exactly which colos are upper tiers. Recommend Smart unless there is a specific reason.
Regional Tiered Cache
2026-07-23
Regional Tiered Cache adds a regional tier between lower and upper tiers, consolidating regional misses before the long haul. Best for globally distributed audiences and large files where cross-region round trips hurt. Included for Enterprise. Position it as an add-on to Tiered Cache, not a replacement.
Speed settings and APO
2026-07-23
Third lever: make every byte count. Once you have proximity and avoidance dialed in, optimization shrinks and accelerates whatever still has to travel.
Speed settings: make the bytes cheaper
2026-07-23
Tour the Speed settings families: protocol (HTTP/3, 0-RTT, connection reuse), content (Brotli, Early Hints, Rocket Loader, Speed Brain, Cloudflare Fonts), and images (Polish, Mirage, Images/resizing). Note Auto Minify was retired in 2024. Close on Observatory as the measurement surface for Core Web Vitals.
Automatic Platform Optimization (APO)
2026-07-23
APO serves the entire site - including HTML - from the edge using Workers and Workers KV, so even dynamic CMS pages get cache-fast TTFB regardless of origin location. It stays correct by bypassing cache for logged-in users, admin paths, and cart/session cookies. Best fit: WordPress and similar CMS sites with a distant origin.
Troubleshooting: Tracing and Grafana
2026-07-23
Shift from features to diagnosing problems. This is the part engineers use every day. The discipline: isolate before you fix.
Name the slow phase before touching config
2026-07-23
Teach phase isolation. Slowness lives in exactly one segment: eyeball, edge, cache, or origin. Find it before changing config. Client-side signals first - cf-ray tells you the colo, cf-cache-status tells you the cache decision, Server-Timing and curl timing tell you where the seconds go. Then go deeper with internal tooling.
Two tools, two different questions
2026-07-23
Two internal tools, two questions. Tracing (tracing.cfdata.org) answers "what happened to THIS request?" - it replays a request through FL2 and shows which products, rules, and modules fired and the cache decision. Grafana answers "what's the TREND?" with aggregate dashboards sliceable by colo, zone, and time. Use both together.
Example use case: "the site is slow in ANZ"
2026-07-23
Work a realistic scenario end to end: "the site is slow in ANZ." Trend in Grafana shows high TTFB and low hit ratio in Singapore/Tokyo. A trace shows misses crossing the Pacific to a US origin with no tiering. Diagnose distant origin plus poor cache coverage. Prescribe Argo + Tiered/Regional Tiered Cache and raise coverage with Cache Rules/APO, then re-measure.
Thank you
2026-07-23
Close the session. Thank the audience, open the floor for questions, and point them at the tools and docs referenced throughout the deck (tracing.cfdata.org, Grafana, and developers.cloudflare.com).