Faut-il vraiment utiliser la balise picture pour servir vos images WebP ?

Pourquoi Google insiste sur le tag picture plutôt qu'une autre méthode ?

La balise permet de déclarer plusieurs sources d'images avec des types MIME différents. Le navigateur évalue chaque dans l'ordre et charge la première qu'il comprend. Si WebP n'est pas supporté, il passe au fallback JPEG ou PNG sans intervention côté serveur.

Cette approche côté client évite de compter sur la détection user-agent ou sur une négociation de contenu HTTP complexe. Elle simplifie la maintenance et garantit un comportement prévisible partout. Google privilégie cette simplicité car elle réduit les risques d'erreur de configuration qui nuiraient aux Core Web Vitals.

Quels navigateurs ne supportent pas WebP et pourquoi ça compte encore ?

Safari sur iOS antérieur à iOS 14 et Internet Explorer n'interprètent pas WebP. Même si la part de marché de ces clients diminue, elle reste non négligeable sur certains publics (entreprises verrouillées sur IE, iPhone anciens). Sans fallback, ces utilisateurs voient une image cassée, ce qui dégrade l'expérience et peut augmenter le taux de rebond.

Pour un site e-commerce ou un média, servir une image cassée à 5-10 % du trafic n'est pas acceptable. Le fallback JPEG assure que 100 % des visiteurs voient le contenu, tandis que la majorité bénéficie du poids réduit de WebP. C'est un compromis pragmatique qui préserve la performance sans sacrifier la compatibilité.

Quelle est la syntaxe exacte recommandée par Google ?

Google conseille de structurer l'élément picture avec un en premier, suivi d'un classique pointant vers le JPEG ou PNG. Le navigateur teste les types MIME déclarés et saute ceux qu'il ne comprend pas. L'attribut srcset peut également gérer les variantes responsive dans chaque source.

Cette syntaxe évite le double chargement : un seul fichier est téléchargé par le client. C'est capital pour les Core Web Vitals, notamment LCP, puisque l'image hero est souvent le plus gros asset de la page. Servir un WebP de 80 Ko au lieu d'un JPEG de 250 Ko fait mécaniquement gagner du temps au LCP.

• Compatibilité garantie : le fallback JPEG évite les images cassées sur anciens navigateurs.
• Performance optimale : WebP réduit le poids de 25-35 % en moyenne, accélérant LCP.
• Simplicité de mise en œuvre : pas de détection user-agent ni logique serveur complexe.
• SEO-friendly : Googlebot lit WebP nativement, donc pas de perte d'indexation image.
• Responsive natif : srcset fonctionne dans chaque source pour gérer les densités d'écran.

Cette recommandation est-elle cohérente avec les pratiques terrain observées ?

Oui, sur des centaines d'audits techniques, l'élément picture domine clairement sur les sites performants. Les approches alternatives (détection user-agent côté serveur, Content-Negotiation Accept: image/webp) existent mais posent des problèmes de cache CDN et de maintenance. Cloudflare, Fastly et autres CDN gèrent mal la négociation de contenu si le Vary: Accept n'est pas configuré correctement, ce qui provoque des servir JPEG aux clients WebP ou inversement.

La balise picture élimine cette classe de bugs. Le navigateur décide, point. Les frameworks modernes (Next.js, Nuxt, Gatsby) génèrent d'ailleurs automatiquement des éléments picture avec srcset et WebP + fallback. C'est devenu la norme de facto, Google ne fait que formaliser ce consensus de l'industrie.

Quelles nuances faut-il apporter à cette déclaration ?

Google ne précise pas si le fallback doit être du JPEG ou du PNG. Pour des photos, JPEG reste optimal ; pour des logos ou icônes avec transparence, PNG s'impose. La recommandation est générique, mais le choix du format fallback dépend du type d'image. [A vérifier] : Google n'a jamais publié de data quantifiant l'impact LCP d'un WebP mal fallbacké versus un JPEG bien compressé.

Autre nuance : si votre CDN supporte AVIF (format encore plus performant que WebP), vous pouvez empiler trois sources : AVIF, WebP, JPEG. Mais attention, AVIF n'est supporté que par Chrome/Edge récent et Firefox. Le HTML devient alors : , , . Google ne mentionne pas AVIF ici, mais c'est cohérent avec la logique picture : le navigateur descend dans la cascade jusqu'à trouver un type qu'il comprend.

Dans quels cas cette règle ne s'applique-t-elle pas ou pose-t-elle problème ?

Sur un site avec des milliers d'images legacy déjà en ligne, réécrire tout le HTML pour insérer des balises picture est un chantier lourd. Les CMS anciens (WordPress sans plugin dédié, Drupal 7, Magento 1) ne génèrent pas automatiquement cette syntaxe. Il faut alors passer par un plugin ou réécrire les templates, ce qui peut casser des layouts existants si le CSS compte sur un simple .

Autre cas limite : les AMP pages. AMP impose qui ne supporte pas nativement picture. Il faut utiliser l'attribut fallback d'AMP, syntaxe différente. Google aurait pu préciser cette exception, mais la doc officielle reste généraliste. Enfin, sur des sites à très fort trafic avec CDN agressif, certains préfèrent la négociation de contenu pour éviter de dupliquer les URLs (une pour WebP, une pour JPEG dans le srcset). C'est un débat d'architecture, pas tranché par cette déclaration.

Que faut-il faire concrètement sur son site pour respecter cette recommandation ?

Première étape : auditer l'existant. Crawler le site avec Screaming Frog ou Sitebulb et extraire toutes les balises . Identifier celles qui servent déjà du WebP (attribut src ou srcset) et celles encore en JPEG/PNG pur. Prioriser les images above-the-fold et les hero images, car elles impactent directement le LCP.

Ensuite, générer les versions WebP de chaque image prioritaire. Des outils comme cwebp (CLI Google), Squoosh, ou ImageMagick permettent la conversion en batch. Viser un niveau de qualité équivalent au JPEG d'origine (généralement qualité 80-85 pour WebP). Stocker les deux formats (WebP + JPEG) dans le même répertoire ou sur le CDN, avec des noms cohérents (ex: hero.webp et hero.jpg).

Quelles erreurs éviter lors de l'implémentation de picture ?

Erreur classique : oublier l'attribut type dans la balise source. Sans type="image/webp", le navigateur ne sait pas qu'il s'agit de WebP et peut tenter de charger le fichier même s'il ne le supporte pas, provoquant un échec silencieux. Toujours déclarer explicitement le MIME type.

Autre piège : placer le fallback JPEG après la balise img au lieu d'utiliser img comme fallback final. La syntaxe correcte est : picture > source WebP > img JPEG. L'img sert de fallback et porte les attributs alt, width, height essentiels pour l'accessibilité et le CLS. Ne jamais dupliquer ces attributs sur les sources, uniquement sur l'img.

Comment vérifier que le fallback fonctionne réellement ?

Tester avec BrowserStack ou un vrai device iOS 13 et IE11. Les DevTools Chrome permettent de désactiver WebP via le panneau Network > Disable cache + override user-agent, mais ce n'est pas fiable à 100 %. Un test en conditions réelles évitera les mauvaises surprises post-déploiement.

Vérifier également que le CDN ne cache pas la mauvaise variante. Si le Vary: Accept n'est pas configuré côté serveur et que le CDN sert un cache unifié, un utilisateur IE peut recevoir du WebP en cache, ce qui casse l'affichage. Avec picture, ce problème disparaît puisque le HTML déclare les deux URLs explicitement, mais reste vigilant si tu mixes picture et négociation de contenu.

• Générer les versions WebP de toutes les images stratégiques (hero, produits, bannières).
• Réécrire les balises critiques en .
• Conserver les attributs alt, width, height sur la balise finale pour éviter CLS et problèmes d'accessibilité.
• Tester le fallback sur Safari iOS 13 et IE11 (BrowserStack ou devices réels).
• Vérifier que le CDN ne met pas en cache la mauvaise variante (Vary: Accept si négociation serveur).
• Monitorer LCP avant/après migration WebP via PageSpeed Insights et CrUX pour quantifier le gain réel.