It’s rendered client-side.
Create React App: whose apps are more performant? In this article, we will unpack that question – including SSR versus CSR – with some data, but first, we need to understand what exactly we are comparing. Next.js is a React framework built by Zeit, and according to nextjs.org:. With Next.js, server rendering React applications has never been easier, no matter where your data is coming from. Next.js also supports static exporting (and newly, incremental static regeneration), but for the purposes of this post, we are focused on that “server rendering” (SSR) capability mentioned above.
According to its Getting Started page:. Create React App is an officially supported way to create single-page React applications. Again, for the purposes of this post, we are paying attention to the term “single-page.”. Next.js is one way that you can leverage React to support server-side rendering (SSR). Likewise, Create React App is one way that you can leverage React to support client-side rendering (CSR).
There are other frameworks out there when it comes to either choice, but what we are really comparing in this post is how each rendering strategy impacts web application performance. We just happen to be using two of the more popular frameworks out there to make that comparison.
Let’s start our experiment with just one of many questions we can ask when comparing Next.js vs. Create React App: Does SSR improve application performance? Walmart Labs published a great post titled, “The Benefits of Server Side Rendering Over Client Side Rendering.” They also provide some excellent diagrams that demonstrate the fundamental difference between SSR vs.
Server-Side Rendering (SSR) vs Client-Side Rendering (CSR)
CSR performance. These diagrams postulate that SSR can deliver HTML to the browser faster than CSR can, so let’s make that our hypothesis: a web application built with SSR is more performant than one built with CSR.
(Note: this article calls out synchronous SSR as a bottleneck with renderToString. This is no an issue with React 16 and Fiber enhancements). The best way to test our hypothesis is by building two applications with identical functionality and UI. We want it to mimic a real-world application as much as possible, so we will set a few parameters.
You can find this under the Audits tab in Chrome DevTools. We will use the exact settings displayed above:. Applied Fast 3G, 4x CPU Slowdown. If you live in Northern California and you are on servers living in AWS us-west-1 (N.
California) all day, you are not experiencing your application the same way as your users in other parts of the United States, nor other parts of the world. So, for the purposes of this test, the demo apps and the API were deployed to Sydney, Australia (specifically, Zeit’s syd1 region). The client’s browser will be accessing the applications from Boulder, CO, USA. The distance between Boulder and Sydney is 8,318 mi (13,386 km). Look at what that means for data fetching between these two applications.
The code for the two apps is available in my GitHub. Here are the applications:. All of the code is in a monorepo:. /cra contains the Create React App version of the application. /nextjs contains the Next.js version. /api contains a mock API that both applications use. The UI appears identical:.
It’s bad for SEO
The actual libraries that we’re using are not important; the point is to get a little closer to the weight of a normal application without taking the time to build all of that in its entirety. Here are the Lighthouse results for a full page load on each application. To understand the details of these metrics, read the Lighthouse Scoring Guide.
Next.js vs. React: How do they compare?
One of the more notable differences for our purposes is the First Meaningful Paint. According to Google’s First Meaningful Paint docs:. This audit identifies the time at which the user feels that the primary content of the page is visible. Lighthouse also helps us visualize these differences:.
Do the visuals above look familiar? They should because they mimic the diagrams included in the Hypothesis section, where we postulated that SSR can deliver HTML to the browser faster than CSR. Based on these results, it can! To view the Lighthouse results yourself:. Download the files for CRA and Next.js. Open https://googlechrome.github.io/lighthouse/viewer/ in Chrome. Drag the downloaded files into the Lighthouse Viewer in Chrome.