Performance Auditing: Analyzing TTFB and Cache Efficiency

Previously in this course, we explored CI/CD: Deployment Pipelines for Cloudflare Workers, where we automated the delivery of our code. Now that our infrastructure is automated, we must ensure it is actually fast. This lesson focuses on Performance auditing: shifting from "it feels fast" to "it is measured fast" by analyzing TTFB, cache efficiency, and Core Web Vitals.

Understanding Performance from First Principles

Performance isn't just about raw speed; it’s about the perceived experience of your user. When we talk about Performance, we are primarily concerned with how quickly a browser can request, receive, and render your application.

The most critical metric for your backend—especially when using a CDN like Cloudflare—is Time to First Byte (TTFB). TTFB measures the duration from the user's request until the first byte of the response arrives. If this is high, your user is staring at a blank screen, regardless of how fast your frontend code is.

To keep TTFB low, we rely on two things:

1. Edge Presence: Serving content from a server close to the user.
2. Cache Hit Ratio: Ensuring the request is served from the CDN's cache rather than traveling all the way to your origin server (the "long trip").

Analyzing Performance with Browser Tools

Your browser’s Network tab is your primary diagnostic tool. Open your application, open Developer Tools (F12), and navigate to the Network tab.

1. Observe the "Waiting (TTFB)" metric: Click on any asset (a CSS file, a JS bundle, or your main HTML page). Look at the "Timing" tab.
2. Check for cf-cache-status: In the "Headers" tab, look for the cf-cache-status response header.
   • HIT: The asset was served from the edge. This is your goal for static assets.
   • MISS or EXPIRED: The request reached your origin. If this happens for files that should be cached, your Configuring Cache Rules for Advanced Performance and TTL Control settings need adjustment.

Leveraging Cloudflare Analytics

While browser tools show you what one user sees, Cloudflare Analytics shows you what all users experience.

Navigate to your Cloudflare dashboard and select Analytics & Logs > Traffic. Here, you can see a breakdown of:

• Cache Hit Ratio: This percentage tells you what portion of your traffic is being offloaded from your origin. A low ratio often indicates that your TTLs are too short or that you are accidentally caching dynamic, user-specific data.
• Bandwidth usage: High bandwidth on origin suggests you aren't maximizing the CDN effectively.

Worked Example: Identifying a Performance Bottleneck

Let's assume our project—the R2-backed asset server—is showing high TTFB for images.

Step 1: Check the Headers When you request an image via your browser, you see:

HTTP
cf-cache-status: MISS

This confirms that every single user request is hitting our Worker and potentially our R2 bucket.

Step 2: Compare against Baseline If we see cf-cache-status: HIT, but the "Waiting (TTFB)" is still high (e.g., > 200ms), it means the edge is struggling to fulfill the request, or we have a network latency issue between the edge and the client.

Step 3: Optimization Strategy If we find we are missing the cache, we would head back to the Dashboard to create a Cache Rule:

• Rule: If ends_with(http.request.uri.path, ".jpg")
• Action: Set Edge Cache TTL to 1 month.

After applying this, refresh the page. You should now see cf-cache-status: HIT for that image, and your TTFB should drop significantly as the edge serves it directly.

Hands-on Exercise

1. Audit: Open your project in a private browser window. Use the Network tab to check the cf-cache-status of your primary assets.
2. Analyze: If you see any MISS statuses for static assets, identify why. Is it missing a Cache Rule? Is the file too large?
3. Report: Create a small text file in your project repo called audit.md. List your current average TTFB (from the Network tab) and your current Cloudflare Cache Hit Ratio percentage.

Common Pitfalls

• Caching Dynamic Data: Never cache a response that contains sensitive user data or authentication tokens. Always test your Cache Rules to ensure they only apply to truly static assets like images, CSS, and JS.
• Ignoring Core Web Vitals: Remember that Decoding Core Web Vitals for Performance: A Practitioner’s Guide is the ultimate goal. A high cache hit ratio is a means to better LCP and INP, not the end goal itself.
• Testing while Logged In: Many browsers or servers bypass cache when they detect session cookies. Always test performance in an Incognito window to see what a "cold" user experiences.

FAQ

Q: What is a "good" Cache Hit Ratio? A: For a static-heavy site, aim for > 90%. For dynamic apps, 30-50% might be considered excellent.

Q: Does a HIT always mean low TTFB? A: Usually, yes. However, if your browser is on a slow 3G connection, the "download" time will be high, even if the "Waiting (TTFB)" is low. Always isolate your testing to a stable connection.

Recap

We've moved from basic deployment to measuring the effectiveness of that deployment. By utilizing the browser's Network tab to inspect cf-cache-status and monitoring the Cache Hit Ratio in the Cloudflare dashboard, you can systematically drive down TTFB and improve user experience. You are now prepared to perform a full system audit.

Up next: Project Milestone: Final Production Audit