Hébergement d’images efficace : CDN et traitement

Tim Koschützki

Cofondateur · Berlin, Allemagne · Afficher la bio

La diffusion statique et la transformation d’images répondent à des besoins différents. Un CDN statique met en cache des fichiers existants ; il ne redimensionne pas un JPEG simplement parce que vous ajoutez ?width=800. Ici, vous générerez des fichiers versionnés à partir d’une photographie locale de confiance et ouvrirez un aperçu adaptatif avec un mécanisme de secours pour l’image déclenché une seule fois. Vous pourrez ensuite publier ces mêmes fichiers sur votre CDN d’hébergement d’images.

Choisir des fichiers statiques ou des transformations dynamiques

La prégénération évite le travail de décodage lorsqu’une nouvelle URL d’image est demandée. Vous stockez et publiez un ensemble connu de fichiers, y compris des variantes qui ne seront peut-être jamais demandées. Une URL versionnée identifie un fichier dont les dimensions et le format sont fixes, ce qui facilite la distinction entre les échecs de génération et les échecs de diffusion.

Choisissez délibérément entre des variantes prégénérées et un service de transformation. Si vous avez besoin de redimensionnements arbitraires, utilisez une origine assurant le traitement ou un service tel que le Smart CDN de Transloadit. Vérifiez les règles de ce service concernant les paramètres et la signature ; les objets S3/CloudFront statiques n’interprètent pas les paramètres de transformation dans la chaîne de requête.

Cloudinary

Les services de transformation hébergés définissent leur propre syntaxe d’URL et les emplacements sources autorisés. Suivez la référence des transformations de Cloudinary⁠ ou la documentation équivalente de votre fournisseur. Une URL provenant d’un fournisseur ne peut pas servir de contrat générique de redimensionnement sur un autre CDN.

Outils et bibliothèques pour le traitement d’images

Sharp (Node.js)

Utilisez une version maintenue de Node.js 26⁠ et Corepack⁠, installé séparément. Cet exemple a été testé avec Node.js 26.12.1 et 26.13.0, ainsi que Yarn 4.12.0. Sharp 0.35.4 est la version fixée ici pour la reproductibilité ; cela ne signifie pas qu’il s’agit de la version corrective la plus récente. Consultez les prérequis d’installation de Sharp⁠ pour connaître les plateformes prises en charge et les paquets natifs facultatifs.

Exécutez ce bloc Bash depuis un répertoire accessible en écriture. Il crée un projet Yarn distinct et laisse votre shell dans son répertoire d’origine. Le fichier de verrouillage vide délimite un projet même au sein d’un espace de travail existant ; Yarn lit toujours la configuration applicable des répertoires parents.

(
  command -v node >/dev/null &&
  command -v corepack >/dev/null &&
  mkdir image-publish &&
  cd image-publish &&
  printf '%s\n' '{"private":true,"packageManager":"yarn@4.12.0"}' > package.json &&
  touch yarn.lock &&
  corepack yarn add --exact sharp@0.35.4
)

Si image-publish existe déjà, choisissez un autre nom de répertoire plutôt que d’en supprimer le contenu. Si l’installation échoue après sa création, inspectez ce répertoire et choisissez un nouveau nom pour la prochaine tentative d’installation. Une fois l’installation réussie, ouvrez un terminal dans image-publish. Utilisez corepack yarn node pour le script afin qu’il fonctionne aussi bien avec l’installation Plug’n’Play par défaut de Yarn qu’avec son mode de liaison node-modules.

Fournissez photo.jpg : son contenu peut être au format JPEG ou PNG malgré ce nom de fichier fixe. Utilisez une image sRGB de confiance sur 8 bits, sans canal alpha. Le fichier d’entrée doit être non vide et ne pas dépasser 8 MiB, avec au maximum 12 000 000 pixels et une largeur d’au moins 1280 pixels après application de l’orientation EXIF. Le programme rejette les autres formats décodés, espaces colorimétriques et profondeurs d’échantillonnage. Il s’agit d’un traitement séquentiel de publication, et non d’un point de terminaison de téléversement ou d’un outil général de validation de fichiers hostiles. Les conteneurs JPEG et PNG sont lus comme une image fixe principale ; cela ne prouve pas qu’une image complémentaire MPO, une animation APNG ou une carte de gain HDR a été traitée.

Enregistrez ceci sous build-images.mts :

import { mkdir, open, writeFile } from 'node:fs/promises'
import sharp, { type SharpOptions } from 'sharp'

async function main() {
  const file = await open('photo.jpg', 'r')
  let source
  try {
    const stat = await file.stat()
    if (!stat.isFile() || stat.size < 1 || stat.size > 8 * 1024 * 1024) {
      throw new Error('Use a regular source image no larger than 8 MiB.')
    }
    source = Buffer.alloc(stat.size)
    let offset = 0
    while (offset < source.length) {
      const { bytesRead } = await file.read(source, offset, source.length - offset, null)
      if (bytesRead === 0) throw new Error('Source changed during publishing.')
      offset += bytesRead
    }
  } finally {
    await file.close()
  }
  const options: SharpOptions = { limitInputPixels: 12_000_000, failOn: 'warning' }
  const metadata = await sharp(source, options).metadata()
  if (!['jpeg', 'png'].includes(metadata.format) || (metadata.pages ?? 1) !== 1) {
    throw new Error('Use a JPEG or PNG primary image.')
  }
  if (metadata.space !== 'srgb' || metadata.depth !== 'uchar' || metadata.hasAlpha) {
    throw new Error('Use an 8-bit sRGB image without an alpha channel.')
  }
  const orientedWidth = metadata.autoOrient?.width ?? metadata.width
  if (!orientedWidth || orientedWidth < 1280) throw new Error('Source must be at least 1280px wide.')
  await mkdir('images', { recursive: true })
  for (const width of [320, 640, 1280]) {
    const result = await sharp(source, options).rotate().resize({ width }).webp({ quality: 80 })
      .toBuffer({ resolveWithObject: true })
    await writeFile('images/photo-' + width + '-v1.webp', result.data, { flag: 'wx' })
  }
  const fallback = await sharp(source, options).rotate().resize({ width: 640 })
    .jpeg({ quality: 80 }).toBuffer({ resolveWithObject: true })
  await writeFile('images/photo-640-v1.jpg', fallback.data, { flag: 'wx' })
  console.log(JSON.stringify({ width: fallback.info.width, height: fallback.info.height }))
}
main().catch((error: unknown) => {
  console.error(error instanceof Error ? error.message : 'Image publishing failed.')
  process.exitCode = 1
})

Exécutez le programme enregistré depuis ce répertoire :

corepack yarn node build-images.mts

Il écrit trois variantes WebP définies uniquement par leur largeur, de 320, 640 et 1280 pixels, ainsi qu’un JPEG de repli de 640 pixels de large. Toutes conservent le rapport d’aspect après orientation. La dernière ligne JSON indique la largeur et la hauteur réelles du JPEG. Ouvrez l’aperçu local et inspectez l’image avant de téléverser quoi que ce soit ; la qualité 80 est un réglage de l’encodeur, pas une promesse de taille de fichier ou de qualité perceptuelle donnée.

Ne modifiez pas le fichier d’entrée pendant l’exécution. Les écritures exclusives refusent les noms de fichiers de sortie existants, y compris celui du JPEG de repli. Un échec peut laisser des fichiers de sortie partiels ; inspectez-les et utilisez une nouvelle version pour réessayer. Lors de la publication d’une nouvelle version, modifiez v1 simultanément dans tous les noms de fichiers de sortie et toutes les références HTML. Le traitement ne supprime pas les fichiers qu’il a déjà écrits en cas d’échec.

L’orientation automatique⁠ de Sharp applique l’orientation EXIF avant le redimensionnement. Son comportement de sortie par défaut⁠ supprime les métadonnées sources. Inspectez vous-même les couleurs et l’orientation du rendu ; ces limites ne prouvent pas qu’un original endommagé est intact.

ImageMagick

Si vous disposez déjà d’ImageMagick 7 avec la prise en charge de JPEG et de WebP, cette commande Bash crée un petit fichier WebP à partir de la même source approuvée. Elle a été testée avec ImageMagick 7.1.2-32 ; obtenez les mises à jour maintenues sur la page de téléchargement d’ImageMagick⁠.

(
  set -o noclobber
  magick photo.jpg -auto-orient -resize '640x640>' -strip -quality 80 webp:- > photo-small.webp
)

La géométrie de redimensionnement⁠ entre guillemets ajuste l’image dans un cadre de 640 × 640 sans agrandissement. Une image de 1280 × 720 devient une image de 640 × 360 ; une image de 320 × 180 conserve ses dimensions. Ce comportement diffère des variantes définies uniquement par leur largeur du script Sharp et ne crée pas l’ensemble complet nécessaire à l’aperçu. Le shell refuse un fichier photo-small.webp existant avant de lancer la conversion. Une conversion échouée peut laisser un nouveau fichier vide ou partiel ; inspectez-le avant de réessayer avec un nouveau nom. La commande ne comporte aucune des protections du script Sharp concernant l’entrée. Utilisez ici uniquement la source sRGB sur 8 bits déjà approuvée ; les fichiers non fiables nécessitent une isolation des processus et des politiques de contrôle des décodeurs et des ressources.

Prévisualiser des images adaptatives prégénérées

Enregistrez cette page complète sous index.html à côté du répertoire généré images/. Enregistrez le bloc de gestion des erreurs situé juste en dessous sous fallback.js, puis ouvrez index.html dans votre navigateur. Ses chemins relatifs fonctionnent directement depuis le répertoire local.

<!doctype html>
<html lang="en">
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Responsive image preview</title>
  <body style="margin: 0">
    <picture>
      <source
        type="image/webp"
        data-srcset="images/photo-320-v1.webp 320w, images/photo-640-v1.webp 640w, images/photo-1280-v1.webp 1280w"
        sizes="(max-width: 640px) 100vw, 640px"
      >
      <img
        id="hero"
        data-src="images/photo-640-v1.jpg"
        data-fallback="images/placeholder.png"
        alt="A description of your photograph"
        width="640"
        height="360"
        style="display: block; width: 100%; max-width: 640px; height: auto"
      >
    </picture>
    <script src="fallback.js"></script>
  </body>
</html>

Définissez width et height avec les dimensions réelles du JPEG de repli affichées par le script. Les valeurs 640 × 360 conviennent à une source 16:9 ; les autres rapports d’aspect nécessitent des hauteurs différentes. Remplacez le texte alternatif par une description de votre image. La valeur sizes correspond à la mise en page de cette page, dont la largeur cesse de croître à 640 pixels CSS. Un navigateur peut choisir parmi les fichiers WebP candidats selon sa fenêtre d’affichage et sa densité de pixels ; le JPEG est utilisé par défaut lorsque WebP n’est pas sélectionné.

Les attributs data-src et data-srcset retardent les requêtes jusqu’à ce que fallback.js installe son gestionnaire. Cet aperçu nécessite JavaScript. Fournissez votre propre fichier PNG réel sous images/placeholder.png, ou utilisez une copie d’un PNG approuvé. Pour tester la récupération après erreur, renommez temporairement le fichier WebP sélectionné et rechargez la page. Rétablissez ensuite son nom. Si l’image de secours est absente, le texte alternatif de l’image devrait rester affiché sans tentatives répétées.

Gestion des erreurs de chargement des images

Enregistrez ceci sous fallback.js à côté de index.html. Le script enregistre le gestionnaire avant d’activer les URL de l’aperçu. La suppression des candidats adaptatifs permet de sélectionner l’image de secours :

function installImageFallback(image, fallbackUrl) {
  image.addEventListener('error', () => {
    for (const source of image.closest('picture')?.querySelectorAll('source') ?? []) {
      source.remove()
    }
    image.removeAttribute('srcset')
    image.removeAttribute('sizes')
    image.src = fallbackUrl
  }, { once: true })
}

const hero = document.getElementById('hero')
if (hero instanceof HTMLImageElement) {
  installImageFallback(hero, hero.dataset.fallback ?? '/images/placeholder.png')
  for (const source of hero.closest('picture')?.querySelectorAll('source') ?? []) {
    if (source.dataset.srcset) source.srcset = source.dataset.srcset
  }
  if (hero.dataset.src) hero.src = hero.dataset.src
}

Le gestionnaire s’exécute une fois par élément image. Si l’image de secours échoue également, le navigateur conserve le texte alternatif accessible et aucune autre affectation de secours n’a lieu. Dans une application existante, attachez le gestionnaire avant de définir les URL des images afin qu’un échec immédiat ne puisse pas survenir avant son enregistrement.

Publier des fichiers versionnés sur votre CDN

Téléversez les fichiers WebP générés et le JPEG de repli depuis images/, ainsi que votre image de secours, vers un préfixe approuvé pour les contenus publics. Conservez les chemins relatifs ou remplacez chaque URL d’image de l’aperçu par son URL CDN. Définissez les types de contenu image/webp, image/jpeg et image/png pour les fichiers correspondants. Ne téléversez pas d’originaux privés sous ce préfixe.

Utilisez des durées de mise en cache longues pour les objets immuables et versionnés. Définissez explicitement les métadonnées de contrôle du cache, puis inspectez les en-têtes de réponse du CDN ; modifier les métadonnées de l’origine ne remplace pas instantanément les réponses en cache.

Vous n’avez pas besoin d’un compte cloud pour cet exemple local. Pour le provisionnement de l’infrastructure, consultez le guide de configuration de S3 et CloudFront EN (English) séparé. Il s’agit d’une lecture complémentaire, pas d’un prérequis pour l’aperçu.

Pour ce déploiement, vérifiez les exigences actuelles d’AWS pour les origines privées⁠. OAC utilise une origine de type bucket S3 classique, et non un point de terminaison de site web. Avec le propriétaire du bucket imposé comme propriétaire de tous les objets, des requêtes OAC systématiquement signées et une politique de bucket limitée à la distribution, CloudFront peut lire une origine privée. Les objets chiffrés avec SSE-KMS nécessitent également une politique de clé KMS appropriée. Le protocole HTTPS pour les visiteurs et l’autorisation des visiteurs sont des paramètres distincts ; OAC authentifie les requêtes vers l’origine, pas les visiteurs d’une URL CDN publique.

Considérations de sécurité lors de l’utilisation de CDN

Les origines privées et la diffusion privée sont des contrôles distincts. Pour réserver l’accès aux visiteurs autorisés, configurez les URL signées CloudFront⁠ et le groupe de clés de confiance associé. Une URL présignée S3 ne signe pas automatiquement une URL CloudFront.

Conservez les clés de signature côté serveur, autorisez l’accès à l’objet demandé avant de délivrer cet accès et évitez de journaliser les chaînes de requête signées. Ne publiez pas de réponses privées avec une politique de cache public partagé.

Résoudre les problèmes courants d’hébergement d’images sur CDN

Invalidation du cache

Préférez un nouveau nom de fichier immuable pour une nouvelle image. Lorsqu’une invalidation est nécessaire, ciblez uniquement la distribution et les chemins prévus. Une invalidation est une véritable opération sur le compte et peut entraîner un coût ; ne l’exécutez pas comme une commande générique de débogage en production.

Surveillance des performances

Utilisez le panneau réseau du navigateur pour inspecter la requête de l’image sélectionnée, la taille de la réponse et les en-têtes de cache. Testez des appareils représentatifs et des caches froids comme chauds. L’aperçu local vérifie la sélection des fichiers et la récupération après erreur ; il ne mesure pas la latence d’un CDN déployé et ne prouve pas une réduction de la bande passante consommée.