What is TTFB by CPU performance
TTFB by CPU performance shows how Time to First Byte (TTFB) varies based on the performance tier of the user's device CPU.
This might seem unusual — since TTFB is a server-side metric — but it can be influenced by device class if you:
Use client hints or request fingerprinting to customize responses
Load resources conditionally at the edge
Have JS-controlled redirects or personalization logic that executes before navigation completes
Healthy TTFB by CPU performance sample
Should you worry
In a healthy view:
TTFB is consistent across CPU tiers
The server responds quickly regardless of device power
Client-side logic before navigation (if any) isn’t stalling the request
This suggests that your infrastructure and edge logic are robust and performance-aware.
Unhealthy TTFB by CPU performance sample
If TTFB is higher on low or mid tier CPUs, possible causes include:
Conditional client-side logic delaying page requests (e.g. JS collecting device data before navigating)
Edge personalization or A/B testing logic based on device hints
Custom scripts or frameworks intercepting requests and slowing things down
If high tier users are also affected, it’s more likely an infrastructure bottleneck — such as overloaded edge servers or slow backend APIs.
Resolving unhealthy TTFB by CPU performance
Go-to action plan to resolve an unhealthy TTFB by CPU performance:
Ask Uxi to analyze your TTFB by CPU performance values and suggest improvements.
Use Filters to isolate specific routes or traffic segments with poor TTFB.
Simulate TTFB of the suspected lens to see if fixing it will resolve the TTFB by CPU performance. If yes, this is where the resolution focus should be.
Use an automated optimization tool like Navigation AI to improve your TTFB by CPU performance values.
Once you’ve improved TTFB, set an alert to be the first to know if it starts worsening again.
Try it yourself
Discover how your website performs with real user data.