Server-side rendering (SSR)

SSR is the opposite of client-side rendering, where the server sends a near-empty page and the visitor's browser builds it with JavaScript, as in a single-page application. Traditional PHP sites such as WordPress, the classic dynamic website, have always rendered on the server; the term is used most today for JavaScript frameworks that can do both.

SSR is also different from static generation, where pages are built once ahead of time by a static site generator and served as files. SSR builds the page fresh for each request, which suits content that changes often or differs for each visitor.

How it works

A visitor requests a page. The server runs the page's code, fetches whatever data it needs from the database or APIs, fills in the template and sends back finished HTML. The browser can display the content as soon as it arrives, before any JavaScript has run, and search engines read the same complete HTML.

In modern frameworks such as Next.js, the browser then downloads the page's JavaScript and attaches interactivity to the HTML it already has, a step called hydration. Until hydration finishes, the page is visible but buttons and menus may not respond, so heavy JavaScript can still make an SSR page feel sluggish.

The cost of SSR falls on the server. Every request means work, so busy sites rely on caching to store rendered pages for a while and serve copies. The time taken to build the page also adds to the wait before the first byte arrives, which is why slow database queries hurt SSR sites directly and why they are often the first thing to examine.

Example

A travel agency's tour pages show live seat availability and prices that change through the day. Building them ahead of time would mean stale prices, and building them in the browser would leave search engines looking at empty pages. With SSR, each request produces a complete page with the current price, readable by Google and by the visitor's phone straight away.

During a busy sale, the server struggles to render every request. The developer adds a short cache so each tour page is rendered at most once a minute and served to everyone else from the cache. Prices are at most a minute old, availability is checked again at booking, and the server load drops sharply.

Why it matters for your business

For public pages, SSR or static generation is usually what you want, because visitors see content sooner and search engines and AI crawlers can read it reliably. The trade-offs are hosting and complexity: SSR needs a server that runs code for each request, which costs more than serving static files and needs monitoring. For pages that change rarely, static generation is cheaper and faster. Ask your developer which pages are rendered on the server, which are pre-built and why, and how the server copes with a sudden rush of visitors. You can get a rough sense yourself by viewing the page source: a server-rendered or pre-built page shows its full text there. Speed tests that report the time to the first byte also reveal when server rendering is slow, because that figure grows when the server takes a long time to build each page.

Common mistakes

• Rendering every page on every request when most content changes rarely and could be pre-built.
• Running slow database queries during rendering, so every visitor waits for them.
• Assuming SSR fixes speed on its own while still sending a large JavaScript bundle to hydrate.
• Caching pages that contain personal details, so one visitor is shown another's information.

Questions people ask

What is the difference between SSR and static site generation?

With SSR, the server builds each page when it is requested, so it can show current or personalised data. With static generation, pages are built once in advance and served as files, which is faster and cheaper but means content updates require a rebuild.

Is server-side rendering better for SEO?

Generally yes, compared with pages built only in the browser, because search engines and AI crawlers receive complete HTML straight away. Static generation is equally good for SEO. Rankings still depend on content quality, titles, links and speed.

Does WordPress use server-side rendering?

Yes. WordPress builds each page on the server with PHP and sends finished HTML, which is classic server-side rendering. Caching plugins then store those pages so they do not have to be rebuilt for every visitor.