RPW 30/06/10: introduction à SVG, CSS display, bilan de Youtube HTML5 vidéo, poids moyen des sites, IE9 WebTiming

Revue de Presse Web de hier :

• SVG : introduction à SVG. Y sont abordés la syntaxe de base, les outils pour en générer et la compatibilité. L'avantage est de pouvoir générer des images qui ne sont jamais pixelisées (comme Flash) car SVG gère des formes, et de pouvoir manipuler ces formes depuis JS. Dans les futurs FF4 et IE9 (le reste des navigateurs suivra forcément), il sera possible d'embarquer du SVG directement dans une page HTML5. Il n'y a plus qu'à attendre la disparition d'IE8 ...
• CSS : petite démo de la propriété display en action, qui montre qu'il existe une palanquée de valeurs possibles en dehors de block et none. Le inline-block (permet de mettre padding et margin sur un élément inline) nous fait rêver depuis longtemps mais est mal supporté par IE6/7. La valeur table-cell (qui permet entre autre un ajustement automatique de la largeur) est également exactement ce que cherchent beaucoup d'intégrateurs, mais n'est pas du tout supporté par IE6/7. Bref, c'est en revoyant ces limites qu'on se souvient de pourquoi on n'utilise que block et none.
• Vidéo : bilan de l'expérimentation HTML5 <video> de Youtube. Commencée en janvier dernier, le résultat est plutôt négatif :
  • impossible d'aller à un point particulier de la vidéo si il n'est pas téléchargé (et il y aurait besoin pour cela d'un standard complémentaire ...)
  • pas de possibilité de sécuriser (pour l'auteur) un flux vidéo, donc Flash restera la techno obligatoire pour le streaming payant
  • le fullscreen (quand il est supporté) n'est pas actionnable via une interface custom (je sais qu'au moins FF travaille sur ce point), et pas de moyen à priori de mettre une interface par dessus une vidéo fullscreen. .
  ainsi que d'autres points plus spécifiques à Youtube. J'avais déjà dressé mon propre bilan négatif en tant qu'utilisateur dans cette news. En passant ils rappellent qu'ils supportent WebM qui a de bonnes chances d'être le remplaçant de h.264 dans plusieurs années (avant 2015 idéalement, année où des droits payants pourraient s'appliquer) et que Adobe prépare une version de Flash supportant ce codec, pour moi dernière étape avant d'envisager sérieusement de migrer vers WebM. L'implémentation actuelle de cette balise est encore jeune, reste à voir si ces limites sont gênantes sur votre site, sinon cela cantonne l'utilisation actuelle de <video> à combler l'absence de Flash (via @pobo)
• Perfs : IE9 preview 3 expose les vrais temps de chargement et autres métriques, telles que constatées par le browser, et non calculées par JS comme c'est le cas aujourd'hui, ce qui fausse les résultats. C'est pour le moment préfixé MS (window.MSPerformanceTiming) et cela correspond à la spec WebTiming, en cours d'écriture. Bonne nouvelle pour les développeurs qui voudront benchmarker leur code manuellement. Je ne sais pas comment font aujourd'hui des plugins comme Firebug ou Dynatrace AJAX : Firebug utilise du JS, donc les temps doivent être biaisés, mais la techno utilisée pour Dynatrace étant différente, peut être que les temps sont déjà réalistes ? (via ajaxian)
• Perfs : dans cette vidéo extraire des conférences Velocity, Google nous donne quelques chiffres précieux (sans doute récoltés grâce à la google toolbar ou avec leur DNS) : le site moyen a un poids de 320Ko, et est chargé en 4,9s, alors qu'au vu de la bande passante moyenne, il pourrait être chargé en 1.4s. La moyenne est de 44 ressources externes (CSS, JS, images ...) pour 7 recherches DNS (widgets, pubs, trackers, sous domaines ...). Cette même page est chargée avec FF3.6 2 secondes plus vite qu'avec un IE6. Le reste de la conférence se concentre sur les améliorations sur lesquelles Google travaille et qui touchent aux protocoles (TCP, HTTP, SSL, DNS), et qui sans toucher aux sites permettrait d'accélérer la navigation.

Articles et liens partagés via RSS, Twitter, Facebook (twitter + blog ou blog seul), identi.ca, Delicious.

Comments

[Rédigé par : Éric Daspet]

Sauf erreur dynatrace et firebug se branchent tous les deux sur des API internes pour se déclencher. Dynatrace étant un binaire je ne vois pas pourquoi il serait concerné par les problèmes de cache js. Pour Firebug vu les résultats j'aurai tendance à dire que son chemin d'exécution javascript ne le fait pas passer par ces caches problématiques, mais je peux me tromper.

[Rédigé par : jpvincent]

tiens j'ai retrouvé ce qui m'avait mis le doute : http://www.softwareishard.com/blog/firebug/firebug-http-time-monitor/
l'équipe firebug s'était rendu compte que dans certains cas (UI bloqué), la précision était largement faussée dans le tab réseau, et ils avaient fait ce post en octobre dernier pour dire que c'était fixé, ce qui m'a laissé supposer que le problème pouvait très bien se reproduire dans d'autres mesures.
Mais maintenant Firefox exécute les addons en dehors du thread principal, logiquement ça doit améliorer la précision

Les addons IE eux (dont dynatrace) ne sont pas fait en JS et sont exécutés dans des process à part, ils partent donc mieux pour être plus précis, mais comme je n'ai aucune idée de la manière dont ils accèdent au coeur de IE, ça ne m'avance pas plus, et cette fois ci impossible de trouver l'info sur le Net