CHP: Change the image formats to nextgen formats, i.e: WebP and AVIF

[pdpinch]

As a user, I'd like the site to load faster and have better performance.

One and an important way to achieve this is to optimize the images which contributes a lot to the better performance of the site.

We can change the image formats to nextgen formats, i.e: WebP or AVIF. WebP can be a good choice but keeping in mind the browser support it has:

Reference

Along with changing the format, I think we also need to compress the images which are being uploaded via studio. Like if an image of size 200-300 KB or greater is being uploaded, it can be compressed to under 200KB and I'm sure there will be not much difference in the image pixels.

Along with this, I think we also need to do the same for all the static images of www in ocw-hugo-themes. For that, maybe we can write some scripts or find an online tool to achieve that or maybe there's some other solution too which I don't have in mind at the moment.

With that being said, I guess we can have 3 things to achieve in this ticket for all the images:

1. Change image format to WebP when uploading from studio.
2. Compress the size of the image when uploading from studio.
3. Do the above-mentioned things for all the static images of www in ocw-hugo-themes. (This can be a separate issue/ticket).

The images are being uploaded to S3 from ocw-studio, so keeping the first 2 points (mentioned above) in mind, I think we can achieve them by overriding the upload function and sending compressed, WebP images to S3. In this approach, we might lose the original image uploaded by the user.

I believe, there can be multiple solutions/approaches to this and one of them might be using a third party like imagekit but I need to do a bit more R&D. I'd also like to hear suggestions from other folks.

[pdpinch]

I'd like to narrow the scope of this just to the CHP page.

[pdpinch]

Can we use Hugo to process the images? See https://gohugo.io/content-management/image-processing/#target-format

What impact will that have on build times?

[MAbdurrehman12]

@pdpinch Looked into it and it seems like there are a few things to discuss beforehand. I think I'll get in touch with @gumaerc today or maybe we can have a checkin later on

[gumaerc]

@pdpinch @MAbdurrehman12 I just read over this ticket and I have a few thoughts. First of all, the images in www could be easily batch converted using GIMP or Photoshop, which I can do easily enough and put into a PR. As far as processing images using Hugo, I don't think we'd be able to take advantage of that aside from images directly embedded into a Hugo build. Since our images are stored in S3 and a link to the image is simply written in during the build process, there's nothing there for Hugo to process. What we would likely have to do (in addition to having ocw-studio convert new images) is download all the existing images in S3, convert and re-upload them, then change the references and remove the old images. Another option would be to use an S3 image processing lambda to convert images on the fly that are requested from the production bucket where the site is deployed. This would allow us to essentially change nothing about how ocw-studio handles the images aside from having to change the references to the images to point to .webp instead of .jpg or whatever format they were uploaded in.

[MAbdurrehman12]

the images in www could be easily batch converted using GIMP or Photoshop

Yeah, I also found an online tool through which we can easily convert in webp and reduce their size, in batch.

Since our images are stored in S3 and a link to the image is simply written in during the build process, there's nothing there for Hugo to process.

This was exactly what I had in mind but just wanted to reconfirm

and I agree with your other thoughts stated above. Resizing and converting images on the fly using lamda seems to be a good approach as it has a couple of advantages, I was wondering whether this approach will have any con(s) or any impact on the performance?

[pdpinch]

I don't think I understand S3 image processing lambda option. When would that be invoked?

I'm trying to keep in mind our alternate distributions schemes -- downloading courses zips, mirror drives, etc -- and I'd prefer an approach that allows us to .webp (or whatever) consistently across all of these.

[gumaerc]

@pdpinch You raise a good point about the alternate delivery methods here. From what I understand about lambda, there are a number of ways you can implement it. The first example they give they show a user requesting an object from a bucket that doesn't exist, which triggers a call to a resize API that finds the image they were looking for and resizes it on the fly. For example, a user requests image_sm.jpg and only image.jpg exists on the server, so a call is made to the resize API automatically on the fly and the user is delivered the image.

In our case, I think we'd need to implement lambda functionality on the ocw-studio buckets themselves, not the live site buckets. In theory, we could allow users to upload images in whatever format they want, then we could set it up so that when Concourse goes to build the site any time it requests any kind of image, it's delivered .webp images instead. There are other things we can potentially use lambda for, like delivering the course zips themselves on the fly as a user requests them. The lambda function could do whatever it needs to do to package the course in a ZIP, whatever we eventually decide we should be putting in there, and then deliver it to the user.

This is all hypothetical of course, and I don't have a whole lot of practical experience using lambda. I would need access to the AMS lambda console to play with that and see what's actually possible. It might end up being that it's not the best way to go and we should just convert the assets upon upload in ocw-studio. It seems like lambda is the best option if you need to do stuff "on demand" though so we should keep it in mind for those kinds of use cases.