Challenge 2: A Slow Screen and an Unhelpful CPU Trace — Solution Walkthrough

What to check next:

The Network Profiler.

Why, per this chapter's own warning box:

The developer assumed the slowdown was CPU-related and jumped
straight to that pane without confirming the assumption first — exactly
the mistake this chapter's warning box describes. The symptom
described (a delay specifically after opening a screen, before data
appears) is a classic sign of the screen waiting on a network request
to complete, which is precisely what the Network Profiler is built to
reveal: real request/response timing and payload size. Finding nothing
unusual in a CPU trace is itself a useful signal — it suggests the
bottleneck likely isn't heavy computation at all, pointing toward a
different resource entirely.

Why the CPU Profiler alone couldn't have caught this:

A slow backend request doesn't necessarily show up as unusual CPU
activity — the app may simply be waiting idle for a response to
arrive, which a method-time trace wouldn't flag as a problem at all,
since very little CPU work is actually happening during that wait.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise directly applies this chapter's own warning box to a
concrete scenario where checking CPU first genuinely didn't help,
correctly redirecting to the Network Profiler based on the specific
symptom described rather than continuing to dig deeper into CPU data
that already came back clean.