Emplacement et déploiement des assetsDans Symfony2, les assets doivent être stockés dans le répertoire«  Resources/public  » du bundle auxquels ils sont liés. Ce répertoiren’étant pas accessible depuis l’extérieur, une manipulation est nécessai-re afin de les «  publier  », c’est-à-dire de les copier dans un répertoireaccessible publiquement. Cette opération est réalisée à l’aide de la com-mande :

php app/console assets:install

Cette commande va copier les assets de chaque bundle (du projet maiségalement des bundles tiers) vers le dossier « web » (par défaut, le seulrépertoire accessible publiquement) en suivant la nomenclature suivante« (web/)bundles/nombundle ».Afin d’être prise en compte, toute modification, ajout ou suppression defichier d’asset doit donc être suivi du redéploiement complet des assets.Afin d’éviter cette manipulation fastidieuse lors de la phase de dévelop-pement, on peut utiliser l’option --symlink de la commande précédente.Au lieu d’effectuer une copie physique des fichiers (« hard mode »), celle-ci va créer un lien symbolique vers les dossiers «  public  » de chaquebundle, permettant ainsi la prise en compte immédiate des modifications.Attention en revanche à ne pas utiliser cette option en environnement deproduction pour des raisons de performance.

Faire référence auxassetsPour l’exemple, considérons que l’on dis-pose d’un bundle AcmeDemoBundle quipossède les assets suivants : Fig.1.Le layout TWIG devrait donc ressembler àceci : Fig.2.On peut remarquer que l’on fait référenceau chemin des assets via la fonction« asset() ».Cette dernière reçoit un chemin publicrelatif, c’est-à-dire celui qui correspond auchemin de l’asset une fois publié, et se

Assetic & Symfony2 : améliorer les performances de votre siteLa gestion des assets fait partie intégrante du travail d’un développeur web. Ces fichiers (images,scripts clients, feuilles de styles, etc.) ont un impact direct sur les performances d’un site etnotamment sur le temps de chargement de ses pages. Le framework Symfony2 met à la dispositiondu développeur divers outils afin de rendre cette tâche plus aisée. Voyons comment utiliserpleinement ces derniers afin d’améliorer les performances de votre site.

charge de la traduire en url. Le code HTML d’une page ressemble alors àceci : Fig.3.

Eviter les problèmes de cacheL’un des avantages de l’utilisation de la fonction « asset » est la possibili-té de suffixer très facilement l’ensemble des assets avec un numéro derévision. Cette méthode, appelée cache busting, permet d’empêcherl’utilisation du cache navigateur après une montée en version dessources. Pour ceci, il nous suffit d’activer la fonction dans la configurationdu framework :

app/config/config.yml

En saisissant ici, par exemple, la valeur « v3 » pour l’attribut « asset_ver-sion », chaque référence au chemin d’un asset ressemble désormais àcela :

Il nous suffit donc d’incrémenter (manuellement ou via un script de miseen production) ce numéro de version à chaque montée de version afind’éviter les problèmes récurrents de cache chez les utilisateurs quechaque développeur ne connaît que trop bien !

Aller plus loin grâce à AsseticNous venons de voir que Symfony propose de base des fonctionssimples pour les assets. Pour aller plus loin, le framework intègre Assetic, une solution tierce quiva permettre de pousser la gestion des assets en automatisant certainstraitements.Commençons par optimiser le chargement des fichiers JS : notre projeten utilise 7 que nous chargeons pour le moment individuellement. L’undes premiers services que peut rendre Assetic est d’automatiser le char-

php

50 Programmez! < Septembre 2014

Fig.1

Fig.2 Fig.3

038_055_177 19/08/14 21:50 Page50

phpgement de ces derniers. Modifions notre layout comme ceci :

On remarque l’utilisation du tag « javascripts » qui reçoit un ou plusieurschemins en paramètre ainsi que le template du code HTML qui va être uti-lisé pour les charger (où « asset_url » sera remplacé automatiquement parl’url du fichier). Ces chemins peuvent accepter des jokers (« * ») permettant ainsi le char-gement automatique du contenu d’un répertoire (mais pas de ses sous-répertoires qui doivent être chargés indépendamment). Il est à noter que,dans ce cas, les fichiers sont chargés dans l’ordre alphabétique. Il peutêtre parfois intéressant de contrôler l’ordre de chargement des fichiers enles préfixant par exemple d’un numéro de priorité (ex : 00-jquery.js).Regardons maintenant le rendu HTML suite à la modification du layout :

On remarque que les fichiers sont désormais préfixés par un hash et sontappelés depuis un répertoire « js » qui n’existe pas physiquement à l’heu-re actuelle.Lorsque l’on se trouve en environnement de développement, Symfony vaintercepter ces appels et les rediriger vers le chemin public du fichier adé-quat. Ce comportement est appréciable car il permet de debugger facile-ment d’éventuelles erreurs JS en pouvant identifier le fichier d’où provientl’erreur. En production, en revanche, Assetic va nous rendre un secondservice en concaténant automatiquement l’ensemble des fichiers en ununique asset réduisant ainsi drastiquement le nombre de requêtes, et enaméliorant du même coup le temps de chargement de nos pages.Pour cela, de la même façon qu’il faut publier préalablement les assets, ilfaut également demander à Assetic de réaliser la concaténation desfichiers et d’en publier le fichier résultant.On réalise cette opération via la commande suivante :

php app/console assetic:dump --env=prod

Assetic génère alors des fichiers dans le répertoire web/js.On peut vérifier que le rendu HTML est maintenant différent en environ-nement de production :

Il est à noter que ces manipulations devront être renouvelées à chaquemise en production afin que les modifications soient prises en compte.

Petite astuce:Si vous chargez vos fichiers avec des chemins contenant des jokers(« * »), il peut arriver qu’au cours de vos développements, l’ajout (ou lasuppression) d’un fichier ne soit pas pris en compte. Pour forcer Asseticà rechercher les nouveaux fichiers, modifiez une ligne de paramètres dutag « javascripts » (en remplaçant par exemple « *.js » par « *.* » ou en

inter-changeant l’ordre de 2 lignes), rafraîchissez votre page puis annulezvos modifications; cela forcera Assetic à les prendre en compte.

L’intérêt d’Assetic : les filtresL’un des intérêts principaux d’Assetic est qu’il permet de piloter des outilsexternes afin qu’ils effectuent des tâches sur nos assets. De base Asseticsait piloter une trentaine de filtres qui vont permettre par exemple de com-presser, minifier ou encore compiler nos scripts. Les outils pilotés parAssetic doivent être installés sur la machine où le déploiement a lieu.Continuons donc à optimiser notre projet : Actuellement, Assetic a conca-téné nos fichiers JS en un unique fichier permettant de gagner 6 requêtessur chacune de nos pages mais la taille de ce fichier n’a pas été optimi-sée. Nous allons donc demander à Assetic de minifier les assets en utili-sant l’utilitaire UglifyJS.Nous ne détaillerons pas l’installation d’UglifyJS, celle-ci se réalise viaNPM (Gestionnaire de paquets de Node.js) et de nombreux tutoriaux trai-tant de ce sujet sont disponibles sur le web.On indique tout d’abord à Assetic que l’on souhaite piloter UglifyJS via lefichier de configuration (adaptez le chemin des binaires selon votre confi-guration) :app/config/config.yml

On demande ensuite à Assetic d’appliquer ce filtre sur nos assets via unedirective du tag « javascripts ».

On remarque que le nom du filtre est préfixé d’un « ? ». Cela permet den’appliquer ce filtre qu’en environnement de production. En effet la minifi-cation n’apporte aucun bénéfice en développement (il devient plus diffici-le de débugger) et entraîne une baisse sensible des performances (l’opé-ration de minification devrait être effectuée à chaque chargement de l’as-set). Si l’on « dump » les assets une nouvelle fois, nos 7 fichiers sont désor-mais concaténés en un seul et unique fichier qui a été minifié, améliorantune nouvelle fois les performances de chargement de nos pages.

Optimisation des CSS Attaquons-nous maintenant aux fichiers CSS de notre projet.Ils sont au nombre de 3, nous allons donc commencer par les chargerautomatiquement. Pour cela nous modifions le layout TWIG comme ceci :

Cette fois-ci nous utilisons le tag « stylesheets » qui est l’équivalent du tag«  javascripts  » pour les feuilles de style CSS. On remarque également

51Septembre 2014 > Programmez!

038_055_177 19/08/14 21:50 Page51

l’utilisation d’un filtre «  cssrewrite  ». En effet, si l’on regarde le renduHTML, on remarque que les fichiers CSS sont désormais appelés depuisle chemin « css ».

L’utilisation de ce chemin, différent de l’emplacement réel du fichier, peutcasser les liens vers d’éventuelles images ou polices de caractères conte-nus dans le CSS. Le filtre cssrewrite va automatiquement parcourir lesfichiers CSS et réécrire à la volée les chemins qui y sont contenus afinqu’ils fonctionnent avec ce nouveau chemin « /css ». De la même façon que pour les fichiers javascripts, les fichiers serontchargés individuellement en environnement de développement (ou toutenvironnement ou le mode de debug est activé) mais concaténés auto-matiquement en production.Ainsi si l’on « dump » de nouveau les assets et que l’on se place en envi-ronnement de production, on obtient un seul appel vers les CSS dans lecode généré :

Tout comme pour les fichiers JS, d’autres filtres existent également etpermettent, entre autres, de minifier les feuilles de styles (avec l’aide dufiltre UglifyCSS par exemple).

Dernière étape : Les imagesNous avons donc amélioré les performances de notre projet sur lesappels JS et CSS, reste maintenant à améliorer nos images. Assetic per-met également de s’attaquer à ce point grâce à de nombreux filtres spé-cialisés dans les formats web les plus courants.Un appel vers une image se traduit normalement par le code suivant :

Afin qu’Assetic prenne en charge nos images nous allons le remplacer parle code suivant :

Nous remarquons l’utilisation du tag «  image », semblable aux 2 précé-dents, qui accepte en paramètre le chemin de l’image et le templateHTML à utiliser.Nous allons ensuite utiliser les filtres OptiPNG et JpegOptim afin d’opti-miser les images PNG et JPEG de notre projet (nous considérons que les2 utilitaires du même nom sont installés sur la machine). Pour cela nous configurons Assetic comme ceci :

app/config/config.yml

Nous déclarons donc les filtres « optipng » et « jpegoptim » et pour cha-cun d’eux les chemins des exécutables et les options d’optimisation. Ici,on souhaite par exemple limiter la qualité à 50% pour les fichiers JPEG età 3 pour les fichiers PNG ainsi que supprimer l’ensemble des donnéesEXIM présentes dans les fichiers JPEG. On applique ensuite automati-quement ces filtres sur les fichiers qui portent une extension en PNG(pour OptiPNG) et JPG/JPEG (pour JpegOptim) grâce à la directive« apply_to ». Il n’est donc pas utile de spécifier le(s) filtre(s) à utiliser dansles vues, ce fichier de configuration pilote l’ensemble des images du pro-jet qui utilisent le tag « image ».Le traitement des images nécessitant du temps et des ressources il estpréférable de l’activer uniquement en environnement de production (enactivant les filtres uniquement dans config_prod.yml par exemple). Lesimages seront alors traitées lors de la mise en production via la comman-de de « dump » d’Assetic.

ConclusionAssetic permet en peu de temps d’améliorer à la fois notre confort dedéveloppement (via le chargement automatique des assets par exemple)mais également les performances finales de notre site en limitant lenombre et la taille des requêtes de nos pages. Mais les possibilitésoffertes par cet outil ne s’arrêtent pas là ! Il peut par exemple simplifier lesdéveloppements et déploiements en se chargeant de compiler desfeuilles SASS/LESS ou encore des scripts CoffeeScript ou Dart !Bien que son intégration au sein de Symfony en fasse un outil à la foissimple et puissant à utiliser, il peut également être utilisé en tant que librai-rie sur un projet n’utilisant pas ce framework.N’hésitez pas à vous rendre sur le site du projet qui recense les filtres dis-ponibles et dont la liste évolue régulièrement.

Pour aller plus loinAssetic : https://github.com/kriswallsmith/assetic

Antoine PACAUDArchitecte technique chez Webnet www.webnet.fr

php

52 Programmez! < Septembre 2014

PDF30 € par an soit 2,73 € le numéro

www.programmez.com

Créer et gérer un projet Open Source

L’informatique quantique

L’ultim

e fro

ntiè

re ?

DITES-LE AVEC DES APIDeezer, S

kype,

Lync, Yammer

PRO

GRA

MM

EZ

3’:HIKONB=^UZ^Z]:?a@b@r@p@a"; E

Printed in EU - Imprimé en UE - BELGIQUE 6,45 €

SUISSE 12 FS - LUXEMBOURG 6,45 € DOM Surf 6,90 €

Canada 8,95 $ CAN - TOM 940 XPF - MAROC 50 DH

Mensuel n°175 - Juin 2014

08-0

6-13

© w

hanw

hana

i (us

ine)

JavaL’essentie

l d

e

Devoxx France 2014

Coding4FunRaspberry Pi :

plus fo

rt q

ue ja

mais

Déjeunez intelligent !

Osez le

Brown

Bag Lunch

Xam

arin

, N

okia X

, W

indows P

hone 8

.1, F

ire

fo

x O

S

Un code pour les gouverner tous !

10-1

3-10

© m

stay

(tor

nade

)

100% mobile avec : Abonnement

038_055_177 19/08/14 21:50 Page52