Add global image optimization support

[hujambo-dunia]

Addresses #3537

Simplified optimized image component.

Images must be located in the /src/assets/ directory to be optimized. Uses Astro Picture component for better browser compatibility with format fallbacks. Works for the following Astro asset types:

1. Markdown (.MD) for Frontmatter image only - the default size

image: /src/assets/HiRes.png
---

2. Astro (.Astro) file images

Width is target width. Height is calculated.

<Image
   src="/src/assets/HiRes.png"
   alt="Galaxy"
   width={320}
   class="inline-block ml-2 -mt-1"
/>

---

Sample image optimization results for 3.7 MB PNG into WebP format at 90% quality no scaling (image from this post):

Yields 95% memory improvement 🎉running locally (note: "Time" difference is likely encoding time for WebP)

---

Next Steps:

1. Compare optimization results on Production (adjust configs and Quality as needed).
2. Explore extending component to embedded images in Markdown files.

[dannon]

This approach (publicDir: '../static') replaces Astro's default public/ directory entirely, which would break preprocessed per-article images, search-index.json, and robots.txt. #3687 takes a different approach — extending the existing preprocessing copy pattern to handle content/assets/ and content/media/ the same way content/images/ is already handled. No new dependencies or config changes needed. I'd recommend closing this in favor of that PR.

[hujambo-dunia]

Hey @dannon Sure - I will reverse that commit in my "draft" PR. Yes, shortly after pushing that commit, I realized that changes to publicDir, while would fix certain things, would break the image paths in other ways. So I'm glad to remove that commit from the PR. However, I will leave that PR open for the attached issue because modifications still need to be made on the ArticleLayout.astro for frontmatter image optimization. I have made a first run and results look good as you recommend - savings of 90% memory. I will push those changes this afternoon.

[hujambo-dunia]

Still need to update this branch & fix linting, but comments welcome.

[dannon]

Thanks for picking this up. Image optimization is a good goal. A few questions as I look through this:

In ArticleLayout.astro, the image && conditional guard was removed from around the <figure> wrapper. The Image component handles the null case internally, but won't that leave an empty <figure> with padding rendering on every article that doesn't have a frontmatter image?

Looking at the content, all the existing frontmatter image values use paths like /images/logos/foo.png served from public/. The component optimizes images from /src/assets/, which is currently empty. What happens for those existing paths — they'd fall through to the plain <img> fallback, right? What's the plan for connecting this to actual content?

The import.meta.glob('/src/assets/**/*.{png,jpg,jpeg,gif,webp,svg}', { eager: true }) runs on every page that uses the component, which via ArticleLayout is every article. What happens when that directory starts filling up with images — does every page bundle all of them?

[hujambo-dunia]

Looking at the content, all the existing frontmatter image values use paths like /images/logos/foo.png served from public/. The component optimizes images from /src/assets/, which is currently empty. What happens for those existing paths — they'd fall through to the plain <img> fallback, right? What's the plan for connecting this to actual content?

Good question. The images for existing/legacy Hub is pretty undisciplined and images are found throughout various content, media, and nested directories. So, I'm thinking we have two general approaches: (1) enforce image optimization across the entire site (except for maybe one or two directories likes /logos where quality is crucial) by configuring Astro to allow optimization beyond its default scope of /src/assets - but that is assuming that is even possible in Astro. This has the benefit of not changing user behavior/documentation/index.md files and being fully backward compatible. Or (2) keep Astro's default settings and copy newly added images into Astro's default optimization directory at /src/assets and maybe add a Github webhook that enforces that newly added images be saved in the optimization directory (and replicate directory structure for images within /src/assets to prevent file name collisions). However, in order to make backward compatible we'd have to modify all existing index.md files (~1900 files) that have front matter images. I'm thinking I'll explore Option #1 first. Thoughts?

[hujambo-dunia]

GPT has some thoughts on the matter - over the weekend, I can look into this one too if you think Vite-ImageTools is another good option:

Option 3 — Custom Vite Plugin

1. Add a Vite image optimization plugin like:

• vite-imagetools
• vite-plugin-image-optimizer

2. Configure it inside astro.config.mjs

import { defineConfig } from "astro/config";
import imagetools from "vite-imagetools";

export default defineConfig({
  vite: {
    plugins: [imagetools()]
  }
});

[hujambo-dunia]

Apologies for the long-winded conversation but I guess I had to think things through a bit... The latest commit takes an altogether different approach and is basically a "dev-qa" version. I am polishing it up now - fingers crossed will be able to get significant image optimization savings and help realize @dannon's vision of improved infrastructure.

[hujambo-dunia]

Sample terminal output: aggregate report. Example is for about 15% images in /news directory.