Bonnes pratiques Webperf : V1

Par Laurent Denis, le 17 octobre 2012, dans .

Lancés en février dernier, les travaux sur les bonnes pratiques performances Web sont arrivés à leur terme. Nous avons donc le plaisir de vous annoncer la publication de la chek-list Webperf (V1), composée de 41 critères disponibles dans Opquast Reporting.

Le détail des 41 bonnes pratiques

Réparties en trois niveaux selon le degré de difficulté de leur mise en œuvre et leur impact, ces bonnes pratiques se déclinent également par thématiques. De manière prévisible, la principale concerne la gestion serveur, avec 23 bonnes pratiques. Par ailleurs, 7 concernent les styles CSS, 2 le code HTML, 3 les images et 6 les scripts.

La portée et les limites de l’exercice

Il va de soi que ces 41 critères ne prétendent pas épuiser le vaste sujet des pratiques d’optimisation des performances Web. Nous avons dû faire des choix rigoureux et nous en tenir, dans cette première version, à un socle limité mais solide de techniques reconnues, aux bénéfices évalués et attestés. Une autre contrainte clé était l’universalité de la bonne pratique : la gestion des performances relève en effet en partie de choix de stratégies d’optimisation qui dépendent du contexte précis du projet. Nous ne pouvions retenir que ce qui était utile, indépendamment de ces choix.

Et l’automatisation ?

Les tests qui le peuvent (34 sur 41) seront prochainement automatisés dans les feuilles d’évaluation Opquast Reporting ainsi que dans l’extension Opquast Desktop, nous y travaillons.

Utiliser la check-list Webperf

Nous remercions vivement tous ceux qui ont participé à l’élaboration de cette check-list et en particulier à :

  • Frédéric Kayser, Martin Supiot, Nicolas Hoffmann, Matthieu Larcher, Éric Daspet, Jérémie Patonnier, Jean-Pierre Vincent et Nicolas Hoizey ;
  • l’équipe mobilisée chez Temesis : Fabrice Bonny, Laurent Denis, Muriel de Dona et Elie Sloïm.

Grâce à eux, vous pouvez donc :

3 commentaire(s)

  1. Par Aurélien, le 17 octobre 2012 à 15 h 39 min :

    Génial !

    Ps : le lien sur “télécharger” semble pointer vers cet article

  2. Par Tyler, le 17 octobre 2012 à 16 h 39 min :

    C’est du gros boulot qui a été fait là, chapeau bas et c’est une checklist à garder sous la main.

    Il n’y a qu’un point pour lequel je ne suis pas d’accord, c’est le #15 :
    « La saisie utilisateur est validée côté client pour réduire les requêtes comportant des données erronées »

    On peut faire une première validation en Javascript, pour épurer un peu les erreurs “faciles” (non remplissage, etc), et je suis d’accord que ça limite le travail côté serveur, mais il ne faudrait pas non plus valider toutes les saisies côté client.
    D’autant qu’on a souvent besoin de vérifier les saisies avec une requête SQL (éviter un doublon, etc.).

    Je ne me vois pas développer un système de commentaire où la saisie n’est validée qu’en Javascript. Ce serait la porte ouverte à beaucoup de problèmes…

  3. Par Laurent Denis, le 18 octobre 2012 à 9 h 24 min :

    @Tyler : la bonne pratique n’impose en effet pas de mettre en place une validation côté client systématique quel que soit le champ. En pratique, les champs concernés sont ceux pour lesquels il y a déjà une validation côté serveur (le but étant d’éviter les requêtes entraînées par l’invalidation d’une saisie côté serveur).

    La checklist n’est pour le moment que partiellement documentée : les moyens de contrôles et les solutions techniques qui vont venir par la suite pour chaque fiche seront l’occasion de préciser ce genre de chose.

    Merci pour ce retour, il nous aidera à documenter, justement 🙂

Les commentaires sont fermés.