You don't want to Server-side Render your Next.js App

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Next.js is a fantastic framework; it provides many unique features, helping you build any web application effortlessly. But when it comes to choosing the right rendering strategy for your pages, you may face a problem; how should I render them? Should I statically generate them at build time? Should I server-side render them at run-time? Well, the answer is surprising. server-side rendering is rarely the best option, and let's explore why (and how to solve this problem!)

This talk has been presented at React Summit 2022, check out the latest edition of this React Conference.

FAQ

Next.js is a React framework that enables functionalities such as server-side rendering and static site generation, allowing for better performance, SEO, and more secure applications. It handles page transitions without needing a page refresh, making applications feel more like native apps.

Client-side rendering in Next.js allows for dynamic interaction without page refreshes, reduced server load, and scalability since static assets can be hosted on a CDN. It's particularly beneficial for apps that require frequent UI updates without server interaction.

Server-side rendering (SSR) in Next.js processes HTML content on the server before sending it to the client, improving initial load times and SEO. SSR can also enhance application security through server-side cookies and reduce the risk of client-side data exposure.

Static site generation (SSG) pre-renders pages at build time, serving them as static HTML files. This method provides high performance, security, and reliability, as the pre-rendered pages can be distributed globally via CDNs, minimizing server load and response times.

Incremental static regeneration (ISR) allows pages rendered using static site generation to be updated in the background at runtime. This technique provides the benefits of static generation with the flexibility to update content when needed without rebuilding the entire site.

Hybrid rendering in Next.js allows developers to choose the appropriate rendering method for each page or component. This flexibility can optimize performance and user experience by combining static generation, server-side rendering, and client-side rendering as needed.

While server-side rendering improves SEO and load times, it can lead to increased server workload, higher maintenance costs, and the need for more powerful server infrastructure to manage rendering processes effectively.

The speaker suggests avoiding server-side rendering due to its inefficiency in handling JSX, high server demands, and the significant costs associated with scaling server resources to meet application demands.

Michele Riva
Michele Riva
28 min
21 Jun, 2022

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Next.js is a framework that allows for client-side rendering and easy page transitions. Server-side rendering offers a more secure application and better search engine optimization but requires a server. Static site generation provides outstanding performance and scalability but has limitations. Incremental static regeneration solves the problem of rebuilding the entire website. Choosing the right rendering strategy depends on the specific scenario, and for e-commerce websites, static site generation with incremental static regeneration is recommended.

1. Introduction to Next.js and its Benefits

Short description:

Hello, everyone! I'm Michele, a senior software architect at NearForm, and the author of Real-World Next JS. NearForm is a professional services company specializing in Node.js, React, Next.js, TypeScript, and maintaining open-source packages. Now, let's dive into Next.js. It's a beautiful framework that allows for client-side rendering, providing a native app-like experience with easy page transitions and lazy loading of components. Plus, it doesn't require a server if you don't need one.

Hello, everyone, and welcome to my talk, You Don't Want to Serve a Set Renderer, Your Next JS App. Before we start, let me please introduce myself really briefly. I am Michele. I work as a senior software architect at NearForm. I'm a Google developer expert and a Microsoft MVP. I am also the author of Real-World Next JS, which is a book that, as you may guess, talks about Next.js. So if after the talk you'd like to hang out and talk about Next.js, please feel free to reach out. I'd be glad to talk with you.

A couple of words about NearForm. We are a professional services company, and we're specialized in Node.js, React, Next.js, TypeScript, and whatever. We are maintaining a lot of open-source packages that get downloaded 1.2 billion times per month cumulatively. So if you're looking for a remote-first job and you're really committed to open source, please feel free to reach out. I'd be glad to introduce you to the company.

But that's not why we are here, so let's talk about Next.js. First of all, what is Next.js? Why do we want to use it? And why is it so beautiful? When React started to be a thing, we only had client-side rendering basically. So that was the norm. We basically generate a big bundle and serve it over the net. This bundle will contain the whole application and as soon as it gets transferred to the browser, the browser will read the file, the JavaScript file, execute it, and we'll have the DOM ready to be browsed.

So basically, the problem with this approach, but we will see many problems later on, is that this is what we see when we first download the bundle. So while it's downloading, while it's executing, we see a spinner. After several seconds, we will see the complete page ready to get browsed. So this approach has some cons and has some pros. So let's see why it might be a good or a bad choice. So first of all, it makes you feel your app, like it's a native application, and that's because page transitions are really easy to handle, and you don't have to refresh the page every single time. Every time you click on a button, for example, and you go to another page, you don't need a page refresh. You already have all the components you need that gets lazy loaded directly into the browser. So for example, you're in the home page, you click to read an article, the whole DOM refreshes, but the page doesn't. So the DOM React will swap the content with the new one, and will execute lazy components that haven't been executed yet during the first load. One other great thing about client-side rendering is that you don't need a server. And if you need because you already have one and you want to serve your client-side application from a server, it doesn't require much power.

2. Pros and Cons of Server-side Rendering in React

Short description:

And there's no server workload, which is pretty good because it's really easy to scale. But if you don't have a server that's still good, you can just put your files, static assets, on a CDN on S3 on AWS, for example, or using Cloudflare pages, or whatever. And you just can host an entire application directly from something that doesn't need a server at all. While this is good for many things, it also has some problems, for example, with search engine optimization. React is not particularly good for search engine optimization, especially in markets outside of Europe and America. Additionally, React has a slow initial page load time. Server-side rendering offers a different approach, providing a more secure application, compatibility for non-JavaScript users, and enhanced search engine optimization. However, it requires a server and comes with higher maintenance costs.

And there's no server workload, which is pretty good because it's really easy to scale. But if you don't have a server that's still good, you can just put your files, static assets, on a CDN on S3 on AWS, for example, or using Cloudflare pages, or whatever. And you just can host an entire application directly from something that doesn't need a server at all.

While this is good for many things, it also has some problems, for example, with search engine optimization. We all know that React, it's not particularly good for search engine optimization, which is true. But it really depends on the market you care about. For example, if you care for the European and American market, we know that Google is the number one search engine and Google today is capable of indexing React content. But there might be other search engines that are more popular in other continents, such as Asia, for example, or Africa, that does not read React generated pages. So if you truly care about those continents and markets, you should definitely look into something different for building your application.

Another con is that React is really bad for the initial page load time, as we saw. So the first time you download a bundle, you just have to wait several seconds in order to be able to browse it. So this is why we begin to see server-side rendering as a different way for approaching React rendering specifically. With server-side rendering, this is what you get as soon as you request a page. It might take a couple of seconds, because the server still needs to render the application on the server side, but eventually it will send you the complete page ready for browsing.

So this approach also has some pros and cons. Let's see them. One pro, the application might be a bit more secure. That's because you might have server-side cookies, for example, for authentication, and you don't have to share those cookies with the client, which makes your application more secure. You can hide some requests from server to server without exposing them on the client. That limits the possibility for a man-in-the-middle attack, for example. Also, you end up having more compatible websites. If you don't have JavaScript enabled, you will still see the first render for your application. Search engine optimization is enhanced thanks to server-side rendering, because you basically end up having a product which is the same that you might have with Ruby on Rails, JavaScript Boot, Laravel, or whatever. The content can be highly dynamic, and you can have that kind of dynamism directly on the server. So, depending on the user that is currently logged in, for example, you might decide to render different things directly on the server. Of course, it also has some problems. For example, a server is required. Every single request gets rendered on the server and transmitted to the browsers once rendered. So, there will be an higher server workload, higher maintenance costs, because you will have to maintain a server. And this is costly.

3. Static Site Generation and Hybrid Rendering

Short description:

Static site generation is a third option that allows for easy scaling and outstanding performance. It serves static files directly to the browser, making it secure and eliminating the need for server-side rendering. However, it has limitations such as no dynamic content on the server side and the need to rebuild and redeploy the entire application for changes. React offers hybrid rendering, allowing different rendering strategies for different pages and parts of the application. Client-side rendering requires waiting for the JavaScript bundle to execute.

So, you have to scale the server horizontally, for example, if you want to add more servers to serve your application, because you need to scale, or you need to add more power to the server you already have if you want to scale vertically. That depends, of course, on how you want to scale your applications.

So, there is a third option that we are going to explore, which is called static site generation. So, just like server side rendering, this is what you get when you request a static site generated page. So, basically as soon as you make a request, you don't need to server side render it, because you already rendered it during build time. So, you will serve your application as static files directly to the browser.

This approach has pros and cons of course, one pro is that it's super easy to scale, and that's because again, you don't need a server. You already have static assets, you put them in a CDN, on S3, on wherever you want, on a bucket, and you just serve them as static assets, because you don't need to render the page every single time you get a request. So, that leads to outstanding performances, because the page is ready, you don't need to render it either on the client or server side. So, the page is done, you just have to transfer it. It is really secure because you don't have a server, so there's no way to attack the server directly, so that's another thing to keep in consideration.

Of course, again, it has some cons. Let's see them. So, no dynamic content is allowed on the server side, because you don't have a server, so you can't render specific things for a specific user on the server, because you don't have a server at all. It relies on client-side rendering for all the dynamics part of your application. So, for example, if you are on Instagram and you're scrolling the feed, you could generate the feed page with the client-side rendering, sorry with static side generation, but eventually you will need to wait for the client to understand who is the user that is logged in and then render the content which is specific to them. And one other thing, which is really annoying, I would say, is that if you need to change something, for example, a typo on the home page, you will need to reload and rebuild and redeploy the whole application. That can be fixed with incremental static regeneration, but we will see that in detail later on.

So one nice thing about React is that you don't have to compromise, you don't have to choose one rendering strategy for the whole website. But you can do that granularly at the page, when you basically render the single page. This is called hybrid rendering. So basically you might say, okay, the home page for this website will be a statically generated page. If you are in a blog, the post page can be dynamically generated with the server-side rendering, for example. That's cool. And some parts of the application can be rendered on the client-side only. So you can choose how long basically the user has to wait before assessing the content. Let's see in detail what I mean by waiting. So for example, this is client-side rendering, right? We make a request and as soon as we make the request, the server or the CDN will send us an empty page. As soon as the JavaScript bundle containing the React application gets executed, we will start seeing the application getting mounted on the browser. So as you can see, the server will be really fast in sending a response, but we will have to wait.

4. Incremental Static Regeneration and Caching

Short description:

With server-side rendering, we ask the server for a specific page, wait for it to be rendered correctly, and then transmit it to the client. Incremental static regeneration solves the problem of rebuilding the entire website for every change. By setting a revalidate value of five minutes, the page is regenerated for each new request after that time. If nothing changes, the cached version of the page will be served.

So as time passes by, we have to wait for the page to be loaded. With server-side rendering, it is a bit different. We ask for the server for a specific page. We wait milliseconds, hopefully, or seconds depending on how good we are at writing React or how slow the APIs behind our applications are. And then when the page is correctly rendered on the server, we transmit it to the client.

Static site generation looks like the perfect match. As soon as we make a request, we get a complete response. So this is why I like to talk about incremental static regeneration because it basically solves a big problem we are having with static site generation. So we don't want to rebuild the whole website every single time we make a change, because this is good, what we are seeing right now on the slide, it's good. But for example, if I change my mind and I start loving Irish setters, for example, I will have to rebuild the whole website. But thankfully, with incremental static regeneration, that's not the case.

So let's see how it works. So basically, this is our page right now. This is a home page for my website, because I love English setters. And so let's say we have a value in our getStaticProps that is called revalidate, set to five minutes. So every five minutes, we have to revalidate that page, meaning we have to rebuild it. So I publish the page. After one minute, one user comes to the website and they will see that page. After three minutes, another user comes to the website and will see the exact same page. The same of course for the third user that looks at our website after five minutes. Remember, this is lazy. So if no users will see the page again from now on, Next.js won't reload the application itself. It won't rerender I would say the home page in that case. But we say that every five minutes when a new request comes, we have to regenerate the page. So that's what's happening basically. We regenerate the page and the next user after five minutes will see a totally new page with a new background color with an Irish setter instead of an English one and that's what will happen after four minutes for another user and after five minutes for another user. And again, from now on after five minutes if another user comes to the website we will need to revalidate the page. So basically if nothing changes we will see server-side render the page. But we will put some caching headers so that it will be able for our cache to serve a cached version of the page. If nothing changes we will still see the same page.

5. Avoiding Server-side Rendering and Playing Smart

Short description:

React server-side rendering is not efficient yet. JSX requires a lot of server-side effort, slowing down the server and requiring scaling. Going serverless solves the scaling problem, but it comes at a cost. For example, using Google Cloud Functions can cost thousands of dollars per month. Compute Engine is cheaper but still has server-side rendering issues. To overcome this, it's important to play smart and consider the specific scenario.

Okay, but that said why would I want to avoid server-side rendering? So it's my opinion that React server-side rendering it's not really efficient yet. That's not Next.js fault. This is no one fault but JSX. JSX is not really efficient as a markup language or I don't know how to call it, but it's not really efficient when it comes to server-side rendering.

So every single request requires a lot of effort on the server-side which slows down the server, so you need to scale it, so you need to add more computing power, more servers to keep up with increasing demand for your application pages. So it might be easy for an architect at a certain point to say, yeah go serverless. You know you don't have that problem if you go serverless. You basically deploy your Next.js application on AWS, Lambda, Google Cloud Functions, Azure Functions, whatever, and you don't need to scale. That's correct but at what cost? It's not cheap.

So let's see a little example on Google Cloud Platform. Let's say this is the price of Google Cloud Functions. So let's say for the first two millions of invocation per month we don't pay anything. Beyond two millions we pay 40 cents every million of invocations. Sounds cheap right? Well we will see later on how much it will cost. As you can see you also pay computer time every 100 milliseconds. I have no idea how to pronounce those small numbers so forgive me. Networking. You also pay for networking. So first gigabyte of transfer traffic are free then you pay 12 cents per gigabyte. Sounds cheap right? So let's say we have an application that handles 100 concurrent server-side renders requests per second which leads to 259 millions and 200,000 requests per month. It's incredibly hard for me as an Italian to say English numbers! I'm super sorry but it's a huge number of requests right? The average execution time, let's say is 300 milliseconds. We can use the cheapest RAM option which is 128 megabytes and we will require around 100 kilobytes of bandwidth per execution and okay and we will need more but let's say for keeping it simple that this is how much we will be transferring. How much would it cost? Yes, using Google Cloud Functions for example it will cost three thousand dollars per month but it will scale of course it will scale but if you get more requests the price will get higher and higher so it's not really sustainable for large-scale applications. If you go back for example on Compute Engine with the two virtual CPUs eight gigabyte of rams you will pay like fifty two dollars per month which is way cheaper but still you'll have the problem of server-side rendering because you will need to scale it so eventually you want to go back to serverless but it will cost a lot so you want to go back again to Compute Engine for example but it won't scale or it will become really costly. So how do we get out of that bad situation? So my suggestion would be play smart depending on the scenario. So let's start with an example scenario. Let's say we want to build a social network app just like Instagram or whatever so I want to play a little quiz game with you. I will give you a couple of seconds for thinking of an answer so this is the first question. We already discussed this let's see if you were paying attention. So let's say we have to build a feed page feature for our application for example on Instagram when scrolling the feed page the the home page of Instagram so the content it's really dynamic and it's custom for every single user it doesn't need SEO and that's because the user is logged in so the feed it's really specific for users it serves a lot of static assets and it's basically one big common page for every single user.

6. Choosing Rendering Strategies and Security

Short description:

What would you choose for that? Would you choose server-side rendering? Would you choose server-side rendering with a caching layer? Would you choose static side generation and incremental static regeneration? Or would you choose static side generation and client-side rendering for displaying dynamic content? In my opinion, the correct answer is static side generation with client-side rendering. That's because you don't need server-side rendering. So let's go with a single post page. It serves big static assets, photos, videos, and there is one single page for every single post. Account setting page needs high security and is a good case for server-side rendering without any cache.

What would you choose for that? Would you choose server-side rendering? Would you choose server-side rendering with a caching layer? Would you choose static side generation and incremental static regeneration? Or would you choose static side generation and client-side rendering for displaying dynamic content? Let's think about it.

So in my opinion, the correct answer is static side generation with client-side rendering. That's because you don't need server-side rendering. We know that it will be different for every single user, but the page is the same. The header will be the same. The footer will be the same. It only changes the content. So the content can be lazy loaded on the client. Also, if you think of a scale of Instagram, this is too big for many of us, but you don't really want to server-side rendering that many requests. It's becoming really costly. So let's go with a single post page. So we see a nice photo. We click on the title, and we see the full post with the description and the comments and whatever. So there are a large amount of pages. It will need a good search engine optimization because this is how we get into Google with the individual posts, not with a homepage. It serves big static assets, photos, videos, and there is one single page for every single post. What would you use? So answers are the same as the previous answer but in my opinion this is a good case for server-side rendering to cache. Let me explain to you why. We will be server-side rendering this for the first time and we'll be serving a caching response every single time a new user asks for the same post. After, let's say, one hour, thirty minutes, one day, we will purge the cache and re-render it, mimic how incremental static regeneration works. If... okay, we will see later on, with another example, what might be a good alternative to that. But for the moment, let's keep our thoughts on SSR and cache.

Okay, last one. Account setting page needs high security. It doesn't need search engine optimization and it's protected under authentication. We know for sure that this is not the most visited page of every account, right? So that might be a good case, in my opinion, for server-side rendering without any cache. We don't want cache, otherwise the risk is that I do login and when another user logs in they will see my account. This is not what we want, you know. But also we have server-side cookies which are more secure than client-side cookies.

7. Rendering Strategies for E-commerce

Short description:

For an e-commerce website with a home page that requires high performance, search engine optimization, and occasional content updates, static site generation with incremental static regeneration is recommended. This approach allows for static rendering of the page with excellent performance and revalidates the page after a specified time. For individual product pages, static site generation with client-side rendering is suitable, as the content is relatively static and can be controlled on the client side using API calls.

So that's a good case for server-side rendering and we can afford it because there are not many requests to that page specifically. So let's go with another example. Let's say we want to build an e-commerce. So the home page, it's really important for every single e-commerce, right? We need high performances, awesome search engine optimization, and the content changes from time to time. Not really frequently, but let's say a couple of times per week, okay? So what would you choose? I'll give you a couple of seconds. My opinion is to go for static site generation and incremental static regeneration without a long revalidate time. So that you basically statically render the page, the performances will be awesome, and you will revalidate the page after, I don't know, one day, two days, one week. It really depends. You can choose. So let's go with a single product page. Let's say that in our e-commerce, we have 250 products, we need awesome SEO for every single product, need awesome SEO, great performances, some dynamic data, for example, stock quantity, I don't know, for example, delivery time, depending on where you come from or where to ship the merch, etc. What would you choose? I would choose static site generation and client-side rendering. And that's because the product page doesn't really change that much. Otherwise, we could have chosen incremental static regeneration, but it doesn't really change that much. And the stock quantity can be controlled on the client side via API calls, for example. And the same can be done with external APIs for delivery.

8. Incremental Static Regeneration with Fallback

Short description:

For large e-commerce or blogging platforms with a billion pages, rendering all pages at build time is not feasible. Instead, we can use incremental static regeneration with a fallback. This allows us to build the most popular posts at build time and defer rendering the rest to request time. Caching headers and revalidation enhance performance.

One thing to mention, and I wanted to mention this previously when talking about the social network, but it's worth mentioning now, is that if we have a very large e-commerce or a blogging platform, for example, where we have one billion pages to be rendered, of course we can't render one billion pages at build time. It will take forever. So we could choose to go with incremental static regeneration with a fallback. There is a fallback value in the incremental static regeneration setting, so that we can say, I will build, at build time, the hundred more popular posts or articles in my e-commerce, whatever, and I will defer the rendering phase for all the other posts or articles at request time with incremental static regeneration. So I will basically generate 100 posts that are the ones that get searched the most and the other ones will be rendered at request time and we will have some nice caching headers thanks to incremental static regeneration and revalidation of course.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Simplifying Server Components
React Advanced 2023React Advanced 2023
27 min
Simplifying Server Components
Top Content
Watch video: Simplifying Server Components
React server components simplify server-side rendering and provide a mental model of components as pure functions. Using React as a library for server components allows for building a basic RSC server and connecting it to an SSR server. RSC responses are serialized virtual DOM that offload code from the client and handle interactivity. The client manifest maps serialized placeholders to real components on the client, enabling dynamic rendering. Server components combine the best of classic web development and progressive enhancement, offering the advantage of moving logic from the client to the server.
A Guide to React Rendering Behavior
React Advanced 2022React Advanced 2022
25 min
A Guide to React Rendering Behavior
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Speeding Up Your React App With Less JavaScript
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Top Content
Watch video: Speeding Up Your React App With Less JavaScript
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.
Routing in React 18 and Beyond
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.
React Concurrency, Explained
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
Top Content
Watch video: React Concurrency, Explained
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.
Exploring React Server Component Fundamentals
React Day Berlin 2023React Day Berlin 2023
21 min
Exploring React Server Component Fundamentals
Top Content
Watch video: Exploring React Server Component Fundamentals
This Talk introduces React Server Components (RSC) and explores their serialization process. It compares RSC to traditional server-side rendering (SSR) and explains how RSC handles promises and integrates client components. The Talk also discusses the RSC manifest and deserialization process. The speaker then introduces the Waku framework, which supports bundling, server, routing, and SSR. The future plans for Waku include integration with client state management libraries.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
AI for React Developers
React Advanced 2024React Advanced 2024
142 min
AI for React Developers
Top Content
Featured Workshop
Eve Porcello
Eve Porcello
Knowledge of AI tooling is critical for future-proofing the careers of React developers, and the Vercel suite of AI tools is an approachable on-ramp. In this course, we’ll take a closer look at the Vercel AI SDK and how this can help React developers build streaming interfaces with JavaScript and Next.js. We’ll also incorporate additional 3rd party APIs to build and deploy a music visualization app.
Topics:- Creating a React Project with Next.js- Choosing a LLM- Customizing Streaming Interfaces- Building Routes- Creating and Generating Components - Using Hooks (useChat, useCompletion, useActions, etc)
Tracing: Frontend Issues With Backend Solutions
React Summit US 2024React Summit US 2024
112 min
Tracing: Frontend Issues With Backend Solutions
Top Content
Featured WorkshopFree
Lazar Nikolov
Sarah Guthals
2 authors
Frontend issues that affect your users are often triggered by backend problems. In this workshop, you’ll learn how to identify issues causing slow web pages and poor Core Web Vitals using tracing.
Then, try it for yourself by setting up Sentry in a ready-made Next.js project to discover performance issues including slow database queries in an interactive pair-programming session.
You’ll leave the workshop being able to:- Find backend issues that might be slowing down your frontend apps- Setup tracing with Sentry in a Next.js project- Debug and fix poor performance issues using tracing
This will be a live 2-hour event where you’ll have the opportunity to code along with us and ask us questions.
Mastering React Server Components and Server Actions in React 19
React Summit US 2024React Summit US 2024
150 min
Mastering React Server Components and Server Actions in React 19
Featured Workshop
Maurice de Beijer
Maurice de Beijer
Calling all React developers! Join us for an immersive 4-hour workshop diving deep into React Server Components and Server Actions. Discover how these game-changing technologies are revolutionizing web development and learn how to harness their full potential to build lightning-fast, efficient applications.

Explore the world of React Server Components, seamlessly blending server-side rendering with client-side interactivity for unmatched performance and user experience. Dive into React Server Actions to see how they combine client-side interactivity with server-side logic, making it easier to develop interactive applications without traditional API constraints.

Get hands-on experience with practical exercises, real-world examples, and expert guidance on implementing these technologies into your projects. Learn essential topics such as the differences between Server and Client Components, optimizing data fetching, passing data effectively, and maximizing performance with new React hooks like useActionState, useFormStatus and useOptimistic.

Whether you're new to React or a seasoned pro, this workshop will equip you with the knowledge and tools to elevate your web development skills. Stay ahead of the curve and master the cutting-edge technology of React 19. Don't miss out - sign up now and unleash the full power of React!
From Frontend to Fullstack Development With Next.js
React Summit 2025React Summit 2025
91 min
From Frontend to Fullstack Development With Next.js
Featured Workshop
Eric Burel
Eric Burel
Join us as we journey from React frontend development to fullstack development with Next.js. During this workshop, we'll follow along the official Next.js Learn tutorial with Eric Burel, professional trainer and author of NextPatterns.dev. Together, we'll set up a Next.js website and explore its server-side features to build performant apps.
Build a Headless WordPress App with Next.js and WPGraphQL
React Summit 2022React Summit 2022
173 min
Build a Headless WordPress App with Next.js and WPGraphQL
Top Content
Workshop
Kellen Mace
Kellen Mace
In this workshop, you’ll learn how to build a Next.js app that uses Apollo Client to fetch data from a headless WordPress backend and use it to render the pages of your app. You’ll learn when you should consider a headless WordPress architecture, how to turn a WordPress backend into a GraphQL server, how to compose queries using the GraphiQL IDE, how to colocate GraphQL fragments with your components, and more.