Automatiser l’optimisation d’images avec un pipeline WASM 2025 — Intégrer esbuild et Lightning CSS

Pour les développeurs web qui jonglent entre builds Jamstack et diffusion edge, la question « quelle part du traitement image doit se faire au build et quelle part à la volée » revient sans cesse. En 2025, l’écosystème WASM (WebAssembly) fournit enfin des compilateurs et optimiseurs rapides qui tournent dans Node.js sans GPU tout en produisant des dérivés de qualité. Ce guide explique comment assembler un pipeline autour d’esbuild et Lightning CSS, renforcé par Squoosh CLI et des encodeurs AVIF compilés en WASM, puis l’intégrer de bout en bout dans le CI/CD.

TL;DR

• Bundle WASM en trois couches : (1) compiler TypeScript + plugins WASM avec esbuild, (2) exécuter Squoosh CLI dans des Worker Threads, (3) laisser Lightning CSS générer automatiquement image-set().
• Règles déclaratives : définir taille/format/qualité dans assets.manifest.json, puis charger ce manifeste via un plugin esbuild.
• Reproductibilité CI : réutiliser des caches .uasset légers plutôt que des blobs Git LFS et régénérer automatiquement quand les hachages divergent.
• Validation locale d’abord : coupler Playwright avec le Comparateur d’images pour détecter les artefacts visuels avant merge.
• Fallbacks et signature : fusionner les profils ICC dans WebP/AVIF via le Convertisseur avancé et conserver un PNG signé C2PA comme ultime repli.

Vue d’ensemble du pipeline

Maîtriser les dérivés avec un manifeste déclaratif

Les scripts npm ponctuels propagent la connaissance tacite. Capturez plutôt l’intention dans un manifeste JSON.

{
  "hero-landing": {
    "source": "assets/hero-source.tif",
    "variants": [
      { "format": "avif", "width": 1600, "quality": 0.82 },
      { "format": "webp", "width": 1200, "quality": 0.88 },
      { "format": "jpeg", "width": 800, "quality": 0.92, "icc": "profiles/display-p3.icc" }
    ],
    "responsive": {
      "breakpoints": ["(min-width: 1280px) 1200px", "(min-width: 768px) 65vw", "100vw"],
      "density": ["1x", "2x"]
    }
  }
}

Le plugin esbuild lit ce fichier et planifie les travaux WASM en parallèle.

Implémenter le plugin esbuild

// build/plugins/image-pipeline.ts
import { Plugin } from 'esbuild'
import { readFile } from 'node:fs/promises'
import { runPipeline } from '../wasm/run-pipeline'

export const imagePipeline = (): Plugin => ({
  name: 'image-pipeline',
  setup(build) {
    build.onStart(async () => {
      const manifest = JSON.parse(await readFile('assets.manifest.json', 'utf-8'))
      await runPipeline(manifest)
    })
  }
})

runPipeline instancie des Worker Threads, maîtrise la concurrence et gère les échecs proprement.

// build/wasm/run-pipeline.ts
import { Worker } from 'node:worker_threads'
import os from 'node:os'

const workerCount = Math.max(1, Math.min(os.cpus().length - 1, 4))

export async function runPipeline(manifest: Record<string, any>) {
  const entries = Object.entries(manifest)
  await Promise.all(entries.map(([id, config]) => dispatchWorker(id, config)))
}

function dispatchWorker(id: string, config: any) {
  return new Promise((resolve, reject) => {
    const worker = new Worker(new URL('./workers/image-worker.ts', import.meta.url), {
      workerData: { id, config }
    })
    worker.once('message', resolve)
    worker.once('error', reject)
    worker.once('exit', code => code !== 0 && reject(new Error(`worker ${id} exited ${code}`)))
  })
}

Dans le worker, mettez en cache les binaires WASM pour éviter les cold starts répétés.

// build/wasm/workers/image-worker.ts
import { parentPort, workerData } from 'node:worker_threads'
import { createRequire } from 'node:module'
const require = createRequire(import.meta.url)

const squoosh = require('@squoosh/lib')
const avif = require('@squoosh/avif')

(async () => {
  const { id, config } = workerData
  const { source, variants } = config
  const jobs = variants.map(async variant => {
    const image = await squoosh.ImagePool.fromPath(source)
    await image.encode({
      [variant.format]: {
        quality: Math.round(variant.quality * 100),
        effort: 7
      }
    })
    await image.save(`public/images/${id}-${variant.width}.${variant.format}`)
  })
  await Promise.all(jobs)
  parentPort?.postMessage({ id, ok: true })
})()

Générer automatiquement du CSS avec Lightning CSS

Pour garder le CSS synchronisé au manifeste, branchez Lightning CSS dans la chaîne.

// build/styles/picture-plugin.ts
import { readFileSync } from 'node:fs'
import { transform } from 'lightningcss'
import manifest from '../../asset-map.json'

export function injectImageSets(cssPath: string) {
  const css = readFileSync(cssPath)
  const result = transform({
    filename: cssPath,
    code: css,
    drafts: { nesting: true },
    visitor: {
      Rule(rule) {
        if (!rule.selectors.includes('.hero-visual')) return
        const sources = manifest['hero-landing'].imageSet
        rule.declarations.push({
          kind: 'declaration',
          property: 'background-image',
          value: {
            type: 'value',
            value: `image-set(${sources.join(', ')})`
          }
        })
      }
    }
  })
  return result.code
}

Après la build, Lightning CSS exploite asset-map.json pour émettre les règles image-set() et les aligner avec les blocs @media. Comme le transformateur tourne lui-même en WASM, le hot reload reste réactif.

Diff et signature dans le CI

Les builds WASM sont rapides, mais une corruption silencieuse reste possible. Protégez-vous côté CI.

1. Diffs visuels : capturez la section hero avec Playwright, puis calculez ΔE2000 via le CLI du Comparateur d’images.
2. Métadonnées : vérifiez avec ExifTool et le Convertisseur avancé que les profils ICC et XMP survivent.
3. Signature C2PA : signez le PNG de secours via le CLI cai et ajoutez l’URI de signature à asset-map.json.

# .github/workflows/build.yml
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run build:images
      - run: npm run test:visual
      - run: npm run sign:fallback
      - uses: actions/upload-artifact@v4
        with:
          name: wasm-assets
          path: public/images

Ces artefacts réduisent de 40 % ou plus le temps de rebuild. Lorsqu’un hash diverge, régénérez les dérivés et alertez l’équipe sur Slack.

Bonnes pratiques côté edge

• Clés de cache : évitez les bascules ?format= opportunistes ; privilégiez la négociation Accept.
• En-têtes : définissez public, max-age=31536000, immutable par défaut et ajoutez must-revalidate uniquement au PNG signé C2PA.
• Fallbacks : si la conversion WASM échoue, renvoyez un JPEG haute qualité produit via le Convertisseur avancé depuis une fonction Lambda@Edge.
• Monitoring : collectez LargestContentfulPaint avec PerformanceObserver et surveillez les régressions lorsqu’un dérivé change de taille.

Checklist de mise en œuvre

• [ ] assets.manifest.json décrit toutes les règles de dérivés.
• [ ] Les workers WASM adaptent la concurrence aux cœurs disponibles.
• [ ] asset-map.json consigne format, dimensions et hash.
• [ ] Playwright + Comparateur d’images automatisent les diffs visuels.
• [ ] Le Convertisseur avancé gère l’injection ICC et la signature dans la release.
• [ ] La négociation Accept et les fallbacks sont validés côté CDN.

En résumé

Un pipeline orienté WASM est plus simple à approvisionner qu’une toolchain native et livre des résultats stables dans un CI cloud. En centrant le flux sur esbuild et Lightning CSS, puis en ajoutant Squoosh et des encodeurs WASM, l’équipe web boucle l’optimisation d’images pendant la build et limite les coûts runtime. Avec des validations et signatures automatiques, vous conciliez performance et confiance, prêt pour un lancement mondial.