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 ?
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
Le 05/07/11 15:25, Pierre Goiffon a écrit :
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
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
Le 05/07/11 16:24, SAM a écrit :
(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.
(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.
(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.
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 ?
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.
Le 05/07/2011 15:25, Pierre Goiffon a écrit :
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.
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 ?
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.
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 ?
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
Le 06/07/2011 14:31, Olivier Masson a écrit :
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
Le 06/07/2011 14:31, Olivier Masson a écrit :
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é.
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
Le 06/07/2011 18:10, Pascal Poncet a écrit :
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é.
Le 06/07/2011 18:10, Pascal Poncet a écrit :
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é.
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é.
unbewusst.sein
Olivier Masson wrote:
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 <sisemen@laposte.net> wrote:
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)
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
Le 07/07/2011 10:25, Une Bévue a écrit :
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.
Le 07/07/2011 10:25, Une Bévue a écrit :
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.
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.
unbewusst.sein
Olivier Masson wrote:
Ce n'est pas le but de HTML5boilerplate (http://html5boilerplate.com/mobile/). Mieux vaut chercher sur les framework mobile existant.
OK, merci !
-- « Pour bien aimer un vivant, il faut l'aimer comme s'il devait mourir demain. » (Proverbe arabe)
Olivier Masson <sisemen@laposte.net> wrote:
Ce n'est pas le but de HTML5boilerplate
(http://html5boilerplate.com/mobile/). Mieux vaut chercher sur les
framework mobile existant.
OK, merci !
--
« Pour bien aimer un vivant, il faut l'aimer comme s'il
devait mourir demain. »
(Proverbe arabe)
Ce n'est pas le but de HTML5boilerplate (http://html5boilerplate.com/mobile/). Mieux vaut chercher sur les framework mobile existant.
OK, merci !
-- « Pour bien aimer un vivant, il faut l'aimer comme s'il devait mourir demain. » (Proverbe arabe)
unbewusst.sein
Olivier Masson wrote:
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. -- « Pour bien aimer un vivant, il faut l'aimer comme s'il devait mourir demain. » (Proverbe arabe)
Olivier Masson <sisemen@laposte.net> wrote:
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.
--
« Pour bien aimer un vivant, il faut l'aimer comme s'il
devait mourir demain. »
(Proverbe arabe)
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. -- « Pour bien aimer un vivant, il faut l'aimer comme s'il devait mourir demain. » (Proverbe arabe)
Pierre Goiffon
On 06/07/2011 14:31, Olivier Masson wrote:
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 ?
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.
On 06/07/2011 14:31, Olivier Masson wrote:
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 ?
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.
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 ?
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.
