Q14 of 38 · Performance
What's the difference between server-side and client-side performance metrics?
Short answer
Short answer: Server-side measures backend behaviour (request latency, DB time, throughput) — load tools and APM see this. Client-side measures user experience (FCP, LCP, INP, TTFB) — RUM and Lighthouse see this. Both matter; tools see only one half each.
Detail
Server-side metrics — what the backend reports about itself. Request duration measured at the load balancer or app server, DB query time, queue depth, error rate, throughput. Tools: Datadog APM, New Relic, k6's http_req_duration. These tell you whether the system is healthy, but they stop at the response leaving the server.
Client-side metrics — what the user actually experiences. Web Vitals are the modern standard:
- TTFB (Time to First Byte) — bridges server and client; how long before bytes arrive.
- FCP (First Contentful Paint) — when first content renders.
- LCP (Largest Contentful Paint) — when the biggest element renders. Google's threshold for "good" is < 2.5s.
- INP (Interaction to Next Paint) — replaced FID in 2024; how responsive is the UI to clicks. < 200ms is good.
- CLS (Cumulative Layout Shift) — visual stability.
These are measured by RUM (Real User Monitoring — actual users in production, e.g. Datadog RUM, Sentry Performance) or synthetic tools (Lighthouse CI, WebPageTest).
Why both matter: a 100ms server-side response can still feel slow if the JS bundle is 5MB or the image is unoptimised. A 2s server-side response can feel acceptable if the page renders progressively. Server-side optimisation alone won't fix a slow user experience; client-side optimisation alone won't help if the API is genuinely slow.
Practical pairing: k6 + RUM. k6 catches API regressions at PR time; RUM catches end-user regressions in production where real network, devices, and JavaScript bundles matter.