Imaginons que vous disposez d'une plate-forme d'intégration continue (idéalement Jenkins ou Hudson) pour vos projets PHP (si ce n'est pas le cas, je vous invite à lire les excellents billets de Pascal Martin : Intégration continue avec Jenkins : installation et configuration de base et Intégration continue d'un projet PHP avec Jenkins).

Imaginons que vous n'utilisez pas Ant comme outil d'automatisation (de build) mais plutôt Phing parce que vous maîtrisez cet outil.

Imaginons que vous souhaitez également vérifier la qualité de vos développement Javascript (Dans un projet PHP, vous avez sûrement un peu de Javascript, non ?) et que vous souhaitez disposer d'indicateur de suivi de la qualité dans Jenkins.

Il existe plusieurs outils pour vérifier la qualité de son code Javascript :

• Jslint de Douglas Crockford
• jslint4java un portage de jslint de Douglas Crockford en Java
• Google Closure Linter un outil développé par Google
• JsHint un fork de Jslint
• Javascript Lint dit JSL est un portage de jslint en Python.

L'outil JSL n'a pas évolué depuis 2007. Il nécessite d'être installé en suivant l'une de ces procédures. Avantage, il existe une tâche Phing pour exécuter JSL. Inconvénient, il n'est pas possible de générer un fichier XML compréhensible par Jenkins.

Je n'ai pas regardé Google Closure Linter.

JSHint semble intéressant. Mais à nouveau, il ne semble pas y avoir de mécanisme simple permettant de l'intégrer à Jenkins.

Jslint ne permet pas, a priori, nativement de générer un fichier XML compréhensible par Jenkins.

Je me suis donc tourné vers jslint4java. Je me suis inspiré du travail de Stephen Rees (qui utilise Ant) pour implémenter l'exécution de Jslint avec phing.

Voici le résultat :

    <!-- Fichier temporaire contenant la liste des fichiers JS à traiter avec JSLint -->
    <property name="temp_file_all_js" value="/tmp/${phing.project.name}/all_js.txt" override="true" />     

    <!-- Chemin vers Jslint4java -->
    <property name="jslint4java" value="/chemin/vers/jslint4java/jslint4java-2.0.0.jar" override="true" />     

    <!-- création d'un patternset contenant l'ensemble des fichiers JS à analyser -->
    <!-- on exclut les fichiers JQuery et les fichiers minimifiés -->
    <patternset id="js_files">
        <include name="public/js/**/*.js"/>
        <exclude name="public/js/**/*-min.js"/>
        <exclude name="public/js/jquery*.js"/>
    </patternset>

   <!-- ============================================  -->
    <!--   (jslint) Target: vérification syntaxe JS    -->
    <!-- attention à créer au préalable un patternset  -->
    <!-- ayant pour nom js_files                        -->
    <!-- ============================================  -->
    <target name="jslint">
        
        <!-- créer le repertoire de stockage du fichier temporaire -->
        <!-- s'il n'existe pas                                     -->
        <php function="dirname" returnProperty="temp_dir">
            <param value="${temp_file_all_js}"/>
        </php>
        <mkdir dir="${temp_dir}" />
        
        <!-- crée un fichier temporaire contenant la liste des fichiers JS à traiter -->
        <!-- cette liste se base sur le patternset refid=js_files -->
        <foreach param="filename" absparam="absfilename" target="_createFilesetText">
            <fileset dir="${install_dir}">
                <patternset refid="js_files" />
            </fileset>
        </foreach>
    
        <!-- on charge le contenu de temp_file_all_js dans la variable ${all_js} -->
        <loadfile property="all_js" file="${temp_file_all_js}"/>
        <echo>Fichiers analysés par JSLint : ${all_js}</echo>
        
        <!-- exécution de jslint4java                       -->
        <!-- browser permet de définir les variables du navigateur dans le contexte d'exécution -->
        <!-- prefed permet de définir les variables dans le contexte d'exécution -->
        <!-- voir : http://code.google.com/p/jslint4java/source/browse/jslint4java-docs/src/main/resources/cli.html -->
        <exec 
            command="java -jar ${jslint4java}
                     --browser --predef $,document,jQuery
                     --report xml
                     ${all_js} > ${builddir}/logs/jslint.xml" 
            passthru="true" 
        />
        
        <delete file="${temp_file_all_js}" />
    </target>

   <!-- ============================================  -->
    <!--   _createFilesetText Target:                  -->
    <!-- stocke la liste des fichiers JS à traiter     -->
    <!-- dans le fichier /tmp/all_js.txt               -->
    <!-- ============================================  -->
    <target name="_createFilesetText" >
        <echo file="${temp_file_all_js}" append="true">${absfilename} </echo>
    </target>

Vous devez ensuite appeler cette tâche dans votre tâche principale de build. Quelque chose comme ça :

<target name="build">
        <echo msg="tâche build" />
        <phingcall target="php-doc" />
        <phingcall target="pdepend"/>
        <phingcall target="phpmd"/>
        <phingcall target="phpcpd"/>
        <phingcall target="phploc"/>
        <phingcall target="php-cs" />
	<phingcall target="php-cb" />
	<phingcall target="phpunit" />
       <!-- on lance la vérification syntaxique de JS -->
        <phingcall target="jslint" />
 </target>

Vous pourrez ensuite configurer dans Jenkins l'appel du fichier de log (build/log/jslint.xml) :

Après l'exécution du build, vous devriez avoir dans le menu Violations, quelque chose comme ça :

J'ai assisté hier, pour la seconde fois, à l'atelier webperf organisé par le Webperf User Group et principalement Eric.

L'objectif de la soirée était d'analyser quelques sites en 30 minutes par groupe de 5 à 10 personnes puis d'échanger sur les analyses effectuées et sur les solutions possibles pour améliorer la performance (navigateur, réseaux) du site.

Nous avons bien sûr évoqués

• les outils habituels :
  • YSlow!
  • Webpagetest

• et les méthodes classiques d'optimisation :
  • réduction du nombre de requêtes
  • concaténation des fichiers JS/CSS
  • gestion des expirations des contenus
  • compression des contenus envoyés au navigateur (gzip & co)
  • sprite des images CSS
  • ...

L'intérêt de la soirée résidait dans les astuces proposées qui étaient directement applicables aux sites audités. J'en ai relevé quelques unes. Certaines pourraient être généralisées à vos projets :

• Une bonne pratique pourrait être d'ajouter dès aujourd'hui dans le code HTML les balises <link rel="prefetch" afin d'indiquer au navigateur de "préfetcher" certains éléments (exemple : requête DNS, ...). Tous les navigateurs ne supportent pas cette fonctionnalité. Quelques articles pour développer le sujet :
  • DNS Prefecth par Eric Daspet
  • HTML5 Link Prefetch par David Walsh
• Le chargement des feuilles de styles d'impression (media=print) peut "ralentir" le chargement d'une page (ajout d'une requête) alors que dans la plupart des cas, elle n'est pas nécessaire dans le contexte de navigation. Une bonne pratique pourrait être :
  • soit de charger les styles spécifiques via @media
  • soit de la charger via JS (en mode asynchrone)
• Suite au commentaire de Vincent Voyer, attention de ne pas charger la feuille de styles CSS print en fin de document (sinon, les navigateurs comme IE6 et 7 n'afficheront rien tant que tous les CSS ne seront pas téléchargés.)
• Si vous utilisez les commentaires conditionnels, il est nécessaire d'ajouter avant le HEAD un commentaire conditionnel vide. Sinon, IE bloque le téléchargement parallèle pendant le chargement de la première CSS (voir les commentaires pour les ressources permettant de valider ce problème). Voir le site de 20minutes.fr qui met en pratique cette technique
• Du fait, du faible nombre de téléchargement parallèle sous IE, il est préférable d'ajouter une classe IE sur le <body> (voire <html> comme le propose Nicolas Hoizey dans les commentaires) et cibler les styles IE via cette classe plutôt que d'avoir un fichier CSS dédié (hack-ie-6.css). On dispose ainsi que d'un seul fichier CSS pour l'ensemble des navigateurs.
• Google Analytics propose deux modes (synchrone, asynchrone). Il est préférable d'utiliser la version asynchrone (dernière version disponible).
• Afin d'éviter que le cookie de Google Analytics soient positionnés sur l'ensemble des sous-domaines, il est possible de lui dire de le positionner que sur un seul domaine en particulier via _gaq.push(['_setDomainName', 'mondomaine']), je pense
• Pour des images inférieures à 100x150, il est souvent préférable de passer en PNG8 plutôt qu'en JPEG. La dégradation de la qualité de l'image ne sera pas perçue (ressource nécessaire pour valider ce point).

Enfin, quelques outils que je ne connaissais pas

• Pour les performances sur mobiles :
  • blaze.io : équivalent webpagetest pour Mobile mais les résultats ne sont pas toujours très pertinents
  • 5o9inc.com propose un APK à installer sur un téléphone Androïd afin de collecter des informations sur les performances du site mobile.
• Pour l'analyse :
  • speedtracer : pour suivre le traitement du chargement d'un site dans le navigateur (traitement du javascript, reflow, analyse CSS,...). C'est une extension pour Google Chrome ou Chromium.
• Pour le chargement des fichiers JS
  • requirejs : équivalent à headJS, ...

C'est tout pour le moment.

Edit : Correction suite différents commentaires.