One of the most useful performance lessons I learned was also one of the least glamorous.

One of the most useful performance lessons I learned was also one of the least glamorous. Sometimes the frontend is not slow. It is waiting.

I saw this while working on a complex CPA platform with dashboards, documents, partner data, permissions, and data-heavy workflows.

The UI was not struggling because React was doing too much work. The browser was waiting too long before React even had a chance to start.

That is where TTFB became important.

Time to First Byte sounds like a backend metric. But for a frontend engineer, it tells a very practical story: how long the user waits before the browser receives the first piece of the response.

If that moment is late, everything else starts late too. HTML arrives later. CSS is discovered later. JavaScript loads later. The app initializes later. FCP and LCP move later. The user waits earlier than the frontend usually looks.

In a product like a CPA platform, that waiting time can hide many things: auth checks, permissions, partner data, offer data, document aggregation, personalization, API composition, cache misses, redirects, network distance.

Without measurement, all of that becomes one vague feeling: the page feels slow.

With measurement, the delay gets shape.

For example: Server-Timing: db;dur=121.3, api;dur=180.4, permissions;dur=72.6

Now the problem is no longer just "frontend performance."

The user may be waiting for permissions, aggregation, or database work before the screen can even begin.

That does not mean frontend engineers should replace backend engineers. But it does mean we should understand where the user is actually waiting.

Because frontend performance is not only about what happens after JavaScript loads.