Image Component

[sergiodxa]

Next has this actually useful Image component which wraps the img tag to optimize how you use it and enforce good practices like providing a width and height to avoid layout shifts.

Remix used to have this img: prefix on the imports to get an object instead of a string and that object contained data like the width, height, srcset, placeholder, etc. based on query params. This was removed on the migration to esbuild.

If it's hard to add that way to import adding the component could be a good fallback to have a way to optimize image load.

Component Interface

The component should be used as a drop-in replacement of the img tag, like Form with form.

// Switch from this
<img src={url} alt="something useful here" width={500} height={500} />
// To this
<Image src={url} alt="something useful here" width={500} height={500} />

And just with that it should be enough to start getting the benefit. Other options could be:

interface ImageProps extends HTMLImageAttributes { // it should still support normal img attributes
  src: string;
  width: number; // required
  height: number; // required
  alt: string; // should probably be required
  loader?(options: { src: string; width: number; quality: number }): string;
  quality?: string; // range from 0 to 100
  placeholder?: string; // if defined the string should be used as placeholder, if not it should be empty while the image loads
}

The loader should also be configured in the remix.config file so you don't need to add it individually. Remix could come with some built-in image loaders for services like Cloudinary, Cloudflare Image Resizing (when creating a new project with Cloudflare adapter this could come as the default) and maybe a custom one with some hidden endpoint created by Remix.

Special import

If adding back the support to img: imports, or using assert { type: "image" } in a future, is possible the object returned by the import could come with the same interface the Image component expects, that way you can use it like this:

import guitar from "img:~/guitar.jpg?quality=80&srcset=720,1080,2048&placeholder";
// with import assertion
import guitar2 from "~/guitar.jpg?quality=80&srcset=720,1080,2048&placeholder" assert { type: "image" };
// with import attributes
import guitar3 from "~/guitar.jpg" assert { type: "image" } with { quality: 80, srcSet: [720,1080, 2048], placeholder: true };

export default function Route() {
  // super simple usage
  return (
    <>
      <Image {...guitar} />
      <Image {...guitar2} />
      <Image {...guitar3} />
    </>
  );
}

In this case the usage will be simplified a lot, you import and pass the imported to the component and it should magically work.

[tchak]

I tried to use an image loader based on query params in imports with vite.js and it was a pain because this kind of imports is impossible to type in typescript. So not sure how I feel about them. But it is definitely a problem worth solving 👍

[ryanflorence]

@sergiodxa yeah that was the plan when we had the image importer. Always thinking on the same wavelength!

We're not sure that the compiler is the right place to process something as expensive as images so we decided to remove it and put it on the backburner until v1 is humming along. We have some rough ideas about how to help out with images w/o making the compiler do it. I hope we can get to sooner than later!

[cbdeveloper]

Hey @ryanflorence , any updates on this? Looking forward to it.

[sergiodxa]

I'm not sure how Next.js did it but when you import an image file the object you import has a specific type

interface StaticImageData {
  src: string
  height: number
  width: number
  blurDataURL?: string
}

I saw they have this:

declare module '*.png' {
  const content: StaticImageData

  export default content
}

In a global.d.ts file, not sure if that's the only thing needed to correctly type the import of an image file

[tchak]

Yes declare module '*.png' is what does the trick. But if you start adding query params to the import path, it doesn’t work any more. You would have to explicitly type every possible query params combination which is obviously not possible.

[merodiro]

Next.js also has a way to handle dynamic images with some custom loader without affecting the build time
the way they handle it in run time is they use /_next/image?url=original_url&w=750&q=75 to generate images only when needed

Someone created this gist for a possible way to build it. it's just a POC https://gist.github.com/olikami/236e3c57ca73d145984ec6c127416340

Or maybe as initial implementation you could provide an integration with popular services such as cloudinary or imgix

[ixartz]

Also extremely interested by this feature. Gatsby and Next JS provide out of the box.

Is it a way to do it in React without meta framework like Gatsby and Next JS?

[kaushalyap]

Really need image optimizations!

[sergiodxa]

Jacob from the team created a POC of the component using a resource route to do the optimization https://gist.github.com/jacob-ebey/3a37a86307de9ef22f47aae2e593b56f

[Josh-McFarlin]

@sergiodxa I just released the package remix-image which can automatically create responsive images using resource routes.

https://www.npmjs.com/package/remix-image
https://github.com/Josh-McFarlin/remix-image#readme

Still in trial, and many more features need to be added to meet the functionality of next/image, so feel free to help with any contributions! Right now it only add srcSet and sizes to the img element, but I plan on expanding the library to include support for layouts soon.

[ccssmnn]

Here's my 50 cents. I optimize everything static with Squoosh tailored to the size I want to display it. My main issue was dealing with images that come from the CMS. Clients should not need to worry about performance.

I've taken @jacob-ebey 's example and stripped it down to only serve external images with a predefined width set. For caching, I rely on the CDN instead of caching in the file system. Gonna use this until remix lands its official solution.

// entry.server.tsx
import * as serverSharp from "sharp";

export const sharp = serverSharp.default;

// routes/images.tsx

import React, { ComponentPropsWithoutRef } from "react";
import { LoaderFunction } from "remix";
import { sharp } from "~/entry.server";

const BadImageResponse = () => {
  const buffer = Buffer.from(
    "R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7",
    "base64"
  );
  return new Response(buffer, {
    status: 500,
    headers: {
      "Cache-Control": "max-age=0",
      "Content-Type": "image/gif;base64",
      "Content-Length": buffer.length.toFixed(0),
    },
  });
};

export const loader: LoaderFunction = async ({ request }) => {
  const url = new URL(request.url);
  const src = url.searchParams.get("src");
  const width = url.searchParams.get("w");
  const quality = url.searchParams.get("q");
  if (!src || !width || !quality) {
    return BadImageResponse();
  }
  try {
    const image = await fetch(src);
    if (!image.ok || !image.body) {
      throw new Error(
        `fetching image failed. src: ${src}, status: ${image.status}`
      );
    }
    const imageBuffer = Buffer.from(await image.arrayBuffer());
    let resizedImage = await sharp(imageBuffer)
      .resize(parseInt(width))
      .webp({
        quality: parseInt(quality),
      })
      .toBuffer();
    return new Response(resizedImage, {
      status: 200,
      headers: {
        "Cache-Control": `max-age=${60 * 60 * 24 * 365}, public`,
        "Content-Type": "image/webp",
        "Content-Length": resizedImage.length.toFixed(0),
      },
    });
  } catch (error) {
    console.error(error);
    return BadImageResponse();
  }
};

const widths = [640, 750, 828, 1080, 1200, 1920, 2048, 3840];
const quality = 75;

export const Img: React.FC<ComponentPropsWithoutRef<"img">> = (props) => {
  if (!props.src) {
    throw new Error("no src provided to Img component");
  }
  if (props.srcSet) {
    console.warn("srcSet will be overwritten by srcSetGenerator");
  }
  const srcSetParts = widths.map(
    (width) => `/images?src=${props.src}&w=${width}&q=${quality} ${width}w`
  );
  return (
    <img {...props} srcSet={srcSetParts.join(", ")} src={srcSetParts[0]} />
  );
};

I think this is also a very basic & understandable approach, which others can use and extend to fit their needs, e.g. providing values for width, height and sizes via props. For me, this fire and forget img wrapper is perfect.

[arekbartnik]

@sergiodxa Next’s Image has also the priority prop. It adds link rel=preload to head to improve LCP.

[sergiodxa]

@sergiodxa Next’s Image has also the priority prop. It adds link rel=preload to head to improve LCP.

Because there’s no Head component in Remix that will not be possible I imagine, if you want to preload the image you can add it to the LinksFunction of the route.

[zwily]

Because there’s no Head component in Remix that will not be possible I imagine, if you want to preload the image you can add it to the LinksFunction of the route.

How does the <Link prefetch="render" /> stuff work then? Couldn't we do something similar?

[arekbartnik]

@sergiodxa Next’s Image has also the priority prop. It adds link rel=preload to head to improve LCP.

Because there’s no Head component in Remix that will not be possible I imagine, if you want to preload the image you can add it to the LinksFunction of the route.

I think it should be done at component level. Otherwise it will be too hard to implement it.

[sergiodxa]

Because there’s no Head component in Remix that will not be possible I imagine, if you want to preload the image you can add it to the LinksFunction of the route.

How does the <Link prefetch="render" /> stuff work then? Couldn't we do something similar?

It renders the <link rel="prefetch" /> tags below the <a> not in the <head> but the difference is that you are prefetching data and assets for the next page, doing this:

<link rel="preload" as="image" href="/something.png" />
<img src="/something.png" />

Will not give you a lot of benefits because it's going to trigger the preload just when it's about to find the img tag so don't optimize anything. The point of preload would be to put it in the <head> so before it starts to parse the body it can start loading the image immediately and when you do <Link prefetch="render" /> (or prefetch="intent") it will prefetch the image before the page navigate.

[zwily]

Will not give you a lot of benefits because it's going to trigger the preload just when it's about to find the img tag so don't optimize anything. The point of preload would be to put it in the <head> so before it starts to parse the body it can start loading the image immediately and when you do <Link prefetch="render" /> (or prefetch="intent") it will prefetch the image before the page navigate.

Makes sense. Surely we can figure out a way to allow components down tree to jam themselves up into <head> right? Requiring someone to specify the images to preload in links() seems kind of sad, especially since we want to put the generated imagesrcset in there, not just the image path.

[Knaackee]

@ryanflorence any news on this?

Thanks for your great work!

[thomasverleye]

Honestly, never liked the Next.js Image component.
Srcsets are wild guesses based on the widths provided with to the component with their own opinionated breakpoints.
The width of an image is in a lot of cases never going to be certain width on every breakpoint.
Grids systems exist for a reason 😊

Besides that, developers always try to abstract everything by moving everything in a custom component leaving no wiggle room to edit or change the <img /> tag and its attribute, I think that is wrong.

In my whole career as a Front-end Developer, I have never found a distinct and 100% correct component that generates this out of the box.

What I always end up doing is just using a service (like imgIX) and creating helper functions to generate srcsets based on widths developers provide themselves based on the sizes they create.

An example of some helper function I use in a project:

export function imgixSrc(url, width, aspectRatio = null, fit = 'crop') {
  if (!url) {
    throw new Error('No `url` argument available.');
  }

  if (!width) {
    console.warn(
      "You did not include a `width` argument, the image will be source size, that's probably not what you're intending to do.",
    );
    return url;
  }

  if (!aspectRatio) {
    return `${url}?w=${width}`;
  }

  if (!(typeof aspectRatio === 'string')) {
    console.warn('aspectRatio should be of type string.');
    return `${url}?w=${width}`;
  }

  return `${url}?w=${width}&ar=${aspectRatio}&fit=${fit}`;
}

export function imgixSrcSet(url, widths, aspectRatio = null, fit = 'crop') {
  return widths
    .sort((a, b) => a - b)
    .map((width) => {
      return `${imgixSrc(url, width, aspectRatio, fit)} ${width}w`;
    });
}

With these functions, you end up building your <img /> tags like this:

import { imgixSrc, imgixSrcSet } from '@/lib/helpers';

const imageSizes = `
  (min-width: 394px) 346px
  calc(100vw - 48px)
`;

const imageWidths = [
  272, // (320px - 48px)
  327, // (375px - 48px)
  346, // 346px is the max-width
  544, // (320px - 48px) * 2
  654, // (375px - 48px) * 2
  692, // 692px is the max-width in dpr 2
];

const SomeComponent = ({ image }) =>  (
  <img
    alt={image.alt ?? ''}
    loading="lazy"
    sizes={imageSizes}
    src={imgixSrc(image.url, 346, '5:4')}
    srcSet={imgixSrcSet(image.url, imageWidths, '5:4')}
  />
);

Please note that these functions are in JavaScript but do not hesitate to copy-paste these and rewrite them in TypeScript ✌️
If you'd like I also have some resize examples as well 🤗

[iDVB]

Also interested where Remix Image optimization is at.
Currently using Gatsby for all our sites and REALLY liking what we see in Remix.
Started to look at feature parody and stuck at Image Optimization.

[TooTallNate]

If you add a vercel.json file with "images" configuration, then the Vercel Image Optimization endpoint (/_vercel/image) will be active in your Remix app:

{
  "images": {
    "domains": [],
    "sizes": [
      640,
      750,
      828,
      1080,
      1200,
      1920,
      2048,
      3840,
      16,
      32,
      48,
      64,
      96,
      128,
      256,
      384
    ],
    "remotePatterns": [],
    "minimumCacheTTL": 60,
    "formats": [
      "image/webp"
    ],
    "dangerouslyAllowSVG": false,
    "contentSecurityPolicy": "script-src 'none'; frame-src 'none'; sandbox;",
    "contentDispositionType": "inline"
  }
}

[dantman]

@TooTallNate Thanks. Vercel's image optimization documentation and configuration documentation doesn't document that anywhere.

[TooTallNate]

@dantman Thanks for pointing that out. We added documentation for that here: https://vercel.com/docs/projects/project-configuration#images

[muco-rolle]

Hey @TooTallNate with that configuration, is it possible to access local images? like the one found in the Public folder? I was able to access remote images and get them optimized but I'm having a hard time accessing the local ones.

I tried something like this https://remix-v2-rho.vercel.app/_vercel/image?url=images/rio.jpeg&w=500&q=75(that image is accessible on my server at https://remix-v2-rho.vercel.app/images/rio.jpeg) but I keep getting a 400 error

[TooTallNate]

@muco-rolle I'm not actually sure to be honest. I think possibly your remotePatterns configuration is preventing that from being allowed. Try doing like I have above.

[zolzaya]

@ryanflorence any news on this?

[thomasverleye]

There are some suggestions as alternatives in the comments :-)
Also, if you want to know where the Remix team currently is working on, you could see their project board:
https://github.com/orgs/remix-run/projects/5

[zolzaya]

Okay thanks for info

[lambdaxyzt]

Hi, also mention that I write a gist for image component with capability of caching , stream base , using sharp
https://gist.github.com/lambdaxyzt/1ad05e98b73aab71fc7714d150a1480a

[kyeshmz]

Hi, just wondering if this is dependent on a certain deployment method as the path caching would not work for lambda operations.