Les articles de la catégorie « Veille »

Kevinjohn Gallagher a écrit un chouette article détaillant le débat autour des préfixes -webkit- (rappel) et d’Opera, intitulé « Est-ce que la grosse dame chante pour les préfixes navigateurs ?« . Il a de bonnes propositions pour améliorer la situation :

La première action à prendre est de mettre la pression sur Apple/Google/WebKit pour implémenter les bons standards des propriétés en retirant le support de « -webkit- » lorsque la version non-préfixée est standardisée, et ne pas contourner le processus convenu. Ne vous trompez pas, en favorisant l’utilisation continue de « -webkit- » en dépis de la version non préfixée comme décris dans les spécifications CSS2.1 et CSS3, ce sont ces organisations qui ont donné aux développeurs la permission de ne pas écrire leur code d’une manière standard.

Deuxièmement, nous devons créer un endroit centralisé avec les bonnes informations, avec le bon niveau de détails. Vous et moi savons ce que nous faisons, mais franchement Internet est inondé de désinformation et de personnes contournant les standards dès que ça corresponds à un truc « cool ». Bruce Lawson me rappelait l’existence des Web Standards Curriculum qu’Opera ont ouverts et soumis au W3C; mais ce n’est pas écrit pour un développeur d’aujourd’hui, c’est écrit pour des gens qui sont déjà bien avertis.

Troisièmement, nous avons besoin que les services de validation HTML/CSS marquent le manque de standards comme des erreurs. Si vous avez un préfixe -webkit- et pas la version non préfixée, c’est une erreur. Si vous avez un préfixe -webkit- mais pas la version -moz-, c’est un avertissement (idéallement une erreur). Au fond nous voulons faire du web un meilleur endroit, et ça n’arrivera que si on éduque.

Quatrièmement, arrêtons avec la minification des CSS. Je sais que ça va causer une controverse, mais on ne gagne que quelques Ko et on rends le débuggage de notre code plus difficile pour les gens. Et avant que quelqu’un ne me sorte « l’excuse des données sur mobile », je vous en réfère aux images dans le responsive design, et le fait que des sites mis en avant par des magazines importants atteignent maintenant 5 Mo à télécharger sur un mobile ! Le web a grandit basé sur la capacité des gens à inspecter du code, lire, apprendre et reproduire; revenons en aux bases.

Cinquièmement, nous avons besoin que le CSS Working Group avance plus vite. Foutrement plus vite ! Une partie des cartes de Apple/Google consiste à dire que le CSSWG (et tous les autres groupes de travail impliqués dans CSS et HTML5) sont tellement horriblement lents à standardiser quoi que ce soit que les gens n’ont pas d’orientation claire et unifiée. Cette excuse foireuse ne marchait pas pour Microsoft à l’époque, et elle ne marche pas non plus maintenant; mais ça ne veut pas dire qu’ils ont tort, mais indique juste le niveau de négligence dont ils veulent se décharger.

Enfin, nous devons pointer du doigt et balancer des noms. Aucun d’entre nous n’aiment cette idée, mais il le faut, désolé. C’est la seule façon pour que les gens fassent attention. Prenez le top 10 000 d’Alexa. Prenez le top 500 FTSE. Prendez le top 100 des agences numériques et parcourez les sites qu’elles ont réalisé. Croyez moi, il ne faudra que quelques messages du genre « Les sites réalisés par R/GA ne fonctionnent pas sur 250 millions d’appareils mobiles » et les choses changeront.

Je suis assez d’accord avec l’ensemble de ces points, en particulier le deuxième invitant à éduquer les développeurs web, comme je l’évoquais ici. Le 4ème point me semble assez futile. Et même si le dernier point et l’idée d’une chasse au sorcière (comme l’avais suggéré Daniel Glazman) me dérange profondément, je crains qu’il ne faille en arriver là pour que les choses changent.

Des étudiants de l’Université de Stanford (en Californie) ont présenté la semaine dernière à Lyon les résultats de leur recherche intitulée « Qui a tué ma batterie : analyser la consommation d’énergie des navigateurs mobiles« . Le rapport de l’étude de 10 pages est particulièrement complet et détaillé, et sa lecture s’avère très intéressante. C’est à ma connaissance un des premières lectures du genre aussi complète sur ce sujet. Si la lecture en anglais vous effraie, voici un petit résumé et une traduction des points les plus importants.

Les mesures ont été effectuées sur un téléphone Android ADP2 avec une connexion 3G. Un multimètre relié à la batterie enregistrait les mesures matérielles. Une version modifiée du navigateur par défaut d’Android a été utilisée pour mesurer précisément l’impact énergétique de chaque fichier chargé, et permettre d’automatiser la mesure de consommation pour des pages avec et sans cache.

Les tests ont été effectués sur 25 sites connus représentatifs du paysage du web. Les premiers résultats des mesures sont assez marquants. S’il faut compter au minimum une dizaine de joules pour établir une connexion 3G, la différence de consommation d’un site à l’autre peut aller de quelques joules à plus de 40.

Voici quelques exemples et quelques points qui m’ont particulièrement marqué dans cette étude.

• Certains sites comme Youtube passent près d’un quart de leur énergie de rendu sur des images.
• Le code JavaScript de Yahoo est inclus dans les pages HTML. La quantité de code JavaScript est très petite mais le code est exécuté à chaque chargement de la page. Ainsi l’exécution JavaScript prends seulement 6,79% du total de l’énergie utilisée pour le rendu.
• AOL et Picasa contiennent tous les deux de grandes images, but la consommation d’énergie des CSS d’AOL est beaucoup plus faible que celle de Picasa. La raison est qu’AOL utilise des tableaux HTML pour positionner ses images alors que Picasa utilise CSS pour positionner ses images. Ceci illustre parfaitement comment le positionnement en CSS est moins efficace en énergie que le positionnement utilisant des balises HTML.
•  Réduire JavaScript sur une page web mobile aux seules fonctions utilisées sur une page réduit grandement la consommation d’énergie. Utiliser des librairies JavaScript génériques (comme jQuery) simplifie le développement, mais augmente la consommation d’énergie des pages résultantes.
• Comme JavaScript, un fichier CSS doit être spécifique à la page et contenir seulement les règles requises par les éléments présents.
• JPEG est le format le plus efficace en énergie sur les téléphones Android, quelque soit la taille des images. Pour démontrer ce point, nous avons utilisé Mogrify pour convertir toutes les images des pages d’Amazon et de Facebook en JPEG avec une compression à 92% de qualité. Les deux sites ont alors constaté un gain de consommation d’énergie, à hauteur de 20% pour Amazon et 30% pour Facebook. La raison de ce gain est que le format JPEG compresse mieux les images et est plus rapide à décompresser que du PNG ou du GIF.

Et voici la traduction de leur conclusion apportant des conseils pour concevoir des sites efficaces en énergie.

• Nos expériences démontrent que le format JPG est le meilleur format pour le navigateur d’Android, et ce pour toutes les tailles d’images.
• Gmail, le plus « vert » des sites mobiles que nous ayons trouvé, utilise des liens HTML pour ouvrir les messages sur lesquels l’utilisateur clique. La version bureau de Gmail utilise JavaScript à la place. Nos expériences suggèrent qu’utiliser des liens plutôt que JavaScript réduit grandement la consommation d’énergie pour le rendu d’une page. Ainsi, en concevant la version mobile du site différemment de la version bureau, Gmail a été capable de sauver de l’énergie sur le téléphone.
• Nous avons trouvé un certain nombre de pages qui auraient pu être mises en cache localement et affichées sans aucun accès réseau. Malheureusement, ces sites utilisent Google Analytics, un outil qui aide le suivi de l’utilisation du site. Le JavaScript utilisé par Google Analytics force une requête réseau dynamique qui ne peut pas être mise en cache. Ainsi, bien que le site aurait pu être affiché à partir du cache, le téléphone doit payer le coût important de démarrer une session 3G. Nous espérons que ce document aidera les sites web à comprendre le coût de l’utilisation de ces outils tiers. Alternativement, si les navigateurs exposaient le statut de leur connexion à JavaScript, Google Analytics pourrait choisir de ne pas reporter d’informations si la connexion 3G est faible.
• AOL est capable de gagner de l’énergie lors de son rendu en utilisant de simples tableaux HTML pour positionner des éléments sur la page. D’autres sites qui positionnent des éléments en CSS demandent beaucoup plus d’énergies pour le rendu.
• Sur tous les sites mobiles que nous avons testé, les publicités étaient de petits fichiers JPEG et avaient peu d’impact sur la consommation totale d’énergie.
• Des sites comme apple.com sont particulièrement énergivores. Nous espérons que ce document démontre l’importance de construire un site mobile optimisé pour les appareils mobiles. Les sites qui ne le sont pas finissent par vider la batterie des téléphones des visiteurs. Ceci peut potentiellement réduire le traffic du site.

La semaine dernière s’est déroulée à Austin au Texas la SXSW (South by Southwest), un des plus grands festivals de musique, films et médias interactifs. C’est un des rendez-vous les plus importants pour le web, où les plus grands acteurs donnent des conférences sur tous les sujets du moment. Google était donc présent, et a donné pendant près de 3 heures une série de mini-conférences sur Android, Google+ et le web. Paul Irish, développeur dans l’équipe de Chrome, a présenté pendant 20 minutes les « trucs vraiment nouveaux nouveaux tout chaud » en HTML5. Si vous avez un peu de temps et que vous voulez rester à la page, cette vidéo est faite pour vous ! (la présentation de Paul Irish débute à 1h51)

Voici l’ensemble des sujets abordés, avec les liens vers les démos présentées :

• Les régions et exclusions CSS (article, démo), pour créer des mises en pages avancées comme dans des magazines
• Les filtres CSS (démo), pour appliquer des effets (flou, luminosité, contraste, …) sur n’importe quel élément d’une page
• La propriété navigator.connection, pour connaître le type de connexion de l’internaute
• L’API FullScreen (démo), pour afficher n’importe quel contenu d’une page en plein écran
• L’API Pointer Lock (démo), pour contraindre le curseur de la souris à rester dans une zone précise (idéal pour les jeux)
• L’API GamePad (démo), pour utiliser une manette de jeu
• L’API Page Visibility (démo), pour savoir si une page web est affichée ou en arrière-plan
• La fonction requestAnimationFrame (article, démo), pour créer des animations en utilisant efficacement le processeur de la machine
• La fonction getUserMedia (démo Photobooth, démo Webcam Toy, démo explosion), pour utiliser la webcam et le micro de l’internaute
• WebRTC, pour créer du chat audio/vidéo en temps réel

 

Le nouvel iPad est sorti, et les premiers tests de journalistes professionnels apparaissent.

Toujours pas de support d’Adobe Flash.
— Edward C. Baig, USA Today

Dommage… […] l’iPad nouvelle formule ne sait toujours pas lire les vidéos en Flash.
— Didier Sanz, Le Figaro

Au-delà des défauts habituels des produits mobiles Apple comme le manque d’ouverture ou l’absence de compatibilité avec flash, les défauts du nouvel iPad reste pour la plupart déjà connu.
— Florent Deligia, Lyon Capitale

Dans la liste des autres technologies mortes que le nouvel iPad ne supporte toujours pas : les disquettes 3,5″, les cassettes audio, les CD audio, les DVD, …

Quelle déception.

Il y a un an, Google annonçait de manière fracassante l’abandon du codec vidéo H.264 (format propriétaire et soumis à des droits de license d’utilisation) au profit d’un nouveau codec, WebM. C’était une grande nouvelle pour Mozilla, ayant toujours refusé de supporter le codec H.264. Mike Shaver (anciennement grand défenseur de l’open web chez Mozilla, qu’il a quitté l’année dernière pour rejoindre Facebook (sic !)) écrivait l’année dernière :

Des organisations comme Google, Mozilla, Opera et les autres qui croient réellement en l’importance de la vidéo ouverte sur le web investissent dans notre philosophie pour leurs produits, et le web va être encore plus fort et encore plus génial grâce à ça.

Félicitations et merci, Google.

L’annonce de Google est vite tombée en désuétude, et la société n’a pas fait grand chose pour pousser le support du format WebM. Mozilla se retrouve alors seul dans son combat pour l’open web. Et les discussions pour supporter le format H.264 dans Firefox sont réapparues cette semaine. Andreas Gal de chez Mozilla écrit alors :

Google a promis beaucoup de choses et n’ont pas suivi, et nos utilisateurs et nos projets en payent le prix. H.264 ne va pas disparaître. Tenir le coup un peu plus longtemps ne va strictement rien nous apporter.

La première motivation de Mozilla, c’est de supporter H.264 pour leur OS mobile, Boot to Gecko. Comme l’écrit MG Siegler, sans support de H.264, « Boot to Gecko serait un véritable faux départ ». Le support de H.264 serait alors étendu aux versions mobiles de Firefox, puis aux versions bureau pour les OS supportant nativement H.264. L’article d’Arstechnica détaille très bien tout le schmilblick.

Cette actualité me rappelle à quel point les avancées du web doivent être supportées par de grandes sociétés. Ces dernières années, Apple a pesé lourd dans la balance contre Flash. Google aurait pu peser lourd dans la balance contre H.264, mais ils en ont décidé autrement.