Strategies to deliver the best UX
One of our core values at Versantus is Quality: delivering gold standard solutions, strategic advice, and expert advice. In order to match our clients' needs with the right solution, we need to regularly evaluate the latest technologies to see what benefits they bring, and how they can fit into our solution toolkit.
The emerging technologies we’ve been investing time into recently are React and, its sibling, Next.js.
The benefits of React & Next.js as your chosen frameworks
You may have heard developers singing React’s praises, as it’s a great framework for creating one-page web applications. It offers significant flexibility, and, in my personal opinion, it is one of the frameworks out there with the easier learning curve if you have a stable JavaScript background.
Next.js is an open-source development framework built on top of Node.js (back-end JavaScript language); it makes it easier to use React-based features such as server-side rendering and generating static websites.
In the last few years Next.js has been growing in popularity, and rightly so. It brings a cost-effective solution to customers by offering an intuitive developer experience, greatly reduced development time, and increased quality.
Next.js rendering
It's important to keep in mind that, with Next.js, there are different ways to use it for ‘rendering’ (i.e page generation). The various options are:
-
Client-Side Rendering (CSR) - the data is fetched after every single render
-
Server-Side Rendering (SSR) - the data is fetched before every single render
-
Static Site Generation (SSG) - the data is fetched once at build time
-
Incremental Static Regeneration (ISR) - the data is fetched once on build time, and will be fetched again after a certain time and served on the second visit.
To help you decide which approach to take, there’s a handy scoring system you can refer to that considers four important metrics (N.B. G is for Green, A is for Amber, R is for Red):
-
Data Accuracy - how timely and accurate the data needs to be (G important, A moderately important, R not important)
-
SEO - how easy is it for the search engine to find the shown data (G SEO friendly, R not SEO friendly)
-
Load Time - if the content needs to be rendered instantly or we can load it on page view (G instant, R on page view)
-
Build Time - how quick it is to build and deploy the website (G fast, R slow)
This is how Next.js measures up on these metrics for us; the results might vary depending on the project you're undertaking, so do your own research to compliment your project’s requirements.
With these scores in mind, you can then go on to choose the correct data fetching strategy to suit the project. Let’s deep dive into what the table means for developers and UX:
CSR for high accuracy
This method is ideal for high accuracy data levels like dashboards, reporting, authentication forms, product pricing, as well as pages that are interactive and contain critical values that cannot be outdated.
I normally use this method if I need to see the latest data every time I access the page.
However, the accuracy data level comes at the cost of SEO; the data is not visible in the page source during the initial load and requires the search engine crawler to work harder. For those reasons, the load time is slower because it happens in the client browser.
SSR for accuracy and SEO
This is ideal for applications and websites that require high data accuracy and a good SEO score, like product pages, comment sections, and for those sites that have lots of products with details that are regularly updated.
However, high data accuracy and SEO friendliness come at a price.
SSR can cause some latency issues; the rendering happens in the server when the request for that page is made before it is sent to the browser. Latency is the time that takes for the request to go to the server and back.
SSG for more permanent content
SSG is ideal for data that doesn't change often, like blog posts on sites that have few products or details that are not updated often, profile pages - anything that shows information that isn’t critical.
Low data accuracy makes the latency issues disappear, as the data rendering is done at build time and cached in the CDNs close to the users.
ISR for a combined approach
ISR (a relatively new technique which is a combination of SSG and SSR) is ideal for blogs built using a CMS; it allows the content to be updated without having to rebuild the whole site (like for SSG). ISR fetches the latest changes when visiting the page ready for the second visit. This data fetching technique is a hybrid between load time and data accuracy, as the rendering and caching is done at intervals.
It’s worth keeping in mind that, once changes are applied, you will need to wait a few seconds and then refresh the page twice to see the changes.
Knowing which Next.js rendering methodologies to use
CSR and SSR are very fast at build time as their approaches only require building one page on request.
SSG and ISR are slower at build time because all the pages built with these techniques are created when the site is built.
All these techniques can be mixed and matched as per data rendering necessity. Knowing what options Next.js offers in terms of rendering methodologies can make a huge impact on the application/website development. If you’re looking to offer the very best UX, understanding these strategies (and their benefits and drawbacks) is key.
Resources used: