Last year, I built my portfolio website in Vite + React. Everything worked locally, so the code was put in production and deployed using Vercel’s deployment. The site was working the same as in the local environment. No issues!
It was fine initially; I purchased a new domain name from Namecheap and pointed it to my portfolio website. After setting up the domain, I worked on the site’s technical SEO by ensuring it was crawlable and indexable by search engines. Once the necessary metadata, sitemap, and robots.txt were in place, the site was ready for indexing. However, over the nine to ten months, I started noticing a pattern. Every time I wanted to improve the site’s SEO reliability, I found myself adding a new plugin, tweaking another config, or writing more boilerplate code. Though React + Vite gave me control, many of the SEO features had to be implemented manually.
When I later built the same portfolio with Next.js, the experience was noticeably different. Features such as metadata management, server-side rendering, server-side generation, and sitemap support were either built in or much easier to implement. Now, instead of picking solutions from different places, I can focus on building the site itself.
Why did I originally build the site with React?
When I first built my portfolio, the demand was for a simple, fast, and lightweight setup. So Vite paired with React was an obvious choice. Vite offers an excellent developer experience with near-instant startup times and fast hot module replacement, while React provides a component-based architecture that makes building reusable, maintainable UIs straightforward.
At the time, a client-side rendered application was more than sufficient for a personal portfolio. React’s mature ecosystem, extensive documentation, and large community also meant I could find solutions to almost any problem I encountered.
But then why I decided to migrate to Next.js?
When I first built the portfolio, migrating to Next.js wasn’t even on my radar. The site worked well, React met all my requirements, and Vite made development incredibly fast. For a simple portfolio, it was the right choice. But once managing the extra plugins and tweaking configs to improve SEO became out of hand, the goal was clear: migrate. Next.js provides built-in features that make SEO much easier to handle, along with SSR (Server-Side Rendering) and SSG (Static Site Generation). It was a simple choice then.
Moreover, Next.js simplifies routing by using File-Based Routing (in React, we use a library called react-router-dom for routing), which reduces boilerplate and keeps the project intuitive. Next.js is majorly touted for its SSR, SSG, and SEO capabilities. These capabilities can be leveraged to make my site SEO-optimised, and let’s not forget it is a full-stack framework, so there was room to expand the project over time.
Challenges during migration:
Routing changes: Earlier, when the portfolio site was developed, it only had one route — the ‘root’ route or ‘/’ route. You might have seen some of the most basic portfolio sites that only have a single page that displays all the information in that route only. My portfolio site was built like that too: one single route that shows or hides data based on the sidebar menu buttons clicked. It’d conditionally show or hide the data. So there was no need for multiple
<Route>components in my portfolio application. But in Next.js, I had to work on specific routes so each page could have its own SEO metadata and be indexed independently.Image optimization: You use
<img>, a standard HTML tag to display an image in the browser. But the<img>tag has some limitations that Next.js handles decently. For instance, the plain HTML<img>doesn’t offer built-in image optimisation, automatic resizing, or automatic serving of modern formats, although it does support native lazy loading. On the other hand, the Next.js<Image>component (yes, you heard it right, it’s a component) offers image optimisation, resizes images on demand, and by default, the image only loads as it enters your viewport, while serving modern formats like WebP or AVIF when supported.Deployment: When migrating, developing, and deploying the beta version of the site in Vercel’s preview deployment, the build was failing, as the original project had automatically configured deployment settings for React. Vercel’s environment wasn’table to find the ./dist folder and kept failing until I changed the build setting in Framework settings under the ‘Build and Deployment’ button in the project’s settings.
Features I gained with Next.js
This portfolio site gained Next.js’s out-of-the-box features like built-in server-side rendering (SSR) and Static Site Generation (SSG). Now this allows the site to build a highly interactive React application while serving pre-rendered HTML that is easier for search engines to crawl and index.
Here are some of the features of Next.js that this project gained:
Zero configuration: No need to manually configure the build tools, as Next.js abstracts them. Also supports file-based routing and built-in TypeScript support, so called “batteries included”.
Full-Stack capabilities: Convenient and built-in API routes and features like Server Actions allow me to write both frontend and backend in a single repo.
Hybrid Rendering Adaptibility: I can choose if I want Server-Side Rendering (SSR), Static Site Generation (SSG) or Client-Side Rendering (CSR) on a per-page basis within the same application.
Performance Comparison
Performance comparison Vite + React vs Next.js
Testing for performance was done under the same conditions:
- same content
- same images
- same network throttling
- same device/browser
- production builds only
- run each test 3–5 times and average the results
I measured the portfolio before and after migration using Lighthouse and production builds only. The goal was not to chase perfect scores, but to see whether Next.js improved the real user experience.
Should you migrate?
The answer depends on whether your current stack is fulfilling your needs or not. Like in my case, React didn’t provide built-in features that made Search Engine Optimisation (SEO) easier; that’s why I moved to Next.js, not because, for the past few years, it has been the “hot new JS frontend framework”. To keep it simple, audit your application and your needs, then decide if the application will really gain from migrating.
Top comments (0)