Skip to content

System task: Image optimization (diagnose + fix) #495

@chubes4

Description

@chubes4

Context

DM has a proven pattern for system tasks: diagnose a structural issue across the site, then fix it. This works great for alt text (alt-text diagnosealt-text generate) and internal links (links diagnoselinks crosslink).

Images are a major gap. DM can generate images via AI, but has no system task for detecting and fixing oversized/unoptimized images — one of the most common structural performance issues on WordPress sites.

Discovery (chubes.net audit)

WordPress stores everything we need in wp_get_attachment_metadata:

  • Original dimensions (width × height)
  • File size (via get_attached_file + filesize)
  • Registered thumbnail sizes and whether they exist
  • MIME type

Example findings on chubes.net (39 images):

  • 1.9MB JPEG at full resolution (ID 1527)
  • 410KB 1024×1024 JPEG (ID 1562)
  • 230KB 1456×816 JPEG (ID 1545)
  • No WebP variants for any images

PHP has both GD and Imagick available — no external API or plugin needed for compression, resizing, or WebP conversion.

Proposed

wp datamachine images diagnose

Scan media library and report:

  • Images exceeding a configurable size threshold (default: 200KB)
  • Images with dimensions larger than WordPress's large_size_w/large_size_h that don't have a -scaled version
  • Missing WebP/AVIF variants
  • Missing registered thumbnail sizes (need wp media regenerate)
  • Summary table: total images, total size, count over threshold, potential savings estimate

Output as table/json/csv like other DM diagnose commands.

wp datamachine images optimize

Fix what diagnose finds:

  • Compress oversized originals via Imagick (configurable quality, default: 82)
  • Generate WebP variants for images that don't have them
  • Regenerate missing thumbnail sizes
  • --post_id=<id> to target a specific post's images
  • --dry-run to preview what would change
  • Batch-aware (uses DM's existing batch system for progress tracking)

Imagify replacement?

This could fully replace Imagify for most sites. Imagify's cloud API gives marginally better compression ratios, but WordPress ships Imagick which handles lossy/lossless compression, resizing, and WebP conversion natively. No external API dependency, no subscription, no API key.

For sites that want Imagify's cloud compression, DM could detect it's installed and delegate to it. But the default path should be self-contained.

Why

  • AI Calls Tools Repeatedly Sometimes #1 structural issue flagged by Lighthouse on most WordPress sites
  • PageSpeed opportunities already surfaces it — DM should be able to act on it
  • All the data and tools already exist in WordPress core — this is just wiring
  • Follows the proven diagnosefix pattern from alt-text and links

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions