En début d’année, kangax mesurait la performance des propriétés CSS3 (box-shadow, border-radius, transform, …). Résultat : ces propriétés sont gourmandes en temps de calcul. Cependant, je suis convaincu qu’en comparant tous les critères de qualité d’une intégration, l’utilisation de ces propriétés CSS3 reste une meilleure solution que l’utilisation d’images, de JavaScript ou de Flash.
Parce que sur le web, en intégration, tout a un coût. Je ne parle pas d’argent, mais de l’impact sur le poids, le temps de chargement, le temps de rendu, l’interopérabilité, et la facilité de maintenance d’une page web. La moindre ligne de code que vous ajoutez a un coût. Le moindre effet visuel a un coût. La moindre fonctionnalité a un coût.
Au fil du temps, j’ai fini par me construire le modèle mental suivant.
C’est une estimation personnelle du coût de l’utilisation de CSS3, d’images, de JavaScript ou de Flash. C’est une estimation allant de 0 à n, sans unité, valable quasiment aussi bien en Ko de poids de téléchargement, en millisecondes de temps de rendu de page, ou en difficulté de maintenance. Le premier échelon, représente le code HTML et CSS le plus petit possible pour représenter une page avec toutes ses fonctionnalités. La répartition du coût d’utilisation de CSS3, d’images ou de JavaScript peut varier selon les cas, mais restera la plupart du temps dans cet ordre.
Prenons un exemple : vous devez utiliser une police non web. Vous avez le choix. Vous pouvez utiliser des images, mais vous réduirez considérablement la maintenabilité de votre site, nécessitant une retouche d’image pour la moindre retouche de texte. Vous pouvez utiliser les déclarations font-face de CSS3, mais qui imposent d’emblée un lourd surpoids et un énorme surcoût de rendu. Vous pouvez utiliser des librairies JavaScript, comme Cufón, mais vous ne rajoutez qu’une couche supplémentaire côté client très coûteuse. Et dans le pire des cas, vous pouvez utiliser une solution en Flash, comme sIFR. Dans cet exemple, la répartition de CSS3, des images et de JavaScript se ferait clairement dans la zone orange/rouge du modèle ci-dessus. Quelque soit la technologie utilisée, le coût de l’utilisation d’une police non web est très important. Mais CSS3 reste la moins pire des solutions.
Autre exemple : vous devez faire des bords arrondis. Vous pouvez utiliser 1 ligne de CSS3. Cette ligne sera relativement lourde à exécuter par le navigateur, mais rapide à télécharger et facile à maintenir. Si vous devez supporter des navigateurs plus anciens, vous pouvez ajouter quelques balises supplémentaires puis utiliser des images de fond pour chaque coin. Même en utilisant des sprites et en simplifiant au mieux votre code, vous alourdissez quand même votre page HTML et le nombre de requêtes pour faire ça. Vous pouvez alors utiliser un fichier JavaScript qui exécutera des bords arrondis uniquement pour les navigateurs nécessiteux (comme border-radius.htc). Mais en faisant cela, vous alourdissez de manière considérable le poids et le temps de rendu de votre page.
Si les intégrateurs ont parfois l’air de rechigner à intégrer certains éléments graphiques (comme une liste déroulante personnalisée), ce n’est pas probablement par fainéantise, mais plus par conscience du coût engendré sur la page web.
Si les intégrateurs sont enthousiastes de l’arrivée de CSS3, ce n’est pas par esprit de revanche, mais parce que les propriétés CSS3 diminuent considérablement le coût des choses. Mais elles ne font que le diminuer.
Que vous soyez chef de projet, graphiste, ou développeur, il est impératif de garder toujours en tête que quoi que vous fassiez, ça aura un coût sur le web. Si de plus en plus de sites adoptent un design minimaliste, ce n’est pas forcément par style, mais bien parce que sur le web, c’est une nécessité.
Nico, le
Tu places où sur ton échelle les images de type data-URI ?
Olivier Nourry (@OlivierNourry), le
Très bonne approche que celle de penser en termes de coût d’ensemble. Ça me rappelle la notion de « valeur » que j’utilisais dans une vie antérieure, dans le domaine du design industriel. Chaque fonction doit être appréciée en termes de valeur, notion qui mesure le service rendu. On compare ensuite au coût (conception, fabrication, usage, maintenance, et même recyclage). Et si valeur < coût, on re-designe jusqu'à inverser le rapport.
Après, parmi les paramètres formant le coût, perso j'aurais intégré l'accessibilité, mais chacun applique son propre système de valeurs! ;o)
Rémi, le
Entre CSS3 et Images. Ça alourdit le poids du HTML ou CSS, mais ça évite des requêtes supplémentaires comme des images classiques.
Bartdude, le
Un peu biaisé sur le Flash, je trouve… je ne suis pas pro-flash, mais on est encore loin d’avoir les outils (et les gens expérimentés) pour faire en HTML+CSS (+JS of course) tout ce qu’on fait en Flash à l’heure actuelle. Même si certaines démos sont prometteuses voire carrément convaincantes, en terme de temps de développement ou de facilité de maintenance (où la difficulté peut simplement résider dans le fait de trouver les bonnes personnes) on peut vite exploser les temps nécessaires en Flash.
pauland, le
@Nico: je mettrai ça au même niveau que les images (voire plus gourmand). car au lieu de faire une requête de plus pour une image, qui pourrait être mise en cache, tu alourdies le poids de ton fichier CSS / HTML qui n’a pas forcément les même règle de cache.
Après, ce serai intéressant aussi de savoir comment est fait le chargement de ce data-uri (synchrone / asynchrone) et est-ce que du coup, ça n’a pas une mauvaise influence sur le temps du rendu de la page
A tester en gros :)
pauland, le
Ah bin Rémi t’as répondu entre temps…
Thomas, le
Merci pour cet article.
Je suis bien d’accord avec toi.
Attention quand-même à un détail que j’ai pu remarquer : L’utilisation massive de CSS3 sur des éléments qui ont une taille qui évolue, un accordéon par exemple, PEUT être plus lourd que l’équivalent en image.
Pas au niveau maintenabilité bien-sûr, mais au niveau confort utilisateur.
« Mais elles ne font que le diminuer. » => Cette phrase semble être en trop dans le texte, non ?
Bonne journée,
Thomas.
Nico, le
@Rémi : ok, merci ! :)
Nico, le
Certaines propriétés de CSS3 peuvent être lourdes également… je pense aux transitions ou aux animations.
lionel, le
@Pauland : pour les images uri (comme dans les CSS) c’est pas mal d’appliquer la règle des 4ko. au delà, autant charger une image car le gain n’est plus intéressant. (j’ai pas le lien sous la main
@remi : je suppose que ton échelle ne s’applique qu’à ce qui touche à « certains éléments graphiques » car en terme de fonctionnalités, comparer une image, du code html, du flash et javascript relève du grand n’importe quoi.
« Si de plus en plus de sites adoptent un design minimaliste, ce n’est pas forcément par style, mais bien parce que sur le web, c’est une nécessité. »
Par contre je me dis que cette approche c’est juste poser comme loi que la fonction prime sur la forme, or ce choix ne revient pas à l’intégrateur C’est fonction du projet, de son but, de ce qu’on doit communiquer. Si on ne s’occupe que des aspects visuels, ta manière d’opposer créativité et performances me dérange de plus en plus. ça fait vraiment écho aux commentaires de @yamo sur ton post http://www.hteumeuleu.fr/le-webdesign-n-est-pas-un-art/
Je dirait plutôt que si des sites adoptent un design minimaliste, c’est parce que la forme redevient en adéquation avec le fond. Si le but est d’informer, d’être lu, alors oui un design qui sert la lecture mais pas besoin de parler de minimalisme, même si je pense qu’on ne met pas la même chose derrière un design minimaliste.