En effet, les ISPs ont toujours été opaques quand à la gestion de la bande-passante – notamment en ce qui concerne les clients Torrents. Cela en parfaite contradiction avec leurs « terms & conditions« . Google  mets donc à disposition des utilisateurs une série d’outils aux noms évocateurs ( Glasnost ) dont le but est de rendre transparentes les pratiques des ISPs.

Vous pouvez donc devenir notre ami, lire les articles que nous souhaitons partager, ou consulter dans article les derniers posts syndiqués directement du blog.

A venir des mises à jour de vidéos sur nos productions. Cela coïncide avec la mise à jour progressive de Facebook vers sa nouvelle architecture plus clair avec une navigation par onglet.

En parlant de vidéo, je vous invite à découvrir le channel Youtube du blog Tequilarapido qui s’étoffera dans les prochaines semaines.

@+ sur Facebook

Pour être honnête je redoutais un peu ce passage chez cisco (un benchmark sur les RJ45 et les routeurs de bon matin cela aurait été un peu g33k…). Le keynote de ce matin a dissipé mes craintes. Topic: comment cisco a su s’approprier le web 2.0, l’intégrer dans le S.I et optimiser le workflow.

L’employee directory a donc été repensé comme un hub pour devenir le facebook de l’entreprise et intègre:

- une gestion des communautés
- un profil « unifié »: personnel & professionel
- des fonctions de social bookmarking
- un indicateur de présence
- des capacités click-to-dial/chat

Cisco considère l’évolution de son SI vers le web 2.0 comme une évolution (et non pas une révolution) et accompagne le changement d’une manière plutôt pragmatique: ‘collaborate to learn how to collaborate‘ et retient quelques points clés du changement opéré:

- necessité d’une base (infrastructure/architecture) solide sur laquelle s’appuyer
- la collaboration n’est pas qu’une question d’outils
- le contenu pertinent reste la clé
- l’agilité et la personalisation sont les facteurs essentiels de l’expérience utilisateur
- l’experience utilisateur conditionne l’adoption
- tous les outils web 2.0 ne sont pas adaptés à toutes les entreprises

(commentaire live: en créeant son web 2.0 interne, cisco réduit le gap qui existe entre l’expérience utilisateur fournit par les outils traditionnels du SI de l’entreprise et celle offerte par le personal information system du web 2.0 – google apps, skype, netvibes, facebook etc…)

http://video.yahoo.com/video/play?vid=1040890

Dans cette conférence, Steve Souder, décrit quelques 14 règles techniques à observer pour rendre un site web performant d’un point de vue utilisateur.

Dans le processus d’amélioration d’un site on trouve deux grands chantiers :

• Backend performance : Un chantier coûteux en temps et ressources vu les éléments qui y sont impliqués : l’application, la base de données, les serveurs, leurs duplication/réplication…
• User performance : Un chantier plus facile à entreprendre, et qui a le plus fort impact.
  

Steve Souder affirme d’après les études qu’il a mené avec son équipe chez Yahoo, une étude réalisée sur le top 10 des sites aux États-Unis (google, Yahoo, cnn, amazon, ….) que le premier chantier peut avoir un impact allant de 5 à 10%, alors que le second peut atteindre 95%, intéressant, non?

A côté du travail nécessaire à effectuer du côté serveur (backend), il est important de se préoccuper de l’impression que l’utilisateur peut avoir en visitant un site. L’idée est d’adopter le fameux LOFNO (Look Out For Number One = User), pour une meilleur perception utilisateur.

Dans la partie Frontend, il y a bien sûr le temps de chargement de la page, càd le temps réponse des requêtes HTTP, mais aussi le temps de affichage de la page. Ce dernier représente 88% du temps global, il s’agit là de la phase où le navigateur analyse le document HTML, parse le feuille de styles, initialise les composants DHTML et exécute les scripts de la page.

Steve Souder nous a concocté 14 règles à respecter et qui sont par ordre de priorité

1. Réduire le nombre des HTTP Requests :

L’idée est que plus il y en a, plus le temps de téléchargement des éléments du document sera plus important. Cela va sans dire, pour le nombre des scripts, des feuilles de styles et bien sûr les images utilisées par la page. Pour ce dernier point la solution est d’utiliser la technique des sprites qui consiste à regrouper les pictos et les backgrounds d’un site dans une seule image (sprite), et d’utiliser le background-position pour sélectionner le picto ou le background voulu. Un site qui utilise 60 pictos, càd 60 requêtes n’en fera qu’une seule.

2. CDN : Content Delivery Network:

Une solution non gratuite, nécessitant plusieurs serveurs, qui consiste à distribuer le contenu statique (images, scripts ..) suivant la localisation physique de l’utilisateur. Cette technique a plus d’impact qu’une distribution de contenu backend (réplication système et base de données).

Une variante à moindre coût, et qui est très intéressante, et d’utiliser plusieurs domaines pour pallier à la limitation imposée par le protocole HTTP1.1. En fait, un navigateur ne peut effecteur que deux requêtes en parallèle et par host. En mettant le images sur img.mysite.com , les scripts sur js.mysite.com et les css sur css.mysite.com on monte déjà à 6 requêtes en parallèle.

3. Utiliser les Expires Headers :

Le but est d’optimiser le cache des navigateurs.

Pour les serveurs Apache il suffit d’utiliser la directive suivante : ExpiresDefault « access plus 10 years »

Il faudra ensuite intégrer au processus de développement du site, un méchanisme de versioning pour changer le nom des fichiers cacheable (js, css, images …) en rajoutant au nom un suffixe pour forcer la navigateur à retélécharger ces fichiers à chaque fois qu’on les modifie. (exemple fonction-v1.2.2.js ou fonction-06072007)

4. GZIP :

La compression GZIP des contenus a un très fort impact sur le temps de réponse du réseau. Cette opération peut réduire la taille d’une page de 90%. Une page de 70ko, ne fait plus que 10ko après compression. Les candidats pour cette opération sont les données de format texte : le document HTML, les scripts, les feuilles de styles, l’XML et les données JSON.

5. Mettre les feuilles des styles au début du document:

Internet Explorer n’affiche aucun élément d’une page avant que toutes les feuilles de styles soient téléchargées. Cette recommandation ne change rien au temps de chargement de la page, mais donne une meilleure perception pour l’utilisateur car le navigateur peut alors commencer à afficher la page progressivement.

N.B : Ne jamais utiliser les directive @import et leur préférer les balises classique LINK.

6. Mettre les script en bas du document :

Les scripts bloquent l’affichage de tous ce qui vient après dans le document. Les mettre en haut implique tout simplement que le navigateur attendra le téléchargement de tous les scripts avant de commencer l’affichage de la page.

Un autre effet négatif est que les script en <HEAD> bloquent les téléchargements en parallèle.

Pour les composants DHTML, par exemple les menus, il est préférable de mettre le script juste après les éléments HTML du menu.

7. Ne pas utiliser les expressions CSS:

De type : expression {document.body.clientWidth<600 ? « 600px » : « auto »};

8. Externaliser les JS et CSS:

En effet, en utilisant des blocs SCRIPT ou CSS la taille de la page est plus grande, et les JS/CSS ne peuvent être mis dans le cache du navigateur.

9. Réduire les DNS Lookups:

Une résolution DNS peut coûter 20 à 120 ms.

10. Minimiser les JS:

Il y a deux méthodes : Minimisation et ‘Obfucation’. La première consiste à éliminer les espaces, tabulations et sauts de ligne et la deuxième rajoute une autre fonction qui raccourcit les noms des variables. Ceci peut entrainer des bugs à cause des conflits de nommage qui peuvent surgir.

La première méthode peut réduire la taille d’un script de 20%. (la 2ème étant risquée peut aller jusqu’à ~25%)

11. Eviter les redirects

12. Eliminer la redondance des scripts:

L’existence d’un script redondant dans une page peut provoquer un dysfonctionnement du navigateur, impliquer des extra HTTP request (pour IE ) et des exécutions répétées.

13.Configurer les Etags:

Les Etags, introduits avec l’arrivée de la version 1.1 du protocole HTTP, offrent un moyen flexible pour contrôler le cache du navigateur. Il permet au navigateur de savoir si le composant dans le cache est le même que celui sur le serveur.

Un Etag est un identifiant unique d’une entité (image, fichier script, …). Pour plus de détails sur ce point http://developer.yahoo.com/performance/rules.html#etags

14: Cacher les requêtes AJAX:

Les données XHR,JSON,iFrame peuvent être Gzipées, minimifiées et cachées.

N.B : Une extention pour firefox est disponible pour vérifier ces règles YSlow

Orange reprends donc à son compte les modèles du web 2.0 pour tenter de s’imposer comme un (futur) acteur majeur du web. Orange appuie son business model sur sa spécificité d’opérateur: en ouvrant son infrasctructure et en exposant ses API, l’opérateur entends favoriser l’élaboration d’un écosystème d’applications qu’il puisse pousser vers sa (large) base de clients. Le second axe retenue par Orange est de s’appuyer sur sa crédibilité pour « vendre » le web 2.0 à l’industrie.

Cette stratégie induit une conception peu innovante du mobile – « downgrader » une application web pour la déployer sur un mobile – ce qui limite nécessairement la portée des apports de l’opérateur.