Performance, Web, API – Les bonnes pratiques pour optimiser les performances d’un site ou d’une webapp

by Posted on


Que l’on soit à la tête d’un site important ou de taille modeste, c’est à dire déjà avec une grosse volumétrie de données. La question de la performance et de la vitesse d’accession aux données est clé. Cette préoccupation est encore plus vraie lorsque vous vous apprêtez ou que vous êtes en train de travailler sur le dimensionnent d’une API qui va par exemple fournir des flux de données non pas seulement à un site web mais à plusieurs sites web, à des applications mobiles et tablettes à des applications de TV connectée et le tout par exemple en plusieurs langues.
Dans ce cas, il va falloir avant de se lancer dans le développement d’une tel API, avoir en tête la performance en-user constamment en ligne de mire sinon vous risquez la catastrophe.

High Performance Web Sites: Essential Knowledge for Frontend Engineers

High Performance Web Sites: Essential Knowledge for Frontend Engineers

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é, http request minimisé...etc.). Un compte-rendu est disponible sur ce site avec quelques retours d'usage maison.

Genre(s) : , , , , , , , , , , , , , , , , , , , , , , , , ,
Auteur(s) :
Edition(s) :
+ d'infos

Voici donc un très/trop résumé les 14 “guidelines” qui doivent être comprises et présentes lorsque on se lance dans le développement d’un site mais aussi et plus encore d’une API sinon c’est un peu comme se lancer dans la plongée sous-marine sans bouteille d’oxygène, l’apnée n’est pas à la portée du premier venu.

Ces recommandations sont tirées d’un livre déjà ancien mais qui reste malgré tout d’actualité High Performance Web Sites de Steve Souders.
Source : http://stevesouders.com/

Pour ceux qui douteraient de la véracité des règles énoncées ci-dessous, une petite biographie de Steve Souders suffira à 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ésultats, je veux parler des performances de google comme webservice et non d’un point de vue financier, il est fort à parier que ce monsieur connait son affaire. Il la connait d’autant mieux qu’il occupait le même poste chez Yahoo ! Il est qui plus est la créateur de YSlow qui doit faire parti avec FireBug des add-ons Firefox indispensables à tout personne qui s’intéresse de près ou de loin au web.

Ceux qui doutent encore me jettent la première pierre…. Bon les bonnes pratiques maintenant en matière de performances. Pour certaines de ces règles, il est mentionné trivial car elles ont la force de évidence et ne demande pas être expliqué, une recherche sur Google est suffisante.

  • 1 – Faire moins de requêtes HTTP
    Trivial que ce soit avec un CMS ou avec un framework les requêtes HTTP sont une ressource rare à préserver et à utiliser avec parcimonie et son acolyte arménien “à bon escient”.
  • 2 – Utiliser un Content Delivery Network
    Trivial si on en a les moyens mais Akamai coûte cher comme les solutions Cloud Amazon ou Windows Azure d’ailleurs qui peuvent à leur manière être utilisé comme solution de caching, nous avons pratiqué la question avec 3WDOC.
  • 3 – Ajouter un en-tête Expires
    Ajouter un en-tête Expire lointain dans le temps pour les éléments de contenu. On s’appuie à fond sur le cache du navigateur.

  • 4 – Utiliser les Composants gzip
    Il faut activer un bon mode mod_gzip, mod_deflate selon la version d’Apache sur votre serveur. Il est aussi vivement conseiller de virer l’indentation des flux JSON si vous avez recours à ce format dans le cas d’une API qui distribue du contenu. Une sorte de minification du transport de données.
    Ce qui se dit c’est que si on “Gzippe” tous les éléments d’une page. On peut arriver à diminuer de 70% le poids moyen d’une page et de facto réduire de 50% le temps de chargement de ladite page. Intéressant.
  • 5 – Mettre les feuilles de style en top
    Trivial. Une bonne pratique tout simplement.
  • 6 – Mettre Scripts en bottom
    Trivial. Une autre bonne pratique tout simplement.
  • 7 – Éviter les expressions CSS
    Trivial. De toutes les façons, on est en Less (http://lesscss.org/) ou on s’appuie sur des solutions type Boilerplate (http://html5boilerplate.com/) ou Bootstrap (http://getbootstrap.com). Pourquoi réinviter la roue….
  • 8 – Placer le JavaScript et les CSS en appel externe
    Embedder dans les pages, pour debugger ou développer, mais lorsque on le passe à la mise en production, il est bien conseillé de faire des appels externes de sorte que ces composants CSS ou/et Javascript peuvent être mis en caches dont toutes les pages qui seront vues après le premier appel seront plus rapides. Cela est vrai si vous êtes chez hébergeur “cheap” ou vous avez pris une Ferrari comme environnement de production.

    Dans un article précèdent, nous nous sommes légèrement pencher sur la question. Voir Memcached, Varnish – La problématique du caching pour des sites à fort trafic

  • 9 – Réduire les recherches DNS
    Il faut réduire au maximum les recherches DNS en utilisant la fonction de maintien en activité du protocole HTTP Keep-Alive 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ésent, il faut mieux faire appel à un administrateur réseau, il doit bien servir à quelques chose.
  • 10 – Minifier le JavaScript
    Trivial. Une excellente pratique.
  • 11 – Eviter les redirections
    Eviter autant que faire se peut de faire des redirections dans tous les sens.
  • 12 – Supprimer les doublons de Scripts
    Trivial. Eviter les redondances comme charger n fois jQuery par exemple, pas toujours évident à 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ée.
  • 13 – Configurer les ETags
    Jamais bien compris mais bon, le dilemme est simple soit les ETagss sont à reconfigurer ou carrément à enlever les ETags.
  • 14 – Faire en sorte que l’Ajax soit caché
    Conseil nettement plus intéressant que le precedent. L’usage veut que les IHM, très UX, soient gavés d’Ajax. Il faut donc s’assurer que les requêtes Ajax, puissent être cachés par exemple et suivent vraiment des directives de performance, en particulier en ayant en-tête Expire lointain

Conclusion : si vous avez appliqué à la lettre ces bonnes pratiques, vous minimisez les chances d’avoir de très mauvaise surprises en terme de performance et donc d’affichage. Vous pouvez d’ailleurs mesurer concrètement le ROI de chacune de ces mesures avec l’aide de l’utilitaire de monsieur Souders, YSLOW. Merci Steve.

En savoir plus

Published by Bruno Flaven

By now, Bruno Flaven works as AI Coordinator. He has been a project manager in a wide variety of Internet business applications both in Mobile and in Desktop for 20 years now. You can find more information about his professional life on his personal website (www.flaven.fr) or his linkedin profile: https://www.linkedin.com/in/brunoflaven. He is currently working In France Media Monde (FMM) mostly on mobile applications (iOS and Android). He has also worked as P.O for a Backoffice project made with Symfony. He also made few trainings to facilitate the handling of the tools that he helps to make.

Related Posts