northdan.
Vezi pagina în română

IT Glossary

What is SSR (server-side rendering)?

Server-side rendering builds a page on the server, on every request, so it reaches the browser ready to display.

A white screen while scripts download and execute costs conversions and unsettles crawlers; server-side rendering is the technique that removes it. A page can reach a visitor in one of two states — assembled by the server, or as a kit the browser puts together itself out of JavaScript — and this is the first option: on every request the server composes the complete page, with all of its content, and delivers it ready to read. The contrast matters commercially for two reasons. Perceived speed is the first: a visitor reads content almost immediately instead of watching an empty screen while an application boots, and that difference is measurable in conversion rates on any page where somebody is deciding whether to buy. Search indexing is the second: the crawler receives complete markup on the first request, without depending on script execution, which makes indexing both faster and more reliable. For online stores and web applications whose dynamic content has to be findable in search, this is often the technique that reconciles a modern interactive interface with the requirement of being discovered at all. It is not free — every request consumes server resources, so hosting is more demanding than for static files, and caching has to be designed deliberately rather than hoped for later.

Let’s talk about your project

Message us on WhatsApp or send an email — you talk directly to a developer.

office@northdan.com · +40 752 070 247

Why it matters for your business

Content visible almost immediately

The page arrives already built, so a visitor reads at once rather than waiting for assembly in the browser — a direct gain in performance scores and in conversions.

Reliable indexing in search

Engines receive complete markup on the first request, so products and articles enter the index correctly, without the risks that come with script-dependent rendering.

Fresh data on every visit

For stock levels, prices or content personalised per user, generating on demand guarantees each visitor sees the current version rather than a stale copy.

Frequently asked questions

How is server-side rendering different from a conventional website?

Technically, conventional platforms also render on the server. The term is used specifically for modern applications built with component frameworks, where the server produces the first view and the application then becomes interactive in the browser — combining the initial speed of a traditional page with the behaviour of an application. The distinction matters when comparing quotes, because the same word can describe two quite different architectures at quite different prices.

Server-side rendering or static generation for an online store?

Usually a combination. Pages with volatile data — stock, price, basket, account — need rendering per request or frequent regeneration, while stable pages such as company information, guides and articles can be generated once at publish time. Modern frameworks allow the strategy to be chosen page by page, so this is not an all-or-nothing architectural bet, and treating it as one is a common way to overpay for hosting.

What are the downsides of rendering on the server?

Each request consumes server resources, so hosting is more demanding and more expensive than serving static files, and the application needs a caching strategy designed with some care rather than added under pressure later. The extra cost is justified where content is genuinely dynamic and has to be indexed. On a marketing site that changes a few times a year it is money spent solving a problem the project does not have.