Comment optimiser le chargement des images avec le traitement côté navigateur dans WordPress

Pour optimiser images WordPress, la plupart des utilisateurs pensent d’abord à la compression via un plugin, au lazy loading, au format WebP ou à la réduction du poids des fichiers avant l’import. Ces bonnes pratiques restent importantes, notamment pour améliorer les Core Web Vitals et accélérer l’affichage des pages. ⚡Mais avec WordPress 7.1, une nouvelle étape apparaît dans le cycle de vie des médias : le traitement des images directement dans le navigateur, avant même leur envoi au serveur.🤔

Cette approche, appelée Client-Side Media Processing, change la logique habituelle. Au lieu de demander uniquement au serveur de redimensionner, convertir ou générer les vignettes, WordPress peut déléguer une partie du travail au navigateur de l’utilisateur. Résultat : l’upload devient potentiellement plus léger côté serveur, tout en conservant un traitement natif des images.😉

Objectif

👇L’objectif de ce guide est d’expliquer clairement comment fonctionne le traitement d’image côté navigateur introduit avec WordPress 7.1, sans entrer inutilement dans une complexité réservée aux développeurs. ✨Vous allez comprendre ce que cette fonctionnalité change par rapport au traitement historique côté serveur, dans quels cas elle s’active, quels navigateurs sont concernés et pourquoi elle peut améliorer l’expérience d’upload des médias. Nous verrons aussi comment vérifier si cette nouveauté est active sur votre site, notamment avec la console du navigateur et l’onglet “Réseau des outils de développement”. Enfin, notre article précisera comment cette fonctionnalité s’articule avec des solutions complémentaires comme LWS Optimize, qui restent utiles pour la performance WordPress, la compression avancée, le cache, les formats modernes et l’optimisation globale de l’affichage.💥

Pré-requis

Pour suivre ce tutoriel, vous devez :

• disposer d’un site utilisant WordPress 7.1 ou une version ultérieure, puisque le traitement d’image côté navigateur est lié à cette génération de WordPress.
• Un navigateur récent est également recommandé, en particulier Chrome, Edge ou Brave, afin de profiter du pipeline navigateur complet lorsque l’environnement le permet.
• Aucune compétence avancée en développement n’est indispensable pour comprendre le principe. En revanche, quelques notions de base sur les médias WordPress, les performances web et les outils développeur du navigateur seront utiles pour la partie vérification.

Pour replacer cette nouveauté dans son contexte, vous pouvez aussi consulter notre guide sur les nouveautés de WordPress 7.0, qui présente l’évolution récente du CMS.

Ce qui existait avant : le traitement d’image côté serveur

Avant l’arrivée du Client-Side Media Processing, WordPress suivait un fonctionnement bien connu : lorsqu’un utilisateur envoyait une image dans la médiathèque ou depuis l’éditeur de blocs, le fichier original était transféré vers le serveur. Ensuite, WordPress utilisait les bibliothèques disponibles sur l’hébergement, principalement GD ou Imagick, pour générer différentes tailles d’image.

Ces tailles servent à afficher le bon fichier selon le contexte : miniature dans l’administration, image moyenne dans un article, grande image dans une page, ou encore dimensions personnalisées déclarées par le thème ou par certains plugins. Ce mécanisme permet à WordPress d’éviter d’afficher systématiquement l’image originale, souvent trop lourde pour une page web.

Ce traitement côté serveur a longtemps été la base de l’optimisation image WordPress. Il fonctionne encore aujourd’hui et reste indispensable dans de nombreux cas. Lorsqu’un fichier JPEG, PNG ou WebP est importé, WordPress peut créer plusieurs variantes adaptées à l’affichage. Selon la configuration du site, un plugin d’optimisation peut ensuite compresser ces fichiers, les convertir en WebP ou AVIF, appliquer du lazy loading, ou encore améliorer leur diffusion via le cache.

Cette approche présente toutefois une limite importante : elle dépend fortement de l’environnement serveur. Deux sites WordPress peuvent donc avoir une expérience différente selon :

• leur hébergement,
• leur version de PHP,
• les extensions installées,
• la mémoire disponible,
• les limites CPU ou la configuration des bibliothèques d’image.

Sur un petit site, cela passe souvent inaperçu. Mais sur un site éditorial, une boutique WooCommerce ou une plateforme avec plusieurs contributeurs, l’import massif de médias peut devenir plus coûteux.

Par exemple, lorsqu’un rédacteur envoie une photo haute résolution issue d’un smartphone ou d’un appareil photo, le serveur doit recevoir le fichier original, le lire, le redimensionner, générer les sous-tailles et parfois le convertir. Chaque étape consomme des ressources. Si plusieurs utilisateurs importent des images en même temps, la charge peut augmenter, surtout sur un hébergement mutualisé où les ressources sont partagées.

C’est précisément cette logique que WordPress 7.1 vient faire évoluer. Le traitement côté navigateur ne supprime pas le traitement serveur classique, mais il ajoute une couche en amont. Lorsque les conditions sont réunies, le navigateur peut préparer les images avant l’envoi. Le serveur reçoit alors des fichiers déjà optimisés ou déjà découpés en plusieurs tailles, ce qui peut réduire la charge liée à l’upload.

Cette évolution s’inscrit dans une logique plus large de performance WordPress. Pour améliorer le temps de chargement, il ne suffit pas de compresser une image après coup : il faut agir sur toute la chaîne, depuis l’import du média jusqu’à son affichage final dans le navigateur du visiteur. C’est aussi ce que l’on retrouve dans les bonnes pratiques liées aux Core Web Vitals WordPress, notamment pour optimiser le LCP, l’INP et le CLS.

Le traitement côté serveur reste donc essentiel, mais il n’est plus forcément le seul acteur. Avec WordPress 7.1, l’optimisation commence plus tôt, dès la sélection du fichier par l’utilisateur. Cette nouveauté ouvre la voie à une gestion plus intelligente des médias, en particulier pour les sites qui publient beaucoup d’images ou qui cherchent à réduire la pression sur leur hébergement pendant les uploads.

Qu’est-ce que le Client-Side Media Processing : définition officielle

Le Client-Side Media Processing est une fonctionnalité native introduite avec WordPress 7.1. Son principe est simple à comprendre : au lieu de laisser le serveur effectuer seul tout le travail après l’envoi d’une image, WordPress peut désormais traiter certains médias directement dans le navigateur de l’utilisateur, avant ou pendant l’upload. La fonctionnalité couvre notamment la compression, le redimensionnement, la conversion de format, la rotation et la génération de vignettes dans le navigateur grâce à WebAssembly.

Concrètement, cette nouveauté permet d’optimiser images WordPress plus tôt dans le processus. Lorsqu’un rédacteur ajoute une image depuis l’éditeur de blocs, le navigateur peut prendre en charge une partie des calculs qui étaient auparavant réservés au serveur. Cette approche repose sur des technologies web modernes, dont wasm-vips WordPress, une version WebAssembly de la bibliothèque libvips.

L’intérêt est double. D’une part, le traitement devient moins dépendant des capacités exactes de l’hébergement, comme la mémoire PHP ou les bibliothèques GD et Imagick. D’autre part, le serveur reçoit des fichiers déjà préparés, ce qui peut réduire la charge au moment de l’import. Cette évolution ne remplace pas toute la chaîne d’optimisation image WordPress, mais elle ajoute une étape native en amont du traitement classique.

Ce que la fonctionnalité fait concrètement, dans l’ordre

Le fonctionnement peut être résumé en plusieurs étapes.

La première intervient lorsque l’utilisateur sélectionne une image depuis l’éditeur de blocs. WordPress vérifie alors si le navigateur et l’appareil peuvent gérer le traitement local. Si les conditions sont réunies, le fichier entre dans le nouveau pipeline côté navigateur. Si ce n’est pas le cas, WordPress conserve automatiquement le traitement serveur habituel, sans erreur visible pour l’utilisateur.

Ensuite, le navigateur prépare l’image. Il peut la décoder, lire certaines informations techniques, appliquer une rotation si nécessaire, puis générer les tailles demandées par WordPress. Ces tailles correspondent aux formats utilisés par le thème, l’éditeur ou les plugins :

• miniature,
• taille moyenne,
• grande image,
• image mise à l’échelle,
• ou dimensions personnalisées.

Le traitement est réalisé dans un Web Worker. Cela signifie que le navigateur exécute les calculs dans un fil séparé, afin d’éviter de bloquer complètement l’interface pendant l’opération. Pour l’utilisateur, l’objectif est de conserver une expérience fluide dans l’éditeur, même lorsqu’une image volumineuse doit être traitée.

Une fois les tailles générées, WordPress n’envoie pas seulement un fichier original au serveur. Les fichiers préparés sont transmis via l’API REST, notamment avec un endpoint de sideload pour les sous-tailles d’image. Le serveur les stocke ensuite dans la médiathèque et met à jour les métadonnées de la pièce jointe. La documentation officielle précise que les sous-tailles générées côté navigateur sont envoyées individuellement au serveur via ce mécanisme.

Cette logique change donc le rôle du serveur. Il ne disparaît pas du processus : il reste responsable du stockage, des métadonnées, de la médiathèque et de la compatibilité avec les plugins. Mais il n’a plus forcément à produire lui-même toutes les variantes d’image lorsque le navigateur peut le faire efficacement.

Pour un site avec de nombreux contributeurs, cette différence peut devenir significative. Les imports de médias sollicitent moins directement les ressources serveur, tandis que l’utilisateur profite d’un traitement plus proche de son environnement local. C’est une approche progressive : elle s’active uniquement lorsque le navigateur, la mémoire disponible, les règles de sécurité et la connexion le permettent.

Formats pris en charge par le pipeline navigateur

Le traitement côté navigateur vise à améliorer la prise en charge des formats modernes, un sujet central dès que l’on cherche à optimiser images WordPress. Dans la documentation technique actuelle, le pipeline WASM/vips liste notamment JPEG, PNG, GIF, WebP et AVIF parmi les formats pris en charge pour le traitement côté navigateur.

Le format AVIF WordPress est particulièrement intéressant, car il permet une compression efficace avec une bonne qualité visuelle. WordPress 7.1 améliore aussi la gestion des uploads AVIF, notamment lorsque l’environnement serveur ne dispose pas lui-même d’un support AVIF complet.

Le WebP reste également un format important pour la performance, car il est largement pris en charge par les navigateurs modernes. Il peut s’intégrer dans une stratégie plus globale avec la compression, le lazy loading, le cache et le choix du bon format selon le contexte. Pour approfondir cette approche, consultez notre guide sur l’[optimisation image WordPress avec WebP, AVIF et lazy-load intelligent].

Le cas particulier des fichiers HEIC (photos iPhone)

Les fichiers HEIC méritent une attention particulière, car ils concernent directement de nombreux utilisateurs WordPress. Ce format est couramment utilisé par les iPhone pour enregistrer les photos avec une bonne qualité et un poids réduit. Le problème, c’est que le HEIC repose sur le codec HEVC, dont l’intégration directe dans les navigateurs est plus complexe en raison de contraintes de licences et de brevets.

Pour un utilisateur non technique, cela se traduit par une situation parfois frustrante : une photo prise avec un iPhone peut ne pas être gérée de la même manière selon le navigateur, le système d’exploitation ou la configuration du site. Avant WordPress 7.1, ce type de fichier pouvait nécessiter une conversion manuelle, un plugin, ou un traitement dépendant fortement du serveur.

WordPress 7.1 apporte une réponse plus intelligente avec une stratégie de décodage en cascade. Autrement dit, le navigateur essaie plusieurs méthodes, dans un ordre précis, afin de trouver celle qui fonctionne sur l’appareil utilisé. Cette approche permet d’améliorer la compatibilité sans imposer une méthode unique à tous les navigateurs.

• La première méthode repose sur createImageBitmap(). Elle peut fonctionner sur Safari, notamment lorsque macOS fournit déjà les codecs nécessaires au niveau du système. Dans ce cas, le navigateur peut exploiter les capacités natives de l’ordinateur pour lire l’image HEIC.
• La deuxième méthode utilise les décodeurs disponibles dans le système d’exploitation via un élément HTMLImageElement, puis un OffscreenCanvas. Là encore, WordPress ne fournit pas directement un codec HEIC universel : il s’appuie sur les capacités déjà présentes dans l’environnement de l’utilisateur.
• La troisième méthode est plus technique. Elle consiste à analyser le conteneur HEIC, puis à utiliser WebCodecs avec VideoDecoder lorsque Chromium peut accéder à un codec HEVC fourni par la plateforme. La documentation officielle indique par exemple que Chromium 107+ peut décoder des flux HEVC via les codecs système, comme VideoToolbox sur macOS ou l’extension HEVC Microsoft sur Windows.

Une fois l’image décodée, WordPress peut l’exporter dans un format web plus courant, comme JPEG, tout en conservant l’original HEIC comme fichier compagnon. Cela permet de préserver le fichier source tout en rendant l’image exploitable dans la médiathèque et dans les contenus du site.

C’est aussi pour cette raison qu’il reste utile de tester le comportement réel sur son site. Si plusieurs rédacteurs envoient régulièrement des photos depuis des iPhone, il est conseillé d’essayer plusieurs navigateurs et plusieurs appareils. Cette vérification permet d’éviter les mauvaises surprises, surtout sur un site éditorial, une boutique WooCommerce ou un blog alimenté par plusieurs contributeurs.

Dans une stratégie complète de compression image navigateur WordPress, HEIC doit donc être vu comme un cas particulier. WordPress 7.1 améliore fortement la gestion native de ce format, mais il ne faut pas confondre cette nouveauté avec une garantie absolue sur tous les environnements. Le traitement côté navigateur est une amélioration progressive : lorsqu’il peut fonctionner, il s’active ; lorsqu’il ne le peut pas, WordPress revient vers un chemin plus classique.

Compatibilité navigateur : un point essentiel à clarifier

Le traitement d’image côté navigateur dans WordPress 7.1 repose sur une logique d’amélioration progressive. Cela signifie que la fonctionnalité s’active uniquement lorsque le navigateur, l’appareil et la configuration du site réunissent les bonnes conditions. Si ce n’est pas le cas, WordPress revient automatiquement au traitement côté serveur classique, sans action particulière de la part de l’utilisateur. Cette approche permet de conserver une expérience stable, même lorsque le pipeline navigateur n’est pas disponible.

Dans la pratique, le pipeline complet concerne surtout les navigateurs basés sur Chromium, comme Chrome, Edge ou Brave. La documentation WordPress indique que le traitement côté navigateur dépend de Document-Isolation-Policy, utilisé sur les écrans de l’éditeur de blocs pour activer les conditions de sécurité nécessaires au traitement WebAssembly. Cette prise en charge est liée aux navigateurs Chromium récents.

Il ne faut donc pas présenter cette nouveauté comme une fonctionnalité identique sur tous les navigateurs. Un contributeur qui utilise Chrome pourra bénéficier du pipeline complet, tandis qu’un autre utilisateur sur Firefox ou Safari pourra rester sur le fonctionnement serveur classique. Cela ne veut pas dire que le site est mal configuré : c’est simplement le comportement prévu par WordPress lorsque les conditions techniques ne sont pas remplies.

Cette distinction est importante pour les équipes éditoriales. Sur un site avec plusieurs rédacteurs, journalistes, administrateurs ou gestionnaires de catalogue WooCommerce, les images peuvent être importées depuis des environnements très différents. Certains utilisateurs travailleront depuis un ordinateur récent avec Chrome, d’autres depuis Safari, Firefox ou un appareil moins puissant. Le résultat attendu reste le même : les images doivent s’importer normalement dans la médiathèque. En revanche, la manière dont elles sont traitées peut varier.

C’est pour cette raison qu’il est utile de considérer le Client-Side Media Processing comme une couche supplémentaire d’optimisation image WordPress, et non comme un remplacement total du traitement existant. WordPress continue de s’appuyer sur le serveur lorsque le navigateur ne peut pas prendre le relais.

Cette logique de fallback est rassurante, car elle évite de bloquer l’upload d’une image simplement parce qu’un navigateur ne supporte pas encore toutes les technologies nécessaires.

Pour une stratégie complète de performance WordPress, il reste donc nécessaire d’agir à plusieurs niveaux : traitement au moment de l’upload, compression, formats modernes, cache, lazy loading, poids des pages et qualité de l’hébergement. Le traitement côté navigateur améliore une étape précise du parcours, mais il ne dispense pas d’optimiser l’affichage final des images pour les visiteurs du site.

Pour aller plus loin sur l’impact des images dans les performances perçues, vous pouvez consulter notre guide dédié Comment améliorer ses Core Web Vitals sur WordPress en 2026, notamment pour comprendre le lien entre images, LCP, stabilité visuelle et temps de chargement.

Cas où la fonctionnalité est automatiquement désactivée (retour au traitement serveur classique)

Le traitement côté navigateur n’est pas activé dans toutes les situations. WordPress vérifie plusieurs critères avant de déléguer le traitement des médias au navigateur. Si l’un de ces critères n’est pas respecté, l’upload reste possible, mais il suit le pipeline historique côté serveur avec GD, Imagick ou les bibliothèques disponibles sur l’hébergement.

Ce tableau montre que la désactivation automatique n’est pas forcément un problème. Au contraire, elle protège l’expérience utilisateur. WordPress évite d’imposer un traitement local lorsque le navigateur, la mémoire ou la connexion ne sont pas adaptés. Le système choisit alors le chemin le plus sûr : l’upload serveur traditionnel.

Ce fonctionnement est particulièrement important pour les sites professionnels. Un site vitrine, un blog d’entreprise, un média en ligne ou une boutique WooCommerce ne peut pas dépendre uniquement du navigateur utilisé par chaque contributeur. L’import d’image doit rester fiable, même si tous les rédacteurs n’utilisent pas le même environnement.

C’est aussi là qu’un outil complémentaire comme LWS Optimize conserve tout son intérêt. Le Client-Side Media Processing intervient avant ou pendant l’upload, lorsque les conditions sont favorables. LWS Optimize, lui, agit plus largement sur l’optimisation image WordPress, la compression, le cache et l’affichage des ressources.

Les deux approches peuvent donc se compléter dans une stratégie cohérente pour optimiser images WordPress sans dépendre uniquement du navigateur du contributeur.

En cas de doute, il est recommandé de tester la fonctionnalité sur un environnement de préproduction, surtout si le site utilise une politique de sécurité personnalisée, des plugins de médiathèque avancés, un CDN, un système de watermarking ou un workflow éditorial avec de nombreux utilisateurs. La documentation WordPress précise que les plugins liés aux médias, comme ceux qui ajoutent un filigrane, synchronisent les images avec un CDN ou modifient les métadonnées, doivent être vérifiés afin de bien gérer les deux étapes de traitement.

Vérifier si la fonctionnalité est active sur son site

Après avoir compris le principe, la question la plus pratique est simple : comment savoir si le traitement côté navigateur fonctionne réellement sur son site WordPress ? La réponse dépend du navigateur utilisé, de la version de WordPress, de la configuration de sécurité et des ressources disponibles sur l’appareil.

La première vérification consiste à travailler depuis l’éditeur de blocs, avec un navigateur Chromium récent comme Chrome, Edge ou Brave. Il faut ensuite ouvrir un article ou une page, puis accéder aux outils de développement du navigateur. Cette vérification ne demande pas de modifier le site : elle consiste seulement à observer le comportement de WordPress pendant un upload d’image.

Il est conseillé de réaliser ce test avec une image suffisamment représentative. Une petite image déjà compressée ne permettra pas toujours d’observer clairement le comportement du pipeline. À l’inverse, une photo issue d’un smartphone, un visuel en haute résolution ou une image destinée à une fiche produit WooCommerce permet de mieux voir si WordPress génère et envoie plusieurs tailles.

Pour obtenir un résultat fiable, testez idéalement trois situations :

• un upload depuis Chrome ou Edge sur un ordinateur récent ;
• un upload depuis Safari ou Firefox pour vérifier le fallback serveur ;
• un upload d’une photo HEIC prise avec un iPhone, si ce format fait partie de votre usage courant.

Cette démarche permet de vérifier le fonctionnement réel du site au lieu de se limiter à une lecture théorique de la documentation. Elle est particulièrement utile pour les sites qui publient beaucoup de visuels, comme les blogs, les magazines, les portfolios, les agences, les sites e-commerce ou les catalogues produits.

Dans une logique de compression image navigateur WordPress, cette vérification permet aussi de mieux comprendre à quel moment l’image est optimisée. Si le traitement côté navigateur est actif, une partie du travail se fait avant l’arrivée complète des variantes sur le serveur. Si le traitement côté navigateur est inactif, le serveur continue de gérer les sous-tailles comme auparavant.

Pour compléter cette vérification, il reste pertinent d’utiliser un outil d’optimisation global afin d’améliorer l’affichage final des images auprès des visiteurs. Vous pouvez notamment consulter notre article sur l’optimisation image WordPress avec WebP, AVIF et lazy-load intelligent], qui aborde les formats modernes, le chargement différé et les bonnes pratiques côté front-end.

Méthode 1 : Console navigateur

La méthode la plus directe consiste à vérifier la variable JavaScript exposée par WordPress lorsque le Client-Side Media Processing est actif. Depuis l’éditeur de blocs, ouvrez les outils de développement du navigateur. Sur Chrome, Edge ou Brave, vous pouvez généralement utiliser la touche F12, ou le raccourci Ctrl + Maj + I sur Windows et Linux. Sur macOS, utilisez plutôt Cmd + Option + I.

Dans l’onglet “Console”, saisissez ensuite la commande suivante :

window.__clientSideMediaProcessing

Si la console retourne true, cela signifie que WordPress a activé le traitement côté navigateur pour cette session. La fonction WordPress associée ajoute précisément cette variable dans l’éditeur lorsque la fonctionnalité est disponible.

Si la console retourne undefined, false ou ne retourne rien d’exploitable, cela ne veut pas forcément dire que votre site rencontre une erreur. Le navigateur peut simplement ne pas remplir les conditions requises. Cela peut aussi venir d’un appareil avec trop peu de mémoire, d’une connexion lente, d’une politique de sécurité restrictive ou d’un navigateur non compatible avec le pipeline complet.

Voici une interprétation simple des résultats possibles :

Cette méthode est rapide, mais elle ne suffit pas toujours à confirmer tout le cycle d’upload. Elle indique que la fonctionnalité est active côté interface, mais ne montre pas encore comment les fichiers sont envoyés au serveur. Pour cela, il faut compléter le test avec l’onglet « Réseau », qui permet d’observer les requêtes générées pendant l’import d’une image.

Méthode 2 : Onglet “Réseau”

La deuxième méthode consiste à observer les requêtes envoyées par WordPress pendant l’upload d’une image. Elle est un peu plus technique que la vérification dans la console, mais elle permet de confirmer concrètement le comportement du pipeline. L’objectif est de voir si WordPress envoie uniquement un fichier classique au serveur, ou s’il transmet aussi des sous-tailles générées côté navigateur.

Depuis l’éditeur de blocs, ouvrez les outils de développement de votre navigateur, puis cliquez sur l’onglet “Réseau” ou “Network”. Cochez éventuellement l’option permettant de conserver les requêtes pendant la navigation, puis importez une image depuis un bloc Image ou depuis la médiathèque.

Lorsque le traitement d’image côté navigateur est actif, vous devez observer plusieurs requêtes liées à l’upload du média. WordPress commence par créer le média principal, puis envoie les fichiers générés localement via un endpoint REST API de sideload, sous la forme POST /wp/v2/media/{id}/sideload. La documentation WordPress précise que les sous-tailles générées côté navigateur sont envoyées individuellement via ce nouvel endpoint, puis finalisées ensuite côté serveur.

Dans l’onglet Réseau, vous pouvez donc rechercher des requêtes contenant le terme sideload. Leur présence indique que WordPress ne suit pas uniquement le chemin serveur classique. Le navigateur a bien participé au traitement du média avant l’envoi des variantes au site.

À l’inverse, si vous observez seulement une requête classique vers POST /wp/v2/media, sans requêtes de sideload visibles, cela peut indiquer que le traitement côté navigateur n’est pas actif dans cette session. Là encore, ce n’est pas forcément une erreur. Le navigateur, la mémoire disponible, la connexion ou la politique de sécurité du site peuvent expliquer le retour au traitement serveur.

Cette vérification complète bien la méthode de la console. La console permet de savoir si la fonctionnalité est déclarée comme active. L’onglet « Réseau » permet, lui, de voir comment WordPress communique réellement avec le serveur pendant l’upload. Ensemble, ces deux méthodes donnent une vision fiable du fonctionnement du client-side media processing WordPress sur votre environnement.

Ce que ça change concrètement pour un site hébergé chez LWS

Pour un site hébergé chez LWS, cette nouveauté doit être comprise comme une évolution de la chaîne de traitement des médias WordPress. Elle ne transforme pas à elle seule la vitesse d’affichage d’un site, mais elle peut améliorer une étape souvent négligée : l’import des images dans l’administration.

Jusqu’ici, une grande partie du travail se faisait après l’envoi du fichier au serveur. Avec WordPress 7.1, lorsque le navigateur est compatible, certaines opérations peuvent être réalisées localement avant que les variantes d’image ne soient transmises au site. WordPress indique que le navigateur peut gérer la compression, le redimensionnement, la conversion de format, la rotation et la génération des miniatures via WebAssembly.

Pour les administrateurs de sites, cela peut rendre les uploads plus efficaces, en particulier lorsque les images sont lourdes ou nombreuses. C’est un cas fréquent pour les blogs, sites vitrines, portfolios, médias en ligne, sites institutionnels et boutiques WooCommerce. Plus un site publie d’images, plus la gestion des médias devient un sujet important.

Cette fonctionnalité s’inscrit donc dans une démarche plus large pour optimiser images WordPress. Elle agit au moment de l’import, tandis que d’autres optimisations interviennent ensuite sur l’affichage :

• cache,
• lazy loading,
• WebP,
• AVIF,
• poids des pages,
• CDN,
• thème utilisé et qualité du code front-end.

Pour approfondir la partie affichage et expérience utilisateur, vous pouvez consulter notre guide sur les Core Web Vitals WordPress, qui explique comment améliorer le LCP, l’INP et le CLS sur un site WordPress.

Besoin d’un hébergement WordPress rapide et de qualité ?

Profitez de l'offre exclusive de LWS : hébergement WordPress en France à -42% ! Démarrez dès maintenant à partir de 3,49€/mois au lieu de 5,99€. Performance 🚀 et support exceptionnel garantis ! 😊

Découvrir l’offre

Réduction de la charge serveur pendant les uploads

Le principal intérêt du traitement côté navigateur est de déplacer une partie du travail depuis le serveur vers l’appareil de l’utilisateur. Sur un hébergement WordPress, cela peut avoir un impact intéressant, car la génération des tailles d’image est une opération qui consomme des ressources. Redimensionner une grande photo, créer plusieurs variantes et appliquer une compression demande de la mémoire et du temps de calcul.

Sur un hébergement mutualisé, ces ressources sont partagées entre plusieurs sites. Cela ne pose généralement pas de problème pour un usage classique, mais les imports volumineux peuvent devenir plus sensibles. C’est notamment le cas lorsqu’un site publie beaucoup de contenus, lorsqu’une équipe importe plusieurs images à la fois ou lorsqu’une boutique WooCommerce ajoute régulièrement de nouvelles fiches produits avec des visuels haute résolution.

Avec le traitement d’image côté navigateur, WordPress peut générer certaines sous-tailles avant leur arrivée complète côté serveur. Le serveur reçoit alors des fichiers déjà préparés, puis les enregistre dans la médiathèque et met à jour les métadonnées. Le fonctionnement exact conserve le cycle WordPress habituel, car les chemins client et serveur convergent vers wp_generate_attachment_metadata, ce qui permet de préserver la compatibilité avec de nombreux plugins.

Le gain ne doit pas être interprété comme une accélération automatique de toutes les pages du site. Il concerne surtout le moment de l’upload et la charge associée au traitement initial des images. Pour améliorer le chargement côté visiteur, il faut continuer à travailler sur la compression finale, le cache, le lazy loading, le choix du bon format et l’optimisation du thème.

C’est justement cette combinaison qui permet d’optimiser images WordPress efficacement : réduire la charge au moment de l’import, puis servir des images légères et adaptées au navigateur du visiteur.

Complémentarité avec LWS Optimize

Le Client-Side Media Processing ne remplace pas un outil d’optimisation comme LWS Optimize. Les deux interviennent à des moments différents. WordPress 7.1 agit principalement pendant l’upload, lorsque le navigateur du contributeur peut prendre en charge le traitement local. LWS Optimize intervient plus largement sur la performance du site, notamment après l’import et lors de l’affichage des pages aux visiteurs.

Cette nuance est essentielle. Le traitement côté navigateur dépend de plusieurs conditions : navigateur compatible, appareil suffisamment puissant, connexion adaptée et règles de sécurité permettant l’exécution du Web Worker. WordPress prévoit un fallback automatique vers le traitement serveur lorsque ces conditions ne sont pas réunies.

À l’inverse, une solution d’optimisation WordPress reste utile même lorsque le contributeur utilise un navigateur non compatible. Elle peut continuer à optimiser les ressources du site, à améliorer le cache, à réduire le poids des fichiers et à accompagner une stratégie globale de performance WordPress. C’est particulièrement important pour un site professionnel, car les visiteurs ne voient pas le processus d’upload : ils voient surtout la rapidité d’affichage des pages.

LWS Optimize peut donc être présenté comme une couche complémentaire. WordPress 7.1 améliore le traitement initial des médias lorsque l’environnement le permet. LWS Optimize aide ensuite à renforcer l’optimisation image WordPress, la mise en cache et les performances front-end, indépendamment du navigateur utilisé par la personne qui ajoute les images.

Pour aller plus loin, vous pouvez consulter notre guide consacré à l’optimisation image WordPress avec WebP, AVIF et lazy-load intelligent, afin de compléter le traitement natif de WordPress par une approche orientée affichage et vitesse de chargement.

Limites et points de vigilance à connaître

Même si le Client-Side Media Processing représente une avancée importante pour optimiser images WordPress, il faut garder en tête qu’il s’agit d’une fonctionnalité récente.

Elle repose sur plusieurs conditions techniques : navigateur compatible, appareil suffisamment puissant, connexion adaptée et règles de sécurité compatibles avec l’exécution d’un Web Worker. WordPress active cette fonctionnalité de manière progressive dans l’éditeur de blocs, notamment grâce à Document-Isolation-Policy, afin de permettre l’isolation nécessaire au traitement côté navigateur.

• La première limite concerne donc la compatibilité. Deux contributeurs peuvent travailler sur le même site WordPress et ne pas bénéficier du même comportement. Un utilisateur sur Chrome ou Edge peut voir le pipeline navigateur s’activer, tandis qu’un autre sur Firefox, Safari ou un appareil moins puissant peut rester sur le traitement serveur classique. Cela ne signifie pas que le site dysfonctionne : WordPress prévoit justement un retour automatique vers le traitement traditionnel lorsque les conditions ne sont pas réunies.
• La deuxième limite concerne les plugins liés aux médias. Certains plugins ajoutent un filigrane, synchronisent les images vers un CDN, modifient les métadonnées, changent les formats de sortie ou appliquent un traitement personnalisé après upload. Avec le traitement côté navigateur, WordPress conserve des points d’intégration côté serveur, notamment lors de la finalisation du média, mais il est recommandé de vérifier que les extensions utilisées réagissent correctement à ce nouveau flux. Le processus peut déclencher wp_generate_attachment_metadata lors de la création initiale puis après la finalisation des sous-tailles générées côté navigateur.
• La troisième limite concerne les tests en production. Avant de généraliser ce fonctionnement sur un site important, mieux vaut réaliser quelques essais sur un environnement de préproduction. Testez plusieurs formats d’image, plusieurs navigateurs, une photo HEIC issue d’un iPhone, une image lourde et un upload avec plusieurs fichiers. Cette démarche permet de vérifier que votre thème, vos plugins d’optimisation image WordPress et votre configuration d’hébergement réagissent correctement.

Enfin, cette nouveauté ne remplace pas les bonnes pratiques classiques. Pour améliorer la performance WordPress, il faut toujours surveiller le poids des images, les dimensions réelles affichées, le cache, le lazy loading, les formats WebP ou AVIF et l’impact des visuels sur le LCP.

Le traitement d’image côté navigateur agit surtout au moment de l’import. L’optimisation de l’affichage reste indispensable pour offrir une navigation rapide aux visiteurs.

Vérification du bon fonctionnement

Pour vérifier que le traitement côté navigateur fonctionne correctement, commencez par tester votre site depuis un navigateur Chromium récent, comme Chrome, Edge ou Brave. Ouvrez ensuite l’éditeur de blocs, importez une image représentative, puis contrôlez la variable JavaScript indiquant si la fonctionnalité est active. Si window.__clientSideMediaProcessing retourne true, le traitement côté navigateur est disponible pour cette session.

Complétez ensuite ce test avec l’onglet « Réseau des outils développeur ». Pendant l’upload, recherchez les requêtes liées au sideload. Le pipeline WordPress peut envoyer les sous-tailles générées localement via l’endpoint POST /wp/v2/media/{id}/sideload, avant une étape de finalisation du média.

Voici une checklist simple à suivre :

• window.__clientSideMediaProcessing retourne true dans la console ;
• l’onglet “Réseau” affiche des requêtes de type sideload ;
• une image classique s’importe correctement dans la médiathèque ;
• une photo HEIC prise avec un iPhone est acceptée et convertie si l’environnement le permet ;
• le site continue d’accepter les uploads depuis Firefox ou Safari grâce au fallback serveur ;
• les plugins d’optimisation image WordPress continuent de fonctionner après l’import.

Cette vérification permet de distinguer deux choses : l’activation du pipeline navigateur et la qualité de l’optimisation finale. Même si WordPress 7.1 traite mieux les médias au moment de l’upload, il reste utile de tester l’affichage réel des pages avec PageSpeed Insights ou Lighthouse, notamment pour mesurer le LCP et identifier les images encore trop lourdes. Pour approfondir ce sujet, consultez notre guide sur les Core Web Vitals WordPress.

FAQ

Qu’est-ce que le traitement d’image côté navigateur dans WordPress 7.1 ?

Le traitement d’image côté navigateur permet à WordPress 7.1 de préparer certaines images directement dans le navigateur avant l’envoi complet au serveur.
Il peut gérer le redimensionnement, la compression, la rotation, la conversion de format et la génération de miniatures.

Le traitement côté navigateur remplace-t-il les plugins d’optimisation d’image comme LWS Optimize ?

Non. Cette fonctionnalité agit surtout au moment de l’upload des images dans WordPress.
Un plugin comme LWS Optimize reste utile pour la compression, le cache, les formats modernes et la performance WordPress côté visiteur.

Cette fonctionnalité fonctionne-t-elle sur tous les navigateurs ?

Non. Le pipeline complet dépend du navigateur, de l’appareil, de la connexion et des règles de sécurité du site.
Si les conditions ne sont pas réunies, WordPress revient automatiquement au traitement côté serveur classique.

Comment vérifier si le traitement côté navigateur est actif sur mon site ?

Ouvrez la console du navigateur depuis l’éditeur de blocs, puis saisissez window.__clientSideMediaProcessing.
Si le résultat est true, la fonctionnalité est active pour cette session.

Les photos HEIC d’iPhone sont-elles prises en charge ?

Oui, WordPress 7.1 améliore la prise en charge des photos HEIC issues des iPhone.
Le comportement peut toutefois varier selon le navigateur, le système d’exploitation et les codecs disponibles.

Conclusion

Le Client-Side Media Processing marque une évolution importante pour optimiser images WordPress. Avec WordPress 7.1, une partie du traitement peut désormais être réalisée dans le navigateur : redimensionnement, compression, conversion, rotation et génération de miniatures, lorsque l’environnement est compatible. Cette nouveauté réduit potentiellement la charge serveur pendant les uploads, tout en conservant un fallback classique si nécessaire.✨ Il faut toutefois la voir comme une amélioration progressive, et non comme une solution unique. Pour obtenir un site rapide, il reste essentiel de travailler l’ensemble de la chaîne : formats modernes, cache, lazy loading, poids des pages et hébergement adapté. ⚡Avec un hébergement WordPress LWS compatible avec les versions récentes de WordPress et LWS Optimize, vous disposez d’une base solide pour améliorer durablement les performances de votre site.

Besoin d’un hébergement WordPress rapide et de qualité ?

Profitez de l'offre exclusive de LWS : hébergement WordPress en France à -42% ! Démarrez dès maintenant à partir de 3,49€/mois au lieu de 5,99€. Performance 🚀 et support exceptionnel garantis ! 😊

Découvrir l’offre

Vous utilisez déjà WordPress 7.1 ou vous avez testé le traitement des images côté navigateur ? Partagez votre expérience en commentaire pour aider d’autres utilisateurs à mieux comprendre cette nouveauté.