Next.js and SSR for our new website — fleetx.io
It was the time when we decided to restructure our product with several new ideas, mostly in terms of solutions provided by the company and product. What good time it could be to revamp our business website to a fresh new look that would amaze most of the visitors.
Our aim was not only to bring in a new UI/UX for the website but also to keep SEO, performance, code maintainability, and dev experience top-notch. Keeping in mind these requirements our team decided to pick Next.js for this project. So let’s dive into how we accomplished this and why we chose Next.js (SSR) over React.js (CSR)
Design flow and requirements
For the initial release, our website had around 15 to 20 pages of content explaining various solutions provided by the product. Our team decided to keep a fixed type of layout for spreading out content on pages so that we could keep adding other pages to the website quickly and easily.
Next.Js to the party
Our frontend team decided to use server-side rendered aka SSR pages over existing client-side rendered aka SSR pages built with React.
So, Why SSR in this world of booming CSR solutions and frameworks/libraries?
Multiple reasons would answer this question.
Better SEO as the content would be generated on the server and SEO was one of our top priorities.
Faster initial page load and content appearance.
Maintainability and amazing features, dev experience provided by Next.js
Some of the cool features which Next.js provides are out of the box code-splitting, pre-rendering, magically creating page routes based on the folder structure, CSS-in-JS (styled JSX) support and not to mention again its ease of use.
Yes, that’s all is required for creating page routes and because of this it was easy for us to keep adding multiple pages without worrying about client-side routing logic, and I as a developer personally liked this feature a lot.
Performance optimization and faster page load
Several steps were taken to improve the overall page load and a good web vital score.
Inline and internal styles for critical CSS.
Link preload and prefetch for third party resources like GTM scripts.
Lazy loading offscreen content using react-lazyload.
Removing unused CSS by identifying through Chrome Devtools coverage report.
And of course Medium like progressive image loading :)
Apart from this, we are using CDN for serving static assets, appropriate image format to keep performance and loading to a good standard.
And we did it…
So, this is how SSR with the help of Next.js helped us bring this website to production in a short time as manually setting up SSR on a React app could prove to be a tedious task. However, SSR can not always be a solution for building websites as it can sometimes make things complex and put additional load on your servers too, so one needs to be careful picking SSR over CSR.
