shadcn.io— des milliers de blocs shadcn/ui
Aller au contenu

Pourquoi vos captures d’écran pèsent 2 Mo, et comment les réduire de 60 à 90 %

J’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 :

CaptureEn PNGEn WebP
Une page de réglages, surtout blanche1.6 MB~180 KB
Un tableau de bord d’analytique complet2.4 MB~310 KB
Un éditeur de code en mode sombre1.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


Tous les articles