Optimize the images in the site taking up a large portion of space

[vee1e]

One thing we can get a win on is moving all the .png and .jpg files to webp. currently they take up a lot of space and are bloating the git repo a lot (over 75% of the used space).

Currently planned after the migration and 1-to-1 compatibility with the old site.

$ fd . -e png -e jpg -X du -csh
89M    total

[MoralCode]

bloating the git repo a lot

These images are in the git history so even if we resize them, anyone cloning the repo will still download the previous images as well as the new ones.

When i imported these images into the git history, I did what I could to remove images that werent being used at all (trust me there were WAY more images in the site's data folder)

I think ultimately the best plan may be to see if this website repo can eventually move towards importing ALL of the actual page content from other repos (such as chaoss/website). We could then potentially move all the images over to that repo (and optimize them as we transfer them if they aren't already there).

Then this repo can be the "technical core" of the site that "converts" the markdown into an actual HTML site for hosting. Once we get to that point, it may be reasonable to rebase the git history to remove all the images and shrink the repo size since the images will all have a new home.

[MoralCode]

id also be interested to look at the browser compatibility of webp as a format - id want to make sure that we aren't losing support for browsers if we do make this transition.

We could also potentially use features of hugo to downscale/intelligently resize images for us during the build to keep the site fast and enabling us to only store one version of each image in the repo, even if what we end up serving is a smaller version on mobile (etc)

[vee1e]

I think ultimately the best plan may be to see if this website repo can eventually move towards importing ALL of the actual page content from other repos (such as chaoss/website). We could then potentially move all the images over to that repo (and optimize them as we transfer them if they aren't already there).

i see, so you want this repo to become sort of a super-repo that handles the entire website? and then optimize images and rebase

[MoralCode]

less of a super-repo and more like the technical side of the website. I.e. the fedora project website is managed in a similar way with one repo that is the core of the site (page templates, CSS, all the structure) and another repo contains the content that is set up to use Decap CMS to allow people a nice, convenient, git-backed way to edit content.

We dont need to fully copy that, but id like to allow newcomers to make content edits to the site without having to learn what hugo is or how to build the site themselves

#10 is probably a better issue for tracking that kind of overall architecture too

[vee1e]

browser compatibility of webp as a format

true, if we have user analytics would be good to track. webp is supported by pretty much every modern ish browser over the past 5 years sans internet explorer (lol) but for people with older hardware it could be a point of concern

[vee1e]

less of a super-repo and more like the technical side of the website. I.e. the fedora project website is managed in a similar way with one repo that is the core of the site (page templates, CSS, all the structure) and another repo contains the content that is set up to use Decap CMS to allow people a nice, convenient, git-backed way to edit content.

We dont need to fully copy that, but id like to allow newcomers to make content edits to the site without having to learn what hugo is or how to build the site themselves

gotcha