A high TTFB on an almost empty WordPress response is useful because it lets you separate network/edge delay from PHP/database work without page-weight noise. Measure the same minimal route through CDN, direct origin and PHP so each layer gets its own timing.
Use one minimal reproducible endpoint
Choose a lightweight uncached request or controlled test page and repeat it. Mixing homepage, admin and REST timings makes layer comparison meaningless.
Measure edge and origin separately
Compare normal public traffic with a controlled direct-origin request using the correct Host/TLS context. A slow edge route and a slow origin are different incidents.
Time PHP before blaming WordPress content
Use application/server timing, PHP-FPM slow logs or request tracing to see whether execution waits for workers, external calls, filesystem or bootstrap work.
Measure database contribution
Inspect query count, slow queries, lock waits and connection time for the same request. A fast database plus slow PHP moves the investigation elsewhere.
Compare cold and warm requests
Object cache, opcode cache and page cache can make the second request misleadingly fast. Record cold/warm behavior and the cache state for each measurement.
Change one layer and repeat the same endpoint
After tuning network, worker capacity, PHP or database work, retest the identical request. A lower TTFB there is stronger evidence than a higher PageSpeed score on a different page.
Compare with first-byte diagnosis when cache is already enabled and use PHP-FPM request tracing when application time dominates.