Jan Mikoláš
Glossary
Server-side rendering
SSR creates HTML in response to an HTTP request. It makes initial content available sooner, but does not eliminate server costs, the need for high-quality HTML, or any client-side JavaScript.
Short definition
The server loads data and passes a complete document to the browser.
With SSR, the backend receives a request, loads the required data, combines it with a template or frontend renderer, and returns HTML. The browser need not wait for a complete client application to obtain a heading, text, links, or a form. Conventional PHP applications and modern frameworks with server rendering both use this approach naturally.
SSR does not mean an application without JavaScript. After loading, a server-generated product detail can hydrate an add-to-cart button, filter, or form. The server and client content must remain compatible, and the basic path should make sense even when the script is delayed or fails.
The problem it solves
Delivering meaningful content before the client application starts
SSR is useful when the initial screen should provide data, navigation, or a form quickly and as standard HTML.
- a product detail, catalogue, or article that should be readable immediately after opening its URL
- an authenticated area of an application with forms, links, and server-side validation
- a website with limited client-side JavaScript and a strong emphasis on progressive enhancement
- a personalised page where the server already knows the user’s session and permissions during the request
- a combination with caching for public HTML responses that can be shared safely
Practical example
Product details are readable before the cart becomes interactive
The server loads the product, price, and availability from an authoritative source or suitable read model and returns HTML containing a heading, price, and add-to-cart form. The browser can display it immediately, while JavaScript later adds live variant changes or AJAX submission.
If the product is unavailable, the server returns the appropriate status and comprehensible content. Sending an empty shell and hoping the client will later discover what to tell the user is not appropriate. Personalised HTML must also not be accidentally served from a cache to another user without separation or correct headers.
PHP
$product = $productRepository->findPublished($slug)
?? throw new ProductNotFound($slug);
return $response->html('product/detail.php', [
'product' => $product,
]);How it works
From an HTTP request to the first HTML render
A server response can be a simple template or the result of a more complex rendering process. The browser always receives a standard document.
- The browser requests a URL The HTTP request carries a path and possibly a session cookie and headers, which the server evaluates only in a trusted context.
- The application loads data The backend verifies access, loads a product, article, or form state, and handles an error if the resource is unavailable.
- The renderer creates HTML A template combines the data with semantic structure, links, forms, and document metadata.
- The server sends the response The browser can parse and display the HTML before all supplementary client scripts have finished.
- JavaScript optionally hydrates it The client attaches event handlers and further interactions. If it disagrees with the HTML, an error or visible content shift can occur.
Key concepts
Initial HTML, hydration, and personalisation
SSR is a response-generation technique. The result’s quality depends on the HTML, data sources, and cache management, not only on where rendering occurs.
Template and renderer
The server creates a document from data and a template. This can be a PHP template, component renderer, or another mechanism, and does not necessarily require a separate frontend server.
Hydration
Client-side JavaScript takes over existing HTML and adds interactions. It is not an unconstrained rewrite of the content; server and client must agree on the output.
Streaming SSR
Some systems can send parts of the HTML progressively. This can improve perceived responsiveness but adds complexity around content order, errors, and caching.
Personalisation
An authenticated user may receive a different price, navigation, or permissions. Such a response cannot be indiscriminately stored in a public cache.
Progressive enhancement
Links and forms work as standard HTML, while JavaScript can make them faster or more convenient where needed.
Benefits and limitations
A quickly available document in exchange for work during the request.
Benefits
- meaningful HTML, links, and forms are available before JavaScript starts
- the browser can begin parsing and rendering content earlier
- URLs, navigation, and basic forms work naturally
- simpler progressive enhancement for many content and commerce journeys
Risks and common mistakes
- a slow database or integration source extends the response time of the whole page
- a personalised response is accidentally served from cache to another user
- extensive hydration that negates part of the benefit of the initial HTML
- a mismatch between server and client content during hydration
- assuming that SSR automatically ensures SEO, accessibility, or security
When it makes sense
For journeys where content should work and be readable immediately after opening a URL.
SSR is suitable for a catalogue, product detail, documentation, authenticated portal, and conventional forms. Its benefit grows when users need the initial content quickly and without depending on a large client bundle. For personalised routes, rendering cost and caching rules must be considered.
This does not mean that everything must be server-rendered. A rich administration interface may have a client-side dashboard, while its public catalogue and first screen benefit from SSR. The best boundary is determined by the nature of the data, interactions, operational costs, and availability without JavaScript.
What to consider
A server-generated document should be accurate, fast, and shared safely.
SSR’s advantage is a conventional web document; a solution that sends only an empty shell or ambiguously caches another user’s data loses it.
- measure response time and first display with a slow data source
- generate semantic HTML with headings, links, forms, and readable errors
- separate publicly cacheable content from a specific user’s session, price, and permissions
- test the basic path without JavaScript and verify content consistency before and after hydration
- do not expose a technical error or stack trace directly in the HTML response to the user
Common questions
SSR in practice
Does SSR use JavaScript?
It may, but need not. The server can deliver a fully usable HTML page that JavaScript subsequently enhances with interactions or uses to hydrate components.
Is SSR the same as a web server?
No. A web server receives HTTP requests and passes dynamic routes to an application. SSR is an application process that creates HTML from data.
Is server-generated HTML always better for SEO?
Not automatically. It helps deliver content directly, but the actual benefit depends on correct URLs, content, accessibility, performance, and indexing behaviour.
Can I cache every SSR page?
No. A public product detail may be suitable, but a response dependent on a session, customer-specific price, or permissions must be separated or not shared publicly at all.
How I work with web applications in practice
I choose rendering based on content, interaction, and operational boundaries.
When designing websites and applications, I connect HTML, the backend, caching, and APIs so that users receive a functional result even outside ideal network conditions.