Common Next.js Project Challenges in 2024

Intro

In 2024, Next.js has firmly established itself among the primary tools for creating web applications. It boasts a rich set of features that meet modern requirements. However, this also means that the framework's entry barrier and overall complexity have increased.

This article discusses typical issues with Next.js applications identified during our audits, allowing you to check whether you've made any of these costly mistakes.

Next.js Rendering Strategies

When you begin developing a Next.js application, one of the first considerations should be your rendering strategy.

Next.js in 2024 offers several options, which can be divided into two categories based on the type of router they use. Thus, the Pages router can offer you SSR, SSG, and ISR, while the App router is mostly focused on SSR. Although the App router can mimic SSG and ISR behaviors, this practice is not recommended and will not be discussed in this article. Noticeably, client-side rendering is not mentioned, and for good reason — it's performance and SEO's worst enemy. Using this approach might be a significant mistake.

The main issues related to rendering strategies are often due to developers trying to save time or simply not wanting to delve into these mechanisms, ultimately breaking them. For instance, expecting a fully static website only to end up with client-side rendering not only disrupts the whole idea but also significantly harms SEO and performance.

The situation with the App router is even more complicated. This very new feature is just beginning to be tested for durability, and from personal experience, it's easy to break rendering and turn what should be static into regular SSR, which is less efficient and potentially more costly.

To summarize, merely using the correct methods for data loading (getServerSideProps, getStaticProps, fetch) does not ensure your project works as expected. You must thoroughly understand how these mechanisms work, what is sent from the server, and how client-side navigation occurs. Consider whether you need SSR or can work with static content, whether you want to work with the new App router, or stick with a tried and tested solution.

Next.js Build Type

An equally important aspect when starting a project is choosing the mode in which your Next.js will operate. This choice impacts several things: the speed and performance of the resource, hosting provider selection, development flexibility, and the cost of developing and maintaining the project.

To summarize, there are essentially two modes, and the difference between them is significant. Next can be built to run in a serverless environment (the default option), or you can build it in stand-alone mode, allowing you to deploy it anywhere, such as within a Docker container. You can read more about this in another article of ours here.

Depending on your project's goals, you can gain significant advantages. For example, if you have a lot of dynamic information that needs to be updated every time a user visits a page, standalone mode might be your choice, as SSR shines in this area. If you plan to have a complex API, standalone mode also performs noticeably better. And this is not even to mention how inconvenient it is to maintain a constant connection with databases if you're working with the default Next.js serverless environment.

However, the stand-alone mode also has its drawbacks. You will need to manage the environment yourself, maintain servers, and configure caching, which is a crucial part of modern web applications. These tasks are complex and require skilled developers at the helm.

Typical signs indicating a problem in this area include:

• Slow SSR performance
• High hosting costs
• Limitations in API development
• Problems with database connections

Missed Optimization Opportunities

Despite Next.js having excellent documentation, which their team deserves praise for, many either do not familiarize themselves with it or simply choose not to utilize all the capabilities of this framework. In this section, we will discuss commonly overlooked features.

One of the most common issues is image optimization. Although Next.js includes a built-in component that solves 90% of problems, we still often see it underused in most projects.

Another widespread issue is the presence of many unoptimized scripts for which there is a special component that significantly improves performance when used correctly. Learn more about this feature here.

Beyond what's described above, it's crucial to consider how you write your CSS, as it's likely a render-blocking resource (along with your project's fonts), severely impacting your site's overall speed by delaying FCP and other metrics, though there's essentially nothing stopping them.

The last point worth mentioning is that, although Next.js mostly delivers markup straight from the server, it does not negate the ability to work with client-side navigation, which speeds up the process for users by several times! Not to mention, it also reduces the load on servers. To achieve this, you must use the Next Link component correctly.

In conclusion, Next.js is a feature-rich framework. By overlooking any of its features, unfortunately, you risk not only losing improvements in user experience but also money.

Conclusion

The issues described above can certainly be considered critical. Each significantly impacts the performance of your resource. However, even if everything is in order with them, there is always room for improvement, as every project is unique in the tools it uses and its concept.

Unfortunately, nowadays, Next.js requires a deep understanding of its features if you want to get what you expect from it, as missteps are easily made.

If you're wondering whether your project is in good shape, feel free to contact us for a NextJS Performance audit. Our engineers are experts in this framework and would be happy to assist you.