April 1, 2025 ⏱️ 10 min
By Cristi C. (RnD – WebFrontend Group)
SSR and SSG are two acronyms that all developers come across when working for any extent of time on frontend projects.
The importance of these concepts cannot be understated especially for developers that are just starting out, but seniors should also make sure they have a good grasp as well.
This article plans to address the concepts of rendering and rendering strategy, SSR and SSG, how to choose between one or the other, what are the next steps and the cost implications of the two. Last but not least, it takes a look at the broader context of the ecosystem and other rendering strategies.
Rendering and Rendering Strategies
Rendering is the process of executing code to make changes to a page’s structure or content, while a Rendering Strategy refers to the approach used to generate and deliver the content of a page to the user’s browser.
The strategy determines whether the content is rendered on the client-side, server-side or during the build process, impacting factors like performance, SEO, and user experience. Clearly understanding these stepping stone concepts is a must and we could not have tackled the main subjects without at least mentioning them, simply because SSR and SSG are two such rendering strategies, but not the only ones.
A Look at SSR
SSR or Server-Side Rendering is a rendering strategy that focuses on or renders a page in real-time. When the user visits a website, the computer that hosts the website creates the page for them.
This is beneficial for:
- web pages that need to show real-time information
- updates, or content that frequently changes
- optimizing pages for search engines and social media sharing (if that is important for use case) by making indexing easier
- having a faster time to first byte compared to other methods such as CRS (Client-Side Rendering)
As developers we have learned that no framework, tool or technology is without tradeoffs, so is important to be mindful of what those are.
Implementing SSR also means:
- more complex build setups
- increased server loads
- somewhat increased load times (time to interact)
- requires higher technical skills to implement and maintain
- and last but not least efficient caching can pose a challenge since each page’s HTML differs
This means that developers face a balancing act between the pros and cons, so they need to rely on the technical expertise (and this article) to decide on the best option for each individual use case.
How SSR works
SSR is a multi-step process starting with the user request end ending with the requested information being rendered on the screen.
The reasonability largely rests on the server which does most of the heavy lifting, dealing with concerns like: caching, routing, data fetching and many more.
The flow diagram highlights this exact flow, but also pointing out the work that is being done on the front end.
The SSR dilemma
Wondering if SSR is the right choice for the project is a dilemma with which all developers are faced at some point and there are always nuances that help point the way.
The decision requires extensive knowledge of the project requirements, of the available tools and their limitations, but usually if you are building a: e-commerce platform (the next Amazon), social media platform (like LinkedIn), news web app, online banking app or booking platform, the general consensus is to seriously consider using SSR.
The next steps
The first step is the hardest in every journey, because it opens some roads while it may close others. Having decided to go with SSR developers are faced with the next step.
Should they build it from scratch or choose a framework? So let’s talk frameworks.
Unlike other ecosystems, the JS ecosystem is slow moving, with new libraries and frameworks not being released to frequently… Just kidding of course, since starting this article 10 more JS libraries/frameworks were released and everything discussed in this article is now obsolete.
Ahh… the joys of being a JS developer…
All jokes aside, this article focuses mostly on fundamental knowledge that is not expected to change frequently, but is important as a developer to always be aware of the latest developments in the field.
One of the, if not the most popular SSR libraries/frameworks is Next.js.
That said it is important to note, from the start, that this framework does also offer static rendering. This makes changing strategies a little more convenient since you don’t need to change library.
Also, if you haven’t used anything but “pure” React, Next.js is quite opinionated, so that might be a little frustrating when first starting out.
This is just the tip of the spear and it is not a must to use Next.js if you feel like it is not a fit for you. Luckily there are other out there: Gatsby, Nuxt.js, Gridsome, to name a few, each offering unique features and benefits like the rendering strategies.
These will be discussed at length in other articles. For now, it is important to point out the diversity and that there are many options to choose from.
A Look at SSG
SSG is of course another rendering strategy similar to SSR.
The similarity comes from the way a page(content) is generated on the server, however the page is rendered at build time. This means that instead of rendering the page at request time that page is already rendered on the server, waiting to be served to the client.
As expected this strategy, unsurprisingly, has both pros and cons.
This is great for:
- very fast page loads (since the data is pre-prepared)
- lower severe load and server costs
- better security (fewer attacks vectors)
- perfect option for CDNs
- simpler to deploy, host and scale
But, this also means:
- build time increases with site size
- not suitable for real-time data
- content updates require rebuilds
- limited dynamic functionality
- may require additional solutions for dynamic features
How SSG works
SSG is different, as we mentioned, because it takes a lot of load from the server at run time and it moves it at build time. As such, the flow is simplified conceptually although comparing the previous SSR diagram with the SSG we can see that a lot of the steps are common.
Visualizing the process in a diagram helps sediment our understanding and better highlights the process.
The SSG dilemma
As for SSR, the general community consensus is that if the use case requires having static data that never changes, SSG is the usually the right option.
The aim of this article is to offer sufficient information without being overwhelming, providing just enough to give you an understanding of both strategies and guide you in the right direction.
The next steps
Fortunately, choosing SSG doesn’t lock us into a one-way path, as most frameworks support both SSR and SSG. So, if a project’s needs change and SSG is no longer suitable, switching frameworks becomes one less concern.
As previously mentioned, we recommend exploring Next.js, Gatsby, or Nuxt.js.
Hybrid Approach
Choosing one strategy over the other might not be feasible due to project requirements and for such situations it is always important to not lose sight that a hybrid approach is also an option, provided by the frameworks.
Next.js is a library that provides a hybrid approach, allowing the developers to gain benefits from both static site generation (SSG) and server-side rendering (SSR). Using it, the key decision remains in choosing the right rendering strategy based on the content presented in each page:
- SSG (getStaticProps) – Best suited for static content that doesn’t change frequently, such as blog posts, product listings, or marketing pages.
- SSR (getServerSideProps) – Ideal for user dashboards, dynamic content that requires real-time updates or authentication.
The Vast Ecosystem
Strategies
At the beginning of the article, it was mentioned that SSR and SSG are not the only strategies available.
So, having a wealth of knowledge at our disposal from which to draw upon is what makes the different between a developer and an engineer. While knowing the most popular option/s is a good start, developers should never stop at that.
As the saying goes: “if you only have a hammer everything starts to look like a nail”.
In no particular order the available rendering strategies:
- Client-Side Rendering (CSR): Content is rendered entirely in the browser. Initially, only a minimal HTML page is sent to the client.
- Incremental Static Regeneration (ISR): Combines static generation with server-side updates. Pages are statically generated but can be updated on-demand.
- Progressive Rendering: Gradually renders content in chunks to enhance perceived performance. Techniques like lazy loading fit here.
- Edge-Side Rendering (ESR): Content is pre-rendered or personalized at edge servers close to the user for ultra-fast performance.
- Rehydration: Initial page load is static or server-rendered, and JavaScript reactivates dynamic content afterward.
- Streaming Server Rendering (SSR Streaming): HTML is streamed progressively to the client during server rendering to speed up the visible part of the page.
- Static Pre-Rendering (SPR): Pages are pre-rendered and cached on first load, then served statically on subsequent requests.
- Hybrid Rendering: Combines different strategies like SSR, SSG, and CSR based on page or route requirements.
Frameworks
Since the JS ecosystem is extensive, it is important to note some of the most used frameworks by the community:
- Gatsby.js: A popular React-based SSG renowned for its suitability for static webpages due to its extensive capabilities and optimal performance.
- Nuxt.js: A popular Vue.js framework that supports SSG and SSR, providing many features for building modern online apps.
- Remix: A React-based SSR framework for building fast, dynamic web applications. Remix focuses on fluid navigation and data fetching, making it an excellent solution for apps that require complicated routing and server-side data exchanges.
- Angular Universal: An Angular extension that pre-renders Angular applications on the server, which improves SEO and speeds up initial load times.
The Costs
One important aspect that was briefly mentioned, but is important to reiterate, regarding the SSR and SSG strategies is the cost. For any company the costs involved with development, hosting, maintenance, all adds up and can affect the viability of a product on the market.
Quite simply put, the more it takes to develop the product, the more the product will cost.
For example, choosing SSR will involve higher server costs, higher maintenance costs and higher technical skill costs (needing more experienced developers). That doesn’t mean that teams should not use SSR, in fact in a lot of scenarios it is a must, but it is important to always keep in mind that if not chosen wisely, decisions might have a negative impact.
Conclusion
This article set out to discuss two of the available rendering strategies SSG and SSR, their pros and cons, their strengths and weaknesses and last but not least their implication on the team and project viability in the market.
The ecosystem offers a lot of options for both strategies and based on the use case developers can choose to use both (this is facilitated by frameworks like Next.js).
As always knowing the technical details is just one part of being a good engineer. Understanding the project’s goal and limitations in order to make the perfect pairing between technology and requirements is also very crucial.
Wish you, Happy coding!
Îndemnul nostru
Efortul pus în programele pentru studenți completează teoria din facultate cu practica care “ne omoară”. Profitați de ocazie, participând la cât mai multe evenimente!
În cei 3 ani am lucrat la proiecte diverse ce au contribuit decisiv la evoluția mea profesională. Am colaborat strâns cu echipe remarcabile, a căror dedicare și sprijin au fost fundamentale în buna dezvoltare a lucrurilor. Cu fiecare proiect, am învățat nu doar aspecte tehnice, ci și abilități esențiale de comunicare și colaborare, reflectate în experiența mea privind interacțiunile cu clienți și modul în care o echipă eficientă operează. Aceasta este cultura companiei, de la ritmul uneori alert al zilei de lucru și practicile Agile, până la momentele relaxante de socializare cu colegii în pauzele de cafea și activități recreative precum darts și ping pong.
Am făcut cunoștință cu echipa NetRom prin intermediul programelor Internship și NetRom Software Academy, in care am descoperit că noțiunile învățate acasă au totuși aplicabilitate, chiar în cadrul unor aplicații reale. Acele experentie m-au convins să aplic pentru un job.
Mentorii foarte deschiși și colegii cu experiență care mi-au răspuns prompt la toate neclaritățile au transformat provocările în task-uri rezolvate cu succes împreună. Făcând parte din #teamnetrom mi-am depășit frica de a greși și am evoluat într-un mod echilibrat pentru mine.
Am aflat de programele NetRom de la o prezentare organizată în facultate de companie. Am decis să mă înscriu la Summer Camp din dorința de a înțelege ce anume ar presupune o cariera în IT. În urma acestui stagiu de practică, am reușit să dezvolt propria aplicație cu ajutorul mentorilor care mi-au oferit informații teoretice, dar mai ales practice, pe care nu aș fi putut sa le găsesc într-un tutorial aleatoriu de pe internet. Modul meu de abordare a aplicaților s-a schimbat odată ce am înțeles în ce constă mai exact procesul, ce presupune un mediu real de lucru și importanța muncii în echipă.
NetRom Software Testing Academy a fost punctul de plecare pentru o carieră pentru mine. Pe parcursul sesiunilor am avut oportunitatea să cunosc bazele necesare pentru asigurarea calității unui produs, urmate de o zi în companie unde am văzut teoria pusă în practică.
Recomand tuturor celor care își doresc o carieră în QA să ia în considerare această academie, fiind destinată atât celor din domeniu, dar nu numai.
Am descoperit NetRom prin intermediul unui program de internship și am fost impresionată încă de la început de mediul de lucru plăcut, de susținerea și angajamentul colegilor. A fost o oportunitate deosebită de a lucra într-o echipă de proiect, cu roluri specifice, și de a înțelege mai bine cultura companiei. Întreaga perioadă s-a dovedit o experiență valoroasă, atât din punct de vedere al cunoștințelor acumulate, cât și prin prisma relațiilor dezvoltate. În momentul în care mi s-a propus să continui ca angajat permanent, a fost o decizie ușor de luat, bucuroasă fiind să pot aplica cele învățate, dar și să adaug cunoștințe noi în fiecare zi.
