-
-
Notifications
You must be signed in to change notification settings - Fork 428
Image Processing Brainstorm #897
Comments
figured i should point out svelte-image exists. also linking the sapper static site optimization thread |
...welp...k...bye... ...and thank you! 🤗 |
i mean.. its still not a first party thing and probably should be. i think its worth keeping open if the maintainers think its a good idea |
hmmmm...yeah, ok. In my mind if it exists it solves my problem, but getting more people on it might be nice :-) |
I'd be surprised if this makes it into the attention of the core team anytime soon, but it would be great to see this eventually appear in Sapper. |
We are all-seeing. |
I was going to write something that handles this for my images I pull in front markdown. My first thought was to do this on the fly as a Lambda when the file was requested. I then was thinking about doing it as part of the build process for upload. In the end, though, I opted to set up lazy loading via JS ( 😢) and do the image size, format, etc from Cloudinary. I am not a huge fan of the lack of picture elements, etc. For example, an animated gif will keep the Gif extension but be an animated WebP in chrome. But it was a cheap, and currently free, solution. My other thought is that image processing is not great at scale. So if I have 100 blog posts with 3 images each. I would be generating 300 images at a minimum, just to optimize. If I wanted placeholder images, images of different formats (WebP, JPEG200) that multiples it considerably. Then you get into generating images that make sense for the responsive size. While this processing is not fast, its not so slow that I can't see us doing it for 100 blog posts, with 3 images. Where it falls over is when your doing this for 1,000's of pages, and 10,000s of images. In other words, I think long term, any solution like this needs some type of cache to prevent duplicate building, or a CDN should be used. I am not sure how Gatsby or Gridsome work at scale for these reasons. |
The Next.js' plugin, next-optimized-images, may also provide useful inspiration. It seems to be the most commonly used for NextJS projects. |
recently Gatsby announced new image processing plugin - https://www.npmjs.com/package/gatsby-plugin-image |
So images are a big deal on the web, and handling them properly by default is a monumental amount of manual work, that can mostly be automated. Gatsby has a plugin for this called
gatsby-image
which does a decent job of dealing with images, and I would be super happy if Svelte/Sapper were to consider something like this as well, at the compile step.The things I would want svelte/sapper to do would be to:
<picture>
elements with<srcset>
's where all of this goodness would be housed.gatsby-image
also gives developers the option to create ansvg
outline of the images content as well, which is pretty neat, but not a necessity. Base64 encoding is common for this approach.Here is an article by Phil Hawksworth outlining the process and some ways to achieve it, via Gulp, Netlify, manually, etc:
https://css-tricks.com/tips-for-rolling-your-own-lazy-loading/
...and here are the docs for
gatsby-image
to help understand where I'm coming from in my desire for this to be included in svelte/sapper:https://www.gatsbyjs.org/packages/gatsby-image/
Anyway, just wanted to get this conversation started and see if other people agree that this would be a nice thing to have built into svelte/sapper.
If I missed a previous issue with this as the subject, my apologies.
The text was updated successfully, but these errors were encountered: