[efficiency-improver] Energy efficiency opportunities — initial scan (2026-05)

[github-actions]

🤖 Efficiency Improver here — I'm an automated AI assistant focused on reducing the energy consumption and computational footprint of this repository.

This is my first scan of the repo. Filing this as an issue (rather than a PR) so a maintainer can choose between two viable approaches before any binary asset is changed.

Scope reminder

This is a documentation/configuration-only repository — no application code to profile. The only meaningful proxy metric here is network transfer size: every byte saved on a git clone, README render, or LLM context load translates linearly to electricity used by network gear, CDN nodes, and client devices ([GSF Networking principle]((learn.greensoftware.foundation/redacted)

Findings

🟡 MEDIUM — Hero image is the dominant payload

File: docs/green-software-with-ai.jpeg
Current size: 482,060 bytes (470.8 KB) — 4.3× larger than the next largest file in the repo and dominates README weight.
Referenced from: README.md:1 (top-of-readme hero), so it loads on every visit to the repo page.
Format: Baseline JPEG, 724×1086, RGB. Estimated original encoding quality ~75–80 (DQT[0] sum ≈ 475).

Measured alternatives

Format	Quality	Size	Saving vs original	Notes
WebP	q=85, method=6	317,520 B	−34.1% (−165 KB)	Single re-encode from JPEG. WebP is rendered natively by GitHub markdown. Requires renaming + updating README.md:1.
WebP	q=80, method=6	266,494 B	−44.7% (−215 KB)	Aggressive; visible-quality margin shrinks.
Optimized JPEG	q=85, optimize+progressive	303,797 B	−37.0% (−178 KB)	Drop-in: same path/extension, no README.md edit. PSNR vs original = 32.55 dB (acceptable: ≥30 dB is the rule of thumb for web imagery). Slight double-encoding loss.
Optimized JPEG	q=82, optimize+progressive	281,521 B	−41.6%	Same trade-off as above, slightly more loss. PSNR 31.84 dB.

Methodology: decoded the source with Pillow once, re-encoded with each setting, then re-decoded for byte-accurate file-size measurement and PSNR comparison against the original.

Recommendation

Either approach is a real win. I'd lean toward optimized progressive JPEG at q=85 because it's a one-file change with no README edit and zero rendering-compatibility risk. WebP saves a touch less here (34% vs 37%) but generally compresses photographic content better at lower qualities — worth the extra change if you're comfortable touching README.md:1.

If you'd like, I can open a focused PR with whichever option you prefer — just react or comment with webp or jpeg. I won't open a PR until I see maintainer input, per the workflow's "no breaking changes / no binary swaps without approval" guideline.

🟢 LOW — Token efficiency of agent/skill markdown

The agent (.claude/agents/green-software-engineer.md, 6.0 KB) and skill (.claude/skills/green-software/SKILL.md, 4.2 KB) are loaded into Claude's context every time they fire. They're already reasonably tight, but if the project intentionally targets minimum-token operation, there's a small (~10–15%) opportunity in tightening repeated phrasing. Not actioning — the readability cost almost certainly outweighs the token savings for files that load at most once per session. Listed only so future scans don't re-discover it.

✅ Already green — everything else

• No build, test, or CI compute footprint (no application code)
• Documentation files are concise and well-structured
• docs/llms.txt is appropriately compact for LLM consumption
• .gitattributes and .gitignore are minimal

Out of scope

• The 108 KB efficiency-improver.lock.yml is auto-generated by gh-aw and would not benefit from manual optimisation — leaving alone.

Next steps

• Maintainer signals preferred image format (webp or jpeg)
• I open a one-file PR with measurements in the description

No other actions required from this scan.

Generated by Efficiency Improver · ● 10.9M · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/efficiency-improver.md@79c99dfd73f3b7ad8ab2b0f4944838018dbe4736