Server-side rendering

Server-side rendering is a way of generating a web page where the HTML is built by a server at the moment the page is requested. The server fetches the data the page needs, renders a complete HTML document, and sends it to the browser. The browser can start displaying content immediately. JavaScript then hydrates the page to make it interactive. ## SSR vs client-side rendering The alternative to SSR is client-side rendering (CSR). In CSR, the server sends a nearly empty HTML shell plus a JavaScript bundle. The browser downloads and runs the JavaScript, which then fetches the data and renders the page. Nothing is visible until the JavaScript executes. SSR trades a bit of server work for faster initial paint and better crawlability. CSR trades slower initial paint for lower server cost and a more app-like experience. Modern frameworks like Nuxt and Next.js support both and let each page pick the model that fits. ## SSR vs static generation SSR is not the same as static site generation. Static generation builds HTML at build time and serves the same file to every request. SSR builds HTML on demand and can include per-request data like the logged-in user, region-specific pricing, or personalized recommendations. For ecommerce, this distinction matters. Product detail pages, cart, and checkout usually cannot be fully static because prices, inventory, and cart state change constantly. SSR handles those. Marketing pages, blog posts, and category shells can often be static. A modern frontend mixes both. ## Why SSR matters for commerce Fast first-paint improves conversion. Google uses page speed as a ranking factor, and Core Web Vitals measure how fast users see and can interact with content. SSR helps because the first byte the browser receives is already useful HTML rather than an empty shell. SSR also helps crawlers. Search engines and social media previews read the initial HTML response. When product pages are server-rendered, structured data, meta tags, and Open Graph tags are all in the initial payload. When they are client-rendered, crawlers can miss content unless they execute JavaScript, and many do so unpredictably. ## The tradeoffs SSR is not free. Each request costs server time, which means hosting is more expensive at scale than serving static files from a CDN. Caching helps but adds complexity. Getting SSR right on a busy storefront requires attention to cache strategy, database load, and failure handling. Frameworks abstract most of this, but the underlying work is real. ## How Frntkey relates Frntkey is a Nuxt.js frontend that uses server-side rendering by default. Pages are rendered on Vercel's edge and cached where possible. Product listings and detail pages are server-rendered so the first paint contains real content, real prices, and real availability. Marketing pages authored in Storyblok are cached and revalidated. Cart and checkout are dynamic and fetch fresh data on each interaction. The mix keeps first-paint fast, crawlers happy, and commerce data current. ## Related terms Static site generation · Core Web Vitals · Jamstack · Ecommerce frontend