DEV Community: Rohan Mehta

Using Next.js Image Component with Netlify

Rohan Mehta — Mon, 15 Feb 2021 14:08:23 +0000

Since Next.js 10’s release, they have added several additional features to their incredible React Framework for Production. Two of the best I fancied were the built-in Image Component and Automatic Image Optimisation features. It serves images in modern formats like WebP if supported by a browser that is smaller than the JPEGs. Google and Vercel team collaboration deliver us this crucial improvement to present images on a webpage in a performant way, following all the best practices.

E.g., they made width and height properties of images a requirement (unless layout=’fill’) to prevent cumulative layout shift (images jumping up and down on page load). It is a core web vital that Google will soon use in their search ranking. So using the next/image component in our next-apps is a no-brainer.

When deploying on Vercel, the adoption of next/image is seamless, without hassle. Everything works out-of-the-box. The hurdle arises when you proceed to Netlify or any other platform of your choice. Hence, next/image and API routes won’t work similarly on such platforms as you would expect them to.

But don’t dissolve in worry now! In this tutorial, I will discuss how, despite the problems, you can benefit from the reasonable defaults and best practices set by the team behind Next.js. Let’s start! ✨

Why Choose to Deploy on Netlify?

Vercel is a logical choice for Next.js apps, their exceptional support for server-side rendering being super cool. However, for organisation and private GitHub accounts, it leaves me with no choice but to move my personal/team projects to Netlify because of their generous free-tier. Another reason for Netlify could be that you have deployed your code on it, and do not want to bear the overhead of shifting to a different platform.

Recently, the Netlify team has been working round the clock to ease the integration of Next.js apps with their platform, which I will discuss further. Last, they support several frameworks like Gatsby, Vue, CRA, etc., creating a one-stop junction for all your frontend web deployments.

Problem Between Next’s Image Component and Netilify.

To deploy Next apps on Netlify, we need to run next export after building the app. It creates a static HTML export you can deploy to Netlify CDNs. Also, to make SSR work, the Netlify team introduced a plugin to build Next.js apps. Previously, this worked like a charm, but since the new Image Component’s arrival, some issues have cropped up.

On running next export while using next/image, the following error occurs:

Error: Image Optimisation using Next.js’ default loader is not compatible with `next export`.

This is because Image Component uses a proxy server (provided by Vercel) that optimises images on-demand, as and when users request them.

The example below shows the conversion:

import Image from 'next/image';

export default function MyImage() {
  return (
    <Image
      src="/boop.jpg"
      alt="what a great boop"
      width="1368"
      height="1044"
      layout="responsive"
    />
  );
}}

The above code is rendered as.

<div style="display: block; overflow: hidden; position: relative; box-sizing: border-box; margin: 0px;">
  <div style="display: block; box-sizing: border-box; padding-top: 76.3158%;"></div>
  <img
    alt="what a great boop."
    src="/_next/image?url=%2Fboop.jpg&w=3840&q=75"
    decoding="async"
    sizes="(max-width: 640px) 640px, (max-width: 750px) 750px, (max-width: 828px) 828px, (max-width: 1080px) 1080px, (max-width: 1200px) 1200px, (max-width: 1920px) 1920px, (max-width: 2048px) 2048px, 3840px"
    srcset="/_next/image?url=%2Fboop.jpg&w=640&q=75 640w,
            /_next/image?url=%2Fboop.jpg&w=750&q=75 750w,
            /_next/image?url=%2Fboop.jpg&w=828&q=75 828w,
            /_next/image?url=%2Fboop.jpg&w=1080&q=75 1080w,
            /_next/image?url=%2Fboop.jpg&w=1200&q=75 1200w,
            /_next/image?url=%2Fboop.jpg&w=1920&q=75 1920w,
            /_next/image?url=%2Fboop.jpg&w=2048&q=75 2048w,
            /_next/image?url=%2Fboop.jpg&w=3840&q=75 3840w"
    style="visibility: visible; position: absolute; inset: 0px; box-sizing: border-box; padding: 0px; border: none; margin: auto; display: block; width: 0px; height: 0px; min-width: 100%; max-width: 100%; min-height: 100%; max-height: 100%;"
  />
</div>

The image URL was changed from /boop.jpg to /_next/image?url=%2Fboop.jpg&w=750&q=75.

/_next/image — this is an endpoint where the image will be sent for processing.
?url=/boop.jpg — where the endpoint should load the image from.
&w=750 — resize the image to 750px wide.
&q=75 — resample the image at 75% quality to reduce the file size.

This proxy URL is unique and thus can be cached, preventing redundant image optimizations. The default loader relies on the Image Optimisation API, which is unavailable for exported-applications, for Next.js tunes images on-demand, as users request them (not at build time).

Here, we have a list of solutions at hand, that is to

use next start, which starts the Image Optimisation API. This would need a physical or cloud server, rendering you responsible for its management and monitoring.
use Vercel for deploying, which supports Image Optimisation.
use the solution provided by the next-on-netlify package.
configure a third-party loader in next.config.js. (e.g., Cloudinary, Akamai and so forth)

For this tutorial, the last two solutions will suffice us. We shall make use of a simple Image Optimiser provided to us by the package next-on-netlify (originally demonstrated by Jason 🙏) which uses jimp under the hood. But that is just a plain API, not performant enough as against the one provided by Vercel. Therefore, we will apply Cloudinary as the default loader, being compatible with Netlify and other hosting platforms.

Using the Next-On-Netlify Package.

With sheer perseverance, the team at Netlify have been toiling to provide one-click integrations for Next.js apps. They have prepared a package called next-on-netlify(currently in beta). You can also install a separate build plugin called @netlify/plugin, which uses the above package under the hood. We are going to use the next-on-netlify for now, just to show the deployment process. So, prep your editors up! 📝

Can't wait to see the final results? Head on to demo repo

Create a New Next App

The first step involves creating a brand new Next.js app. If you already have one, you can skip this part. Just make sure you have the latest version of Next.js installed.

yarn create next-app

Install the Package

Now we will install the next-on-netlify package. While drafting this article, I was on v2.8.6, so update to the latest version as it often inculcates revisions.

yarn add next-on-netlify

Create `netlify.toml`

This involves telling Netlify how to build our Next.js app, and which folders to upload to its CDN. We answer that with a netlify.toml file in our root directory and the instructions below:

[build]
  command = "yarn run build"
  functions = "out_functions"
  publish = "out_publish"

This would create two folders: viz out_publish, including all static elements; out_functions, containing all the API routes’ implementations.

The names **out_functions** and **out_publish** are hard-coded, therefore not configurable at the moment.

Add a `postbuild` Hook

Paste the following line of code in your package.json.

{
  ...
  "scripts": {
    "dev": "next",
    "build": "next build",
    "postbuild": "next-on-netlify"
  },
  ...
}

When you run the build command, the postbuild hook will be fired automatically, driving the next-on-netlify command for us which makes use of the netlify.toml file we created earlier.

Create `next.config.js`

Now the call is to build our Next.js app as a serverless app. Just create a next.config.js file in your root directory and write:

module.exports = {
  // Target must be serverless
  target: "serverless",
};

Let’s Create a Production Build

We are almost there! Time to build our app by running yarn run build. When the build finishes, you’ll see some terminal messages, where next-on-netlify creates folders to upload to Netlify CDNs. Add these folders to .gitignore, having no point in committing them to version control.

# Files generated by next-on-netlify command
/out_publish/
/out_functions/

Let’s Deploy 🚀🚀🚀

Last, to deploy using the terminal, you need to install netlify-cli and log in using the cmd netlify login.

After your successful login, run netlify deploy to start a deployment. If a new project, it will ask you to configure one for this site or add this site to an existing project. Now, select appropriately and wait for the deployment to finish.

Following the fruitful deployment, you will get a preview URL. Check if everything works as intended, and then run netlify deploy --prod to get the production URL.

Good going! ⚡ We have deployed our boilerplate application as operational on the web. Let’s add some images and optimise them.

Add Images

Download images and move them to the public folder.

Check out the commits on this PR where I add basic markup and styling to display images. Also, you can clone use-next-on-netlify branch of the demo repo.

Rebuild and Deploy

Run yarn build and wait for the build process to complete.

Head onto the generated out_functions folder where you can see a file named next_image.js. On deployment, this file will be uploaded to Netlify Functions and act as our Image Optimiser. Also, note that the out_functions folder contains other files as well, which are our API routes implementations. All of these files will be deployed as separate Netlify Functions.

Now, if look into the out_publish folder, you will see other static files and images, ready to be uploaded. Here, the next-on-netlify package has generated a _redirects file for us, containing the following code:

# Next-on-Netlify Redirects
/api/hello  /.netlify/functions/next_api_hello  200
/_next/image*  url=:url w=:width q=:quality  /.netlify/functions/next_image?url=:url&w=:width&q=:quality  200

The first redirect is for our pages/api/hello.js which was already present when we created a new next-app. The second redirect is redirecting the traffic going from URLs containing /_next/image to /.netlify/function/next_image with all the query parameters.

This happens because developers of the next-on-netlify package are currently working to create their image optimiser function, naming it as next_image.js. If you want to look at how are they doing it, check out this file.

On the successful build, check the preview URL by running netlify deploy. Whereupon, run netlify deploy --prod to push towards production.

Bravo! ⚡ We have successfully made the Next.js Image Component work with Netlify! But it does not end here. As you can notice, on visiting the preview URL, the images load slow. So, let’s advance and solve this in the next section.

Using Cloudinary as Default Loader.

The problem with the above Image Optimizer is that it skipped quite a few optimisations like conversion to WebP formats, caching images on the browser, etc. If you go to the deployed version of this section, you find the first two images load slower than the last two. This is because Cloudinary optimises and caches the final two.

Implementing these much-needed features alone would be tedious. And you know what they say, "Don’t reinvent the wheel."

Set-Up a Cloudinary Account

After finishing the sign-up process, note down your public ID as shown in the image below:

Now, to use our images with Cloudinary, we have two options, either to

upload all our images to Cloudinary, and use https://res.cloudinary.com/YOUR_PUBLIC_ID/image/upload/IMAGE_NAME.jpg to fetch it
or provide absolute URL of the image hosted on the platform of our choice to Cloudinary like https://res.cloudinary.com/YOUR_PUBLIC_ID/image/fetch/https://YOUR_PROVIDER.com/IMAGE_NAME.jpg

If you get 404 errors on fetching images the second way, log into your Cloudinary account, goto settings ->security and un-check the Fetched URL checkbox under Restricted media types option. It allows us to use any image URL. To prevent misuse, provide the list of accepted domains under the Allowed fetch domains option.

To use Cloudinary as the default loader with Next.js Image Component and get the same results, we have two ways:

By Using Loader Prop (requires next v10.0.5)

Since v10.0.5, Next.js adds loader prop to the Image Component. It takes a custom loader function as the prop, receiving src, width and quality as arguments.

Here lies the implementation of custom Image Component with loader prop:

import Image from "next/image";

const myLoader = ({src, width, quality}) => {
    return `https://res.cloudinary.com/YOUR_PUBLIC_ID/image/upload/w_${width},q_${
        quality || 75
        }/${src}`;
};
const MyImage = (props) => {
    return <Image loader={myLoader} {...props} />;
};

export default MyImage;

Use the above component as shown below:

import MyImage from "../components/MyImage";

//...

<MyImage
 key={i}
 src={`/coffee-1.jpg`}
 width={640}
 height={426}
 />

//...

Check out the PR and the deploy preview URL for this method and compare the performance difference.

By Specifying Loader and Path in `next-config.js`

Now, we will discuss another method to use Cloudinary as the default loader in which you need not create a new component as we did in the previous method.

In the next-config.js, add the following code to use Cloudinary as the default loader:

module.exports = {
  // Target must be serverless
  target: "serverless",
  images: {
    loader: "cloudinary",
    path: "https://res.cloudinary.com/YOUR_PUBLIC_ID/image/upload/"
  },
};

Since the Next.js docs officially list Cloudinary as an option for loaders, the second method scores better. On debugging, I found, by using loader prop for Cloudinary, images weren’t being converted to WebP, while in the second method it was. I assume there is some kind of extra configuration by the Next.js team under the hood.

Check out the PR and the deploy preview URL for this method and compare the performance difference.

Conclusion

Congratulations on reaching the end! 🎉

Now you know the two ways to function the Next.js Image Component with Netlify. I would suggest using Cloudinary as the default loader until the wonderful developers of next-on-netlify release a performant Image Optimiser.

In my deployed demo, I have used the most performant one. But you can check these deploy URLs and respective PRs to get an understanding.

Using next-on-netlify: PR(#1) and deploy preview.
Using custom loader prop: PR(#2) and deploy preview.
Using Cloudinary as default loader: PR(#3) and deploy preview.

In search of more examples? Check out my PR on this repo where I am converting my community’s website, deployed on Netlify, to use Next 10 and Tailwind CSS.

I over-engineered my blog, and here’s what I’ve learned

Rohan Mehta — Wed, 06 Jan 2021 07:23:36 +0000

Are you the type of person who wants to build something big? Something that doesn’t overwhelm you but gives enough exposure to different technologies that work together. Here, I hope to detail my journey of building a blog afresh (technologies used, suggestions, red flags, pointers).

It took me eight months to launch. But if we’re being honest, had I not slacked off, it wouldn’t have taken me more than a couple of months to get my tasks done.

The following points discuss ways to help you get started and to not make the same mistakes that I did:

Why Do You Want to Have Your Own Platform?
Choose Your Tech the Wise Way
Design First, Code Later
Research, Learn, Research
Escape Tutorial Hell and Start Actual Coding
What to Do When You Feel Stuck?
My Month-Long Hustle
A Note to the Beginners

A fair warning: you might need a hot cup of beverage because this isn’t ending anytime soon!

Why Do You Want to Have Your Own Platform?

We already have several tools of experienced groups of people, serving everyone to start their blog, with no hassle (e.g., ThePracticalDev, Medium, Hashnode, etc.). In a nutshell, it removes distractions and allows creators to focus on the content.

But as a web developer, I am always tinkering with tools to build stuff for the web. It is the best playground out there. So, I made a raw static blog. With my custom tweaks, it wasn’t too much of a vast project for me, and it boosted my skill set, assuring me I can build stuff of my own.

I had little ideas to blog on. Therefore, I did what I knew at that moment and converted whatever I had learned while developing into a blog post.

Also, having your own platform feels a bit more personal, and you can change it whenever, to whatever, or however you want. But yes, no one can deny the value of a community that the above sites bring. So, I suggest that you get the best of both worlds, and cross-post your content on the above sites, linking it to the original source.

Choose Your Tech the Wise Way

Prior to jumping onto the code, put some time aside to plan tasks out. Before proceeding with the tech stack, I wanted to have a mental model of things that I had to accomplish. My initial ambitions included

a combination of my blog and portfolio, so that people can see my projects too
a proper design of colours and font that are eye-catching
a dark mode support
some basic animations like background colour change while hovering, button click shadows, etc. fast page loads with a good SEO

It’s agreeable to have a clear picture in front of you, so you can remain driven in the face of blockages.

After a bit of research on recent trends, I went with the following tools initially that complemented my ambitions well:

Next.js, for generating a static site.
styled-components, for easing the styling process.
next-mdx-remote, for managing mdx files.
rehype-prism, for highlighting code syntax.
next-seo, for managing SEO stuff.
next-pwa, for PWA support.
use-dark-mode, for handling dark mode.
splitbee, for site analytics.

If you want to learn a specific tech or tool, that fits the use of something that you are working on, then you should add it to your tech stack list. In this way, you grasp while creating
(slam dunk! 🏀).

Design First, Code Later

“Let’s get this party started!” cheering to myself, I created a next-app. I installed a few dependencies and set up the initial folder structure.

But wait, hold up! Where are the designs? Should I code with a hazy picture of my future blog that always varies? Or should I let my thought-process get finer by creating designs? Obviously, the latter.

Getting your designs ready before coding helps you stay on track and saves you from bad UI/UX in the beginning.

But I am not a designer. Designing is hard!

Figma is an easy-to-use, collaborative app, accessible on your browser. It has a wide community of designers, who provide amazing plugins to start with basic wireframing and creating low-level designs. Plus, you could always use a simple pen and paper. Just have something visual in front of you.

In the beginning, I had spent a couple of days to figure out the perfect colour combination and fonts. My overflowing concern in colours for dark and light modes left me overwhelmed. It restricted me to direct attention on critical topics.

Colours and font decisions are fun, but first, try to form a basic structure for the website, and try to tackle the hard parts like spacing, mobile responsiveness, etc.

Designing can be time-consuming if you try to be a perfectionist. It exhausted me after dedicating a month to it. A week is doable, but nothing more than that. Your designs help solidify your initial understanding of the layouts and structure.

One of my many hard-learned mistakes, I had put up a timer for three months on the index page, saying ‘Under Construction’. Don’t do this, as it could heavily harm your SEO and page ranking on Google search.

Research, Learn, Research

After my internship finished in August, I took a sabbatical leave from coding. This prevented me from reaching burnout and cleared out a way for more ideas.

Before resuming my work, I glanced at the list of ideas I was maintaining, all of it coming back to me. Going through it again, I realised that my previous designs lacked polish. This allowed me to punch in a few more ideas and improve the previous ones.

Maintain an idea or feature log to give yourself a head start as and when you are back at it.

As I wanted things to pick up a pace, I turned over to Tailwind CSS for a try. A lot of time on hands-on tutorials on YouTube also provided me with fresh ideas.

This phase was quite rewarding. I had figured out a couple of things like

MDX integration
animation with framer-motion
lighthouse optimisations
native feel on mobile devices, using bottom navigation instead of sidebar navigation.
typography and putting the main content in the middle for better readability

Escape Tutorial Hell and Start Actual Coding

In time, I realised that tutorial hell had trapped me, watching other people build things on a loop.
Not knowing when to actually begin, sometimes watching tutorials can be pretty comfortable. But in reality, you aren’t putting that newly got knowledge to any use. It would just vanish away in a week. Such a realisation should come early, as it could protect a lot of your time. Stop watching tutorials until you are in a tight corner again.

To get yourself all pumped up before coding, I would suggest creating a list of activities to carry out on a per-day or a per-week basis. Create a month-long plan, outlining things that you’d do every day. Planning a list in such a way did not overpower me, and also allowed me to take minor breaks in between if I were to get stuck.

I upgraded and removed several packages and re-setup my project. My designs were becoming a reality. With a tool like Tailwind CSS, a non-designer like me was able to create decent-looking websites. From then on, Tailwind CSS was my go-to CSS framework for my side-projects.

During the build process, it's nice to have a different opinion from someone you know. I gave a sneak peek to a couple of my friends, and their initial reactions were inspiring. They liked the new design better than the previous one, assuring me I was moving in the right direction. This could also help you fix those features you were content with but had mixed reactions from others.

What to Do When You Feel Stuck?

Everybody gets stuck sometimes, and it’s alright. I like to think of it hopefully. Because then I get to chase that feeling of accomplishment upon solving it. And if I cannot, then there is always room for more learning. You fail, you learn; you win, you grow.
Don’t want to sound pretentious, but sometimes a problem can be quite hard to solve. My advice would be to get up, leave everything, go for a stroll, or watch a movie. Clear your mind and start afresh.

My Month-Long Hustle

During the last month, the most challenging part for me was MDX integration. Good thing I had watched a lot of tutorials, so I was aware of what I was doing (ha-ha).

I used next-mdx-remote to read and convert MDX (markdown with jsx) to HTML.
It works in the following steps:

Process MDX to HTML. With custom components, it passes raw markdown content. This saves us from importing components in the MDX file itself.

function getFileData(filePath) {
    // read the file contents
    const fileSource = fs.readFileSync(filePath)

    // extract frontMatter data and raw markdown
    // I am using a `matter` for this.
    const { data, content } = matter(fileSource);

    // process the markdown with your custom components
    const mdxSource = await renderToString(content, {
        components: { img: CustomImage,
         code: MyCodeBlock
        }, // pass them here
        mdxOptions: {
            remarkPlugins: [
                require("remark-autolink-headings"),
                require("remark-slug"),
                require("remark-code-titles"),
                require("@fec/remark-a11y-emoji")
            ]
        }
    });

    return {
        mdxSource,
        frontMatter: {
            ...data
        }
    };
}

Hydrate the content. Combine both processed markdown and jsx components, and render them on the client-side.

export default function Blog({ mdxSource, frontMatter }) {
    const content = hydrate(mdxSource, {
        // pass again for hydration
        components: { img: CustomImage, code: MyCodeBlock },
    });

    // use common layout to render a blog post
    return <BlogLayout frontMatter={frontMatter}>{content}</BlogLayout>;
}

Add optional plugins. To use remark and rehype plugins, specify them in the remarkPlugins array in the first step.

Read more
why it’s better than next-mdx-enhanced, and what it is solving.

While shaping this, it cramped me in a scenario that I had to implement a ‘copy to clipboard’ feature for the code blocks.

Initially, I was going with @mapbox/rehype-prism, a rehype plugin for syntax highlighting that also supports line highlighting. I used it by specifying it in the plugin array of next-mdx-remote.

In this method, when the next-mdx-remote finishes with the conversion, it splits out the HTML. It contains divs and span with class names around the elements, which need different styles according to their type. (See the example conversion below.)

import { Flex } from "@chakra-ui/react";

// generated html for above code.
<pre class="language-jsx">
    <code class="language-jsx">
        <span class="token keyword module">import</span>
        <span class="token punctuation">{</span>
        <span class="token maybe-class-name">Flex</span>
        <span class="token punctuation">}</span>
        <span class="token keyword module">from</span>
        <span class="token string">'@chakra-ui/react'</span>
        <span class="token punctuation">;</span>
    </code>
</pre>

For syntax highlighting, I needed to specify styles for every token by targeting all the generated classes. For example, in the above code class="token string" is generated class to target the styles for the word @chakra-ui/react. To apply those styles, I target those elements using CSS class selector.

The issue is that I would not be available to grab the raw text that I want to stick to the clipboard whenever the user clicks the 'copy to clipboard’ button. Because @mapbox/rehype-prism inserts its own divs and spans among the code text, sticking to the user’s clipboard.

As I didn’t have enough time to play with it, I went with another package, prism-react-renderer. It allowed me to access the raw code text in between the conversion process of next-mdx-remote, for it is a wrapper around the <code> block.Therefore, I use it to stick it to the clipboard on button click with ease.

I could then style each line of code separately if I wanted or use a pre-defined theme such as Night Owl by Sarah Drasner.

As I am writing this, I realised that I could have targeted the <code> element from the DOM on button click using document.querySelector. And copy the inner text using innerText method on that DOM element.

I will try it after launch since prism-react-renderer has contributed to low lighthouse scores. On inspecting, I found a lot of unused JavaScript, being parsed on the client-side, increasing the total blocking time.

I felt held back on a few more things, like the dreaded light flicker issue because
of dark mode and the flash of unstyled text (FOUT) because of slow downloading of
fonts.

I solved the dark mode flash issue after reading a comprehensive blog about it by Josh Comeau. And for the FOUT, I stopped using Google fonts and self-hosted my fonts, with the font-display property set to optional. Read more about this here.

Finally, I concluded all of my initial requirements with some added features. I am merry with what I have and quite glad of my efforts.

A Note to the Beginners

Had anyone asked me to model a blog two years ago, by all means, I’d have surrendered in five minutes! When I had set off with web development, I did a bunch of JavaScript exercises. And only when I was comfortable enough, I created my first website, my portfolio. Although plain, it was the start of building small things, deepening my knowledge pool.

As a beginner, I know things can be pretty bewildering. You want to build cool stuff and put it out there, but sometimes, fear of things not working out, or not having enough experience with tools, can pull you back.

I can only suggest to keep learning, exploring new things, and creating an initial understanding. Then you move forward to develop something out of it. Strengthening such initial concepts will guide you to make much bigger things in the future.

Therefore, over-engineering my blog served me to culminate all those small lessons into a project of great size.

I still need to improve and optimize things, but I am at peace with it right now. 😌

If you made it to the end, go checkout my website. Also, hit me up on Twitter if you have suggestions, query or just want to talk.

Have a great one!

Rohan.