Update Image Optimization

[Snugug]

• [x] Investigate ImgIX, Cloudinary, and other 3p solutions for image optimization
• [x] Implement either a 3P solution, or Vite Plugin Img, depending on outcome of investigation
• [x] FIx resulting bugs from using removing need of picture element
  • [x] Home page fade and parallax
• [x] Height and width added
• [x] GIFs using videos instead

3P Solution Criteria

• Must be able to be used based on URL parameters
• Must be able to both resize images and change formats
• (Optionally) allow upload via API call (eventual CMS integration)
• (Optionally) must be able to convert GIF to Video
• Get pricing for estimated current usage.

3P Solution Implementation

• Vite/PostHTML plugin to manipulate images to Picture elements with correct URLs (like Vite Plugin Img)
• Ensure 3P images can be cached with our Service Worker
• (Optional) Ensure that all images are present in 3P system at build time (imgix example)

[Snugug]

Reached out to ImgIX (who web.dev uses) to ask about GIF to Video conversion (requires an Enterprise plan, so contacted Sales for initial inquiry)

[Snugug]

Signed up for free account, going to test. Some image related things are broken on the current dev build, namely around the home page, so looking to resolve by fixing this image issue.

[Snugug]

ImgIX findings:

• Works off of Google Cloud Buckets, and was able to successfully set it up connecting to our Firebase storage bucket for the site.
• Does work with images not uploaded from the built-in image manager, but those images don't show up in built-in image manager
• Can add categories and custom fields to images, handy for sorting in the image manager.
• Images can be added to paths in image manager, keeping the bucket organized
• Building a CMS that allows image upload and usage w/this tool seems trivial; we can just build an app using our existing Firebase access and bam instant usage.
• Requires the storage service account (auto-generated by Cloud) to have the Storage Object Admin role, which doesn't feel too bad, and likely will be needed for all implementations that use GCP Buckets
• Great tutorial on responsive images with ImgIX; we wouldn't use the DPR stuff but we would use resizing. fit=max means we can kind of blindly apply the same formatting options to all images without fear of sending enlarged images.
• Base image formatting to apply to all images: fit=max&auto=compress,format. This ensures that images are never served larger than their inherit size, they're automatically compressed, and the right format is automatically chosen. Additionally, because format can be automatically chosen, we don't need to wrap images in picture tags; we can apply srcset directly to an img tag, greatly simplifying our overall codebase and the transforms we'll need to do.
• We currently have 239 files in our images folder, which should be well below the 1k origin images mark they price against.
• Includes analytics
• Can sign image URLs to prevent (but web.dev doesn't do this)
• May want to write Vite plugin to cache remote images locally like 11ty Img
• Can use Firebase Storage API to determine if image is available

[Snugug]

Other tools to investigate:

• https://imageengine.io - Does GIF/Video/aWebP conversion, and Google is a prominent partner on their homepage. Pricing may get expensive because I think we'd need their Pro plan just to start out with. In their how we compare page, ImigX appears to be 2nd best per their rankings, and I'm not sure device detection is necessary something we need (but may help w/automatic resizing and compression). Integrates w/GCP Storage. They also offer URL-less and URL-based image manipulation
• https://cloudinary.com - A regular player in the space, will likely need their Advanced plan just for the number of transformations we'll likely make and we don't need (or necessarily want) their DAM solution

Other options investigated but dropped:

• Cloudflare - Doesn't appear to offer GIF->MP4 conversion
• ImageKit - Doesn't appear to offer GIF->MP4 conversion
• Optimole - Focuses on Wordpress. First-pass, doesn't appear to offer GCP integration or GIF->MP4 conversion

[Snugug]

ImageEngine:

• Replace URL with custom CDN name, then a transparent implementation of what's live on your server
• Setting up a website where the images already existed was fairly straight-forward to do, but setting up access from a non-S3 bucket doesn't appear possible. We can probably get around this by having a public-read bucket on GCP, but less elegant than direct integration like ImgIX has.
• Apples-to-apples size test against ImgIX for auto-format and auto-compression results in slightly smaller (77128 vs 80270) payload size which may be cumulative over larger periods of time but probably not so big of a difference
• Biggest optimization win appears to be including auto-resizing of images based on total available screen width (did a test emulating a mobile device) where image is reduced in size to be no taller than device height. Not sure if this is desired or not given that we are already producing srcset code with sizes information, but it's possibly a nice to have
• Most of what's written about ImgIX applies here, except no need for URL params for automatic optimization, although that's not that big of a deal IMO
• Origin image must be present on our server to work, so it's guaranteed to be there on deploy

[Snugug]

Cloudinary:

• Super powerful image manipulation tools, much more than other tools, and has a ton of add-ons, including things like google AI video transcription. Could be super useful for wider marketing/newsletter usecases or CMS usecases if no designer is available to make image adjustments.
• Actual image optimization is much worse than other tools. No out-of-the-box auto formatting that I could find. Created a custom transform that chooses format automatically and uses an "economy" automatic quality optimization ("More aggressive algorithm, which results in smaller files of slightly lower visual quality. Example of a target audience: popular sites and social networks with a huge amount of traffic.") and what was returned (from the same demo) was 107079 as an AVIF (20+kb larger than ImageEngine and ImgIX in a more compressive format).
• Heavy reliance on their DAM, can upload from a GCP Storage bucket, but requires building an app to use their API to upload
• Transforms happen in the middle of a URL instead of as a query parameter, making dynamically building URLs from existing images much more difficult than the other options.
• Has widgets, including media editor, media library, and media upload, that could be super useful when implementing a CMS (https://github.com/chromeos/chromeos.dev/issues/54)
• Has an API that can should be able to be used to determine if image is available on deploy

[Snugug]

Overall:

• All three have analytics to help us understand our image usage
• ImgIX and ImageEngine are roughly equal in terms of automatic image formatting and quality, with Cloudinary trailing (on the sample image) by >33%
• Cloudinary is a very comprehensive suite of image and video manipulation tools, including "creative" ones like sepia tone, image overlays, boomerang effects, region-specified pixelation, and photo collages, whereas ImgIX and ImageEngine offer limited photo manipulation.
• Even with automatic resizing, we'd probably want to build out custom picture elements for each anyway.
• Ease of Implementation
  • ImageEngine seems easiest to implement, just make sure the image is available on the server, and swap out the origin for their CDN. Straight-forward production-only manipulation. It does, though, for us mean keeping images in our codebase, needing to be able to commit to our codebase from a potential CMS to add images, and re-deploying our images with each build.
  • ImgIX seems next-easiest; direct integration with a GCP Storage bucket, makes it pretty straight-forward to use and manage, and the commit and deploy issues from ImageEngine go away. Good support for keeping important areas in crop for responsive images. Image->Video doesn't come out-of-the-box and optimized images are slightly worse than ImageEngine. Images also need to have full path to ImgIX during dev, not just prod, and query params are required to enable optimization (although that's not so bad if we're already transforming image URLs).
  • Cloudinary seems most complex to implement. Requires using their DAM, getting the URL from the DAM, and then transferring new URL back to content, so much less flexibility and can't be done with simple transforms as URLs include revision numbers. Most transforms happen within the URL structure as a sub-folder instead of as a query parameter, making building transforms more difficult than other solutions. Great integration tools should we go down the CMS route, but optimization performance trailed behind the other two options significantly.

Will take this back to the team to discuss and make a final decision.

[Snugug]

After discussing with the team, I think we'll likely go with ImgIX because of its Storage integration and some additional tooling other teams have built that we can share. As for GIF->Video conversion, we'll either go with ImgIX or, when a user uploads a GIF, automatically convert it to a video for them using a Firebase function and serve it straight from storage.

[Snugug]

Closed w/#173