Mistakes I Made From The Previous Version of My Next.js Project
I’ve been working with Next.js for a few years and I considered myself as newbie in React and Next.js at the time. Before that, I worked extensively with Angular for both SPA and SSR applications. It’s quite a shame but I should’ve started getting serious about React sooner. But let’s leave my experience aside and get straight to the main topic today.
On my previous version of my current project which was built with Next.js had a lot mistakes and flaws. Here are some of them.
Did not utilize dynamic loading
I know, it sounds stupid and I have no excuses. At that time, I just thought “Hey, React is already fast enough so it shouldn’t be much problem when it was rendered in Next.js framework” and I was dead wrong. Turns out that cost me a bunch of large size of chunk files, and by the term ‘size’ I mean file size in bytes. Some of them even bigger than a megabyte which effects some serious problem about page load speed. No wonder why PageSpeed Insight keep complaining to me.
How I fixed the problem in my current application? Lazy loading everything that does not require to be SEO friendly. Looks for more detail at Next.js Lazy Loading. We analyzed everything in each page and see what can be lazy loaded or dynamic loaded. And by ‘everything’ I mean every single component in that page. It sounds like a tough work but it’s the most efficient for us to control the chunk loading. As a result, the first load JS file size which is shared by all pages was decreased more than 50%.
But don’t just lazy loading everything, you have to think about the LCP as well. So what I did is to create a fixed main layout (only HTML and some css styling) and make it a SSR component that will be rendered at server. After that, you should know what part of the above-the-fold of your web page should be server or client component.
Both application and UI code are together
I used to have everything inside one single project repository both pages, components and a custom-made React UI components packages which is actually a very difficult way to maintain in such a large code base.
So I had an idea to split the UI or styling parts to another project repository as our common UI library and use it like any other npm packages. After we succeed, our main project has a lot less code than before and we also had another common React UI library to be shared across our projects.
If you interested how we did it, please refer to this article I previously wrote.
Did not utilize code-splitting as much as we should
I used to implement everything in a single component and that was a huge mistake. If you were there before, you can understand it.
So I told my team that we should do the code-splitting as soon as we can, don’t worry about how many source file we’ll have to create, just make sure it is simple and easy enough to read. If it can be one job per one component and business logic is separated from the UI, that’d be great. Also start using Bundle Analyzer more often if we start seeing slow page load by looking into its chunk size. If it’s too big, we have to take care of it.
As a result, code is now much cleaner and file chunks are now much smaller which means pages load faster than before, that’s great!
By the way, if you’re thinking that what’s the difference if we still have a large amount of component files even if we already separated UI library to another project, you might be right. But one benefit here is, we have completely separated the business logic and the look-and-feel part and also have another common UI library project which can be used in our another projects later which I think it’s better for the styling consistency.
Did not pay much attention to the data loaded in server
We used to think that everything that is displayed on the page needs to be rendered on the server side, that’s why our Next.js page has a large JSON data to be loaded for rendering process and that also effects that page load speed as well.
So as we try to analyze which component should be loaded on server or client, we also have a chance to consider which data can be loaded upon the page server side rendering state. But to be honest, UX team can help developers in this process because if the design put too many things for display and all of those stuff are required to be SEO friendly which means we have to load all of those data for server side rendering. And if that happens, a large JSON data for page rendering is inevitable and it’s gonna effect page load time (assuming we’ve already got the back-end caching and network stuff parts done).
These are only some of the problem that I have gone through. I’m still a newbie to the Next.js world but I do hope this article helps you to improve your project and guide you to avoid mistakes I’ve been through.
Until next time, front-end fellas.
