28172 sujets

CSS et mise en forme, CSS3

Et si on parlait de l’optimisation de l’écriture de la couleur ?

Bonjour à tous.

La couleur peut être écrite de différentes façons :
1. Couleur hexadécimale #rrvvbb : ex. : #00ffff;
2. Couleur hexadécimale réduite #rvb : ex. : #0ff;
3. Couleur par intensité des composantes de rouge vert bleu : ex.: rgb(0,255,255);
4. Couleur par intensité des composantes de rouge vert bleu complétée de la valeur de l’opacité : rgba(0,255,255,1);
5. Couleur par la valeur des composantes de teinte saturation luminosité : hsl(180,100,100);
6. Couleur par la valeur des composantes de teinte saturation luminosité complétée de la valeur de l’opacité : hsla(180,100,100,1);
7. Couleur par nom normalisé : aqua;

La deuxième écriture est un reliquat du temps où n’existaient que très peu de teintes sur les écrans et elle me semble donc à éviter.
La septième écriture ne peut être utilisée que si la couleur appartient à la liste commune, actuellement de 140 valeurs. Son avantage consiste d’abord en une meilleure lisibilité du code. Qu’en est-il en ce qui concerne l’optimisation ?

Plus généralement quelle est la meilleure écriture en ce qui concerne l’optimisation sur les navigateurs récents ? Et la moins bien ?

Merci pour vos explications.
Modifié par Pyanepsion (06 Nov 2015 - 09:18)
Administrateur
À ce qu'il me semble, la 2e écriture (#FFF pour #FFFFFF) est surtout un raccourci syntaxique, ce n'est pas forcément lié à une limitation physique du nombre de couleurs.

S'agit-il de parler d'optimisation en poids de fichier ? Par exemple écrire "white" est plus court que "#FFFFFF" ? Je pense que c'est négligeable Smiley cligne

De nos jours, on utilise souvent des outils de pré/post processing CSS qui vont se charger de générer ou réécrire ces codes couleurs.
La deuxième écriture me semble à éviter, car elle ne permet l’écriture que de 255 couleurs. La couleur #808080 (Gray) ne peut par exemple pas être réduite. En amenant une différence d’écriture avec la forme standard, la deuxième écriture peut aussi créer des confusions et être source d’erreurs alors difficiles à retrouver.

Je cherche ici surtout à optimiser la vitesse de chargement de la page finale. Même si la différence de temps est minime, multipliée par le nombre de couleurs, cela finit parfois par faire beaucoup... ne serait-ce qu’au niveau personnel, sans parler de l’intérêt écologique qui va amener à consommer moins d’énergie sur la masse, car on utilise alors considérablement moins de temps-machine sur l’ensemble des visiteurs.
Bonjour,
Pyanepsion a écrit :
La deuxième écriture me semble à éviter, car elle ne permet l’écriture que de 255 couleurs. La couleur #808080 (Gray) ne peut par exemple pas être réduite.

Pour le web ce n'est pas forcément un problème car il faut un minimum de contraste sur un écran pour que celui-ci soit repérable. A l'heure actuelle, quel écran est-il en mesure de repérer une différence telle que #fefefe et #fff ? Réponse : aucun.

Pyanepsion a écrit :
En amenant une différence d’écriture avec la forme standard, la deuxième écriture peut aussi créer des confusions et être source d’erreurs alors difficiles à retrouver.

Pour un néophyte uniquement. Quand l'habitude est prise on switche facilement d'une écriture à une autre, quand ce n'est pas un pré/post-processeur qui le fait pour nous.

Pyanepsion a écrit :
Je cherche ici surtout à optimiser la vitesse de chargement de la page finale. Même si la différence de temps est minime, multipliée par le nombre de couleurs, cela finit parfois par faire beaucoup... ne serait-ce qu’au niveau personnel, sans parler de l’intérêt écologique qui va amener à consommer moins d’énergie sur la masse, car on utilise alors considérablement moins de temps-machine sur l’ensemble des visiteurs.

"Considérablement"... Et avec quel outil réalisez-vous vos tests ? Car personnellement je n'en connais aucun qui soit en mesure d'accomplir un tel test. Et - j'ai beau fouiller dans ma mémoire - je ne me souviens pas avoir lu un article présentant un lag de chargement lié à un choix d'encodage couleur. Ce qui serait d'ailleurs étonnant étant donné que ces codes sont créés à destination des navigateurs.
Modifié par Olivier C (06 Nov 2015 - 13:58)
Olivier C a écrit :
quand ce n’est pas un pré/post-processeur qui le fait pour nous.

Là n’est pas la question d’autant que lorsque l’outil est bon, il faut [on peut] généralement aussi le paramétrer.

Olivier C a écrit :
Et avec quel outil réalisez-vous vos tests ?

Le meilleur, le bon sens. Dès lors qu’il peut y avoir une différence, alors, multipliée par le grand nombre, on arrive à des volumes considérables.

Olivier C a écrit :
ces codes sont créés à destination des navigateurs.

Et ? Un navigateur ne prend-il pas du temps pour calculer et donc de l’energie ? Inversement, c’est sur le principe de la quantité négligeable multipliée par le grand nombre que certaines entités ont bâti des empires. Quelle est donc par exemple la quantité d’énergie consommée par Google par une recherche sur Google ? Elle est si infime que l’on pourrait la considérer comme négligeable, mais au bout de la chaine on arrive à plusieurs centrales nucléaires uniquement pour faire tourner les ordinateurs de Google.
Donc je résume : aucun élément de réalité ne vous permet de confirmer vos dires, mais vous voilà persuadés de la justesse de vos principes... Tant mieux pour vous. Au revoir.
Modifié par Olivier C (06 Nov 2015 - 14:56)
Olivier C a écrit :
Donc je résume : aucun élément de réalité ne vous permet de confirmer vos dires, mais vous voilà persuadés de la justesse de vos principes... Tant mieux pour vous. Au revoir.

Et réciproquement aucun élément de réalité ne vous permet de confirmer vos dires, mais vous voilà persuadés de la justesse de vos principes... Tant mieux pour vous, mais est-il pour autant nécessaire de provoquer un clash ?

Il est peut-être plus intelligent d’argumenter. C’est cela que l’on appelle une discussion.
Il va en falloir des optimisations sur les codes couleur afin de compenser toute "l'encre" que ce sujet fait couler Smiley lol
Pyanepsion a écrit :

Et réciproquement aucun élément de réalité ne vous permet de confirmer vos dires, mais vous voilà persuadés de la justesse de vos principes... Tant mieux pour vous, mais est-il pour autant nécessaire de provoquer un clash ?


Faut avouer que le sujet prête en soi au pinaillage...
Pour rejoindre l'un des précédents commentaires, je n'ai pas encore vu d'article traitant ledit sujet "en profondeur", susceptible d'inciter à utiliser l'une ou l'autre de ces formulations.
Pas vraiment une question existentielle.
Si le fond de la réflexion est à visée écologique, alors le fait d'économiser deux ou trois octets sur une page HTML ne paraît pas en soi un gain évident pour sauver la planète.
A priori, les gros pollueurs sont déjà bien identifiés...
Concernant la deuxième écriture, il ne s'agit que d'une écriture abrégée et n'est en rien une manière à part entière de désigner une couleur. Cela permet un gain, certes minime, sur la taille du fichier final :

/* Au lieu d'écrire */
#element {color: #FFFFFF}
/* On écrira */
#element {color: #FFF}

/* Pareil pour */
#element {color: #0099FF}
#element {color: #09F}

Si on parle d'optimiser l'écriture pour gagner de l'espace alors cette écriture est à utiliser lorsqu'il est possible de réduire le code de la couleur qu'on utilise.

D'une manière plus générale, les couleurs écrites en hexadécimal occuperont généralement moins de place.
Après, il y a des exceptions pour "red" qui sera meilleur que "#f00" par exemple ou d'autres où il n'y a pas de différences (blue = #00f en terme d'octets).

Les pré-processeurs choisissent la solution qui sera la moins couteuse en octets.

Après, si on a besoin d'écrire un "rgba(0, 0, 0, .5)" par exemple, il n'y a aucune autre façon de faire que celle-ci (en utilisant les couleurs).
J’ai été un peu surpris de ne pas trouver de test de vitesse d’affichage selon le mode d’écriture de la couleur, car les couleurs sont l’une des propriétés les plus utilisées sur Internet.

La difficulté d’un tel test ressemble finalement beaucoup au test de durée déterminant la durée minimale pour aller d’un point à un autre dans une même ville ou dans une autre ville. Le véhicule utilisé n’est pas nécessairement le plus rapide : on va parfois plus vite à pied qu’en voiture, par exemple pour aller acheter son pain, le poids transporté peut intervenir, mais pas nécessairement, le trajet calculé va différer selon les GPS utilisés, la durée sera différente selon l’heure du trajet, etc.

Ici, la vitesse d’affichage sur l’écran de l’utilisateur va dépendre du navigateur utilisé, de la taille du fichier chargé, des capacités de l’hébergement, du nombre de visiteurs, du fournisseur d’accès Internet, du mode de transfert des données, etc.

Je ne peux bien sûr faire varier que les navigateurs : j’ai utilisé les nouvelles versions de Chrome, Edge, Firefox, et Opera. Les temps se tiennent.

Sur le plan pratique, j’ai écrit une routine PHP qui réinitialise le chronométrage avant chaque mesure. Elle répète ensuite 10 000 fois une opération simple :
<p class="color:#ff0000;">Chronométrage de l’affichage de ce texte.</p>
et elle affiche enfin la durée totale.
J’ai recommencé ensuite avec un autre mode d’écriture de la couleur.

Voici les durées totales arrondies :
nom = 350 000
hsl = 300 000
rgb = 300 000
#rrvvbb = 275 000
#rvb = 250 000
rgba = 140 000
hsla = 100 000

La durée semble donc varier de 10 à 35 microsecondes selon le mode d’écriture utilisé. C’est négligeable pour un site en particulier : 100 à 200 fois la différence pour un site (c’est le nombre de fois où la couleur est utilisée sur un site moyen) ne donne jamais qu’une différence de 2.5 à 5 millisecondes.

Cela ne l’est plus dès lors que l’on ramène cela à l’ensemble des internautes qui utilisent chaque jour leur ordinateur. Ne serait-ce que sur Google, il y a par exemple 4 000 000 de recherche toutes les 60 secondes...
Modifié par Pyanepsion (11 Nov 2015 - 14:19)
Bonjour,

Le calcul c'est seulement le temps de traitement du client, il n’inclus pas le temps machine serveur ?

Apres gagner quelques octets sur un site, pourquoi pas, mais le serveur les envois par paquet plus ou moins plein. Pour une optimisation parfaite des bouts de chandelles, il faudrait en plus que le site soit codé de manière à ce que chaque paquet envoyé vers le clients soit plein ?

Votre comparaison avec google, tient compte d'un calcul global, mais quid de la compression, effectué par le serveur même, ou par les algorithme des différents FAI et du réseau global internet ?
J’ai créé une page réduite au minimum et je l’ai publiée sur un site confidentiel privé hébergé sur un VPS. La page utilise l’algorithme suivant :

1. Réinitialisation des valeurs de microtime.
2. Saisie du temps initial.
3. 10 000 boucles de la routine à tester, ici le texte ci-dessus avec toujours la même couleur selon le même mode d’écriture.
4. Saisie du temps final.
5. Calcul par différence de la durée totale des 10 000 boucles.

Puis j’ai recommencé en changeant le mode d’écriture de la couleur. Et ainsi de suite.

Smiley cligne Ce que vous indiquez, ce sont les limites de la méthode utilisée. Cela dit, j’ai testé à plusieurs moments de la journée dans les conditions précitées, et parfois en lançant le test sur plusieurs ordinateurs du bureau en même temps [pour voir l’influence du nombre d’utilisateurs]. Les écarts restent, ce qui laisse imaginer que c’est ici avant tout le mode d’écriture qui influe.
Modifié par Pyanepsion (11 Nov 2015 - 14:21)
Sujet clos
Aller à