Sprites, CSS et téléchargement image
Pierre Goiffon
Je suis en train de travailler de mani�re approfondi � am�liorer les
perf des �crans du produit sur lequel je travail. Apr�s avoir concat�n�
les CSS autant que possible, je m'attaque � mettre en sprites les images.
Une question m'est venue : si j'ai une css g�n�rique, appel�e sur toutes
les pages, qui contient des appels aux images sprites_A.png et
sprites_B.png, que va-t-il se passer (t�l�chargement des images par le
navigateur) :
- sur une page qui n'utilise que des s�lecteurs utilisant sprites_A
- lorsque l'on n'a que des s�lecteurs utilisant sprites_B
- une page qui m�lange des appels � sprites_A et sprites_B
- une page qui ne contient que des appels � sprites_A, mais dans
laquelle on va charger ensuite en Ajax du html contenant des appels �
sprites_B
Je n'ai pas vraiment trouv� de support pour avoir une id�e des
comportements... et j'imagine qu'ils vont varier de navigateur �
navigateur ?
SAM
> Bonjour,
>
> Je suis en train de travailler de mani�re approfondi � am�liorer les
> perf des �crans du produit sur lequel je travail. Apr�s avoir concat�n�
> les CSS autant que possible, je m'attaque � mettre en sprites les images.
keskec� ?
Ha!? mais c'est une image de x images ! que l'on d�place en background
� part le probl�me de son chargement (assez lourd) au 1er appel
� mon avis : que du bonheur !
(surtout pour les rollovers, portes coulissantes, toussa, maizossi
toutes sortes de trucs :
<http://www.alsacreations.com/xmedia/doc/full/sprites-big-sites.png>)
> Une question m'est venue : si j'ai une css g�n�rique, appel�e sur toutes
> les pages, qui contient des appels aux images sprites_A.png et
> sprites_B.png, que va-t-il se passer (t�l�chargement des images par le
> navigateur) :
> - sur une page qui n'utilise que des s�lecteurs utilisant sprites_A
> - lorsque l'on n'a que des s�lecteurs utilisant sprites_B
> - une page qui m�lange des appels � sprites_A et sprites_B
pour les images,
ben .. on s'en moque
... d�s que les A *et* B auront �t� utilis�es au moins une fois, non ?
indice : le navigateur n'ira charger l'image de background que s'il
rencontre lors du parsage html la r�gle css la r�clamant.
(d'o� l'int�ret du sprite pour le roll-over, on n'attend pas le
chargement de l'image de remplacement au survol, ou au clic)
> - une page qui ne contient que des appels � sprites_A, mais dans
> laquelle on va charger ensuite en Ajax du html contenant des appels �
> sprites_B
ben ... pareil ...
*si* c'est un fichier css d�j� connu qui est "re"charg� (certainement du
cache, m�me en Ajax).
> Je n'ai pas vraiment trouv� de support pour avoir une id�e des
> comportements... et j'imagine qu'ils vont varier de navigateur �
> navigateur ?
�a doit d�pendre des appels
- � fichier communs de css (possiblement d�j� vus et mis en cache)
- � css individuelles (possiblement compl�tement inconnues)
peut-�tre cela d�pend t-il du navigateur ?
v�rifie t-il toutes les images des css ? voir � voir si elles ont chang�
depuis mise en cache
--
St�phane Moriaux avec/with iMac-intel
SAM
>
> (d'o� l'int�ret du sprite pour le roll-over, on n'attend pas le
> chargement de l'image de remplacement au survol, ou au clic)
Le temps d'attente est imperceptible au 2i�me survol, l'image utilis�e
alors est certainement celle du cache.
Ph�nom�ne constat� m�me sur un autre roll-over utilisant la m�me r�gle
css, la m�me image.
<http://stephane.moriaux.pagesperso-orange.fr/truc/pg-sprites/>
Olivier Masson
Firebug est l� pour t'aider. Les navigateurs (en g�n�ral IE) n'ont pas
toujours le m�me comportement � ce niveau.
Par ailleurs, pour l'optimisation web, tu peux d'inspirer de
HTML5boilerplate, que j'utilise en prod depuis 2 projets.
Pascal Poncet
> Par ailleurs, pour l'optimisation web, tu peux d'inspirer de
> HTML5boilerplate, que j'utilise en prod depuis 2 projets.
Merci pour le tuyau, �a a au moins l'avantage de centraliser plusieurs
r�ponses � des probl�matiques qui vont devenir courantes (ou le sont
d�j�), avant que HTML5 soit d�finitivement normalis�.
--
Cordialement,
Pascal
Olivier Masson
> Merci pour le tuyau, �a a au moins l'avantage de centraliser plusieurs
> r�ponses � des probl�matiques qui vont devenir courantes (ou le sont
> d�j�), avant que HTML5 soit d�finitivement normalis�.
>
�a a beaucoup d'avantages, m�me si tout d�pend de la fa�on dont tu
travailles actuellement.
Il faut quelques heures pour bien comprendre ce que �a fait,
c'est-�-dire lire le build.xml (config pour ant, outil bien connu des
dev java).
J'y ai int�gr� less.js ce qui est juste formidable puisque je cr�e mes
css en lessjs et au passage en prod, il me sort un css nickel.
Il existe �galement une version mobile, que je n'ai pas essay�.
Une Bévue
> Il existe �galement une version mobile, que je n'ai pas essay�.
avec boilerplate ?
�a m'int�resse beaucoup car je souhaite d�velopper une application de
sauvegarde, via html5 et sqlite, qui puisse tourner sur iPhone et
desktop avec butineur compatible webkit...
--
� Pour bien aimer un vivant, il faut l'aimer comme s'il
devait mourir demain. �
(Proverbe arabe)
Olivier Masson
> avec boilerplate ?
> �a m'int�resse beaucoup car je souhaite d�velopper une application de
> sauvegarde, via html5 et sqlite, qui puisse tourner sur iPhone et
> desktop avec butineur compatible webkit...
>
Ce n'est pas le but de HTML5boilerplate
(http://html5boilerplate.com/mobile/). Mieux vaut chercher sur les
framework mobile existant.
Une Bévue
>
> Ce n'est pas le but de HTML5boilerplate
> (http://html5boilerplate.com/mobile/). Mieux vaut chercher sur les
> framework mobile existant.
OK, merci !
Une Bévue
> Ce n'est pas le but de HTML5boilerplate
> (http://html5boilerplate.com/mobile/). Mieux vaut chercher sur les
> framework mobile existant.
Ben, je viens de passer cette apr�s-midi sur un Framework existant sur
ma b�canne )))
Il s'agit de Dashcode qui permet de g�n�rer du code � la fois pour
mobile et pour desktop...
j'ai pratiqu� le premier tuto pour mobile seulement :
<http://82.226.217.239/National_Parks/index.html>
seulement optimis� pour mobile il tourne sur Chrome.
Pierre Goiffon
>> Une question m'est venue : si j'ai une css générique, appelée sur toutes
>> les pages, qui contient des appels aux images sprites_A.png et
>> navigateur) :
>> - sur une page qui n'utilise que des sélecteurs utilisant sprites_A
>> - lorsque l'on n'a que des sélecteurs utilisant sprites_B
>> - une page qui mélange des appels à sprites_A et sprites_B
>> - une page qui ne contient que des appels à sprites_A, mais dans
>> laquelle on va charger ensuite en Ajax du html contenant des appels à
>> sprites_B
>>
>> Je n'ai pas vraiment trouvé de support pour avoir une idée des
>> comportements... et j'imagine qu'ils vont varier de navigateur à
>> navigateur ?
>
> Firebug est là pour t'aider. Les navigateurs (en général IE) n'ont pas
> toujours le même comportement à ce niveau.
Firebug est pour Firefox... Et comme je n'ai pas trouvé de référence sur
le W3C indiquant quel devrait être le comportement, j'imagine que
vraiment ça peut bcp varier. Avant de me lancer dans des tests
exhaustifs, j'ai préféré demander ici si quelqu'un avait une idée de la
réponse...
J'en conclus qu'en gros on ne sait pas trop, et que donc par conséquent
il faut prévoir le cas le pire.
Pierre Goiffon
>> Je suis en train de travailler de manière approfondi à améliorer les
>> perf des écrans du produit sur lequel je travail. Après avoir concaténé
>> les CSS autant que possible, je m'attaque à mettre en sprites les images.
>
> keskecé ?
>
> Ha!? mais c'est une image de x images ! que l'on déplace en background
Oui, exactement !
> à part le problème de son chargement (assez lourd) au 1er appel
> à mon avis : que du bonheur !
C'est bien le prb :)
Car après inventaire précis des images existantes (un peu moins d'une
centaine, dans des tailles très variées) et de leurs appels, je me
posais la question du découpage. Evidemment, faire une seule image de
sprites aurait été un peu crétin ! Pour les usages mais aussi pour des
prb techniques (tailles et repeat-x en particulier).
Mais quasiment tout est centralisé dans une seule CSS appelée de partout.
J'avais donc cette question sur des images appelée uniquement dans
certains écrans de l'application, en me demandant si je faisais une
image de sprites dédiée s'il fallait également créer une css dédiée.
Il y a bcp de problématique derrière, car il faut penser également à la
maintenance (et avoir toutes les icones au même endroit par exemple !)...
Pierre Goiffon
> HTML5boilerplate, que j'utilise en prod depuis 2 projets.
Ca a pas mal grandit depuis la première fois où j'y suis allé !
Malheureusement il n'y a pas possibilité pour moi d'incorporer
facilement tout celà, et même des bouts.
Enfin, il y a quand même énormément de doc sur les perf web, ça fait
plaisir ! En plus de l'indispensable site de Yahoo dédié au sujet
(http://developer.yahoo.com/performance/) je me suis appuyé sur
l'excellent http://performance.survol.fr/ (mais sniif, qui commence à
dater) et http://www.websiteoptimization.com/, et beaucoup de recherches
google :)
SAM
> On 05/07/2011 16:24, SAM wrote:
>>> je m'attaque à mettre en sprites les images.
>>
>
> C'est bien le prb :)
> Car après inventaire précis des images existantes (un peu moins d'une
> centaine, dans des tailles très variées) et de leurs appels, je me
> posais la question du découpage. Evidemment, faire une seule image de
> sprites aurait été un peu crétin !
heu ... google a une image avec des tas d'icônes de tailles variées
<http://v3.x.mappy.com/static/images/6bea5d3cd4720d8bc99929a351605f1c.png?iU4>
il suffit que les zones d'affichages soient aux dimensions des icônes y
requises.
On nous assure qque part que le poids total des images n'est guère
différent du poids de l'image les réunissant, le blanc nécessaire à la
mise en forme de cette sprite ne comptant pas (beaucoup).
> Pour les usages mais aussi pour des
> prb techniques (tailles et repeat-x en particulier).
Ha! du repeat-x avec une image spritée ... je ne sais pas faire
c'est possible ?
(en HTML 5 ... ou 6 ?)
> Mais quasiment tout est centralisé dans une seule CSS appelée de partout.
>
> J'avais donc cette question sur des images appelée uniquement dans
> certains écrans de l'application, en me demandant si je faisais une
> image de sprites dédiée s'il fallait également créer une css dédiée.
Ma foi ...
avec une css dédiée cela doit assurer de moins encombrer,
ça doit aussi faciliter la création des règles
Mais ... à mon idée :
des règles des feuilles de styles ne seront chargées au load que les
images utiles à la page.
Donc à part la lourdeur du chargement des lignes du fichier css, qu'il y
ait dedans 1 ou 1000 lignes désignant x images (de background), ne
seront effectivement chargées ou contrôlées que les images utiles à
l'affichage *normal* de la page appelant ce fichier css.
Le fichier css, surtout s'il est compacté, ne doit pas peser bp dans
l'ensemble de la page, il doit pouvoir tout réunir sans poser de tracas.
Le truc des fichiers séparés peut être avantageux pour l'humain qui s'y
colle et probablement la maintenance mais guère pour le fonctionnement
du site ou du serveur.
> Il y a bcp de problématique derrière, car il faut penser également à la
> maintenance (et avoir toutes les icones au même endroit par exemple !)...
oui ... bon .. à chacun son dada, hein ?
si je préfère avoir les icônes arrondies dans le dossier /smoth/ et
celles plutôt carrées dans celui /rect/ et celles en étoiles dans
/stars/ ... ;-)
d'avoir les icônes au même endroit doit faciliter leur recherche humaine
sinon pour le serveur leur emplacement ne doit pas beaucoup influencer
sur sa célérité, non ?
Maintenant, il est certain que si les icônes sont toutes réunies sur la
même image ça doit en faciliter les recherches puisque reduites à une.
Se poser la question du devenir de cette image quand on ajoutera de
nvelles icones ou les modifiera en tailles.
Pour la maintenance des FdS, penser à LESS dont Olivier Masson nous a
vanté les bienfaits
js : <http://lesscss.org/>
app : <http://incident57.com/less/>
... encore d'autres instructions/fonctions à apprendre :-/
Curieusement j'ai l'impression que le rollover est plus réactif avec 2
images (si déjà en cache)
qu'avec une seule image glissée
(essai avec images 560ko/1120px/655px ou double)
--
Stéphane Moriaux avec/with iMac-intel
Olivier Masson
> Firebug est pour Firefox... Et comme je n'ai pas trouvé de référence sur
Tu as un équivalent pour Chrome (même comportement que Safari a priori),
Opera a aussi des outils. Et IE... 10. Peut-être 9 aussi.
Et tu peux toujours utiliser un sniffer réseau (Ethereal) pour regarder
ce qui est lu. La lecture n'est pas aisée mais tu sais ce que tu
cherches (le nom de ton image) donc ça facilite grandement.
Pierre Goiffon
>> Car apr�s inventaire pr�cis des images existantes (un peu moins d'une
>> centaine, dans des tailles tr�s vari�es) et de leurs appels, je me
>> posais la question du d�coupage. Evidemment, faire une seule image de
>> sprites aurait �t� un peu cr�tin !
>
> heu ... google a une image avec des tas d'ic�nes de tailles vari�es
> <http://v3.x.mappy.com/static/images/6bea5d3cd4720d8bc99929a351605f1c.png?iU4>
Oui en effet il est tout � fait possible de mixer des images de tailles
diff�rentes, je l'ai d'ailleurs fait ! Mais la taille des images n'est
pas le seul argument � prendre en compte : il faut voir la fr�quence
d'appel et sur quels �crans, les r�gles de cache que l'on va appliquer,
la fr�quence de maj, etc. etc.
C'est tout de m�me rare qu'il soit pertinent de charger toutes les
images d'une application web en m�me temps, certains �crans sont
forc�ment tr�s sp�cifiques, et puis des composants sont g�n�riques, etc etc.
> Ha! du repeat-x avec une image sprit�e ... je ne sais pas faire
> c'est possible ?
Pour le repeat-x, il suffit de r�p�ter ses images les unes au-dessus des
autres et que le conteneur auquel on applique l'image ait bien une
hauteur fixe. Et inversement pour le repeat-y.
On peut aussi tr�s bien mettre en place le syst�me des sprites sur la
technique des sliding doors.
> Mais ... � mon id�e :
> des r�gles des feuilles de styles ne seront charg�es au load que les
> images utiles � la page.
Ca parait logique, mais je n'ai trouv� aucun document me permettant
d'�tre s�r que c'est bien le cas. Et comme �a n'est pas �crit noir sur
blanc dans la recommandation �a me laisse tr�s tr�s dubitatif sur le
fonctionnement adopt� par les navigateurs !
> Pour la maintenance des FdS, penser � LESS dont Olivier Masson nous a
> vant� les bienfaits
> js : <http://lesscss.org/>
> app : <http://incident57.com/less/>
> ... encore d'autres instructions/fonctions � apprendre :-/
Oui, j'avais vu passer sur le groupe le lien vers ce framework, mais �a
me parait dans mon cas trop lourd � adopter ! Mais en effet il faut le
garder en t�te car dans certains cas �a pourrait rendre de fiers services !
> Curieusement j'ai l'impression que le rollover est plus r�actif avec 2
> images (si d�j� en cache)
> qu'avec une seule image gliss�e
> (essai avec images 560ko/1120px/655px ou double)
Ha ? Surprenant !
Ici nous avons commenc� la mise en sprites sur les images concern�es par
des rollover, nous n'avons jamais constat� de diff�rence significative ?
Mais ce sont pour des images de 16*16px ou 32*32px max...
Pierre Goiffon
En effet c'est faisable, mais le coût me parait déraisonnable.
Olivier Masson
> Pour le repeat-x, il suffit de répéter ses images les unes au-dessus des
> autres et que le conteneur auquel on applique l'image ait bien une
> hauteur fixe. Et inversement pour le repeat-y.
>
Et en diagonale http://www.aaronbarker.net/2010/07/diagonal-sprites/