Pourquoi vos captures d’écran pèsent 2 Mo, et comment les réduire de 60 à 90 %
Dov Azencot
@DovAzencotJ’ai compté un jour les captures d’écran dans un seul fil d’e-mails de revue de design. Onze, en PNG, à un peu moins de 2 Mo pièce en moyenne. Une vingtaine de mégaoctets de tableaux de bord surtout blancs, faisant des allers-retours entre six personnes qui avaient toutes la même appli ouverte dans un autre onglet. Personne n’y a pensé, parce que « ça marchait ». C’est ça, le piège. Les captures d’écran sont discrètement énormes, et la raison est inscrite dans la façon dont votre ordinateur les prend.
Pourquoi une capture pèse 2 Mo
Quand vous appuyez sur le raccourci de capture, votre système d’exploitation enregistre un PNG. C’est un choix par défaut sensé — le PNG est sans perte, la capture est donc au pixel près, et pour une capture pleine de texte net, c’est réellement le bon réflexe. Le problème, c’est ce que le PNG fait de la taille.
Le PNG stocke chaque pixel à l’identique. Un écran moderne est dense — une capture plein cadre sur un écran Retina ou 4K peut faire plus de 2 000 pixels de large, et le PNG consigne fidèlement chacun de ces millions de pixels en pleine fidélité. Peu lui importe que 60 % de l’image soit la même nuance de presque-blanc. Il ne jette rien, parce que jeter n’est pas ce qu’il fait. Une capture d’une page de réglages presque vide — visuellement quasi rien — pèse donc quand même 1,5 à 2,5 Mo, parce que la toile est immense même quand le contenu est clairsemé.
La solution : passer au WebP
Le WebP sait faire une chose que le PNG ne peut pas — compresser avec perte tout en gardant des bords nets et la transparence. Sur les captures d’écran en particulier, cette combinaison tient presque du prodige, parce qu’une capture, c’est surtout des zones uniformes (peu coûteuses à compresser) avec un peu de texte (que le WebP garde net). La passe avec perte jette le bruit imperceptible ; votre œil ne dépose jamais de plainte.
Chiffres réels tirés de captures présentes sur mon propre disque :
| Capture | En PNG | En WebP |
|---|---|---|
| Une page de réglages, surtout blanche | 1.6 MB | ~180 KB |
| Un tableau de bord d’analytique complet | 2.4 MB | ~310 KB |
| Un éditeur de code en mode sombre | 1.9 MB | ~240 KB |
Soit environ 85 à 90 % en moins, et placées côte à côte, je suis incapable de dire laquelle est laquelle. Le texte reste lisible au pixel près. C’est la conversion au meilleur rendement que je fasse, précisément parce que les captures sont si follement en surpoids au départ — il y a une énorme quantité de rien à essorer.
« Le texte ne va-t-il pas devenir flou ? »
C’est la crainte, et elle est légitime, parce que vous avez sans doute déjà vu une capture JPG au texte flou et cerné, et supposé que tous les formats avec perte font ça. Le WebP gère mieux les bords que le JPG — nettement mieux. À un réglage de qualité raisonnable, le texte d’une capture WebP reste net. J’ai zoomé à 400 % en quête d’artefacts autour des lettres et je suis revenu bredouille sur des captures d’interface normales.
L’exception honnête : si vous poussez la qualité à fond vers le bas pour courir après un tout petit fichier, vous finirez par voir le texte se ramollir. La solution, c’est de ne pas faire ça. Un réglage de qualité intermédiaire vous offre déjà le gain de 60 à 90 % avec le texte intact. Aucune raison de pousser dans la plage où ça casse.
Quand réduire ne sert à rien
Deux cas où je laisse le PNG tranquille.
Si la capture retourne dans un outil de design pour être annotée, commentée ou composée, je la garde sans perte. La passe avec perte du WebP est une porte à sens unique, et je ne veux pas incruster de la compression dans quelque chose que je suis sur le point d’éditer et de réexporter. Livrez le WebP, gardez le PNG maître — la règle habituelle.
Et si une capture est déjà petite — un petit détail recadré, un seul bouton, quelque chose déjà sous les 100 Ko environ — la conversion ne bouge quasiment pas l’aiguille. Le gain de 60 à 90 % vient de fichiers énormes parce que la toile est énorme. Un petit recadrage a déjà réglé ce problème. N’ajoutez pas une étape pour rien.
Comment je m’y prends
Je fais passer mes captures par le convertisseur PNG vers WebP de ce site avant qu’elles n’approchent d’un e-mail ou d’un document. Ça se passe dans votre navigateur, la capture — qui, soyons honnête, montre souvent la moitié de votre écran et tout ce qui traînait en arrière-plan — ne quitte donc jamais votre appareil. Déposez le PNG, regardez la colonne du poids s’effondrer, téléchargez le WebP, joignez celui-là à la place.
Le point le plus important, ce n’est pas l’outil, c’est le réflexe. Une fois que « capture, puis réduction » devient automatique, vous arrêtez d’envoyer des images de 2 Mo à des gens qui ont déjà l’appli ouverte, vos e-mails partent plus vite, et les fils cessent d’enfler jusqu’aux dizaines de mégaoctets. Cet e-mail de onze captures aurait pesé environ 2 Mo au total, au lieu de plus de vingt. Les mêmes images. Tout pareil. Juste sans le poids mort.
Articles liés
Pourquoi je convertis mes PNG en WebP (et la seule fois où je m’abstiens)
Le PNG est génial pour éditer, ruineux pour publier. Voici ce que le WebP fait vraiment gagner, là où il ne sert à rien, et l’unique règle que je ne transgresse jamais.
AVIF ou WebP — le fichier le plus léger n’est pas toujours le bon
L’AVIF bat le plus souvent le WebP sur la taille, parfois de 20 % ou plus. Voici ce que cette compression en plus vous coûte en temps d’encodage et en cas limites, et quand je reste malgré tout sur le WebP.
SVG vers PNG — quand vous avez vraiment besoin de pixels (et quand il ne faut pas)
Un SVG s’agrandit à l’infini et reste minuscule, alors le rastériser ressemble à une régression. Parfois ça l’est. Voici quand vous avez réellement besoin de pixels PNG tirés d’un vectoriel, et quand laisser le SVG tranquille.
Tous les articles