Suggest an editImprove this articleRefine the answer for “SSR and Time to First Paint”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)**Time to First Paint (TTFP)** is the time from the start of the page load to the **first visual change** the user sees. **Key point:** SSR can increase TTFP because the server has to render and wait for data before sending the HTML, while CSR sends static files right away.Shown above the full answer for quick recall.Answer (EN)Image## What TTFP is **Time to First Paint (TTFP)** is the time from the start of the page load to the **first visual change** (the first pixel the user sees). The lower the TTFP, the faster the user feels the page has "loaded". --- ## Why SSR can increase TTFP ### 1. The server has to **render before it responds** In CSR the server just serves static files (`index.html`, JS, CSS) - almost instantly. In SSR, however, the server: 1. Starts up the Node.js application. 2. Loads the needed data (fetch, DB, API). 3. Runs React/Vue/etc. to generate the HTML. 4. Only then sends the HTML to the client. All of this adds latency to **TTFB (Time to First Byte)**, and therefore to **TTFP** as well. Until the server finishes rendering, the browser has nothing to paint. > In other words: with SSR the browser **waits** for the server to "cook the dish", > while with CSR it gets the "raw ingredients" right away. --- ### 2. Network + distance to the server SSR increases the size of the response (a fully rendered HTML document is bigger than a bare template), and it also makes server rendering sensitive to **network latency**. - If the server is far away (or has no CDN), the request + response time grows. - A user in another country receives the HTML later. > With CSR and SSG this is solved with CDN caching, but with SSR it is not always possible because of the dynamic content. --- ### 3. JS execution is delayed until the HTML arrives Until the server delivers the finished HTML, the client **cannot start downloading the JS bundles**. With CSR the browser fetches JS and CSS **in parallel**, so JS can start executing sooner. > SSR -> "wait for HTML" -> then load JS > CSR -> "download JS right away" -> render an empty page faster --- ### 4. Slow server-side API requests If server rendering waits on responses from an API (for example, `getServerSideProps` in Next.js), each one directly adds to the delay before the first render. > One extra 300 ms request = +300 ms to TTFP. --- ### 5. No streaming (or using it incorrectly) If the server does not use **streaming SSR (React 18's renderToPipeableStream)**, it generates the **entire HTML at once**, not in parts. The browser cannot start painting until it receives the whole document. > Modern streaming SSR lets the First Paint start earlier, > but classic SSR does not. --- ## Summary: SSR improves *perceived* speed but can slow down the *technical start* | Loading stage | CSR | SSR | |---|---|---| | Sending the first byte (TTFB) | Fast | Slower | | Start of the first Paint (TTFP) | Faster (empty screen + JS) | Slower (waits for HTML) | | Displaying real content | Later (after JS) | Earlier (finished HTML) | That is, the **first pixel may appear later**, but the **first useful content appears earlier**. --- ## Conclusion SSR can **increase TTFP** because: 1. The server needs time to render before responding. 2. The response is larger and depends on API requests. 3. The client waits for HTML before it can start loading other resources. 4. Without streaming, the render is blocked entirely. --- **Key point:** > SSR makes content "visible" earlier, but the "first pixel" can arrive later. > That is why proper SSR is always paired with **streaming**, **CDN caching**, and **hybrid approaches (ISR, partial hydration)**. </content>For the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.