Coût du redimensionnement d'image côté client

[Thomas Bassetto]

Bonsoir,

Je travaille sur des pages qui ont en moyenne 1000 images (album
covers, beaucoup d'avatars, etc.)... Je ne parle pas de balises img,
ce sont des divs avec les images en background-image +
background-size.

Comme on peut s'y attendre, le chargement des pages est un peu
saccadé. En plus d'optimiser le nombre et le poids des images, la
prochaine étape sera la mise en place d'un système de lazy loading.

Cependant, je me pose la question du redimensionnement. La grosse
majorité des images fait 256x256 pixels mais elles ne sont affichées
qu'en 58*58px ou 138*138px. Savez-vous comment mesurer le coût du
redimensonnement ? Faut-il s'en soucier ?

--
Thomas

[Eric Daspet]

Hello

256x256 sur 1000 images, personnellement je penserai plus au coût en
terme de mémoire sur les mobiles qu'en terme de processeur.
Normalement le redimensionnement de petites images est assez rapide
(mais j'avoue ne pas avoir eu besoin de tester sur de tels volumes).
J'aurai tendance à penser que si tu fais du lazy loading bien foutu
avec téléchargement en fonction du scroll et que tu trouves une astuce
pour ceux qui scrollent d'un coup tout en bas, le processeur ne sera
pas forcément un blockeur.

Par contre que ton navigateur doivent mapper 256000 pixels sur 256000,
là ça m'inquiète plus. Si tu peux réduire à 58000 sur 58000, c'est
clair que ça va se sentir. Dès que tu vas afficher une centaine de tes
images, ça va commencer à faire mal, même si tu les charges
progressivement.


Si j'osais faire une usine à gaz et que ta page est longue avec
relativement peu d'affichage à la fois, j'aurai tendance à mettre des
cadres gris par défaut (background-color, par d'image par défaut), de
faire un lazy-load qui chargent les images dès qu'on doit les
afficher, mais aussi qui entretient une file de références (par
exemple une centaine) et qui retire de la page les images en bas de
file quand tu en ajoutes en haut de file.

-- Eric

[Julien Wajsberg]

si ça peut ajouter à ce que dit Eric, le chargement d'une page de résultats Google Images sur un PC vieux de 10 ans (256mo de RAM) faisait bien souffrir le dit PC en terme de mémoire.

2013/3/12 Eric Daspet <eric....@survol.fr>

--
--
Liste de diffusion sur les performances web : http://groups.google.com/group/performance-web
Plus d'informations : http://performance.survol.fr/
Se déinsinscrire : performance-w...@googlegroups.com
---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes performance-web.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse performance-w...@googlegroups.com.
Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .

[Mickael Morier]

Plus que le resize, c'est la taille mémoire qui coutera cher.

Je trouve intéressante la technique proposée par Éric.
En Android natif, on réutilise souvent les widgets instanciées pour éviter d'augmenter la mémoire utilisée ainsi que le CPU.

Par contre, il y a un élément qui me manque pour que ce soit vraiment intéressant.
Si le navigateur a déjà rendu l'image, il l'a dans sa mémoire allouée pour cette page. Si tu scroll et que l'image n'est plus affichée à l'écran, le navigateur fait-il est un nettoyage ? Comment le forcer à oublier cette image ?

Mickaël

2013/3/12 Julien Wajsberg <fel...@gmail.com>

[Nicolas Hoizey]

Hello,

Pour compléter il me semble les autres réponses…

Le 11 mars 2013 à 18:09, Thomas Bassetto <tbas...@gmail.com> a écrit :
> Je travaille sur des pages qui ont en moyenne 1000 images (album
> covers, beaucoup d'avatars, etc.)... Je ne parle pas de balises img,
> ce sont des divs avec les images en background-image +
> background-size.
>
> Comme on peut s'y attendre, le chargement des pages est un peu
> saccadé. En plus d'optimiser le nombre et le poids des images, la
> prochaine étape sera la mise en place d'un système de lazy loading.

Peux-tu aussi charger la page par fragments, avec un système de type "scroll infini" ? Ton HTML doit déjà être pas mal lourd…

> Cependant, je me pose la question du redimensionnement. La grosse
> majorité des images fait 256x256 pixels mais elles ne sont affichées
> qu'en 58*58px ou 138*138px. Savez-vous comment mesurer le coût du
> redimensonnement ? Faut-il s'en soucier ?

Au delà du coup évident du redimensionnement, que tu peux éviter puisque tu n'utilises visiblement jamais les images à leur taille native, es-tu sûr que ce soit visuellement satisfaisant sur tous les terminaux ?

Si tu affiches soit en 58x58 soit en 138x138, sans valeurs intermédiaires, ne peux-tu pas avoir les deux tailles sur le serveur et appeler la bonne quand tu en as besoin ?


-Nicolas

--
Nicolas Hoizey

Mon blog : http://gasteroprod.com/
Mon jeu : http://esviji.com/

[Cédric Morin]

Le 12 mars 2013 à 12:20, Eric Daspet <eric....@survol.fr> a écrit :

> Hello
>
> 256x256 sur 1000 images, personnellement je penserai plus au coût en
> terme de mémoire sur les mobiles qu'en terme de processeur.

Si on parle de mobile et de connexion itinérante, j'ai peur que ce qui soit vraiment dimensionnant c'est la latence de la connexion pour récupérer les 1000 images.
Il suffit de naviguer un peu en mobilité pour voir que récupérer une page avec quelques images est souvent rédhibitoire dans la vraie vie....
Le lazy-loading s'impose très certainement pour que ce soit acceptable aussi du point de vue du temps de chargement de la page.

> Normalement le redimensionnement de petites images est assez rapide
> (mais j'avoue ne pas avoir eu besoin de tester sur de tels volumes).
> J'aurai tendance à penser que si tu fais du lazy loading bien foutu
> avec téléchargement en fonction du scroll et que tu trouves une astuce
> pour ceux qui scrollent d'un coup tout en bas, le processeur ne sera
> pas forcément un blockeur.
>
> Par contre que ton navigateur doivent mapper 256000 pixels sur 256000,

(plutôt 256x256000 : il y a un 000 de trop)

Cédric

[Eric Daspet]

2013/3/12 Cédric Morin <cedric...@yterium.com>:

> (plutôt 256x256000 : il y a un 000 de trop)

Oups, effectivement (bon, ça reste très élevé mais pas le même ordre
de grandeur)



--
Éric Daspet
http://eric.daspet.name/

[Thomas Bassetto]

Bonsoir,

Merci beaucoup pour vos réponses ! Quelques commentaires :
-Clairement la priorité est d'implémenter un système de lazy loading
sur les images et sur le HTML (genre scroll infini)
-Nous maîtrisons bien la taille d'affichage des images (3 tailles)
sauf que la grande majorité d'entre elles ne nous appartiennent pas
(avatars directement récupérer depuis Twitter et Facebook). Du coup
mettre en place un "proxy" pour générer, stocker et servir les bonnes
miniatures est une bonne idée mais couteuse en ressources humaines et
matérielles.
-Le cœur de l'application est la musique donc si l'utilisateur a une
latence catastrophique, le défilement et/ou les images est le dernier
de ses soucis... On ne bloque pas l'accès aux mobiles pour autant mais
ils ne sont pas une priorité.

J'aimerais revenir sur l'utilisation de background-color durant le
lazy-loading. En fait on utilise une technique similaire pour les
images ne se chargeant pas (ou n'existant pas). Cela ressemble grosso
modo à :

<div class="user-picture"><div class="inner"></div></div>
.user-picture,
.inner {
background: transparent center top no-repeat;
background-size: cover;
}
.user-picture {
position: relative;
width: 100px;
height: 100px;
background-image: url("/img/user-picture-default.png");
}
.inner {
position: absolute;
top: 0;
right: 0;
bottom: 0;
left: 0;
}

L'image souhaitée sera placée en tant que background-image de .inner
{}. On peut la faire apparaître avec une transition par exemple. Vu
que /img/user-picture-default.png est souvent réutilisée, j'espère que
les navigateurs réutilise celle qu'ils ont en mémoire.

Il serait peut-être préférable d'avoir un seul élément et de changer
son background-image, mais on perd la possibilité de faire une
transition (entre 2 valeurs de background-image). Ou alors je pourrais
utiliser ::before {}.

--
Thomas

2013/3/11 Thomas Bassetto <tbas...@gmail.com>:

[Gaël Métais]

Salut,

J'avais fait quelques tests à ce sujet, mais sur des images plus grosses (1000px de large redimensionnées en 200px). Ce n'est pas la mémoire qui m'inquiète. J'ai l'impression que les navigateurs s'en sortent plutôt bien sur la consommation mémoire, ils ont l'air d'avoir mis en place des stratégies pour recycler la RAM lorsqu'on scroll dans une page. Par contre, au niveau de la consommation CPU il y avait clairement un problème. Chaque resize d'image coûtait 15ms de traitement (c'est énorme).

Pour mesurer le coût, tu peux utiliser l'outil Timeline de Chrome Developpers Tools qui permet d'analyser les frames. 

Le traitement du redimensionnement ne se faisant qu'à l'affichage réel de l'image, sur Chrome, c'est en scrollant que tu observera le plus facilement les temps de calcul (et la page qui rame).

Mets toi en haut de ta page puis recharge la (sinon les images ont déjà été redimensionnées). Lance la mesure et scroll dans la page. En observant le détail des frames, tu verras apparaître le temps de décodage du JPEG ainsi que le temps de resize. Si les temps sont trop importants, le FPS baisse et le scroll devient moins fluide.

J'ai essayé de mesurer le coût pour tes dimensions d'images, j'ai l'impression que le resize prend environ 1,2ms par image (sur ma machine rapide). J'ai l'impression que c'est suffisamment faible pour ne pas s'en soucier, mais peut-être que ça entrera en concurrence avec la décompression de la musique sur les ordinateurs les plus lents. Je ne saurais pas dire.

Pour les smartphones, si l'application n'est pas en responsive alors cela signifie que les images sont déjà redimensionnées, donc pas de surcoût. 

Et enfin, attention sous IE. J'ai l'impression que IE8 effectue le calcul de resize au chargement initial, et non au scroll. Si c'est confirmé, avec tes 1000 images cela lui ferait faire 1200ms de calcul lors du chargement des assets, ce qui doit le freezer pas mal.

Pas d'avis sur la meilleur technique pour remplacer le background par défaut. Mais lorsque tu parles de mettre une transition, ça ça risque de bien plus pénaliser les performances que le redimensionnement de l'image !!

Gaël METAIS