Image Optimisation with next/image

Images are one of the quickest ways to make a website feel slow, heavy, and visually unstable. They are also one of the hardest assets to ignore because the problems are easy for users to feel even when they cannot name them.

Pages jump whilst images load.

Mobile users download more pixels than they need.

Large hero images quietly dominate the payload.

That is why Next.js introducing next/image mattered. It took a familiar web performance problem and turned it into a first‑class framework concern rather than leaving every project to reinvent the same optimisation habits.

A normal img tag leaves more work to the developer

There is nothing wrong with plain HTML images, but using them well requires discipline:

• choose sensible sizes
• avoid layout shifts
• think about responsive behaviour
• think about loading priority
• optimise the assets beforehand

These are all still important with next/image, but the component gives us much better defaults and tooling around them.

The Basic Usage is Familiar

At a simple level:

import Image from 'next/image';

const Hero = (): JSX.Element => {
  return (
    <Image
      src="/images/hero.jpg"
      alt="Mountain landscape"
      width={1600}
      height={900}
    />
  );
};

The component still needs the essentials:

• a source
• alt text
• dimensions

That dimension requirement is one of the most useful differences.

Width and Height Help Prevent Layout Shift

One of the most frustrating image problems on the web is content jumping down the page once an image finally appears.

If the browser does not know the image dimensions early enough, it cannot reserve the correct space.

next/image encourages us to provide width and height up front so layout can remain more stable. That is not just a technical nicety. It makes the page feel calmer and more deliberate.

Responsive Images Matter Because Users Do Not All Need the Same Asset

A huge desktop hero image should not necessarily be sent in the same form to a smaller mobile device.

This is one of the places where image optimisation becomes more than just compression. It is also about matching delivery to context.

Next.js helps by generating more appropriate image outputs and letting the browser choose more suitable sizes for the situation.

Lazy Loading is Another Practical Benefit

Images below the fold often do not need to load immediately.

If the user has not scrolled anywhere near them yet, loading them later can reduce the initial cost of the page. next/image helps with this sort of behaviour by default in a way that is much nicer than wiring up every image manually.

Again, the gain is not only theoretical. Less initial competition for network and rendering resources can make the page feel more responsive overall.

Not Every Image is Equally Important

This is another useful mindset that next/image encourages.

Some images are decorative and can wait.

Some are essential to the first impression of the page and deserve higher priority.

Good image optimisation is not only about shrinking files. It is about deciding which images matter to which moment in the user journey.

The Component Does Not Remove the Need for Judgement

It would be nice if a single framework component solved image performance entirely, but no component can fully substitute for good content decisions.

Teams still need to think about:

• whether an image is too large conceptually
• whether the crop makes sense
• whether the alt text is useful
• whether the page really needs all the imagery it contains

next/image improves delivery. It does not rescue weak image choices upstream.

It is Especially Useful on Content‑Heavy Pages

Blogs, editorial pages, category pages, and marketing pages often lean heavily on imagery. That means image performance can have a huge effect on:

• first impressions
• scrolling smoothness
• perceived polish
• mobile usability

This is why image optimisation is so often a meaningful part of front‑end quality work rather than just a nice extra.

Accessibility Still Matters Just as Much

Because the feature is performance‑focused, it is easy to fixate on bytes and forget meaning.

The alt text still matters.

Decorative images should still be treated as decorative. Informative images should still be described meaningfully. A fast image that fails accessibility expectations is still a poor image implementation.

Better Defaults Matter with Expensive Assets

Before shipping an image‑led page, check it at narrow and wide viewport sizes. Does the browser download an appropriately sized image, is its space reserved before it loads, and does the alternative text still make sense? Those checks tell you more than the choice of component alone.

I would also check a slower connection. An image that looks fine on a desktop can still leave somebody waiting on their phone.

import Image from 'next/image';

const ArticleHero = (): JSX.Element => {
  return (
    <div style={{ position: 'relative', width: '100vw', height: '420px' }}>
      <Image
        src='/images/article-hero.jpg'
        alt='Office workspace with multiple displays'
        fill
        priority
        sizes='100vw'
        style={{ objectFit: 'cover' }}
      />
    </div>
  );
};