Référencer les applications RIA Flex et Silverlight
Pourquoi référencer une application dans les moteurs de recherche ?
Le référencement est une étape non négligeable du développement d'un site Internet. Ne pas référencer son application dans les moteurs de recherche revient à imprimer une plaquette publicitaire sans la distribuer. Si les moteurs de recherche savent parfaitement référencer un site HTML, qu'en est-il des applications RIA développées avec des technologies telles que Flex ou Silverlight ?
Pourquoi le référencement d'une application RIA pose-t-il problème ?
Les sites HTML standards répondent aux normes du consortium W3C. Il est ainsi facile pour les moteurs de recherche de parser et d'indexer les différentes pages d'un site en s'appuyant sur ces normes. Ces normes permettent également à votre navigateur de comprendre la façon dont il doit afficher la page HTML. Dans le cadre des applications RIA, le serveur envoi un fichier SWF (Flex) ou XAML (Silverlight) à votre navigateur qui doit utiliser des plugins pour interpréter ces fichiers. Les moteurs de recherche sont identiques à votre navigateur, ils ne savent pas encore comment bien indexer ces fichiers (bien que la spécification du format SWF soit publique depuis l'an dernier). Google et Yahoo! ne se contentent que d'indexer les textes statiques et suivre les liens hypertextes des SWF. Faites une simple recherche sur Google avec le mot-clé filetype:swf et vous observerez qu'il comprend le format du fichier et qu'il en indexe quelques textes, mais il faut avouer que cela est très pauvre. Faites la même recherche avec le mot-clé filetype:xaml et vous constaterez que Google ne comprend rien du tout. Précisons que le faible nombre de texte s'explique également par la manière dont est exécutée l'application, les données ne sont pas toujours présentes dans les fichiers SWF et XAML mais proviennent de services. Même si quelques textes sont récupérés des fichiers SWF, on ne peut modifier l'importance des mots clés. Tous les textes ont la même valeur contrairement à ce que l'on peut faire en HTML avec les balises titres (h1 à h6).
OK, mais ce problème est-il nouveau ?
La problématique du référencement des applications RIA n'est pas nouvelle, elle se posait déjà lorsque les applications Flash fleurissaient sur le net. A cette époque, le haut débit n'était pas très répandu. Le choix le plus répandu était de diviser le site en deux parties : un site Flash pour les connexions haut débit et un site HTML pour l'accès bas débit. Cette technique permettait d'être dans l'air du temps avec un site Flash tout en garantissant le référencement dans les moteurs de recherche avec la partie HTML.
Et les choses ont vraiment changé aujourd'hui pour le référencement d'une application Flex ?
Aujourd'hui les débits de connexion Internet ont évoluées ainsi que la technologie Flex qui permet de faire des applications riches permettant d'interagir avec des fichiers externes contrairement au Flash qui se résumait au fichier SWF. Comme il est impossible de réaliser un bon référencement sur ces fichiers, il faut orienter le référencement vers du contenu HTML alternatif et interdire le référencement des fichiers SWF en configurant le fichier robots.txt comme suit :
User-agent: *
Disallow: /monApplicationFlex.swf
Du contenu HTML alternatif ! Les méthodes n'ont donc pas évolué ?
Aujourd'hui, on ne construit plus un site alternatif complet mais on ajoute simplement du contenu HTML utile au référencement à la place de l'application Flex. La librairie JavaScript SWFObject permet de réaliser cette astuce simplement. Voici un exemple :
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Exemple d'utilisation de SWFObject</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<script type="text/javascript" src="swfobject.js"></script>
</head>
<body>
<div id="monContenuAlternatif">
<h1>Mon application Flex</h1>
<p>description de mon application</p>
</div>
<script type="text/javascript">
swfobject.embedSWF("monApplicationFlex.swf", "monContenuAlternatif", "800", "400", "9.0.0");
</script>
</body>
</html>
Avec cette méthode, les moteurs de recherche ne voient que le contenu HTML alternatif du bloc monContenuAlternatif car ils n'interprètent pas le JavaScript. Quant aux utilisateurs, ils voient l'application Flex monApplicationFlex.swf se charger à la place du contenu du bloc monContenuAlternatif s'ils possèdent le lecteur Flash. L'intérêt est que l'on peut produire du contenu HTML hiérarchisé. Ainsi lorsqu'un moteur de recherche référencera cet exemple, il donnera plus d'importance au titre "Mon application Flex" qu'au paragraphe "description de mon application". De la sorte, on peut optimiser à souhait le référencement de ce contenu alternatif et avoir un site respectant les standards du web. L'inconvénient de cette méthode est que les personnes ayant désactivé JavaScript mais possédant le lecteur Flash, ne verront pas se charger l'application Flex. Adobe revendique que 99% des internautes auraient le lecteur Flash d'installé tandis que le W3C rapporte un taux d'activation du JavaScript de seulement 95%.
Super mais je n'ai qu'un seul contenu alternatif dans ce cas, non ?
Au même titre qu'un site HTML classique, une URL correspond à un contenu, mais rien ne nous empèche que le contenu alternatif soit dynamiquement généré par le serveur. De la même manière, rien ne nous empèche de multiplier le nombre de pages HTML afin que l'application web soit accessible depuis plusieurs URL.
Mais ces différentes URL lanceront la même application Flex, alors pourquoi plusieurs pages ?
Tout d'abord, multiplier le nombre de page d'une application web est important pour le référencement. C'est autant de liens retour (backlinks) possible vers notre application, ce qui pourra la rendre plus populaire. En outre, les différentes URL lanceront la même application Flex mais son état peut dépendre de cette URL. Prenons l'exemple d'une application Flex répertoriant des livres. Il serait intéressant d'accéder directement aux livres d'un auteur depuis une URL. Par exemple, l'URL www.monsite.com/auteur/octo afficherait la liste des livres publiés par OCTO. Afin que l'application Flex fasse ce traitement, il suffit de récupérer ces informations de l'URL et de les transmettre à notre application en variable (FlashVars) :
<script type="text/javascript">
var url = window.location.toString(); // http://www.monsite.com/auteur/octo
var value = url.substr(url.indexOf(".com/", 0) + 5); // Pour ne garder que auteur/octo
var flashvars = {url : value};
swfobject.embedSWF("monApplicationFlex.swf", "monContenuAlternatif", "800", "400", "9.0.0", null, flashvars);
</script>
Dans cet exemple, notre application Flex récupère "auteur/octo" dans la variable url et sait qu'elle doit afficher les livres de l'auteur OCTO. On pourrait se dire que ce JavaScript est inutile car Flex gère le deep linking qui permet de bénéficier de tous les avantages de la navigation par URL. Pour cela, Flex s'appuie sur les fragments suivant les ancres symbolisés par le symbole #. Notre application Flex gèrait naturellement l'URL www.monsite.com#auteur/octo sans le JavaScript précédent. Le souci est que les fragments suivant les ancres ne sont pas référencés par les moteurs de recherche, ils ne référenceront pas l'URL www.monsite.com#auteur/octo mais l'URL www.monsite.com.
Intéressant, n'aurais-je pas pu récupérer ces informations dans ma page HTML au lieu de l'URL ?
C'est tout à fait envisageable si nos pages sont générées par le serveur, la variable FlashVars url aurait pu être directement valorisée à "auteur/octo" par celui-ci. En produisant du code xHTML, il est même possible de transmettre ce code dans une variable FlashVars à l'application Flex qui le parsera comme un simple fichier XML afin d'en exploiter les données. Voici un exemple étayant cette méthode :
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Exemple innerHTML</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<script type="text/javascript" src="swfobject.js"></script>
</head>
<body>
<div id="auteur">
<h1>OCTO</h1>
<ul>
<li>Gestion des Identités</li>
<li>Une Politique pour le Système d'Information</li>
</ul>
</div>
<script type="text/javascript">
var innerHTML = document.getElementById('auteur').innerHTML;
var flashvars = {auteur : innerHTML};
swfobject.embedSWF("monApplicationFlex.swf", "auteur", "800", "400", "9.0.0", null, flashvars);
</script>
</body>
</html>
Dans cet exemple, l'application Flex reçoit dans sa variable FlashVars auteur le contenu du bloc auteur. En parsant ce contenu XML, l'application Flex récupère le nom de l'auteur ainsi que sa liste de livres.
Très bien, je vois qu'il y a plusieurs possibilités pour les applications Flex, mais est-ce pareil pour les applications Silverlight ?
Dans son Kit de développement logiciel, Silverlight embarque un fichier JavaScript qui permet d'avoir le même comportement que SWFObject pour les applications Flex. Voici un simple exemple illustrant cette technique :
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Exemple d'utilisation de Silverlight</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<script type="text/javascript" src="Silverlight.js"></script>
</head>
<body>
<div id="monContenuAlternatif">
<h1>Mon application Flex</h1>
<p>description de mon application</p>
</div>
<script type="text/javascript">
var monContenuAlternatif = document.getElementById("monContenuAlternatif");
Silverlight.createObject("monApplicationSilverlight.xaml", monContenuAlternatif, "objectId", {width:'800', height:'400', minRuntimeVersion:'2.0'});
</script>
</body>
</html>
Les utilisateurs possédant le plugin Silverlight voient l'application à la place du contenu HTML alernatif que seuls les moteurs de recherche analyseront. Il en est de même avec l'utilisation de plusieurs URLs. Reprenons notre exemple de l'URL www.monsite.com/auteur/octo, nous allons récupérer les informations de cette URL et les transmettre à notre application en paramètre d'initialisation :
<script type="text/javascript">
var url = window.location.toString(); // http://www.monsite.com/auteur/octo
var value = url.substr(url.indexOf(".com/", 0) + 5); // Pour ne garder que auteur/octo
var param = "url=" + value;
Silverlight.createObject("monApplicationSilverlight.xaml", monContenuAlternatif, "objectId", {width:'800', height:'400', minRuntimeVersion:'2.0'}, null, param);
</script>
Par la même méthode, on pourrait facilement transmettre le contenu HTML alternatif en paramètre à notre application Silverlight afin d'exploiter son contenu.
Génial mais n'y a-t-il pas de techniques supplémentaires avec Silverlight ?
Il est existe une qui permet d'utiliser le fichier XAML de l'application Silverlight comme source du contenu HTML alternatif car le XAML est un document XML valide. L'utilisation d'un fichier XSLT permet de transformer les données intéressantes du XAML en contenu HTML. Regardons à travers un exemple afin de reproduire le contenu HTML de l'exemple innerHTML :
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Exemple XSLT avec Silverlight</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<script type="text/javascript" src="Silverlight.js"></script>
</head>
<body>
<asp :Xml ID="XHTML" runat="server" DocumentSource="monApplicationSilverlight.xaml" TransformSource="transform.xslt" EnableViewState="False"/>
<script type="text/javascript">
var auteur = document.getElementById("auteur");
Silverlight.createObject("monApplicationSilverlight.xaml", auteur, "objectId", {width:'800', height:'400', minRuntimeVersion:'2.0'});
</script>
</body>
</html>
<canvas xmlns="http://schemas.microsoft.com/client/2007" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<textblock x:Name="auteur" Text="OCTO" Foreground="Blue" FontFamily="Arial" Canvas.Top="50" Canvas.Left="50">
<linebreak />
<run Text="Gestion des Identités"/>
<linebreak />
<run Text="Une Politique pour le Système d'Information"/>
</textblock>
</canvas>
<xsl :stylesheet version="1.0" xmlns:sl="http://schemas.microsoft.com/client/2007" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" exclude-result-prefixes="sl">
<xsl :output omit-xml-declaration="yes" indent="yes"/>
</xsl><xsl :template match="/">
<xsl :apply-templates select="*"/>
</xsl>
<xsl :template match="sl:Canvas">
<xsl :apply-templates select="*"/>
</xsl>
<xsl :template match="sl:TextBlock">
<div id="auteur">
<h1><xsl :value-of select="@Text"/><xsl :value-of select="text()"/></h1>
<ul>
<xsl :apply-templates select="*"/>
</ul>
</div>
</xsl>
<xsl :template match="sl:Run">
<li><xsl :value-of select="@Text"/><xsl :value-of select="text()"/></li>
</xsl>
A l'exécution de notre page ASP.NET, la transformation du contenu de notre application Silverlight représenté par le fichier XAML sera réalisée par le fichier XSLT. Ce qui nous donnera le résultat suivant.
<div id="auteur">
<h1>OCTO</h1>
<ul>
<li>Gestion des Identités</li>
<li>Une Politique pour le Système d'Information</li>
</ul>
</div>
Serons nous toujours obligé de faire tout ça pour référencer nos applications RIA ?
Rien n'est sur pour l'instant mais les acteurs majeurs veulent améliorer la situation. Le 1er juillet 2008, Google, Yahoo et Adobe ont annoncé qu'ils collaboraient ensemble pour améliorer le référencement des fichiers SWF. L'ouverture de la spécification du format SWF est un pas dans cette direction. Dans l'avenir, Google, qui ne référence que les textes statiques et les liens hypertextes, souhaite pouvoir référencer les contenus dynamiques des SWF, référencer les images, comprendre le deep linking, agir sur les boutons des formulaires, etc. Nul doute que les algorithmes de référencement des applications Flex vont suivre le chemin parcouru par les sites HTML. Des bonnes pratiques d'optimisation pour les moteurs de recherche (SEO) pour les applications RIA naîtront au fil du temps.