Quel est le débit moyen en France

À quelle vitesse s’affiche un site ? La question est importante tant le confort d’utilisation et les revenus d’un site peuvent dépendre de cette réponse. Vous intégrez probablement déjà des pratiques visant à améliorer le rendu des pages et leur réactivité, et si vous êtes en phase d’industrialisation, vous faites peut-être du monitoring de la performance. Au moment de paramétrer votre solution, une question a dû vous poser problème : quelle est la connexion type en France ? Et pour les mobiles ?

Nous allons non seulement répondre à ces deux questions, mais en plus nous apercevoir qu’il y a une question plus pertinente à se poser.

Pourquoi et comment calibrer ses test ?

Les solutions de monitoring du marché testent les pages généralement sans vous dire avec quel navigateur (probablement des Webkit headless, pour accélérer les tests), et le font depuis des datacenters qui sont beaucoup trop proches des nœuds principaux du Web. Potentiellement, les sondes sont exécutées à partir de machines hébergées physiquement dans le même datacenter que votre hébergeur ou avec un peering privilégié avec le CDN.

Autant dire que les tests standard ne sont pas représentatifs de ce qu’endurent vos utilisateurs et c’est la raison pour laquelle on limite volontairement débit et latence, par exemple sur l’indispensable WebPageTest ou chez certaines solutions payantes. WebPageTest a le mérite d’être transparent car vous avez une liste de connexions pré-paramétrées cependant nous allons voir qu’elles ne représentent pas du tout la France.

Paramètres par défaut de WebPageTest.org

Côté transit réseau, il y a essentiellement 4 données qui influencent l’affichage d’un site :

  • la latence ou ping, qui est le temps d’un aller / retour entre un navigateur et le serveur qui lui répond. Pour le site moyen, en HTTP 1.1, basé sur TCP, c’est la mesure la plus importante. C’est aussi la plus difficile à obtenir.
  • le download ou bande passante descendante, qui reste importante pour récupérer de gros objets. On nous vend des ADSL à plus de 20Mb/s (1, 2, 3 et des mobiles à 5Mb/s, qu’en est il vraiment ?
  • l’upload qui est rarement pertinent dans la webperf.
  • la perte de paquets : pratiquement inexistante sur des connexion filaires, mais omniprésent sur mobile. Là par contre impossible de trouver des chiffres, en supposant qu’ils signifient quelque chose

Idéalement, il faudrait récupérer ces métriques de vos propres utilisateurs, grâce à du Real User Monitoring (RUM), mais la mise en œuvre est moins aisée que de récupérer les informations de sources externes, telle que nous allons le faire ici.

Si vous êtes pressé ou si vous me faîtes aveuglément confiance (et je vous comprends), vous pouvez sauter directement à « En résumé »

à la pêche aux chiffres

En cherchant dans mes archives et sur Google, je me suis rendu compte qu’il existait très peu de rapports rendus publics. J’en liste ici 6 en extrayant des données brutes. N’hésitez pas à m’en indiquer d’autres ou à décortiquer plus avant les sources.

Etude Akamai / Pingdom de 2010

Akamai est le leader mondial des CDNs, autant dire qu’ils voient passer du traffic et ont une bonne idée de ce qui se fait à l’échelle mondiale. L’étude de cette année là comprend la répartition des débits en France.

  • Débit moyen : 3,3 Mb/s
  • Répartition :
    • 25 % moins de 2 Mb/s
    • 60 % entre 2 et 5 Mb/s
    • 15 % plus de 5 Mb/s

Akamai 2012

Chiffres plus récents, mais dont l’échelle de répartition a changé.

  • Débit moyen : 4,6Mb/s
  • Débit moyen des réseaux mobiles : 2,8Mb/s
  • Répartition :
    • 0,1% moins de 256Kb/s
    • 45% plus de 4Mb/s
    • 4% plus de 10Mb/s

DegroupTest, 2012 et 2011

La population des utilisateurs de Degrouptest est probablement biaisée, car on a affaire à des gens qui au minimum s’inquiètent de leur débit. Ce qui exclut ma mère et probablement la votre. Mais ils ont l’avantage de mesurer le ping, et d’isoler les extrêmes comme la fibre, le mobile et l’outre-Mer.

  • Débit moyen : 8,27 Mb/s (5,4Mb/s hors fibre )
  • Débit moyen des réseaux mobiles : 2.5Mbps (chiffres 2011)
  • Ping moyen : 80ms (86ms hors fibre)
  • Ping moyen réseaux mobiles : 200ms
  • Débit montant moyen : 1,3 Mb/s ( 641Kbp/s hors fibre)
  • Répartition :
    • 13% à 27Mb/s de débit moyen
    • 87% à 5,4Mb/s
  • à noter :
    • Meilleur latence possible : Fibre Orange avec 19ms. Les opérateurs ADSL se situent entre 70ms (Free) et 100ms (SFR)
    • 1s-1.5s de latence sur satellite
    • 270ms de latence depuis l’outre-mer, 3Mbps de débit moyen

A noter que le débit et la latence moyenne ont baissé entre 2011 et 2012. J’imagine que leur public a du s’élargir à des zones moins bien couvertes.

60 millions de consommateurs, 2012

Leur testeur de débit a tourné pendant 1 an en 2011 et leur public est probablement plus proche du français moyen que DegroupTest. En plus on y quantifie les variations périodiques de débit.

  • Débit moyen : 5.6Mb/s
  • Répartition :
    • 11.8% moins de 1Mb/s
    • 12.8% de 1 à 2Mb/s
    • 31,8% de 2 à 5Mb/s
    • 30% de 5 à 10Mb/s
    • 12% plus de 10Mb/s
  • A noter :
    • -20% de débit à 21h
    • -10% le dimanche

Etude ARCEP

De cette étude sur les chiffres d’affaire des FAI et opérateurs mobile, j’ai extrait les volumes de population pour confirmer ou requalifier les chiffres des autres :

  • 22 millions d’abonnements ADSL et fibre
  • 0,6 million d’abonnement fibre / cable
  • 0,3 million abonnés RTC
  • 32 millions d’abonnés mobile « data »
  • +80% de volume de data mobile par an

Statistiques Cedexis

Les statistiques de “l’aiguilleur du net” mesurent le temps d’aller-retour moyen entre un utilisateur de FAI et un CDN afin de choisir le meilleur. Les valeurs de latence y sont plus hautes qu’ailleurs car les CDN ne font pas que servir des fichiers statiques, il y a beaucoup d’intelligence lorsqu’une requête arrive chez eux. Je les prends car elles donnent une bonne idée de la vitesse avec laquelle les fichiers arrivent chez l’internaute qui visite des sites utilisant les CDN.

  • 118 ms de latence pour des fichiers hébergés sur Akamai (leader)
  • 134 ms de latence pour des fichiers sur Amazon EC2 Europe

Après les chiffres bruts, passons à l’analyse.

Quelle analyse ?

Il faut bien se dire que l’on compare des études avec des buts différents : mesurer l’efficacité des CDNs, des FAI ou avoir un vision plus globale oriente les méthodologies. C’est pour cela que j’explicite ma réfléxion, pour que vous utilisiez les commentaires pour critiquer ma tentative de compréhension.

Le débit moyen

Les statistiques d’abonnement de l’ARCEP montrent 2,7% d’abonnés fibres par rapport au nombre total d’abonnement, alors que Degrouptest reçoit 13% de ses mesures depuis la fibre. Nous pouvons donc requalifier le débit moyen de Degrouptest : 5,01Mb/s (97,3 % * 5,4 Mb/s + 2,7 % * 27,3 Mb/s = 5,01 Mb/s).
Cette nouvelle moyenne se situe entre celle d’Akamai pour la France (4,6 Mb/s), et celle de 60 millions de consommateurs (5,6 Mb/s). Akamai ne détaille pas sa méthode mais on suppose qu’elle est plus représentative, car non volontaire. Elle ne mesure cependant que la connexion entre Akamai et un internaute et Cedexis nous indique qu’Akamai n’est pas le plus performant. Il faudrait donc légèrement remonter ce chiffre. D’un autre côté, 60 millions de consommateurs a fait son étude en 2011, et entre-temps DegroupTest semble indiquer une baisse de débit ADSL de 600 Ko/s. Il faudrait donc revoir leur moyenne à la baisse. Les chiffres convergent vers la valeur DegroupTest, que j’estime légèrement surestimée (population trop “aware”).

Pour arrondir, on peut donc situer un débit moyen à 4,8Mb/s sur ligne fixe. Concernant le débit mobile moyen, Akamai et Degrouptest ont à 30Kb/s près la même moyenne, on peut l’arrondir à fixer à 2,5Mb/s.

La latence

On applique la correction des stats ARCEP sur les stats DegroupTest et on obtient cette valeur arrondie : 85ms. Cependant en regardant les données Cedexis, on voit des temps de réponse bien supérieurs, de 110ms par exemple pour récupérer un statique sur un CDN populaire comme Akamai. Cela est assez cohérent avec le fait qu’un CDN rajoute forcément un peu de latence (temps de routage supplémentaire, mise en cache, etc.) et que la population Degrouptest est surement un peu moins représentative que celle mesurée par Cedexis.

Concernant le ping sur mobile, on manque cruellement de données, la seule qu’on ait trouvé pour la France est celle de Degrouptest de 200ms. Dans des études bien moins larges dans d’autres pays, les chiffres varient de 200ms à 300ms.

Pour la latence, nous nous fixons donc une moyenne arrondie de 95ms sur ligne fixe et 200ms sur mobile.

Le cas du mobile

Donc le débit moyen sur réseau mobile (2,5Mb/s) est plus élevé que 25% des ADSL de France. La latence est tout de même deux à trois fois plus élevée. Mais même en calibrant vos tests avec ces données et en supposant que vous les exécutiez depuis un vrai mobile, vous réalisez vite que quelque chose cloche : le ressenti utilisateur n’est pas du tout le même. En fait il manque une dernière composante, assez rare en ADSL : la perte de paquets TCP. Constamment les connexions ouvertes entre votre téléphone et l’antenne relai sont interrompues par des obstacles physiques, électro-magnétiques ou un changement d’antenne. Je n’ai pas trouvé d’étude avec un taux moyen de perte de paquet, aussi c’est un peu au pifomètre que j’utilise la valeur 25%. à débattre.
Il manque également le côté aléatoire de la connexion qui fait tout le charme des réseaux mobiles : parfois vous téléchargez une image en une demie seconde, parfois vous n’arrivez pas à avoir un octet pendant plusieurs minutes.
Exécutez régulièrement les applications speedtest ou Degroupest (iOS, Android) pour halluciner sur la variabilité des caractéristiques réseau.

Test débit mobile

Sur quelques tests ci-dessus, sur 2 tests effectués à moins d’une minute d’intervalle et sans bouger, vous pouvez voir une différence de latence de 1 à 4. Vous pouvez également voir des tests qui vont de 14Kb/s à 9Mb/s, sans compter ceux qui n’aboutissent pas.

Mais non seulement il n’existe pas d’étude sur les trous réseau (en supposant qu’une telle étude puisse être représentative), mais en plus nous ne voulons pas introduire d’aléa dans le cadre du monitoring, ou alors comment savoir si une alerte en est vraiment une ? Nous devons malheureusement choisir des mesures dégradées mais fixes.

En résumé

Les connexions moyennes françaises en 2012
Lignes Fixes Réseau mobile
Débit descendant 4,8Mb/s 2,5Mb/s
Latence 95ms 200ms
(+25% de perte de paquets)

Il n’y a pas de connexion type

Mon prof de stats me tirerait les oreilles si on s’arrêtait là. En effet une moyenne seule est à peu près inutile sans l’écart-type qui permet de juger de la représentativité de cette moyenne. En fait une moyenne est certes pratique à manipuler, et il est utile de surveiller son évolution, mais elle est particulièrement trompeuse si la répartition des mesures n’est pas concentrée autour de la moyenne.
Et justement les études d’Akamai, de l’ARCEP et de 60 millions de consommateurs montrent qu’il y a de fortes disparités dans l’équipement des utilisateurs.

  • L’ARCEP nous dit qu’il reste 1,4% de gens en RTC (56Kb/s), soit à l’échelle de la France 300 000 personnes. Dur de savoir si c’est leur unique moyen d’accéder au Web, mais c’est un débit 500 fois inférieur aux mobiles ! Akamai signale également un faible taux de débit inférieurs à 256Kb/s
  • DegroupTest nous avertit sur le fait que depuis la France d’outre-mer, on a du 250ms de ping en moyenne, l’équivalent du mobile, et un débit 40% inférieur à la métropole
  • 60 millions de consommateurs et Akamai montrent que 50% des utilisateurs ont moins de 5Mb/s, avec une répartition qui a l’air à peu près égale par tranche de 1Mb/s : 10% ont moins de 1Mb/s, 20% moins de 2Mb/s, etc.
  • les tuyaux du Web français sont embouteillés le soir, avec une perte de 20% de débit entre 21h et 22h.

Il n’y a pas d’ADSL type en France

Nous nous sommes donc posés la mauvaise question : calibrer vos tests sur LA moyenne française est à peine moins trompeur que de mesurer depuis votre poste avec votre navigateur récent, sur votre réseau d’entreprise branché à la fibre (oui tout le monde le fait, et c’est MAL).

Enfin : quelle stratégie de test ?

Tous ces chiffres vont nous permettre de définir une vraie stratégie de test de la performance perçue. Cela commence par définir des objectifs de réactivité raisonnables en terme de confort d’utilisation, par exemple :

  • afficher quelque chose avant 1 seconde (start render)
  • promesse / fonction principale de la page affichée avant 2 secondes
  • fonction principale interactive avant 5 secondes

Note : les valeurs que j’indique ici sont un peu génériques, et sont à définir entre les équipes “produit” (marketing, ergonomie) et les équipes techniques (développeurs, sysadmins).
Vous devez maintenant être cruel et déterminer quelle proportion d’utilisateurs n’aura pas droit à cette rapidité. C’est un peu rude dit comme ça, mais une page rapide pour “tout le monde” coûte très cher. Généralement on vise à satisfaire par exemple 80 % de la population.

Voici un petit tableau qui devrait vous aider à prendre vos décisions :

Calibrage des tests pour ligne fixe
Un débit de X Mb/s et une latence de Y ms laissent de côté Z % des visiteurs
5.0Mb/s 95ms 50%
4.0Mb/s 100ms 40%
3.0Mb/s 110ms 30%
2.0Mb/s 120ms 20%

Remarques :

  • Les débits et pourcentages semblent joliment arrondis. C’est de la chance.
  • Pour le ping, on n’a aucune stat sur la répartition réelle, ce sont donc des suppositions personnelles que je vous invite à critiquer

Pour le réseau mobile, on est bien embêté car on n’a aucune idée de la répartition ! On sait juste qu’elle est très volatile, ne serait-ce que pour le même utilisateur. Donc, soit on joue ça au doigt mouillé avec la certitude de se tromper, soit on utilise la moyenne qui est pratiquement un mensonge. Mmmm. Choix cornélien mais, à choisir, autant partir sur une valeur un tout petit peu objective, c’est-à-dire la moyenne constatée, et y rajouter de la perte de paquets.

Je mettrais donc ces 3 valeurs par ordre de priorité :

  1. 3,0Mb/s avec une latence de 110ms pour représenter 70% de vos utilisateurs
  2. 2,5Mb/s avec une latence de 200ms et une perte de paquets de 25% pour l’ensemble des utilisateurs de réseau mobile
  3. 4,80Mb/s avec une latence de 95ms pour « la moyenne » des connexion filaires

La moyenne reste là surtout parce que c’est un chiffre que tout le monde (croit) comprendre et pour comparer mobile et bureau.

Si vous avez une population particulière (outre-mer, visiteurs à 21 h, habitant une grande ville, professionnelle, très mobile, etc.), il va vous falloir fouiller dans les chiffres ci-dessus pour trouver ce qui se rapproche le plus de vos utilisateurs. Ou, bien sûr, monter votre propre monitoring des capacités de vos utilisateurs.

Résultats

Pour conclure, comparons les valeurs DSL par défaut de WebPageTest.org avec celles que nous avons déterminées pour représenter 70 % des français. J’ai lancé un test sur un site moyennement complexe, qui n’a pas (encore) été optimisé et qui fait partie des sites à forte audience de France : Pluzz.fr.

Comparaison valeurs par défaut et personnalisées

Pour plus de détails, voir le détail du déroulé. Avec les valeurs par défaut, ce site s’affiche en moins d’une seconde, donnant l’impression que l’optimisation n’est pas nécessaire. Avec nos valeurs plus réalistes prenant en compte 70 % de la population, le start render se situe à 1,4 seconde, confirmant le besoin d’entamer des travaux si l’on veut atteindre les objectifs de performance perçue.

Performance web mobile, chargement de page 2/2

Reprioriser les optimisations

On l’a vu dans le premier article, certaines techniques pourtant reconnues peuvent devenir contre-productives si l’on ne fait pas les tests nécessaires. Ne jetons cependant pas tout aux orties, voici les techniques que vous devrez maîtriser plus que jamais et pousser dans leurs extrêmes si vous voulez obtenir un résultat correct sur mobile ; par ordre de priorité :

1. Travailler le chemin critique

La notion de performance est plus un ressenti qu’une collection de chiffres. Lorsque vous devez retravailler une page pour un réseau mobile, demandez-vous ce que l’utilisateur est vraiment venu voir et dégagez le passage pour afficher au plus vite la zone ou la rendre fonctionnelle :

  • pas (trop) de redirections, et surtout pas côté client ;
  • concaténation ou mise en ligne des CSS ;
  • un code HTML / CSS prêt à « marcher » sans JavaScript : pour un article, c’est facile, on affiche le texte (sans police de caractère, jamais) ; pour une vidéo, on peut utiliser HTML5 comme interface de lecture en attendant JavaScript. Si vous dépendez de JavaScript pour afficher la fonctionalité (un webmail par exemple), affichez au moins un indicateur de chargement ;
  • scripts asynchrones comme vu dans le premier article ;
  • JavaScript chargé et exécuté par ordre de priorité : on peut très bien imaginer de charger d’abord les fichiers JavaScript concaténés qui concernent la zone principale, puis un second pack de fichiers qui concernerait tout le reste de la page.

2. Minimiser le nombre de requêtes HTTP

On l’a vu lors de l’exemple du domain-sharding, la première limite vient du réseau : le même mobile sur la même session de surf pourra passer d’un WiFi de bonne qualité à une absence complète de réseau. Vous ne pouvez jamais prévoir quand la latence va s’allonger jusqu’au timeout ou quand le débit passera en dessous de ce dont vous auriez besoin pour afficher une simple image. En supposant que vous serviez votre site classique sur mobile (1 Mo, 100 requêtes, 15 domaines… source http archive), il va falloir faire baisser de manière drastique le nombre de requêtes pour minimiser les effets de latence ou de timeout et maximiser l’utilisation de la bande passante. Cet objectif est là pour durer et la plupart des techniques classiques utilisées jusqu’ici sont non seulement à investiguer, mais à pousser dans leurs extrêmes.

La concaténation

Il est plus que jamais temps de faire de vos CSS et JS des fichiers uniques ou presque. De base dans Ruby on Rails, avec des plugins divers pour Spip ou Drupal, avec Assetic pour Zend 2, des dizaines de librairies pour d’autres projets PHP, avec SASS côté CSS et des outils comme YUI Compressor.
Il n’y a plus vraiment d’excuses pour ne pas gérer correctement vos JS et CSS, sauf peut être le coût de refactoring initial, mais il reste généralement négligeable par rapport aux bénéfices attendus.

À noter que les stratégies de concaténation vont varier en fonction de la taille de votre site : si il est relativement petit, mettez tous vos CSS dans une seule feuille ; si il est plus grand, mettez le CSS commun dans une première feuille et les CSS de chaque type de page dans une autre. Ne dépassez jamais 2 feuilles par page. En JavaScript, les stratégies sont plus variées du moment que vous utilisez l’asynchrone : un fichier unique pour tout le site si il est petit, un fichier par zone fonctionnelle sinon (avec chargement asynchrone).

Les images

Les images sont généralement petites et nombreuses, c’est donc votre seconde cible après le CSS. Vous avez forcément déjà entendu parler du spriting ; sur mobile, vous pouvez aller encore plus loin avec les caractères unicode : lorsque vous avez beaucoup d’icônes, essayez de voir si vous pouvez en réutiliser (♻) qui viendraient directement des polices du système !
Attention à la compatibilité navigateur ET système d’exploitation. Pour les mobiles, c’est généralement bon ; pour IE sur XP, vous n’aurez qu’un choix limité.

Encodage des images : visez le zéro requête en encodant vos images en texte directement dans le CSS, voire dans le HTML. C’est un peu fastidieux à faire à la main mais un simple script PHP suffit :

print '<img src="data:image/png;base64,'.base64_encode(file_get_contents('/path/to/image.png')).'" />';

Qui vous donnera en sortie quelque chose de ce genre :


<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAABO1BMVEX92RlCQj+7vLzvzSzmhgnXgybyz3uLj5T13mj99cDwrmWMfzXmyTz78bT1zUf++uX437bxzqzmpj/dlDdcVUbuxnjszDLq6uvqmS/43Hv99t+foaOMgl5tYDjsu1vfwT388NijlXr52Vn22Y3999Z2bmD34svhrFlQTD378ajuwWXThzH668PpsFbvw5zrtU2Vh03x0Y3MzMz73kr664qZmZnmnUblqm/7w1HokRbefBb//e324HL2z0TsuENYRC399s/343z46paYijr88s/z1KXvyIvspkzroTj81yL56cnajjLwxm9KSkLmqj1gVj+Xg2H3vkv+/tz35XL+3CD89cj45Lf88MSipab13FnvtGP224T45Yb78rr++uv3zij25Grz1Ub1yi7wxFztu2vYiTH95kfqs2v45csXvxkaAAAAAXRSTlMAQObYZgAAAMlJREFUaN5jYAACY0llQzafZFsGCAiJDvNSkJJSEEjR9wQLROvw86s4OISqxLkJgfhKYfz8/NZA4MBrnW4HFGBzkZKKAwlIxWpmCAMFRKVCQ1VUXFzCY52CpVKBAlpeKo4xUVFR7jGRJmreQAE+N2sbCRsbDhuWxCBzP5Cpcq5BHjYJCTaWnIKsYHs9dV25bIDAXY81CeIyT3WzwLQ0CyvteKhTGcQCFJ25Ve2ZGeBAJiLClN0fwWcwYBI3kpZFEuAR8WXUkGfACgC55CKssDjPhQAAAABJRU5ErkJggg==" />

Des frameworks complets comme SASS permettent de le faire dans le CSS. Vous pouvez utiliser cette technique à partir de IE8, et envisager l’équivalent MHTML pour IE7.

Le nombre de domaines

Le site moyen a entre 10 et 15 domaines à faire résoudre et il n’y a pas eu d’études sur l’utilisation du cache DNS sur mobile. Pratiquement invisible sur ordinateur de bureau, le coût de recherche DNS est peut être dix fois plus important sur mobile à cause de la latence. Chaque recherche de domaine va bloquer une file de téléchargement en attendant la réponse. Donc, soit vous sacrifiez trackers, publicité, widgets et autres sources externes, soit vous les dépriorisez fortement, tout simplement en les appelant après vos propres fichiers.

Connexions permanentes

Si vous avez une version dédiée mobile de votre site (pas de problématique de référencement, code spécifique), autant y aller à fond et utiliser une technologie très prometteuse pour contrer les effets de la latence : WebSocket. Pointez deux navigateurs cette page de démo, et observez le peu de délai dans la transmission d’une info d’un navigateur à l’autre, réseau mobile ou pas. Websocket ou d’autres techniques de connexions permanentes peuvent être détournées : vous chargez en une seule requête une page initiale ne contenant que le strict nécessaire de CSS, de contenu et de JS, puis vous chargez tout le reste (images, CSS, JS, contenu) via cette connexion, que vous pouvez même réutiliser pour renvoyer des informations (AJAX, tracking…), sans payer le prix d’ouverture de nouvelles connexions HTTP.
Je n’ai pas encore vu d’équipe web déclarer avoir implémenter cela, mais ça ne saurait tarder. Au pire, patientez un peu, je vais coder une démo sur de vrais sites.

3. Le cache et l’offline

Comme avant, il va falloir que vous commenciez par maîtriser absolument toutes les URLs vers les statiques de votre site pour pouvoir les servir avec des caches agressifs, sur des domaines sans cookies. Ça c’est surtout pour les navigateurs de bureau car le cache des navigateurs mobile est une vraie calamité en terme d’efficacité ! Il y a beaucoup trop de limites (nombre d’objets, taille maximale par objet, taille maximale par site et taille maximale pour tout le navigateur) pour espérer de vrais gains avec les comportements par défaut. Attention il ne faut pas les ignorer pour autant, si votre visiteur va d’une page à l’autre, il sentira la différence.

Les sites très efficaces en sont donc à utiliser HTML5 localStorage pour stocker des JS, des CSS et même des images (encodées en base64). C’est la technique choisie par LinkedIn mobile, Bing ou GMail, et elle demande un certain niveau de maîtrise de son application. Par exemple, imaginez-vous sur une page d’accueil : vous allez télécharger via XHR tous les objets dont vous avez ou aurez besoin, puis les stocker dans localStorage.

var loader = new XMLHttpRequest();
loader.open("GET", "http://example.com/js/main.js");
loader.onload = function(e) {
    localStorage.setItem('main.js', e.response);
}
loader.send();

Ensuite, au moment ou vous en avez besoin, vous vérifiez la présence des fichiers voulus dans votre cache maison.

if( localStorage.getItem('main.js') !== null ) {
    eval( localStorage.getItem('main.js') );
}

Oui, vous faites à la main le boulot du navigateur (télécharger, gérer le cache, insérer…) mais c’est avec ce genre de code un peu extrême que l’expérience utilisateur sur mobile fera la différence. En prime, les navigateurs de bureau en profiteront aussi.

Une note pour ceux qui ont entendu dire que LocalStorage était contre-performant car synchrone (lorsque vous écrivez, vous bloquez le programme le temps que le disque ait fini de travailler) :

  • c’est évitable facilement en passant par un wrapper qui va simplement effectuer l’écriture en asynchrone ;
  • les mobiles écrivant tout en RAM / Flash disk, les temps d’accès sont de toute façon négligeables.

Vous pouvez encore passer au niveau supérieur en utilisant une technique qui a autant fait ses preuves que montré ses limites : l’utilisation de la spécification Application Cache. Native, bien supportée par tous les navigateurs modernes mobiles ou de bureau, elle permet de déclarer en un fichier (le manifeste) quels sont les fichiers à télécharger, quelles ressources doivent continuer à être servies en ligne, et quoi afficher lorsque la connexion n’est plus là. Au contraire de la gestion du cache présentée précédemment qui est personnalisée et donc très adaptée à votre application, Application Cache vous force à coder d’une certaine manière (maîtriser absolument toutes ses URLs), présente certains manques (invalider le cache de certains fichiers seulement) et il faut un petit temps d’adaptation pendant la phase de développement pour comprendre son fonctionnement intrinsèque. En revanche, en terme de performance et de mode de distribution, c’est parfait !

4. Réduire la taille

Minification et compression des JS / CSS

La minification est généralement exécutée au déploiement du site juste après la concaténation et vous pouvez généralement gagner 50 % du poids des fichiers avec des outils solides comme YUI Compressor. Activez la compression gzip par-dessus et vous aurez gagné au final 90 % du poids initial de vos fichiers. Sachant qu’il n’est plus rare de trouver des sites avec 200-500 Ko de CSS et de JS, le gain est assez important.

Les photos

Pour les images de l’interface, comme pour les photos, vous avez beaucoup à gagner en compressant au maximum les images servies. Encore plus efficace : ne les afficher que si elles sont nécessaires. Dans le cas d’une application Web Mobile ou l’interface permet de beaucoup scroller, considérez comme une amélioration majeure de faire du lazy-loading sur les images, c’est à dire de ne télécharger l’image que lorsqu’elle est sur le point d’être affichée.
En terme de compresseur d’image sans perte de qualité, voyez avec PNGout (ligne de commande) et PNG Gauntlet (son interface visuelle) pour compresser efficacement les PNG, ou JPGoptim (ligne de commande) et Image Optim (meta interface pour Mac) pour les JPG.

Les cookies

Là aussi, investissez du temps pour maîtriser toutes les URLs de toutes les ressources statiques de votre site , afin de les mettre sur des domaines séparés du domaine principal. Imaginez un cookie d’un peu moins d’un Ko qui serait envoyé à la centaine d’objets généralement appelée par une page Web classique : vous demandez à votre utilisateur d’uploader 100 Ko de données inutiles. Une autre piste pour remplacer les cookies qui sont parfois servis sur des pages statiques qui n’utilisent même pas de données personnalisées est de ne pas les utiliser du tout… pour les remplacer par HTML5 localStorage si vous avez tout de même besoin de persistance côté client (préférence d’affichage, historique…). Pour la compatibilité navigateur, passez par des petites librairies spécialisées.

En résumé

Vous voilà donc paré pour arrêter de perdre vos clients dès qu’ils essayent d’accéder à votre site à partir d’un réseau mobile. Nous avons vu que :

  • la performance est empirique : testez même les grands classiques avant de choisir vos solutions ;
  • la plupart des techniques déjà connues marchent mais sont à traiter dans un autre ordre ;
  • ces techniques sont à pousser dans leurs extrêmes ;
  • de nouvelles possibilités sont apparues.

Et ne comptez pas sur l’évolution future de l’équipement réseau : sauf inversion de la tendance actuelle, non seulement vos sites vont continuer à grossir mais en plus les futurs utilisateurs des réseaux 4G voire Wimax auront toujours des doigts, des murs, des gens et de l’atmosphère à traverser avant d’arriver sur vos serveurs.

L’optimisation, c’est maintenant.

Performance web mobile, chargement de page 1/2

Cet article a été initialement publié sur le train de 13h37, magazine du développement web de grande qualité, qui a le double mérite de rémunérer ses auteurs et de proposer les articles avec une licence CC BY-NC-SA.

Introduction

Vos utilisateurs viennent chez vous sur mobile : 5 % selon StatsCounter ; 10 % selon ATInternet ; 9 % d’après ce que je vois chez mes clients dont le site n’a PAS été pensé pour du mobile. Évidemment cette part est en augmentation constante, a déjà largement dépassé IE7, va dépasser IE8, et il est raisonnable de penser que, ces statistiques étant récoltées via JavaScript, certaines tentatives d’accès ne soient même pas comptabilisées ! Que vous le vouliez ou non, que votre site ait été fait ou pas pour cet usage, vos utilisateurs essaient de venir sur votre site dans des conditions de réseau qui ne vous arrangent pas forcément, mais qui vont vous poser quelques défis intéressants.

De quels mobiles parle-t-on ?

Plus on rentre dans les détails des navigateurs, des systèmes d’exploitation et des capacités matérielles, et plus il semble illusoire de définir ce qu’est vraiment un mobile. Restons pragmatiques et, dans le cadre de cet article sur la performance, précisons ce que nous allons considérer comme notre cible :

  • capacité du navigateur à afficher des sites non spécifiquement prévus pour mobiles ;
  • navigation « tactile » ;
  • matériel sous-dimensionné par rapport à la machine de bureau moyenne ;
  • qualité de réseau fluctuante.

Ce dernier critère peut prêter à discussion, tant on observe d’utilisateurs mobiles accéder aux sites depuis le confort du WiFi de la maison : par exemple, la moitié des visiteurs dits « mobile » sont en fait sur iPad, ce qui implique (le plus souvent) le WiFi.

Mais dans le cadre de cet article nous allons surtout nous intéresser aux « problèmes supplémentaires à résoudre pour le chargement des pages » : les temps de chargement depuis une tablette / mobile sur WiFi sont largement comparables aux temps de chargement sur certains navigateurs de bureau.

Comment tester ?

Tout développement commence par la mise dans de bonnes conditions pour tester ; la mesure a lieu ensuite dans un chantier performance web. Le banc de test idéal pour le mobile est simplement impossible à monter et force est de constater que les éditeurs de sites, de l’indépendant aux sites avec des millions de pages vues, se contentent généralement de l’iPhone de l’intégrateur et éventuellement de l’Android-qui-s’appelle-revient du collègue.

Si l’on regarde les parts de marché en France, cela correspond effectivement à une réalité : nous avons Safari pour iOS partagé entre les différents iPhone et iPad, et le navigateur par défaut d’Android distribué avec les version 2.x. En queue de peloton et souvent ignorés, à tort pour les valeurs d’interopérabilité du Web, viennent les Opera (mini ou mobile) pourtant ultradominants dans d’autres pays, Firefox mobile, ainsi que différentes variantes de Webkit sur les OS mobiles survivants (Blackberry, SymbianOS, LG…), ainsi que IE Windows.

Ah, et ne comptez pas sur les émulateurs : ils sont déjà à peine acceptables pour tester les fonctionnalités, alors question performance ils sont tout simplement disqualifiés d’office ! Entre l’utilisation du processeur de la machine hôte, une connexion filaire sans défaut et les approximations inhérentes à tout émulateur, vous n’aurez jamais quoi que ce soit de réaliste dans votre quête de la fluidité.

La solution minimale du pauvre, c’est de conserver ses mobiles et d’attendre qu’ils vieillissent ou d’acheter des occasions datant d’un an ou deux, sans mettre à jour le système d’exploitation. Pour simuler un réseau 3G, on pourra utiliser des proxys via WiFi qui dégradent volontairement la connexion. Il y a une grosse dizaine de solutions, généralement limitées à un seul OS (souvent Mac). La plus compatible et reconnue est le proxy payant Charles mais la gratuité de Trickle (Linux), Network Link Conditioner (OSX 10.6) ou Slowy App (OSX 10.5) peut vous séduire.

Le principe est simple : ces logiciels contiennent de quoi dégrader artificiellement une connexion (débit, latence, perte de paquets). Vous configurez votre téléphone pour utiliser votre machine comme proxy via WiFi, et voilà ! En prime, vous pouvez analyser les trames réseau qui passent. C’est moins cher que de vraies cartes SIM et la constance de la dégradation permet de faire des tests répétés, là où la qualité d’un vrai réseau data peut varier d’une minute à l’autre.

Pour être honnête, les techniques décrites dans cet article ont surtout été testées sur le navigateur Android 2.3 et Safari iOS 6, avec des vérifications fonctionnelles sur Firefox et Opera mobile sur Android, les deux absents notoires étant le Safari de Blackberry et Internet Explorer.

Signalons également que nous ignorons délibérément un bon milliard d’habitants sur cette planète qui se connectent au Net avec des mobiles pré-smartphones : techniquement difficiles à adresser sérieusement, ils sont également une minorité en France à posséder ces anciens mobiles et avoir souscrit un abonnement 3G.

Chargez !

L’importance du réseau

Croyez-le ou non, les débits théoriques en 3G et technologies au-delà peuvent être plus rapides que les débits constatés des ADSL. Mais comme finalement assez peu de gens font du Web depuis les laboratoires de tests des constructeurs, il va falloir composer avec la réalité physique : une couverture nuageuse un peu forte, un déplacement un peu rapide, un doigt mal placé, un mur un peu épais, ou des gens autour de vous également équipés de mobiles (incroyable en 2012), et vous vous retrouvez rapidement avec des débits ridicules, des pertes de paquets énormes et le sentiment global qu’on vous a un peu survendu la « meilleure couverture réseau de France ».

Lorsque le réseau marche, l’utilisateur français moyen a en moyenne 2,50 Mb/s (sources) ce qui est plus rapide que 25% des ADSL de France. Par contre, la latence ou ping est en moyenne à 200 ms soit le double de la moyenne en ADSL.

Depuis toujours, la latence est l’ennemi numéro 1 de nos pages Web. Ceci est du à la nature même de HTTP et signifie que pour un débit moyen seulement deux fois inférieur, le temps de chargement sera en fait 3 à 6 fois plus long sur mobile ! Pire, la perte de paquets est assez conséquente et inhérente à la technologie radio utilisée pour communiquer entre le mobile et l’antenne de l’opérateur. Et cette perte de paquets arrive plus fréquemment pour les petites requêtes… Exactement la manière dont sont composées la majorité de nos pages Web actuelles !

Ajoutez à cela qu’accrocher et maintenir le réseau data est une des opérations les plus coûteuses en terme de batterie : passez en mode avion sur votre smartphone, utilisez-le presque comme d’habitude (lectures, jeux…) et vous verrez qu’il peut tenir une seconde journée sans recharge. Et souvenez-vous des anciens portables sans data qui tenaient une semaine…

Bref, c’en est au point que les constructeurs optimisent comme ils peuvent le matériel, par exemple en mettant en veille la radio après un certain temps d’inutilisation. On se retrouve donc dans des situations où, le temps de lire cet article, l’antenne s’est déconnectée et il vous faudra plusieurs secondes pour que la requête suivante aboutisse !

Malgré cela, les utilisateurs ne sont pas beaucoup plus patients que sur un ordinateur de bureau : après 5 à 10 secondes de page blanche, une majorité d’utilisateurs a déjà rebroussé chemin, et autant vous dire qu’ils n’apparaissent même pas sur les statistiques collectées en JavaScript. Comment faire pour vaincre l’hémorragie de visiteurs et proposer des services de meilleure qualité perçue ?

Eh bien il va nous falloir revisiter tout l’arsenal des classiques de la Performance Web.

Remettre en cause les classiques

Lorsque le pape de la performance, Steve Souders, a émis chez Yahoo! les premières recommandations de performance Web, c’était en faisant du reverse-engineering sur les moteurs IE6-IE7 et Firefox 2. C’était en 2005 et, avec l’abandon progressif du support de ces navigateurs antédiluviens (à l’échelle du Web) d’un côté et la banalisation de l’ADSL de l’autre, certaines règles ou astuces sont devenues moins importantes.

L’apparition de la navigation sur mobile en a même rendu certaines dangereuses !

Le domain-sharding

Citons par exemple le domain-sharding, qui consiste à répartir ses fichiers statiques sur plusieurs sous-domaines différents. Étonnamment populaire, à l’origine cette technique permettait de passer outre la limitation à 2 files de téléchargement par domaine et de bénéficier de toute la largeur des bandes passantes modernes. Mais à partir de IE8, sorti en 2009, cette technique devient inutile car le nombre de téléchargements simultanés passe de 2 à généralement 6 : les navigateurs se sont adaptés à la banalisation des gros débits et tentent d’en tirer parti.

Utilisons le service Cuzillon qui va nous permettre de simuler une page avec 24 images réparties sur 4 domaines et une autre page avec 24 images sans domain-sharding. Le service WebPageTest nous permet de voir qu’il y avait effectivement une amélioration sur le temps de chargement sur IE7 :

WebPagetest – Test de chargement d’une page sous IE7 avec (en bas) et sans sharding (en haut). Voir la source

Le test sur les mêmes URLs sur IE8 nous montre que l’on ne gagne plus grand chose en premier rendu (les petites images chargées) :

WebPagetest – Test de chargement d’une page sous IE8 avec (en bas) et sans sharding (en haut). Voir la source

On ne gagne plus rien car la parallélisation des téléchargements est assurée de base par le navigateur. On a en fait rajouté deux mini-problèmes en rajoutant un temps de résolution DNS supplémentaire par domaine, et en faisant concourrir plusieurs images pour la même bande passante. Je dis « mini-problème » en supposant qu’on ne ciblait que les navigateurs de bureau (c’est mal) où ces problèmes sur des vrais sites (75-150 requêtes, 10-15 domaines) passent finalement inaperçus, mais vous ciblez les mobiles, pas vrai ?

Sur mobile, les navigateurs ouvrent également plusieurs connexions par domaine et font même du multiplexing HTTP (plusieurs requêtes HTTP dans le même tuyau TCP) pour minimiser les problèmes liés à la latence. Vous prenez alors le risque de couper court à ces optimisations. Résultat ?

WebPagetest – Test de chargement d’une page sous iOS avec (en bas) et sans sharding (en haut). Voir la source

L’affichage a été ralenti ! En forçant encore plus de domaines, vous demandez à plus d’objets de se partager la même bande passante, que vous devez considérer a priori comme rare sur mobile. Donc vous ralentissez l’affichage des premières images alors même que les suivantes ne sont pas immédiatement utiles. Ici, le temps de chargement total est en plus augmenté car le multiplexing n’a pas pu être utilisé, ce qui peut être le cas sur des sites avec un ratio ressources / domaine faible.

Les scripts en bas de page

Le temps avant le premier rendu (l’affichage des premiers pixels du site) est un peu le but ultime de la performance Web, car il y a une très forte corrélation entre ce temps et une augmentation des taux de transformation ( + rapide = + d’argent ).

Dans ce cadre, une autre technique populaire consiste à déplacer toutes les balises script en bas de page. Cette technique marche effectivement bien sur les anciens navigateurs et continue à faire ses preuves dans une moindre mesure sur les nouveaux malgré leurs progrès dans la prioritisation des téléchargements.

Regardons l’effet attendu avec IE8 sur une page simple où le téléchargement du JavaScript est retardé côté serveur.

Bureau : tests de comparaison de chargement d’une page avec les scripts en bas et en haut de page. voir la source

En haut, la page améliorée par déplacement des balises script ; on voit que le contenu (une simple phrase) s’affiche rapidement, alors qu’en bas la page blanche de la mort est de rigueur.

Passons sur mobile, si vous le voulez bien, et testons Safari iOS et Android Browser 2.3.

Mobiles Android et iOS : tests de comparaison de chargement d’une page avec les scripts en bas de page. Voir la source

Android se comporte comme nos navigateurs de bureau et affiche le contenu dès qu’il l’a. Safari iOS préfère attendre le script avant d’afficher quoi que ce soit, sans doute par peur du FOUC (Flash Of Unscripted Content).

On peut débattre sur le fait qu’ergonomiquement il vaut mieux attendre une page bien faite (complètement scriptée) plutôt que d’afficher rapidement du contenu pas finalisé, mais les taux de tranformation montrent que l’affichage rapide rapporte plus.
Et de toute façon, en tant qu’auteur de la page, c’est à vous de juger si elle peut être vue momentanément sans scripting ou pas : si vous utilisez des méthodes de développement par couche (HTML, puis CSS, puis JS), ça devrait être bon. Si vous voulez de la performance, il va donc falloir faire évoluer votre technique d’inclusion de script pour passer à une version asynchrone.

Le chargement asynchrone à la base est bête comme chou :

var oNode = document.createElement('script'); 
oNode.type = 'text/javascript'; 
oNode.src = 'http://domaine/monscript.js'; 
document.getElementsByTagName('head')[0].appendChild(oNode); 

Vous utilisez le DOM pour créer dynamiquement de nouveaux noeuds script qui vont charger des fichiers JS. Cette technique est notamment utilisée par les Google Analytics, boutons G+ et autres Like Facebook pour s’insérer dans vos sites sans introduire de dépendance forte vis-à-vis de leurs serveurs.
Autrement dit, lorsque leurs serveurs sont en rade ou bloqués par un proxy, le navigateur va tout de même afficher votre page (trop aimable). Utiliser cela avec ses propres scripts est globalement une bonne idée, et devient vital sur mobile. Vous aurez probablement besoin d’aller plus loin avec le chargement dynamique de scripts (exécuter du code lorsque le fichier est arrivé, gestion des dépendances et de l’ordre de chargement, concaténation de fichiers à la volée…), aussi pensez à utiliser des frameworks solides comme requireJS, YepNope.js (inclus avec Modernizr), HeadJS, LabJS… Chacun a sa philosophie.
Et puisque je vous tiens, voici le mien : LazyLoadLight, qui se veut léger et facile :)

Voir la suite de cet article qui parle des chemins à explorer pour des pages toujours plus rapides sur mobile.

HTML5, aujourd’hui

L’article suivant est la retranscription de l’article que j’ai écrit pour le magazine PHP Solutions, dans le numéro hors série de 2011 consacré à HTML5. Le monde compliqué du droit d’auteur veut que ce texte ne m’appartienne pas, c’est donc avec leur permission express que j’en fait bénéficier mes lecteurs (oui toi). Toute reproduction est donc interdite.

Cet article se veut une introduction générale à HTML5, notamment pour les développeurs PHP qui sont généralement les mieux placés pour prendre au sérieux ce qu’il se passe au frontend. Si vous avez lu mon livre sur HTML5 ou que vous suivez déjà régulièrement l’actualité, je doute que vous y appreniez grand chose. Il explique :

  • l’origine de la spécification
  • comment les sites d’aujourd’hui peuvent en bénéficier
  • le futur des applications Web
  • les rares synergies entre HTML5 et PHP

Historique

Une définition variable

Le terme même « HTML5 » couvre plusieurs définitions, et nous allons voir que le W3C a surpris tout le monde dans son choix final. Avant que le terme HTML5 n’apparaisse, HTML 4.01 était stabilisé et le W3C planchait sur XHTML 2 car pour eux la syntaxe stricte de XML allait permettre à tous les navigateurs d’être enfin d’accord sur les règles de parsingdes pages.
Lire la suite »

Usage avancé des fonctions JavaScript

Cet article est un complément à l’article sur les 3 fondamentaux de JavaScript, il vaut mieux être déjà à l’aise avec JavaScript avant de crier au scandale en voyant ce qu’on peut en faire. Pour reprendre un bon mot de quelqu’un qui avait assisté à ma conférence sur JavaScript :

javascript == la pornstar des langages de dev: souple, puissant, tu lui fait faire ce que tu veux, et ça peut finir bien crade.

Admettons donc que vous ayez digéré sans problème les portées et les fonctions, passons à deux choses vraiment particulières à JavaScript :

  1. le renvoi de fonction qui permet de belles optimisations et qui ouvre la voie à des patterns que les amoureux de la théorie du langage apprécieront,
  2. une implémentation de classe statique, pour reprendre le terme utilisé en PHP ou en Java.

Et enfin nous verrons une proposition d’implémentation de deux design pattern célèbres et particulièrement utiles en JavaScript : Singleton et Factory.
Lire la suite »

JavaScript : 3 fondamentaux

Après quelques années à écrire dans un langage, on finit facilement par oublier les premières difficultés que l’on avait rencontrées. Et à force de faire de la veille, de l’autoformation et de parler entre experts dans des conférences, j’ai un peu quitté la réalité de la majorité des équipes Web.

Maintenant que je suis consultant indépendant je retourne dans des équipes qui avaient autre chose à faire que de se demander si on a le droit de parler de classe en JavaScript, quelle est la bonne définition d’une closure, ou quelles sont les fonctionnalités de EcmaScript 5 qui auraient du rester dans Ecmascript.Next.

J’avais déjà parlé sur ce blog de JavaScript et la programmation orienté objet pour les développeurs PHP, nous allons explorer ici les 3 notions fondamentales de JavaScript qui sont probablement les plus grosses sources de bugs, d’incompréhension et de frustration pour le développeur Web moyen. Et qui accessoirement sont la base d’une programmation plus évoluée par la suite.

JavaScript est différent : apprenez le

Le monde du développement Web semble dominé par les langages dérivés de la syntaxe du C, PHP en tête, avec des paradigmes qui se ressemblent. Forcément en abordant JavaScript dont la syntaxe n’est pas vraiment révolutionnaire, on est tenté d’appliquer la même logique. Mais c’est oublier un peu vite que ce langage a été créé il y a déjà 15 ans, quand Java était seulement à mode et pas encore ultra dominant comme aujourd’hui, et qu’il est principalement l’héritier de langages comme Erlang et Lisp, aujourd’hui très peu connus. En fait le mot Java dans JavaScript a été rajouté pour des raisons commerciales, et seuls quelques concepts comme la syntaxe et je crois la gestion des dates ont contribué à former JavaScript. JavaScript n’est donc qu’un cousin éloigné des langages mainstream.

Le maître mot de ses concepteurs semble avoir été la versatilité. Nous allons voir qu’en explorant seulement 3 bases à priori simples, il est possible d’obtenir à peu près n’importe quoi, ce que les grands maître de JavaScript s’amusent tous les jours à faire. En attendant de passer dans la catégorie des maîtres, il faut déjà maîtriser ces bases pour faciliter son travail au quotidien.

Nous allons donc nous baser sur EcmaScript 3 (le javascript de IE6-7-8) dont les trois fondamentaux sont :

  • La portée des variables ( var + function)
  • Les fonctions
  • Le contexte (this)

Commençons par la portée.
Lire la suite »

HTML5 maintenant, chapitrage de la conférence

La vidéo sur la conférence que j‘ai donné à Paris Web 2010 vient de sortir, aussi comme pour la conférence sur les Performances Web je l‘ai chapitré et je vous remets les slides pour que vous vous y retrouviez.

Mes capacités d‘orateur valent ce qu‘elles valent, mais le contenu et le discours restent d‘actualité et devraient permettre je l‘espère à certains développeurs de se décoincer face à HTML5 : les fonctionnalités sont utilisables maintenant en production, pour peu qu‘on sache coder, utiliser des librairies faites pour ça et qu‘on soit suffisamment curieux pour tester tout cela. Les bénéfices sont soit immédiats soit à venir, et il y a certains écueils à connaître.
Le maître mot est : testez ! Dans la plupart des cas vous vous rendrez compte que vous pouvez mettre en production et donc améliorer votre site pour vos utilisateurs.
Lire la suite »

Etat des lieux de l‘accessibilité de HTML5

Après avoir affirmé à Paris Web 2010 que HTML5 était utilisable immédiatement en production, un expert accessibilité m‘a repris en disant qu‘il était dangereux de dire que HTML5 était accessible (j‘en parlais au futur cela dit). Dans le cadre d‘un gros projet autour de HTML5, j‘ai depuis fait pas mal de recherches ce qui m‘a permis de mieux comprendre son intervention.
Je sais qu‘il est dangereux de parler en dehors de son domaine d‘expertise, mais il faut bien qu‘un développeur Web mette les pieds dans le plat et à tout le moins provoque le débat. Autant vous dire que si vous vous y connaissez en accessibilité, je prend tout ajout ou correction.

Autant vous le dire tout de suite, mes conclusions sont mitigées, et il se peut même que je revienne sur ce que j‘affirmais à l‘époque.
Lire la suite »

Conférence performance à Paris Web 2010

J’avais un atelier sur les performances pour le cycle de conférence Paris Web 2010, qui est maintenant sorti en vidéo. L’atelier s’est finalement transformé en une conférence improvisée d’1h30, par manque de candidats pour tester leurs sites, et de par la configuration de la pièce (amphi au lieu de salle de cours). Malheureusement le côté improvisé se ressent un peu car je ne m’étais pas chronométré pour réussir à synthétiser chaque sujet.
Chaque sujet est donc discuté en profondeur, mais je n’ai pu traiter que les bases. Voici le chapitrage de cette conférence :
Lire la suite »

HTML5 et le Web ouvert, pour les aigris et les cyniques


L’actualité récente autour de HTML5 a fait réagir beaucoup de développeurs, ce qui à tout le moins permet d’avoir un instantané des opinions de la communauté Web. Elle vont de l’inutilité d‘avoir un logo aux affirmations du type “HTML5 ne me concerne pas car je supporte IE6”. Ceux qui participent au débat sont soit enthousiastes soit aigris par la réalité de leur travail. Ceux qu‘on ne voit pas parler sont les blasés. Ce post d‘opinion, plutôt inhabituel sur ce blog technique, s‘adresse à ces 2 dernières catégories : pourquoi soutenir ou même s‘intéresser à l‘extension des technologies du Web en général, et au mouvement HTML5 en particulier ?
Lire la suite »