![\"High](\"http:\/\/ecx.images-amazon.com\/images\/I\/5169mD4idJL._SL160_.jpg\")
<\/a>\n\t\t\t\t\t <\/div>\n\t\t\t\t\t\tHigh Performance Web Sites: Essential Knowledge for Frontend Engineers<\/a><\/h2>\n\t\t\t\t\t\t\t\n\t\t\t\t\t Un livre succinct mais bien fait, pas long, tout ce qu'il faut savoir sur l'optimalisation d'un site, d'une API (gzip activ\u00e9, http request minimis\u00e9...etc.). Un compte-rendu est disponible sur ce site avec quelques retours d'usage maison.<\/p>\n\t\t\t\t\t\t\t\tGenre(s) : Ajax<\/a>, Amazon<\/a>, Analyse<\/a>, Apache<\/a>, API<\/a>, APIs<\/a>, Applications<\/a>, Azure Platform<\/a>, Cloud<\/a>, D\u00e9veloppement<\/a>, Direction de projet<\/a>, Google TV<\/a>, HTML5<\/a>, Hypermedia<\/a>, Memcached<\/a>, Multicanal<\/a>, Open Source<\/a>, Pratique<\/a>, R\u00e9f\u00e9rencement<\/a>, ROI<\/a>, Savoirs<\/a>, Social TV<\/a>, Tablette<\/a>, T\u00e9l\u00e9vision<\/a>, Web<\/a>, Web Apps<\/a>
Auteur(s) : Steve Souders<\/a>
Edition(s) : O'Reilly Media<\/a>
\n\t\t\t\t\t<\/i>+ d'infos<\/span><\/a><\/div>\n\t\t\t\t\t\t<\/div>\n\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t\t\t\n Voici donc un tr\u00e8s\/trop r\u00e9sum\u00e9 les 14 “guidelines” qui doivent \u00eatre comprises et pr\u00e9sentes lorsque on se lance dans le d\u00e9veloppement d’un site mais aussi et plus encore d’une API sinon c’est un peu comme se lancer dans la plong\u00e9e sous-marine sans bouteille d’oxyg\u00e8ne, l’apn\u00e9e n’est pas \u00e0 la port\u00e9e du premier venu.<\/p>\n
Ces recommandations sont tir\u00e9es d’un livre d\u00e9j\u00e0 ancien mais qui reste malgr\u00e9 tout d’actualit\u00e9 High Performance Web Sites<\/code> de Steve Souders.
\n Source : http:\/\/stevesouders.com\/<\/i><\/p>\n Pour ceux qui douteraient de la v\u00e9racit\u00e9 des r\u00e8gles \u00e9nonc\u00e9es ci-dessous, une petite biographie de Steve Souders suffira \u00e0 faire taire les esprits les plus dubitatifs. Pour information, Steve Souders est monsieur Performance chez Google (excusez du peu). Chez Google, il est le grand manitou qui travaille sur les performances Web et les initiatives open source. Au vu des r\u00e9sultats, je veux parler des performances de google comme webservice et non d’un point de vue financier, il est fort \u00e0 parier que ce monsieur connait son affaire. Il la connait d’autant mieux qu’il occupait le m\u00eame poste chez Yahoo ! Il est qui plus est la cr\u00e9ateur de YSlow<\/code> qui doit faire parti avec FireBug<\/code> des add-ons Firefox indispensables \u00e0 tout personne qui s’int\u00e9resse de pr\u00e8s ou de loin au web.<\/p>\n Ceux qui doutent encore me jettent la premi\u00e8re pierre…. Bon les bonnes pratiques maintenant en mati\u00e8re de performances. Pour certaines de ces r\u00e8gles, il est mentionn\u00e9 trivial<\/code> car elles ont la force de \u00e9vidence et ne demande pas \u00eatre expliqu\u00e9, une recherche sur Google est suffisante.<\/p>\n\n- 1 – Faire moins de requ\u00eates HTTP
\nTrivial<\/code> que ce soit avec un CMS ou avec un framework les requ\u00eates HTTP sont une ressource rare \u00e0 pr\u00e9server et \u00e0 utiliser avec parcimonie et son acolyte arm\u00e9nien “\u00e0 bon escient”.\n<\/li>\n- 2 – Utiliser un Content Delivery Network
\n Trivial si on en a les moyens mais Akamai co\u00fbte cher comme les solutions Cloud Amazon ou Windows Azure d’ailleurs qui peuvent \u00e0 leur mani\u00e8re \u00eatre utilis\u00e9 comme solution de caching, nous avons pratiqu\u00e9 la question avec 3WDOC.\n<\/li>\n - 3 – Ajouter un en-t\u00eate Expires
\n Ajouter un en-t\u00eate Expire lointain dans le temps pour les \u00e9l\u00e9ments de contenu. On s’appuie \u00e0 fond sur le cache du navigateur.<\/p>\n - 4 – Utiliser les Composants gzip
\n Il faut activer un bon mode mod_gzip<\/code>, mod_deflate<\/code> selon la version d’Apache sur votre serveur. Il est aussi vivement conseiller de virer l’indentation des flux JSON si vous avez recours \u00e0 ce format dans le cas d’une API qui distribue du contenu. Une sorte de minification du transport de donn\u00e9es.
\n Ce qui se dit c’est que si on “Gzippe” tous les \u00e9l\u00e9ments d’une page. On peut arriver \u00e0 diminuer de 70% le poids moyen d’une page et de facto r\u00e9duire de 50% le temps de chargement de ladite page. Int\u00e9ressant.<\/b>\n <\/li>\n- 5 – Mettre les feuilles de style en top
\n Trivial<\/code>. Une bonne pratique tout simplement.\n <\/li>\n- 6 – Mettre Scripts en bottom
\n Trivial<\/code>. Une autre bonne pratique tout simplement.\n <\/li>\n- 7 – \u00c9viter les expressions CSS
\n Trivial<\/code>. De toutes les fa\u00e7ons, on est en Less (http:\/\/lesscss.org\/<\/a>) ou on s’appuie sur des solutions type Boilerplate (http:\/\/html5boilerplate.com\/<\/a>) ou Bootstrap (http:\/\/getbootstrap.com<\/a>). Pourquoi r\u00e9inviter la roue….\n <\/li>\n- 8 – Placer le JavaScript et les CSS en appel externe
\n Embedder dans les pages, pour debugger ou d\u00e9velopper, mais lorsque on le passe \u00e0 la mise en production, il est bien conseill\u00e9 de faire des appels externes de sorte que ces composants CSS ou\/et Javascript peuvent \u00eatre mis en caches dont toutes les pages qui seront vues apr\u00e8s le premier appel seront plus rapides. Cela est vrai si vous \u00eates chez h\u00e9bergeur “cheap” ou vous avez pris une Ferrari comme environnement de production.<\/p>\n Dans un article pr\u00e9c\u00e8dent, nous nous sommes l\u00e9g\u00e8rement pencher sur la question. Voir Memcached, Varnish \u2013 La probl\u00e9matique du caching pour des sites \u00e0 fort trafic<\/a>\n <\/li>\n- 9 – R\u00e9duire les recherches DNS
\n Il faut r\u00e9duire au maximum les recherches DNS en utilisant la fonction de maintien en activit\u00e9 du protocole HTTP Keep-Alive<\/code> et surtout limiter autant que possible le nombre de domaines. Il existe le jeu perilleux de jouer avec les “time-to-live” (TTL) mais dans ce cas pr\u00e9sent, il faut mieux faire appel \u00e0 un administrateur r\u00e9seau, il doit bien servir \u00e0 quelques chose.\n <\/li>\n- 10 – Minifier le JavaScript
\n Trivial<\/code>. Une excellente pratique.\n <\/li>\n- 11 – Eviter les redirections
\n Eviter autant que faire se peut de faire des redirections dans tous les sens.\n <\/li>\n - 12 – Supprimer les doublons de Scripts
\n Trivial<\/code>. Eviter les redondances comme charger n fois jQuery par exemple, pas toujours \u00e9vident \u00e0 faire respecter lorsque vous faites appel des solutions tierces genre tracking, solution video… puisque tous ces braves prestataires vous impose parfois d’embarquer leur version jQuery par exemple donc inclure tous les scripts en une seule fois n’est pas forcement chose ais\u00e9e.\n <\/li>\n- 13 – Configurer les ETags
\n Jamais bien compris mais bon, le dilemme est simple soit les ETagss sont \u00e0 reconfigurer ou carr\u00e9ment \u00e0 enlever les ETags.\n <\/li>\n - 14 – Faire en sorte que l’Ajax soit cach\u00e9
\n Conseil nettement plus int\u00e9ressant que le precedent. L’usage veut que les IHM, tr\u00e8s UX, soient gav\u00e9s d’Ajax. Il faut donc s’assurer que les requ\u00eates Ajax, puissent \u00eatre cach\u00e9s par exemple et suivent vraiment des directives de performance, en particulier en ayant en-t\u00eate Expire lointain\n <\/li>\n<\/ul>\n Conclusion : si vous avez appliqu\u00e9 \u00e0 la lettre ces bonnes pratiques, vous minimisez les chances d’avoir de tr\u00e8s mauvaise surprises en terme de performance et donc d’affichage. Vous pouvez d’ailleurs mesurer concr\u00e8tement le ROI de chacune de ces mesures avec l’aide de l’utilitaire de monsieur Souders, YSLOW. Merci Steve.<\/b><\/p>\nEn savoir plus<\/h2>\n\n- Steve Souders – High Performance Web Sites, la voix du maitre
http:\/\/stevesouders.com\/<\/a><\/li>\n- High Performance Web Sites
http:\/\/stevesouders.com\/hpws\/<\/a><\/li>\n- YSlow pour Chrome
https:\/\/chrome.google.com\/webstore\/detail\/yslow\/ninejjcohidippngpapiilnmkgllmakh<\/a><\/li>\n- YSlow pour Firefox
https:\/\/addons.mozilla.org\/fr\/firefox\/addon\/yslow\/<\/a><\/li>\n- Un autre opus de Steve Souders
Even Faster Web Sites: Performance Best Practices for Web Developers<\/a><\/li>\n- Un autre sp\u00e9cialiste de la question Andrew G King de Website Optimization
http:\/\/www.websiteoptimization.com\/<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"Que l’on soit \u00e0 la t\u00eate d’un site important ou de taille modeste, c’est \u00e0 dire d\u00e9j\u00e0 avec une grosse volum\u00e9trie de donn\u00e9es. La question… <\/p>\n
Auteur(s) : Steve Souders<\/a>
Edition(s) : O'Reilly Media<\/a>
\n\t\t\t\t\t
Voici donc un tr\u00e8s\/trop r\u00e9sum\u00e9 les 14 “guidelines” qui doivent \u00eatre comprises et pr\u00e9sentes lorsque on se lance dans le d\u00e9veloppement d’un site mais aussi et plus encore d’une API sinon c’est un peu comme se lancer dans la plong\u00e9e sous-marine sans bouteille d’oxyg\u00e8ne, l’apn\u00e9e n’est pas \u00e0 la port\u00e9e du premier venu.<\/p>\n
Ces recommandations sont tir\u00e9es d’un livre d\u00e9j\u00e0 ancien mais qui reste malgr\u00e9 tout d’actualit\u00e9 Pour ceux qui douteraient de la v\u00e9racit\u00e9 des r\u00e8gles \u00e9nonc\u00e9es ci-dessous, une petite biographie de Steve Souders suffira \u00e0 faire taire les esprits les plus dubitatifs. Pour information, Steve Souders est monsieur Performance chez Google (excusez du peu). Chez Google, il est le grand manitou qui travaille sur les performances Web et les initiatives open source. Au vu des r\u00e9sultats, je veux parler des performances de google comme webservice et non d’un point de vue financier, il est fort \u00e0 parier que ce monsieur connait son affaire. Il la connait d’autant mieux qu’il occupait le m\u00eame poste chez Yahoo ! Il est qui plus est la cr\u00e9ateur de Ceux qui doutent encore me jettent la premi\u00e8re pierre…. Bon les bonnes pratiques maintenant en mati\u00e8re de performances. Pour certaines de ces r\u00e8gles, il est mentionn\u00e9 Dans un article pr\u00e9c\u00e8dent, nous nous sommes l\u00e9g\u00e8rement pencher sur la question. Voir Memcached, Varnish \u2013 La probl\u00e9matique du caching pour des sites \u00e0 fort trafic<\/a>\n <\/li>\n Conclusion : si vous avez appliqu\u00e9 \u00e0 la lettre ces bonnes pratiques, vous minimisez les chances d’avoir de tr\u00e8s mauvaise surprises en terme de performance et donc d’affichage. Vous pouvez d’ailleurs mesurer concr\u00e8tement le ROI de chacune de ces mesures avec l’aide de l’utilitaire de monsieur Souders, YSLOW. Merci Steve.<\/b><\/p>\n Que l’on soit \u00e0 la t\u00eate d’un site important ou de taille modeste, c’est \u00e0 dire d\u00e9j\u00e0 avec une grosse volum\u00e9trie de donn\u00e9es. La question… <\/p>\nHigh Performance Web Sites<\/code> de Steve Souders.
\n Source : http:\/\/stevesouders.com\/<\/i><\/p>\nYSlow<\/code> qui doit faire parti avec FireBug<\/code> des add-ons Firefox indispensables \u00e0 tout personne qui s’int\u00e9resse de pr\u00e8s ou de loin au web.<\/p>\ntrivial<\/code> car elles ont la force de \u00e9vidence et ne demande pas \u00eatre expliqu\u00e9, une recherche sur Google est suffisante.<\/p>\n\n
\nTrivial<\/code> que ce soit avec un CMS ou avec un framework les requ\u00eates HTTP sont une ressource rare \u00e0 pr\u00e9server et \u00e0 utiliser avec parcimonie et son acolyte arm\u00e9nien “\u00e0 bon escient”.\n<\/li>\n
\n Trivial si on en a les moyens mais Akamai co\u00fbte cher comme les solutions Cloud Amazon ou Windows Azure d’ailleurs qui peuvent \u00e0 leur mani\u00e8re \u00eatre utilis\u00e9 comme solution de caching, nous avons pratiqu\u00e9 la question avec 3WDOC.\n<\/li>\n
\n Ajouter un en-t\u00eate Expire lointain dans le temps pour les \u00e9l\u00e9ments de contenu. On s’appuie \u00e0 fond sur le cache du navigateur.<\/p>\n
\n Il faut activer un bon mode mod_gzip<\/code>, mod_deflate<\/code> selon la version d’Apache sur votre serveur. Il est aussi vivement conseiller de virer l’indentation des flux JSON si vous avez recours \u00e0 ce format dans le cas d’une API qui distribue du contenu. Une sorte de minification du transport de donn\u00e9es.
\n Ce qui se dit c’est que si on “Gzippe” tous les \u00e9l\u00e9ments d’une page. On peut arriver \u00e0 diminuer de 70% le poids moyen d’une page et de facto r\u00e9duire de 50% le temps de chargement de ladite page. Int\u00e9ressant.<\/b>\n <\/li>\n
\n Trivial<\/code>. Une bonne pratique tout simplement.\n <\/li>\n
\n Trivial<\/code>. Une autre bonne pratique tout simplement.\n <\/li>\n
\n Trivial<\/code>. De toutes les fa\u00e7ons, on est en Less (http:\/\/lesscss.org\/<\/a>) ou on s’appuie sur des solutions type Boilerplate (http:\/\/html5boilerplate.com\/<\/a>) ou Bootstrap (http:\/\/getbootstrap.com<\/a>). Pourquoi r\u00e9inviter la roue….\n <\/li>\n
\n Embedder dans les pages, pour debugger ou d\u00e9velopper, mais lorsque on le passe \u00e0 la mise en production, il est bien conseill\u00e9 de faire des appels externes de sorte que ces composants CSS ou\/et Javascript peuvent \u00eatre mis en caches dont toutes les pages qui seront vues apr\u00e8s le premier appel seront plus rapides. Cela est vrai si vous \u00eates chez h\u00e9bergeur “cheap” ou vous avez pris une Ferrari comme environnement de production.<\/p>\n
\n Il faut r\u00e9duire au maximum les recherches DNS en utilisant la fonction de maintien en activit\u00e9 du protocole HTTP Keep-Alive<\/code> et surtout limiter autant que possible le nombre de domaines. Il existe le jeu perilleux de jouer avec les “time-to-live” (TTL) mais dans ce cas pr\u00e9sent, il faut mieux faire appel \u00e0 un administrateur r\u00e9seau, il doit bien servir \u00e0 quelques chose.\n <\/li>\n
\n Trivial<\/code>. Une excellente pratique.\n <\/li>\n
\n Eviter autant que faire se peut de faire des redirections dans tous les sens.\n <\/li>\n
\n Trivial<\/code>. Eviter les redondances comme charger n fois jQuery par exemple, pas toujours \u00e9vident \u00e0 faire respecter lorsque vous faites appel des solutions tierces genre tracking, solution video… puisque tous ces braves prestataires vous impose parfois d’embarquer leur version jQuery par exemple donc inclure tous les scripts en une seule fois n’est pas forcement chose ais\u00e9e.\n <\/li>\n
\n Jamais bien compris mais bon, le dilemme est simple soit les ETagss sont \u00e0 reconfigurer ou carr\u00e9ment \u00e0 enlever les ETags.\n <\/li>\n
\n Conseil nettement plus int\u00e9ressant que le precedent. L’usage veut que les IHM, tr\u00e8s UX, soient gav\u00e9s d’Ajax. Il faut donc s’assurer que les requ\u00eates Ajax, puissent \u00eatre cach\u00e9s par exemple et suivent vraiment des directives de performance, en particulier en ayant en-t\u00eate Expire lointain\n <\/li>\n<\/ul>\nEn savoir plus<\/h2>\n
\n
http:\/\/stevesouders.com\/<\/a><\/li>\n
http:\/\/stevesouders.com\/hpws\/<\/a><\/li>\n
https:\/\/chrome.google.com\/webstore\/detail\/yslow\/ninejjcohidippngpapiilnmkgllmakh<\/a><\/li>\n
https:\/\/addons.mozilla.org\/fr\/firefox\/addon\/yslow\/<\/a><\/li>\n
Even Faster Web Sites: Performance Best Practices for Web Developers<\/a><\/li>\n
http:\/\/www.websiteoptimization.com\/<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"