Publié le mars 30th, 2010 | Par admin | classé dans E-marketing | Pas de commentaires »
Depuis que Google surveille le temps de chargement des sites pour l’inclure comme critère de référencement, nombreux responsables Marketing Internet regardent de plus près la réactivité de leurs sites. Si c’était auparavant surtout une problématique qui intéressait surtout les responsables techniques (pour des raisons de coûts), les enjeux marketing ne sont pas neutres…
Un site lent vous fait perdre de l’argent
Le choix de google est tout à fait logique : si le site passe du temps à charger, les visiteurs n’y resteront pas. Il est donc perçu comme un site de moindre qualité. Cela été vrai bien avant google et remarqué de nombreuses fois depuis :
- Amazon estime que 100ms de latence dans le chargement des pages leur fait perdre 1% de ventes.
- Shopzilla a montré qu’en diminuant de 5 secondes (!!) le temps de chargement de leurs pages, leur chiffre d’affaire augmentait de 10%, leurs pages vues de 25% et leur trafic en provenance de google de 120%
- Pour Bing, deux secondes de chargement superflues représentent 4,3% d’abandon et -1,8% de chiffre d’affaires.
- Google estime qu’une demi-seconde supplémentaire pour le chargement des pages de résultats fait abandonner 20% des visiteurs
L’évolution des débits et de l’accès à l’ADSL au niveau mondial a conduit à une inflation du chargement des pages. Alors qu’il y a quelques années, la règle était de limiter le poids des pages à 30Ko, nous arrivons maintenant à des pages qui peuvent dépasser 1Mo (hors vidéo). L’utilisation de CMS complexe avec des mécanismes de cache difficile à mettre en œuvre n’aide pas…
Un investissement technique léger pour de gros retours
En suivant quelques règles élémentaires (poids des images utilisés), des optimisations de codes et de serveur, on peut déjà diminuer de près de 60% le poids de pages, voire plus.
Pour moi, la référence reste ce que propose Yahoo en termes de bonnes pratiques pour avoir un site performant. Je vous conseille d’ailleurs vivement leur plugin YSLOW pour firebug, un outil de diagnostic essentiel pour savoir où on en est avec son site et ce que l’on peut améliorer (sans avoir besoin d’être soi-même un technicien).
Quand on pense que de nombreuses société investissent des dizaines de milliers d’euros dans de la génération de trafic alors que quelques miliers pourraient suffire à améliorer grandement leur résultats (amélioration du référencement, plus de visiteurs, meilleur taux de conversion… sans parler de la diminution des coûts d’hébergement liés à la consommation de bande passante)…
Et vous, avez-vous récemment optimisé le temps de chargement? Si oui, quels ont été les impacts?
Publié le mars 21st, 2010 | Par admin | classé dans Design | 2 commentaires »
Le choix des polices pour le web a toujours été très limité. Certaines technologies de remplacement ont été inventées, pour palier au problème d’alignement des différentes navigateurs sur un modèle standard de la gestion de la typographie… L’avenir s’annonce meilleur avec l’adoption du Module CSS3 Fonts… si l’histoire ne se répète pas!
Un attendant, un petit panorama des techniques envisageables pour gérer la typographie sur le web.
WebSafe
Il s’agit ici de choisir une police qui sera présent sur les ordinateurs de tous les visiteurs de votre site, qu’ils aient un PC, un MAC, un LINUX (et toutes les déclinaisons de distributions)… L’idéal étant de choisir une police présente sur toutes les plateformes, il est aussi possible de choisir une famille de police et de préciser une police de secours.
Bien que les technologies évoluent, le choix d’une police websafe pour la police principale de votre site reste toujours la meilleure façon de conserver l’intégrité du design de votre site, tout en garantissant une bonne interprétation par les moteurs et une bonne accessibilité. Certes, le choix est limité, mais certaines polices « standard » permettent de faire des choses très jolies.
sIfr
En combinant Javascript, DOM et conteneurs flash, Shaun Inman, Mike Davidson et Mark Wubben ont créé sIfr (pour Scalable Inman Flash Replacement). Cette technique, désormais disponible en version 3 permet tout simplement le remplacement des textes par du flash.
Au niveau du code, on retrouve le texte, donc pas de problème concernant le référencement (il s’agit d’une classe de style appliquée à un conteneur html).
Si l’on ne peut pas remplacer tout un texte avec cette technique, cela permet néanmoins à deux nombreux sites et blogs d’avoir des titres et sous-titres plus attractifs.
Avantages :
- Beaucoup plus de choix de polices qu’en web-safe
- Utilisation du flash, présent chez 97% des utilisateurs
- Possibilité de sélectionner le texte
Inconvénients :
- lenteur de chargement
- difficile à mettre en oeuvre
- difficultés à faire évoluer la police une fois mise en oeuvre (si vous voulez grossir le texte, en comparaisont avec un texte standard dont le format peut être changer rapidement dans les CSS).
- Attention aux notions de droits d’auteurs sur les polices.
FLIR
Flir permet de remplacer un texte par une image grâce à PHP et sa librairie GD. L’image contient donc le texte à afficher, dans la police souhaitée.
Avantage :
- Pas de problème de droits d’auteurs : le texte est contenu dans une image.
Inconvénients :
- Ne fonctionne qu’avec un site en PHP,
- Ne permet pas de sélectionner le texte.
Cufón et TypeFace.js
Cufon et TypeFace sont deux alternatives intéressantes à sIfr. Il s’agit là de convertir une police standard en un format spécifique qui permet de générer un texte de remplacement en CANVAS ou VML.
Avantages :
- Pas besoin de flash, s’affiche donc même si le plugin n’est pas activé,
- Plus léger et rapide que sIfr.
Inconvénients :
- l’impossibilité de sélectionner le texte,
- la lenteur sur Internet Explorer, dans certains cas,
- Attention aux notions de droits d’auteurs sur les polices.
Cufon a pris une longueur d’avance à Typeface grâce à la compatibilité avec IE8, 2Ko de moins au niveau du poids du script, le support d’un plus grand type de police (TTF, OTF, Postcript, PFB là où Typeface ne gère pour l’instant que le TTF). Cependant, TypeFace permet de gérer quelques attributs CSS complémentaires. A vous de choisir, ma préférence allant à Cufon.
@font-face
C’est l’avenir et le présent… Cette technique permettant d’appeler directement une police sur un serveur est déjà fonctionnelle sur Safari, Firefox, Opera, Chrome. Pour Internet Explorer, c’est à nouveau une autre histoire: Microsoft l’implémente pour un format de police bien spécifique (EOT).
Tant que Microsoft ne permettra pas d’utiliser d’autres types de polices, il faudra une fois encore adopter une mise en forme spécifique IE (et convertir une police TTF en EOT).
Avantages :
- Intégration directe des polices
- Facile à intégrer pour tout un site
- Assez rapide
Inconvénients :
- Mauvaise prise en charge par Internet Explorer
- Attention aux droits d’auteurs.
TYPEKIT: un service pour intégrer des polices légalement
TypeKit est un service en ligne payant (ou gratuit pour l’essai) qui permet de choisir parmi un grand nombre de polices (près de 500) et de les appeler par la technique @font-face. L’abonnement mensuel que vous payez (à partir de $25 / an) vous permet d’utiliser jusqu’à 5 polices différentes sur votre site, en total respect de la loi. Les polices sont hébergées sur le serveur de TYPEKIT.
Voici donc un petit tour d’horizon… Le design du blog n’est pas encore retravaillé (vive le thème de base, génial pour se concentrer sur le fond et non la forme), mais je pense utiliser @font-face et/ou Cufon. Et vous, qu’utilisez-vous pour vos sites?
Publié le mars 16th, 2010 | Par admin | classé dans Wordpress | 1 commentaire »
J’ai rencontré un problème d’erreur 500 ce soir en administrant mon blog. Cela vient du fait que mon hébergeur (1and1) gère mal le PHP5, sur lequel tourne wordpress depuis la version 2.7.
En effet, dans le panneau de configuration de l’hébergeur, on peut lire PHP5, mais une analyze via Firebug, onglet réseau montre qu’il s’agit en fait de PHP4…
Une simple modification du HT ACCESS à la racine du site suffit à modifier cela. C’est aussi valable pour d’autres hébergeurs (free, OVH). Je tenais juste à faire un lien pour apporter ma contribution à la popularité de cette page!
Publié le mars 9th, 2010 | Par admin | classé dans Design | Pas de commentaires »
En lisant un bouquin de webdesign compilé par Rob Ford (le créateur des Favourite Website Awards), je me suis aperçu que le flash était omniprésent dans les exemples… Ce livre (et le site de l’auteur), que ne cible que les designers web, ne présente quasiment que des exemples de sites en flash.
Je n’irais pas jusqu’à tenir les propos de Steve Jobs sur la technologie d’Adobe, mais je n’aime pas les sites en flash.
Bien que la technologie flash ait quelques avantages (animations, démonstrations interactives, navigations immersive), son utilisation doit à mon sens rester limitée à quelques cas… et surtout pas à l’intégralité d’un site.
Pour étayer mon point de vue, volontairement polémique, voici quelques raisons.
1. Où est mon clic droit?
Quoi de plus énervant dans un site tout flash, de ne pas pouvoir ouvrir un lien dans une autre fenêtre? Vous me direz, en matière d’ergonomie, il vaudrait mieux annoncer au client si le lien doit s’ouvrir ou non dans une nouvelle fenêtre. Mais quand l’utilisateur souhaite ouvrir un lien pour continuer sa lecture principale, comment fait-il?
2. Respect des standards et évolution
Un site conçu avec le respects des standards (séparation fond/forme) peut évoluer facilement au niveau graphique sans avoir à remanier lourdement le contenu. Sur flash, même si la définition de styles permet une réutilisation simple des mises en forme, les modifications sont beaucoup plus lourdes à mettre en oeuvre.
3. Référencement limité
OK, cela s’améliore… Flash est de mieux en mieux pris en compte par les moteurs et l’indexation est de plus en plus profonde. C’est d’autant plus vrai lorsque l’on mélange texte de remplacement et flash. Mais au final, un texte en mode « html » reste toujours mieux indéxé.
4. Gestion de contenu compliquée
Là encore, il existe certaines iniatives de CMS en flash, cela reste assez complexe à mettre en oeuvre et très propriétaire.
5. Temps de chargement
Il est OK d’attendre qu’une page charge lorsque l’on a demandé à voir une vidéo ou une démonstration spécifique. Attendre plusieurs secondes pour que du flash se charge au démarrage d’un site, c’est déjà beaucoup plus pénible (et je ne parle même pas des introductions de site en flash sans intérêt réel pour le visiteur).
6. Mise à jour de plugin
« Vous devez avoir le plugin flash installé pour utiliser… » C’est frustrant, n’est-ce pas? Les mises à jour ne sont pas forcément très nombreuses, mais lorsque l’on consulte un site proposant du flash « dernière version », le processus de mise à jour casse le flux d’information (on est dérouté vers le site d’Adobe et il n’est pas toujours évident de retourner sur le site que l’on consultait).
7. Firewalls
Ceux qui travaillent dans une entreprise ayant une politique de sécurité restrictive de ses réseaux informatiques auront constaté que certains contenus flashs ne se chargent pas…
8. Accessibilité extrêmement limitée.
Une pensée pour un ancien collègue pour qui l’accessibilité était un must-have… Dans de nombreux pays, c’est une obligation légales. Dans la plupart des cas, c’est un simple respect pour la personne qui vous lit votre site. Cette dernière peut en effet être aveugle (ou avoir d’autres problème de vision ou de mobilité) et peut faire appel à des logiciel de lecture. Ces logiciels ne prennent pas en compte le contenu flash (de ce que j’en sais à ce jour). D’autre part, il est souvent impossible de naviguer dans un site en flash à l’aide du clavier (passer au lien suivant avec la touche tabulation).
Alors les flasheurs (et les autres), qu’en dites-vous?
Pour finir, un peu de lecture sur le sujet: