Server-rendered is not a score: TTFB, the 75th percentile and headers on every response

Server-rendering gets credited with speed it does not automatically deliver. On Abbys Consult, a server-rendered showcase platform for an independent Belgian consulting firm, we measured time to first byte under 200 ms and zero technical SEO issues at launch. The first number is useful, but it is not the score anyone is grading. TTFB measures the time between starting to navigate to a page and when the first byte of a response begins to arrive. Nothing more than that.

TTFB is a diagnostic, not the grade

Good TTFB values are 0.8 seconds or less, and poor values are greater than 1.8 seconds, which makes it a reasonable health check on your origin. But TTFB is not a Core Web Vitals metric, and it is not absolutely necessary that a site meets the good threshold, provided that it does not impede its ability to score well on the metrics that actually matter to the assessment.

This is where the server-rendered trade becomes explicit rather than ideological. A server-rendered site that does not require as much client-side work could have a higher TTFB but better FCP and LCP values than an entirely client-rendered experience. You are buying time on the server to avoid work on the device. Judge that trade on what the visitor sees rendered, not on the byte that arrives first.

The three thresholds that decide passing

To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading, and pages should have an INP of 200 milliseconds or less. Tools that assess Core Web Vitals compliance should consider a page passing if it meets the recommended targets at the 75th percentile for all three of the Core Web Vitals metrics. All three. Passing two of them is not passing.

Measure at the 75th percentile, segmented

A good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices. The segmentation is the part that gets skipped. A median taken from a fast desk machine on a wired connection hides exactly the slow quarter of loads that decides the outcome. Set up percentile and device-class reporting before anyone argues about rendering strategy, because without it the argument has no scoreboard.

Security headers are a response concern, not a deployment afterthought

A Content Security Policy should be delivered to the browser in the Content-Security-Policy response header, and it should be set on all responses to all requests, not just the main document. To control script loading as a mitigation against cross-site scripting, recommended practice is to use nonce- or hash-based fetch directives, which is called a strict CSP. On Abbys Consult, hardened security headers were part of the build from day one.

Report-only before enforce

To ease deployment, CSP can be deployed in report-only mode: the policy is not enforced, but any violations are sent to the reporting endpoint specified in the policy. That gives you an inventory of what the pages actually load before you start blocking anything. One caveat is worth repeating to anyone who treats a policy as a patch: setting a CSP is not an alternative to sanitising input.

Misconfiguration is now the second most serious risk

In the OWASP Top 10:2025, Security Misconfiguration moved up from #5 in 2021 to #2 in 2025. Broken Access Control maintains its position at #1 as the most serious application security risk; the contributed data indicates that, on average, 3.73% of applications tested had one or more of the 40 Common Weakness Enumerations in that category. Neither of those is a framework choice. Both are configuration and route-guard work.

Two further items from the same list belong on the operations checklist of any small-business platform. Great logging with no alerting is of minimal value in identifying security incidents, so the logs that matter have to reach a human through an alert. And Mishandling of Exceptional Conditions is a new category for 2025: how a platform behaves when a dependency fails is now a rated risk, not a detail.

If you are commissioning or reviewing a server-rendered platform, ask for three numbers and one artefact: LCP and INP at the 75th percentile, segmented across mobile and desktop; TTFB as an origin health check against the 0.8-second line; and the Content-Security-Policy header as actually returned on a request that is not the main document. Abbys Consult launched with time to first byte under 200 ms and hardened headers from day one. Those were measurements, so ask for yours in the same form.

Sources

OWASP — Top 10:2025 Introduction — https://top10.owasp.org/2025/0x00_2025-Introduction/

MDN Web Docs — Content Security Policy (CSP) — https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP

web.dev (Google Chrome) — Web Vitals — https://web.dev/articles/vitals

web.dev (Google Chrome) — Time to First Byte (TTFB) — https://web.dev/articles/ttfb

Neurolinks case study — A consulting firm, dressed for trust — https://neurolinks.be/work/abbys-consult