Énaurme modif sur mon #plugin #SPIP « Image responsive » (oui, je suis content) :
►http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive
Ça concerne le chargement des images sur écran haute définition (Retina chez Apple, mais je teste actuellement avec un Nexus 7).
Sur un écran « normal », en admettant qu’on affiche l’image sur 512 pixels de large, le plugin va charger l’image « xxx-resp512.jpg » :
elle pèse 22ko.
Si on a un écran haute définition (densité 2), le javascript précédent chargeait la même image, mais en 1024 pixels de large « xxx-resp1024.jpg » (512x2) :
et là, gros souci : elle pèse 169ko.
J’ai déjà évoqué ces deux buts contradictoires des images reponsives :
– ne plus charger les grandes images quand on est sur petit écran, parce que ça ne sert à rien (généralement, sur smartphone avec connexion lente),
– mais aussi, pouvoir charger les images en haut définition sur écran haute définition. Malheureusement, le plus grand nombre d’écrans haute déf pour le moment, ce sont les smartphones.
Donc sur smartphone, on a connexion (plutôt) lente et écran haute définition, du coup on charge des images plus grosses là où on pensait en charger des plus légères.
La solution : si écran haute définition, alors je charger bien une image de 1024 pixels, mais en compressant le JPEG de manière beaucoup plus importante « xxx-resp512-2.jpg » :
L’image pèse… 34ko. Ouéééé !
Par défaut, les images JPEG traitées par SPIP sont sauvegardées avec un taux de compression de 85%, de façon à avoir de belles vignettes. Avec un taux de 50%, on gagne donc énormément en poids de fichier. Mais évidemment, on détruit largement la qualité de l’image. Sauf qu’ici, on affiche l’image sur un écran haute définition : l’œil est à ce niveau de définition incapable de percevoir la différence.
Note : la compression à 50% n’est appliquée que si l’image d’origine est suffisamment grande par rapport à la taille cible. Avec le plugin, il n’est pas rare qu’on n’affiche finalement pas une image beaucoup plus grande que ce qu’on ciblait à l’origine (si mon image d’origine fait 800 pixels de large, que je l’affiche sur 600 pixels de large sur un écran Retina, je ne pourrai évidemment pas expédier d’image de 1200 pixels sur-compressée… donc dans ce cas je ne sur-compresse pas pour éviter que la dégradation ne devienne perceptible).
Alors, ça ressemble à la logique des « compressive images » :
▻http://filamentgroup.com/lab/rwd_img_compression
l’article prétend qu’une image sauvegardée à un taux JPEG de 10%, affichée deux fois plus petite, est perçue comme de même qualité qu’une image sauvegardée à un taux normal. C’est peut-être vrai quand on affiche cette image sur un écran « normal » (l’image est à nouveau lissée par le fait qu’on affiche 4 pixels de l’image d’origine en un seul à l’écran) ; mais sur écran haute définition, c’est très perceptible, et on perd à mon avis carrément l’intérêt de balancer une image haute définition sur un écran retina.
Bon, c’est en fonctionnement sur OrientXXI :
►http://orientxxi.info
Sur écran « normal », il n’y a logiquement aucune différence. En revanche, sur écran haute définition, on charge des images visiblement beaucoup plus « nettes », « définies » (« sharp »), parce qu’avec quatre fois plus de pixels, mais quasiment de même poids (environ un tiers de plus, alors que dans la version précédente, l’écran Retina provoquait le chargement d’images 7 fois plus lourdes…).
Je trouve que ça commence à devenir sympa.
(Pour ceux qui avaient déjà installé/testé le plugin, penser à remodifier le fichier .htaccess, la redirection a été modifiée.)
