Akamai Web Performance common mistakes
Akamai Web Performance · Understand the traps and how to avoid them.
Treating cache hit ratio as the primary goal and configuring very long TTLs on HTML and API responses, then shipping stale content to users after deploys.
Hit ratio is easy to measure and feels like the headline CDN metric, so candidates optimize it in isolation and forget that freshness requirements differ by content type.
What to do instead
Tie TTL policy to content class: long TTLs plus cache-key/version busting for immutable assets, short TTLs or revalidation for HTML and API responses. Evaluate hit ratio alongside origin offload and freshness/error rates, not as a standalone target.
Assuming the default cache key is sufficient and being surprised when personalized, geo-specific, or device-specific content is served to the wrong users.
Candidates picture the cache key as just the URL and overlook that cookies, headers, query strings, and device characteristics can or should participate in the key.
What to do instead
Explicitly reason about what varies the response, then configure the cache key (hostname, path, selected query parameters, selected headers, device type) to match, and strip or ignore irrelevant variance so you don't fragment the cache unnecessarily.
Confusing edge TTL, origin Cache-Control, and browser TTL, and predicting the wrong effective caching behavior when they disagree.
Multiple caching layers each have their own directives and override rules; candidates memorize one layer's semantics and apply them to all layers.
What to do instead
Learn the precedence at each layer separately (what the edge honors vs. what the browser honors, and where platform rules can override origin headers). Practice tracing a single request through browser cache, edge cache, and origin to state which TTL wins.
Diagnosing a performance problem from a single synthetic test run or a single geographic location and declaring the cause.
Synthetic tools are fast and give clean numbers, so candidates anchor on one measurement instead of correlating with field data and multiple vantage points.
What to do instead
Combine synthetic (controlled, repeatable) with real-user monitoring (representative), and compare across regions, devices, and connection types. Use percentiles rather than averages before attributing a cause.
Reading average page load time as the user experience and missing that a slow tail (p75/p95) is where most of the pain is.
Averages are the default output of many tools and look reassuring; the long tail is invisible unless you deliberately look at percentiles.
What to do instead
Report and reason about percentile distributions (p50/p75/p95) and segment by device/network/geo. When asked to improve 'performance', identify which segment drives the tail before proposing a fix.
Applying a front-end optimization (image compression, minification, lazy loading) and asserting a Core Web Vitals or load-time improvement without checking which metric it actually moves.
Candidates learn optimizations as a checklist and assume all of them improve all metrics, when some help LCP and others help CLS or INP, and some can even hurt.
What to do instead
Map each optimization to the metric it targets (e.g., LCP: critical resource priority, image sizing, preload; CLS: reserved dimensions; INP: reducing main-thread work). State the expected metric effect and verify it with measurement.
Blaming the CDN for slow responses when the real bottleneck is origin latency, TLS negotiation, or a redirect chain, because the candidate never isolates which phase of the request is slow.
The CDN is the visible layer in the request path, so it becomes the default suspect; candidates skip phase-level breakdown.
What to do instead
Decompose the request into DNS, connection/TLS, time-to-first-byte, and content transfer, and compare edge vs. origin timings. Attribute the delay to a specific phase before recommending a change.
Configuring property rules in the wrong order or with overlapping match conditions, so an intended behavior is silently overridden or never fires.
Rule evaluation order and match specificity are easy to gloss over; candidates test only the happy path and don't verify which rule actually applied.
What to do instead
Understand rule ordering and precedence, keep criteria specific, and verify with request/response debugging or logs which behavior was applied. Test the exact URL/header combination that should trigger each rule.
Turning on a security or delivery behavior (e.g., aggressive bot mitigation, strict geo/IP controls, or origin-pull restrictions) to fix one issue and breaking legitimate traffic or caching as a side effect.
Security controls are treated as set-and-forget toggles; candidates don't consider their interaction with caching, personalization, and legitimate client behavior.
What to do instead
Before enabling a control, state its effect on legitimate traffic and on cacheability, stage it in a test property or with monitoring, and have a rollback plan. Validate with representative real traffic, not just a single test request.
Making a production configuration change with no staged validation, no monitoring window, and no rollback path, and then being unable to explain how the change would be safely deployed.
Exam scenarios reward the 'correct' setting, so candidates jump straight to the answer and skip the operational discipline that surrounds a change.
What to do instead
Pair every configuration recommendation with a safe-change practice: validate in staging or a limited scope, monitor key metrics after activation, and keep a defined rollback. Treat operational safety as part of the answer, not an afterthought.