I’ll be quick, by Robbie Davey. Together

We like speed here at Together. We like the sites we build to look great and load fast.

That’s why we use Next.js.

It’s a front-end framework we’ve come to love. Whether we’re building a simple page or something large, complex and multilingual, it gives us the tools to craft sites that are responsive, user-friendly, and above all — fast.

If you’d like to know more about how we use and tweak Next.js for speed, you should read this article.

I promise it won’t take long.

The late Gatsby

Years ago, when we first started building headless sites, we used Gatsby. It was one of the largest frameworks for building headless sites, and did everything we needed to move from PHP to React.

For a long time Gatsby did the job. But over time other frameworks progressed and built new features, while Gatsby was slow to react (no pun intended), and just fell behind.

Gradually we started feeling it was holding back our full potential: Starting up a local development instance was slow, working with GraphQL was laborious, and caching issues would make sites just break.

Next, please

In stepped Next.js, instantly making a lot of our problems go away.

It offers complete flexibility, takes care of a lot of complex issues in the background, and provides the freedom to build the sites how both we and our clients want.

Next.js also makes the dev process smoother. Seamless integration with WordPress, Sanity, Contentful and Storyblok has been particularly useful to us.

Most importantly: it’s great for speed.

Take the site of our good friends at Coastpay, originally built with Gatsby. Over the years it got bloated and slow, so we decided to migrate the site to Next.js. After switching frameworks (and before adding any third party scripts) the previously sluggish site scored an impressive 94/100 on mobile page speed — a massive improvement.

Tools of the trade

Out of the box, Next.js comes with several tools that help us optimise and increase the performance of our sites.

Here are three of our favourite ones.

Next/Image

First and probably simplest, the Next/Image component replaces the humble <img /> element, and processes your media assets, ensuring you always serve the best possible image to the user.

It automatically optimises images, converts them into modern formats (WebP or AVIF), and generates appropriate sizes for different responsive levels. It also removes any layout shift, giving your site a massive speed boost.

It’s a must-have for any Next.js site. [Get Next/Image]

Next/Script

For us, the biggest speed bumps on websites are the third party scripts.

Picture a team of proud developers who have just launched a perfectly performing site, only to have Google Tag Manager or a cookie banner swoop in to ruin their day.

A sad story, I’m sure we can all agree.

We know these scripts are essential for marketing departments and user experience testing. We just wish there were an easier way to add them onto a site.

Most of the time, clients add these scripts directly to the site in Google Tag Manager, and don’t try to optimise the load process, so the scripts start running the moment a user lands on a page, increasing initial loading time and making the overall site seem sluggish.

Luckily, Next/Script helps alleviate a lot of these issues.

You can add it to a specific route or globally to the _app file to ensure the file loads on every page. Next.js ensures the script is only loaded once, and it even comes with a handy strategy prop that lets you decide when to load the script.

These strategies are:

beforeInteractive — loads the script before hydration.
afterInteractive — loads the script early but after some hydration has occurred.
lazyOnload — loads the script after the page has fully loaded and is not idle.
worker — an experimental option that loads the script separately in a web worker.

By using these strategies you ensure the third party scripts are loaded at the appropriate time, and not all at once on the first page load. [Get Next/Script]

Next/Dynamic

My final example of a great way to speed things up, Next/Dynamic lets you ‘lazy load’ page components, i.e. only load them as and when they’re needed.

Paired with the npm plugin @next/bundle-analyzer, it’s the perfect way to optimise your final build.

This combo works particularly well with flexible page builders and CMS’s that give clients full control of their sites, letting them choose and arrange any component on any page. (We use Advanced Custom Fields to create our own Flexible Content.)

However, all this flexibility can cause builds to get very big, very fast. Since every possible component must be imported into the page builder file, all of them end up being included in the final site build — even those that are not used on every page.

With the bundle analyzer, Next/Dynamic lets us see which of our components are needed specifically on the homepage and which ones are needed above the fold. Once identified we use the Dynamic function to lazy load the rest of the components across the site.

This greatly reduces the overall bundle size of the site through this process of code splitting, ensuring only the essential components are loaded. This is one case of size does matter and the smaller the size, the quicker the site can load, the better the page speed score, a more satisfied developer and most importantly a happier client.