Les « media servers » ont depuis longtemps été adoptés par les géants du web comme Amazon, Google ou Yahoo. Concrètement, ces derniers permettent de stocker l’ensemble des contenus statiques (images et/ou vidéos) sur un serveur différent de celui qui héberge les pages, scripts et tous les services qui vont va avec. Les conséquences d’une telle séparation sont nombreuses, mais surtout très intéressantes sur plusieurs plans :

• Diminution de la charge (processeur, mémoire, processus Apache…) du serveur principal, qui est ainsi plus réactif pour afficher les pages ;
• Diminution du temps de chargement des pages grâce au téléchargement en parallèle sur plusieurs urls, à l’utilisation d’un domaine « cookie-free » et à l’appel d’un serveur à proximité (principe de base du Content Delivery Network, ou cdn) ;
• Gain de poids sur vos pages html grâce au choix d’une url courte (comme msda.fr/ au lieu de www.monsitedactu.fr/images/) ;
• Simplification de la gestion des images et vidéos sur votre serveur.

Créer un domaine dédié aux médias sur votre serveur

Dans l’idéal et en imaginant que vous ayez beaucoup d’argent, il faudrait 2 serveurs. Le principal vous servirait à faire tourner Apache et MySQL afin d’afficher les pages de votre site en php tandis que le second n’hébergerait que vos contenus statiques, et n’aurait donc pas besoin de grand chose pour tourner. Oui mais voilà, avoir 2 serveurs n’est pas donné à tout le monde, et complique la gestion d’une bibliothèque d’images et de vidéos.

C’est pourquoi je vous propose une approche différente, basée sur l’association de votre domaine secondaire avec un répertoire de votre serveur. Concrètement, il s’agira d’accéder aux contenus de www.monsitedactu.fr/images/ via l’url msda.fr/. Sur un serveur tournant sous Linux, il vous suffira de créer un VirtualHost dans le fichier de configuration d’Apache httpd.conf (chemin : /etc/apache/httpd.conf). Voici à quoi ressemblent les quelques lignes à ajouter :

<VirtualHost IP.IP.IP.IP:80 >
ServerName msda.fr
ServerAlias www.msda.fr
ServerAdmin webmaster@monsitedactu.fr
DocumentRoot /home/user/domains/monsitedactu.fr/public_html/images/
SuexecUserGroup user user
</VirtualHost>

Comme vous le voyez, nous faisons simplement pointer le nom de domaine msda.fr vers notre répertoire d’images. Pour éviter que vos images et vidéos ne soient accessibles via différentes urls, il ne faut pas oublier de mettre en place une redirection 301 de l’url de base vers le nouveau nom de domaine. Cela se fait via le fichier .htaccess qui se trouve à la racine de votre site, dans lequel on va mettre en place une règle d’url rewriting (réécriture d’url) assez basique :

RewriteEngine on
RewriteRule ^/?images/(.*)$ http://msda.fr/$1 [R=301,L]

Choisir un nom de domaine pertinent

Le nom de domaine de votre media server doit être le plus court possible, et ne jamais avoir été utilisé pour héberger un site. C’est la garantie que lorsque vos visiteurs afficheront un contenu via cette url, leur navigateur n’enverra aucun cookie inutile. Essayez de trouver un nom qui reprenne les initiales ou le nom partiel de votre site, et n’hésitez pas à y ajouter des chiffres si vous ne trouvez pas de domaine disponible.

Après avoir réservé votre nouveau nom de domaine chez votre registrar (environ 6€ par an) et configuré un dns secondaire, faites-le pointer vers les dns de votre serveur. Notez que sur les noms de domaines en .fr, il faut patienter quelques heures pour que le changement de dns soit possible.

Optimiser les performances votre Media serveur

Avant toute chose, il est important de s’assurer que les images et vidéos accessibles sur msda.fr ne le soient que d’une façon. Pour ce faire, nous allons créer un fichier .htaccess à la racine du dossier /images/, dans lequel nous vérifierons que l’accès se fait correctement (sans les www notamment). Ce fichier va également nous servir à indiquer au navigateur que nous souhaitons qu’il conserve les contenus en cache un maximum de temps :

# Gestion du cache
Header unset Pragma
FileETag None
Header unset ETag
<FilesMatch "\.*$">
Header set Cache-Control "max-age=60000000, public"
Header unset Cookie
RequestHeader unset Cookie
</FilesMatch>
# Sans les www
RewriteEngine on
RewriteBase /
RewriteCond %{HTTP_HOST} !^msda.fr$
RewriteRule (.*) http://msda.fr/$1 [R=301,L]

Et enfin, mettre en place un véritable cdn

Avant de passer à cette dernière étape, il est primordial de vérifier que ce qui a été fait avant fonctionne correctement. Et pour cela, il faut bien sur que vous ayez remplacé tous les appels de vos images et vidéos avec la nouvelle url msda.fr. On ne doit plus trouver de lien vers www.monsitedactu.fr/images/ dans vos pages. N’hésitez pas à effectuer une recherche dans votre base de données via phpMyAdmin, et à effectuer des REPLACE en masse (à manier avec précaution).

Pour créer notre cdn, nous allons utiliser le service proposé par CloudFlare, disponible en version payante mais aussi gratuite. Cette dernière suffira d’ailleurs largement pour l’utilisation que nous allons en faire. Pour créer un profil, commencez par renseigner l’url de votre media serveur, puis suivez les étapes jusqu’à ce qu’on vous demande de changer les dns de votre nom de domaine par ceux de CloudFlare. N’ayez crainte, cela fait partie de la procédure…

Ceci étant fait, il va se passer entre quelques minutes et quelques heures pour que le basculement soit effectif. Quand ce sera le cas, il faudra vous rendre dans les options « CloudFlare Settings » pour y effectuer quelques changements. Notre cdn n’hébergeant que des images et vidéos, vous allez désactiver toutes les options, et baisser le niveau de sécurité au minimum. Et… c’est tout ! Vous n’aurez plus qu’à profiter des joies de votre nouveau media server ;)

Des résultats sans appel et des perfs en hausse

J’ai créé ce guide après avoir mis en place ce système sur mon site Scooter System. J’ai donc pu mesurer concrètement la différence entre l’hypothèse de départ et celle de l’utilisation d’un media server. Plutôt que de vous bourrer le crâne avec des chiffres, je vous propose 3 graphiques (obtenus avec l’outil Munin) illustrant les statistiques du serveur. On voit une nette évolution le 22, alors que la fréquentation est restée la même…

Nombre de process Apache qui passe de 85 à 55 aux heures de pointe.

Cela se ressent sur le nombre de process total.

Trafic réseau en chute libre, les images étant chargées depuis le cdn.

Le gain en termes de réactivité se fait sentir sur les pages où sont présentes des images et vidéos, mais également sur toutes les autres. Car la diminution du nombre de process Apache soulage le processeur et la mémoire, qui sont plus disponibles pour générer les pages en php et effectuer les requêtes dans la base de données. Pour terminer sur les graphiques, voilà ce que cela donne du côté de CloudFlare après 24 heures…

Une petite économie côté requêtes http et bande passante ;)

Longtemps réservé aux images, fichiers javascript et autres css, le préchargement, ou « prefetching » en anglais, est maintenant disponible pour des pages complètes. Cette avancée, on la doit à html5 qui, grâce à une simple balise meta, ordonne au navigateur de charger une page à l’avance. Là où c’est formidable, c’est que ce dernier ne se contente pas de télécharger les éléments de la page, mais en réalise un pré-rendu. Du coup, lorsqu’un visiteur clique sur un lien vers cette page, l’affichage est instantané.

Si le prefetching offre une expérience utilisateur incomparable, il est important de choisir avec précaution les pages que vous allez pré-charger. Il convient d’en limiter le nombre (à 2-3 selon moi) pour ne pas surcharger votre serveur avec des requêtes http inutiles. J’ai énormément réfléchi à la meilleure façon d’utiliser cet outil, et l’ai finalement implémenté sur Scooter System dans 3 cas de figures :

• sur la page d’accueil du site, vers la dernière actualité publiée ;
• sur les principales rubriques du site, vers les pages de destination les plus populaires (liste récupérée dans Google Analytics) ;
• sur toutes les pages lorsqu’un visiteur arrive sur le site (détection du referer en php), vers la page d’accueil.

function prefetch($l){
if(false!==strpos($_SERVER['HTTP_USER_AGENT'],'Chrome/')){
return "\n".'<link rel="prerender" href="'.$l.'">';
} elseif(false!==strpos($_SERVER['HTTP_USER_AGENT'],'Firefox/')){
return "\n".'<link rel="prefetch" href="'.$l.'">';
}
}

Il suffit ensuite d’appeler votre fonction prefetch() dans le header de votre site ou blog autant de fois qu’il y a de pages à précharger, et elle renverra le code qui va bien. Notez qu’Internet Explorer, Opera et Safari ne gèrent pour le moment pas le pré-chargement, mais que cela viendra prochainement. Il vous suffira alors de modifer la fonction pour prendre en compte les évolutions. Voilà donc pour cette introduction à une nouveauté html5 pleine de promesses ! N’hésitez pas à publier un petit commentaire ci-dessous si cet article vous a intéressé !

Depuis quelques mois, les webmasters ont découvert que l’utilisation des boutons de partage social pouvait s’avérer bien plus intéressante qu’ils le pensaient. Non contents de permettre une diffusion rapide (de type virale) des contenus jugés intéressants ou pertinents, ces derniers constituent un signal d’appel pour les moteurs de recherche (Google pour le moment) qui utilisent les « votes » dans leur algorithme de classement. L’utilisation de ces gadgets ou widgets est ainsi devenue incontournable si on veut bien faire les choses.

Seulement avec la multiplication des services, c’est autant de scripts javascript qui viennent alourdir vos pages. J’ai donc cherché à réduire l’impact de l’utilisation des boutons de partage sur le temps de chargement des pages de Scooter System. Je me suis intéressé aux boutons Facebook J’aime, Tweeter et Google +1, les seuls qui soient vraiment pertinents pour un site 100% francophone. J’aurais pu intégrer également les boutons Wikio ou d’autres plus exotiques comme LinkedIn ou Viadeo, mais leur impact reste très limité…

Les différents services ont mis en ligne des générateurs de boutons permettant de personnaliser l’apparence, la langue ou le type d’appel du bouton. Javascript ou iframe, en synchrone ou asynchrone… Malheureusement , il n’existe aucune cohérence entre ces derniers, si bien qu’on finit par avoir un code lourd et indigeste. J’ai donc cherché à uniformiser le fonctionnement des services Facebook, Twitter et Google en appelant les javascript de façon asynchrone grâce à l’excellent Head.js, que je vous présentais il y a quelques mois.

L’intégration n’a pas été évidente mais j’ai réussi à faire fonctionner le tout comme il faut, sans qu’aucun bug ne soit à signaler, y compris sous les navigateurs les plus anciens. Tous les boutons sont configurés en français. Je vous livre ci-dessous les résultats de mes recherches, à adapter à votre site mais fonctionnel.

À insérer dans le header :

<script src="/path/to/head.js"></script>
<script>
window.___gcfg={lang:'fr'};
</script>
<script>
head.js("http://platform.twitter.com/widgets.js");
head.js("https://apis.google.com/js/plusone.js");
head.js("http://connect.facebook.net/fr_FR/all.js",function(){FB.init({appId:'APP_ID',status:false,cookie:true,xfbml:true});});
</script>

Ce code charge les 3 fichiers javascript en asynchrone, puis invite l’api Facebook à s’initialiser une fois le chargement effectué. Si vous utilisez Jquery ou Google Analytics, vous pouvez les chaîner dans la liste afin qu’ils soient eux aussi chargés en parallèle de la page (regardez le code source de Scooter System ou de la page sur laquelle vous vous trouvez pour plus de détails).

À insérer dans le corps à l’endroit des boutons :

<fb:like href="[votre_url]" send="false" layout="box_count" show_faces="false"></fb:like>
<a href="http://twitter.com/share" data-count="vertical" data-via="[votre_compte]" data-lang="fr">Tweeter</a>
<div class="g-plusone" data-size="tall" data-count="true" data-lang="fr" data-href="[votre_url]"></div>

Nous générons ici le code html qui sera utilisé par les 3 api pour afficher les boutons de partage. Les paramètres sont personnalisables facilement en consultant les aides fournies par Facebook, Twitter et Google. Les seules limites que j’ai rencontrées sont la non prise en charge du balisage de Facebook par html5 (code non valide W3C) et l’impossibilité de sélectionner la langue française pour le bouton Google +1 (solution trouvée et intégrée).

Voilà donc pour la petite astuce javascript du moment. Le tout permet un gain significatif en termes de temps de chargement des pages, et donc en confort de navigation. Vous n’aurez plus à choisir entre outils sociaux et confort pour vos visiteurs ;)

Les bandeaux de titres en relief inspirés par les marque-pages sont à la mode. Dans le cadre de la dernière refonte de Scooter System, j’ai eu l’occasion de travailler avec ce type d’éléments graphiques, et j’ai vraiment apprécié leurs qualités ergonomiques et esthétiques. C’est donc tout naturellement que dernièrement, dans le cadre de la refonte complète du site Techno Scoots, je me suis tourné vers eux. J’ai toutefois longuement réfléchi au meilleur moyen de les réaliser, l’objectif étant d’obtenir un code html et CSS le plus propre possible tout en limitant l’impact en termes de poids et de requêtes http.

Sur Scooter System, j’avais opté pour les sprites CSS qui répondent en partie à mes attentes, sauf au niveau du poids des éléments. Pour Techno Scoots, j’ai cherché à limiter les images et en suis arrivé à un constat : seuls les coins en triangles sont véritablement problématiques. Bien qu’il soit possible de les créer à partir de CSS3 (grâce aux sélecteurs :before, :after et à quelques rotate), j’ai préféré me tourner vers des images classiques, à savoir des png-24 transparents de 5×5 pixels. J’ai ensuite encodé ces petits fichiers en base64 afin de les intégrer directement dans le fichier CSS.

Le résultat répond à mes attentes en termes de poids (le fichier CSS est Gzipé par le serveur) et de requêtes http (aucun fichier externe n’est appelé). Après avoir appliqué un background-color (et en option un border-bottom) sur la zone centrale du bandeau, il me restait à trouver une solution pour intégrer proprement ces coins en dessous. Après plusieurs essais, j’ai finalement opté pour un positionnement absolu dans le div enfant. En utilisant les background multiples et en jouant sur les margin et padding, on arrive à un résultat identique sous tous les navigateurs récents, les plus anciens se contentant d’afficher un vide à la place des coins.

Voici le code CSS correspondant à mes travaux sur la colonne latérale (#aside) du site Techno Scoots, en 300 pixels de large :

#aside h2{
font-size:24px;
line-height:38px;
text-align:center;
width:310px;
height:38px;
margin:20px 0 0 -5px;
color:#fff;
text-shadow:1px 1px #8d0000;
background:#c90000;
}
#aside .child{
width:310px;
margin:0 0 0 -5px;
background:url(data:image/png;base64,codeenbase64) 0 0 no-repeat,url(data:image/png;base64,codeenbase64) 305px 0 no-repeat;
}

Suite à cet article publié par la Ferme du web, je me suis intéressé à une nouvelle librairie javascript baptisée Head.js. Encore très jeune comparée aux ténors que sont Mootools, Prototype ou Jquery, cette dernière propose un angle d’attaque différent. Elle a en effet un objectif simple : remplacer tous les appels de fichiers javascripts du header par un seul et unique script très léger (2.3 ko gzippé).

Une fois appelé, ce dernier va charger dynamiquement vos fichiers javascript, en parallèle de la page, comme s’il s’agissait de simples images. Pour autant, et c’est là toute la force de head.js, vos scripts développés sur la base de Jquery resteront entièrement opérationnels. Dès que les fichiers seront chargés par le navigateur (depuis le serveur, un cdn ou le cache du navigateur), vos scripts deviendront opérationnels, qu’ils soient appelés depuis les fichiers ou la page en elle-même.

Si ce changement n’est pas considéré comme une évolution positive par les Yslow et autres Page Speed (plug-ins Firefox), les résultats sont bien là côté performances. Les pages s’affichent beaucoup plus rapidement, avec un gain de 100% à 400% selon les sites et le nombre de fichiers javascript appelés. J’ai déployé head.js sur Scooter System hier, et ai constaté un gain de plusieurs centaines de millisecondes sur les temps de chargement.

Au delà de cette fonctionnalité extrêmement prometteuse, la librairie Head.js permet d’autres acrobaties fort pratiques : prise en charge des balises html5 sur les anciens navigateurs, création de classes permettant de cibler les visiteurs en fonction de leur navigateur ou de la résolution de leur écran directement depuis un fichier css… bref, de quoi simplifier le développement d’un site tout en améliorant significativement l’expérience utilisateur.

Je vous propose ci-dessous un exemple d’appel à Head.js dérivé de mes « travaux » sur Scooter System. Pour une efficacité maximale, ce dernier est à placer dans le header de la page (bien qu’il puisse également être appelé à la fin) :

<script src="http://static.monsite.com/js/head.js"></script>
<script>
head.js("http://static.monsite.com/js/jquery.js","http://static.monsite.com/js/jquery_perso.js");
</script>


Il s’agit de l’appel le plus simple, qui permet de charger une série de scripts les uns à la suite des autres. En l’occurrence ici, Jquery suivi de divers plug-ins et de mes scripts maison (regroupés dans un unique fichier). Simple à mettre en oeuvre, Head.js devrait faire parler de lui dans les prochains mois. S’il est pour le moment toujours en cours de développement (version 0.8.0), il a déjà été adopté par de nombreux sites plus ou moins importants.

Vous pouvez suivre les avancées de Head.js sur Github.

Dans le cadre de la refonte de Scooter System, je me suis intéressé de près à l’implémentation de polices d’écriture exotiques dans les pages web. Après avoir trouvé une première solution que je pensais idéale (@font-face CSS avec un .ttf + javascript Cufon), mes heures de recherches sur les sites et blogs spécialisés m’ont conduit vers une solution à la fois plus légère, plus simple et multi-plateformes.

La solution que j’ai finalement adoptée ne fait appel à aucun plugin ou librairie javascript et a l’avantage d’être interprétée directement par les navigateurs quels qu’ils soient : IE6, 7, 8 et 9, Firefox, Chrome, Opera, Safari et ses versions mobiles (pour iPhone et iPad). Elle repose sur un simple appel en CSS3 de la propriété @font-face, avec une subtilité qui fait que chaque navigateur va appeler un format de police qu’il sait interpréter :

• Internet Explorer : .eot (format propriétaire de Microsoft interprété depuis IE6) ;
• Firefox, Opera, Chrome et Safari : .ttf (format de police d’écriture TrueType tandard) ;
• Safari mobile : .svg (format basé sur une structure xml).

Pour générer les 3 formats de fichiers nécessaires, j’ai utilisé le Font-face Kit Generator de Squirell. Ce script extrêmement poussé permet de convertir un fichier de police .ttf ou .otf dans de multiples formats tout en maîtrisant le contenu du fichier (et donc son poids). Voici les options à sélectionner pour obtenir le résultat escompté (commencez par cocher la case « Expert… ») :

• Font formats : cochez TrueType, EOT et SVG ;
• Rendering : décochez tout ;
• Misc : cochez la case « WebOnly » ;
• Subsetting : cochez la case « Custom subsetting… » puis « Mac Roman » dans la liste qui apparaît. Vous allez ensuite pouvoir ajouter ou supprimer des caractères en fonction de vos besoins, la liste étant mise à jour en temps réel dans la partie basse. De cette façon, vous allez pouvoir diminuer la taille des fichiers de police générés en supprimant les caractères inutiles ;
• CSS formats : laissez « Bulletproof (Smiley) » ;
• CSS options : ne cochez rien ;
• Agreement : cochez la case pour accepter les conditions.

Une fois ce formulaire validé, vous allez télécharger une archive compressée contenant tous les éléments dont vous avez besoin. Reste à mettre vos fichiers .ttf, .eot et .svg sur votre serveur via ftp, puis à mettre à jour votre fichier CSS pour qu’il appelle les fichiers selon le navigateur. La seule solution qui fonctionne est celle donnée ci-dessous. Elle garantit que chaque navigateur ne téléchargera que le fichier dont il a besoin.

@font-face{font-family:"custom";
src:url("http://www.votresite.fr/fonts/custom_font.eot");
src:local("Nom original de la police"),
url("http://www.votresite.fr/fonts/custom_font.ttf") format("truetype"),
url("http://www.votresite.fr/fonts/custom_font.svg#custom") format("svg");}

Notez que dans l’appel du fichier .svg est présent un hashtag (#custom). Ce dernier fait référence à l’identifiant de la fonte présent dans le fichier .svg. Il est indispensable pour que la police d’écriture soit appelée. Vous pouvez le retrouver très facilement en ouvrant le fichier .svg avec un éditeur texte, et en récupérant l’ID contenu dans la ligne « <font id= »custom » horiz-adv-x= »*** » > ».

Maintenant, il ne vous reste plus qu’à utiliser votre police d’écriture « custom » où bon vous semble dans votre fichier CSS… Simple, efficace et garanti fonctionnel sous tous les navigateurs utilisés actuellement ;)

CSS3 débarque avec une propriété qui va réjouir graphistes et intégrateurs html : @font-face. Cette dernière permet d’appeler des polices d’écriture stockées sur un serveur dans une page en html sans nécessiter l’utilisation de plugins javascript ou de hacks. Malheureusement, elle n’est interprétée que par la dernière génération de navigateurs Webkit, à savoir Chrome et Safari. Firefox et les dernières versions d’Internet Explorer peuvent en profiter mais en utilisant des formats de fichiers de polices différents.

Alors que les navigateurs Webkit fonctionnent avec n’importe quel fichier avec l’extension .ttf, Firefox nécessite l’utilisation d’un fichier en .otf alors qu’Internet Explorer, toujours à la traîne, ne comprend que les fichiers au format propriétaire .eot. Comme le suggère Alsacréations, il est alors nécessaire d’utiliser les commentaires conditionnels pour obtenir un résultat potable sous tous les navigateurs. Une technique obsolète et pas facile à gérer dans le cadre d’un projet de développement complexe.

L’alternative la plus pertinente consiste à se tourner vers des systèmes tels que Cufon. À partir d’un classique fichier .ttf, l’outil permet de générer en ligne un code javascript qui sera interprété par le navigateur et affichera les polices stylisées dans tous les navigateurs. Le poids du fichier de police est certes doublé, mais le résultat est garanti 100% identique dans tous les navigateurs utilisés aujourd’hui, IE6 compris.

Pour un résultat optimal, Cufon peut être appelé de manière conditionnelle dans les navigateurs ne gérant pas la propriété @font-face. C’est la solution que j’ai choisie pour la nouvelle version de Scooter System, actuellement en cours de développement. Grâce au plugin FontAvailable pour Jquery (quelques lignes de javascript seulement), le navigateur détecte si la police est chargée ou pas et, le cas échéant, fait appel à Cufon pour la charger en javascript.

En intégrant l’ensemble des codes javascript nécessaires dans un unique fichier .js (Jquery + FontAvailable + Cufon + police pour Cufon), il est possible d’obtenir un fichier relativement léger, de l’ordre de 20ko avec compression Gzip. L’affichage sera instantané avec les derniers navigateurs, et un peu plus lent avec les autres. Pour rappel, voici le code à utiliser dans votre fichier CSS pour appeler une police via @font-face :

@font-face{
font-family:'custom';
src:url('http://www.votresite.com/polices/custom_font.ttf');
}

La police peut alors être utilisée dans votre fichier CSS via un simple appel par son nom :

.custom_font{
font-family:custom;
}


Source : http://dev.pockyworld.com/developpement/css/gestion-des-polices-exotiques-avec-css3-jquery-et-cufon.html

À cheval sur les recommandations de Google et de Yahoo que l’on peut obtenir facilement en utilisant des outils tels que Page Speed ou Yslow (2 plugins pour l’extension Firebug de Firefox), je suis régulièrement amené à faire des choix en matière de graphisme. Faut-il privilégier l’expérience utilisateur en intégrant (intelligemment) des icônes aidant à la compréhension de l’interface, ou bien est-il plus important de conserver des pages rapides à charger, avec un minimum de requêtes http ?

J’ai découvert aujourd’hui l’existence d’un algorithme de codage de l’information basé sur une table limitée à 64 caractères, le Base64. Une fois une image encodée à l’aide d’outils comme celui de Motobit, elle peut être intégrée simplement à tous types de fichiers dont le html, le xml et le CSS ! Au lieu d’afficher ces images depuis votre serveur, le navigateur les génèrera à partir du code Base64 contenu dans le fichier CSS. Cela permet de limiter le nombre de requêtes http, et donc d’accélérer le temps de chargement et d’affichage des pages.

Certains me diront que les images appelées via CSS sont mises en cache par le navigateur. C’est certain, mais le fichier CSS en lui-même l’est également… D’autres argumenteront en annonçant un poids supérieur de l’ordre de 150% entre un code en Base64 et une image équivalente. Certes, mais un fichier CSS peut être gzipé, ce qui n’est pas le cas d’une image. Pour convaincre ceux qui douteraient encore de l’intérêt de la chose, l’appel d’images en Base64 est instantané. Il peut remplacer les sprites pour gérer les changements de backgrounds en hover sans temps d’attente.

Appel d’une image en CSS classique :

.maclasse{
padding-left:20px;
background:url(icone.png) 0 0 no-repeat;
}

Appel d’une image avec Base64 :

.maclasse{
padding-left:20px;
background:url(data:image/png;base64,CODE64ASSEZLONG...) 0 0 no-repeat;
}

Du côté des faiblesses, on notera tout de même une non-compatibilité acec les navigateurs anciens comme IE6 et IE7, et la relative difficulté de mise à jour du graphisme si vous n’avez pas conservé une version non encodée des images utilisées. Au delà de ces limitations faciles à contourner, le couple CSS/Base64 m’apparaît comme une révolution à même de résoudre les « problèmes » de nombre de graphistes et webdesigners. La fin des sprites de 500 pixels carrés et des background-position à gogo est terminée (pour moi en tous cas) !

Le html5 inaugure une nouvelle balise <canvas> permettant d’intégrer des zones graphiques en 2 ou 3 dimensions dans le corps des pages. Pour le moment gérée par une poignée de navigateurs récents (dont Safari, Chrome, Opera et Firefox), elle laisse entrevoir de belles opportunités en termes de design et de graphisme. Il est en effet possible d’y « dessiner » en utilisant les nombreuses possibilités offertes par CSS3 : formes complexes, transparence, dégradés, calques….

En se substituant à des images simples, la balise html canvas (en dessin 2D) permet de limiter le nombre de requêtes http exécutées au chargement d’une page, et donc d’en accélérer la vitesse d’affichage. On peut imaginer que dans un futur proche, les logos de sites et autres éléments faisant partie intégrante de la charte graphique seront chargés dans des balises canvas, directement depuis le fichier CSS. On comprend pourquoi Google promeut la technologie !

Afin de tester les possibilités offertes par ce nouvel élément canvas, plusieurs graphistes et web-designers se sont amusés à créer des illustrations plus ou moins travaillées. On retrouve notamment des personnages et des logos de navigateurs web. Pour un début, certaines créations sont tout simplement bluffantes… Voici une liste des plus réussies d’entre elles :

• Dragon par Smashingmagazine ;
• Doraemon par ShopDD ;
• Homer Simpson par Roman Cortes ;
• iPod par AdmixWeb ;
• Logo IE par Andreas Jacob ;
• Logo Opera par David Dessndro…

Si ces dessins en canvas html5 et CSS3 sont pour le moment dessinés minutieusement (et longuement) par de talentueux graphistes, je suis prêt à parier que des logiciels voire des services web permettront prochainement d’en générer à partir d’images classiques ou en mode édition. Photoshop pourrait par exemple proposer un enregistrement dans ce format. Avec la montée en puissance des navigateurs « CSS3 compliant », la balise canvas a de beaux jours devant elle ! N’hésitez pas à proposer d’autres exemples sympas via les commentaires ;)