#best approach to handle svg

1 messages · Page 1 of 1 (latest)

icy orchid
#

what is the best way to handle svg with nextjs project?

  1. utilizing next/image with public directory
  2. utilzing loader to use svg as react JSX element

I guess 1. => storing many images in public can increase payload
2. => can render svg on serverside so it just can be contained in html payload

so 2. might be better.

is it right comparison?

vapid perchBOT
#

Hi @icy orchid. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

#

Your comparison is quite accurate. However, it's important to note that each approach has its own use cases and benefits.

  1. Utilizing next/image with the public directory: This approach is beneficial when you want to leverage Next.js's built-in Image Optimization API. However, the default loader does not optimize SVG images due to a few reasons. SVG is a vector format meaning it can be resized losslessly. Also, SVG has many of the same features as HTML/CSS, which can lead to vulnerabilities without proper Content Security Policy (CSP) headers. Therefore, it's recommended to use the unoptimized prop when the src prop is known to be SVG. This happens automatically when src ends with .svg. If you need to serve SVG images with the default Image Optimization API, you can set dangerouslyAllowSVG inside your next.config.js. It's also strongly recommended to set contentDispositionType to force the browser to download the image, as well as contentSecurityPolicy to prevent scripts embedded in the image from executing [source (https://nextjs.org/docs/pages/api-reference/components/image#dangerouslyallowsvg)].
module.exports = {
 images: {
 dangerouslyAllowSVG: true,
 contentDispositionType: 'attachment',
 contentSecurityPolicy: "default-src 'self'; script-src 'none'; sandbox;",
 },
}
  1. Utilizing a loader to use SVG as a React JSX element: This approach is beneficial when you want to manipulate the SVG as a React component, for example, changing the fill color based on the theme. However, this approach might not be as efficient as the first one in terms of caching and delivering the SVG files.
#

In conclusion, if you're dealing with a large number of SVG files and want to leverage Next.js's Image Optimization API, the first approach might be more suitable. On the other hand, if you want more control over the SVG and don't mind the potential performance trade-off, the second approach might be a better choice.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@icy orchid kapa.ai is still learning and improving, please let us know how it did by reacting below

icy orchid
#

what about payload? I guess public directory is always delivered, increasing payload.

#

@vapid perch what about payload? I guess public directory is always delivered, increasing payload.

vapid perchBOT
#

Let me check the knowledge base for you. One moment! :books:

#

The public directory in a Next.js application is used to serve static assets like images, fonts, and other files. These files are not included in the JavaScript bundle, so they don't directly contribute to the JavaScript payload size. They are served separately by the server or CDN.

However, if you have a large number of static assets in the public directory, it could potentially increase the amount of data that needs to be downloaded by the client. This is especially true if these assets are large in size.

To optimize the delivery of these static assets, you can leverage the caching capabilities of CDN providers. Files inside the public directory can be cached by CDN providers so that they are delivered efficiently.

Also, Next.js does not safely cache assets in the public folder because they may change. The default caching headers applied are Cache-Control: public, max-age=0.

If you're dealing with a large number of SVG files and are concerned about the payload size, you might want to consider using a third-party service like Vercel Blob or AWS S3 for persistent file storage. Only assets that are in the public directory at build time will be served by Next.js. Files added at request time won't be available [source (https://nextjs.org/docs/pages/building-your-application/optimizing/static-assets)].

In terms of SVGs specifically, if you're using them as React components (option 2), they will be included in your JavaScript bundle and will contribute to its size. However, this allows you to manipulate them as JSX elements and could potentially save on HTTP requests since they are included in the initial payload.

#

In conclusion, the impact on payload size depends on how you're using the SVGs and the specific requirements of your application.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: