Depuis quelques temps, et en grande partie grâce à Éric, je tente de m’initier aux bonnes pratiques de performance Web.
Armé de l’extension YSlow, j’essaye de mettre en place une configuration la plus performante possible.
Bonne nouvelle
Certaines des recommandations sont évidentes et du coup il est rassurant de voir qu’on suit déjà ses principes :
- externaliser les fichiers CSS et JS ;
- éviter les redirections ;
- ne pas dupliquer les scripts ;
- réduire la taille de l’arbre HTML ;
- utiliser le moins possible d’iframes ;
- éviter les pages 404 ;
- préférer
<link>à@import; - optimisez au mieux les images et
- ne pas les redimensionner côté client.
Les premières étapes
Beaucoup de règles se comprennent aisément, et il suffit d’adapter son code pour s’y conformer.
Je me suis ainsi retrouvé à :
- déplacer mes appels JS en bas de page ;
- utiliser bien plus souvent la technique des sprites CSS ;
- concaténer mes fichiers CSS et mes fichiers JS ;
- limiter au maximum l’utilisation des filtres ;
- minimiser la taille des mes fichiers CSS et JS ;
- faire attention à mes appels au DOM et
- réduire la taille de mes favicons.
La suite
Arrive maintenant les points qui me semblent plus obscurs (que je découvre à peine). À savoir :
- gérer le cache au mieux ;
- compresser les fichiers ;
- configurer les ETags ;
- vider le buffer ;
- etc.
Et pour les professionnels de l’optimisation et de l’hébergement
Reste ensuite quelques points plus spécifiques qui, de mon avis, sont réservés aux professionnels ou tout du moins, bien peu évidents à mettre en place :
- l’utilisation d’un CDN ou encore
- la répartition des contenus sur plusieurs domaines.
Mes interrogations du moment
Elles sont multiples.
J’aimerais comprendre pourquoi malgré mes efforts certains de mes contenus ne sont pas Gzippés, comprendre un peu mieux les principes de ETags, fouiller un peu du côté de cette fonction flush(), automatiser les compressions et les concaténations, etc.
Et justement sur ce dernier point, j’expérimente en ce moment deux techniques. Celle de Niels Leenheer pour concaténer les fichiers et celle de Douglas Crockford pour minimiser le code JS.
Avez-vous des conseils à me donner sur ces sujets ? Est-ce des domaines que vous découvrez également ?
12 commentaires ↓
Salut a tous et merci pour l’article 20cent.
pour la partie « Bonne nouvelle », je suis ok avec toi pour dire que ce sont des automatismes de dev front qui font partis de mon quotidien maintenant.
pour la partie « premières étapes », j’ai encore du mal a disposer mes déclaration d’appel js en fin de code HTML.
sinon je suis disponible pour en parler autour d’une bierre ou d’un jus de goyave quand vous le voulez d’une manière générale, il faudrait également que je prenne le plis de la compression css/js/html avant toutes mise en prod, mais c’est une démarche de dev un peu fatigante quand on a pris l’habitude de pusher a vau l’eau des fichiers tel quel.
après effectivement si on avais pas de client, qu’on vivais au pays de bambi et que j’avais donald duck comme voisin, j’utiliserais jamais au grand jamais ni filtres, ni iframes, ni png transparents.
Ahah Etienne ! C’est cool de te lire.
Quelques lectures rien que pour toi alors :
Pour le jus de goyave, on se tient au courant rapido, très bonne idée !
Je lis ce blog Performance Web mais je n’ai pas encore vraiment mis en place toutes ces bonnes pratiques même si certaines sont « naturelles ».
Hello Monsieur dont je découvre le blog à travers ce billet. Je m’étais promis de me pencher aussi sur la question et mis de côté un lien sur certaines optimisations via la .htaccess : http://perishablepress.com/press/2006/01/10/stupid-htaccess-tricks/ Il y a du boulot en perspective. 😉
Excellent résumé des articles d’Éric
Pour la minification des documents JS et CSS je pense qu’on peu facilement s’y faire avec des environnements de développement… Un environnement de dev sur lequel tous les fichiers sont normaux. Un environnemment de préprod qui nous servira à effectuer autant la recette pour le client, que les tests utilisateurs et les tests de performance … sur lequel ont minimiserait les fichiers grâce à des scripts shell par exemple, la minification manuelle d’une centaine de fichiers par jour étant inconcevable 😉 Et finalement un environnement de prod identique à la préprod, gzip, minifié, etc 😉
Sinon les JS en fin de document … c’est pas toujours possible techniquement, certaines fonctionnalités JavaScript doivent être présente au chargement du DOM (avant l’affichage dans le navigateur). Ils sont néanmoins très rare.
Salut Yves,
Avoir un environnement de prod, preprod et dev, ce n’est pas donné à tout le monde quand même.
Pour tout ce qui est des scripts sur le shell, je suis totalement perdu moi… d’où cette solution en php qui me plait bien.
(Tiens je viens de te laisser un commentaire où je parle de contexte, en voilà un deuxième)
Dans le web mobile, pour des questions de performance justement, on préconise de mettre la CSS dans le
head.Nous allons tous devoir réapprendre les notions de contexte, en remplaçant « variantes de navigateurs bureautiques » par « variantes d’interfaces et de situations de navigation ».
Euh… on mets tjs la CSS dans le
headnon ?Intéressante réflexion Stéphane, je me demande d’ailleurs comment nous allons nous y prendre pour « émuler » ces “variantes d’interfaces et de situations de navigation”… Vais-je enfin devoir acquérir un téléphone pour tester mes sites sur le web mobile ? =þ
@Vincent:
Ce que je veux dire c’est que pour le web de bureau, pour des histoires de mise en cache etc., nous mettons nos instructions CSS dans un fichier externe que nous appelons dans le
head.Pour le web mobile, nous devons mettre une série d’instructions CSS conçue tout exprès entre les balises
styledirectement dans le code de la page, et plus dans un fichier externe, pour éviter de multiplier les requêtes HTTP.Ah voilà ! Merci pour les précisions.
« Eviter les pages 404 ? » c’est dommage, mais c’est une des premières recommandations que l’on vient à donner à un client. Cela relève de l’expérience utilisateur, du bon sens, et c’est souvent obligatoire pour tous les outils de suivi (Google Webmaster Tools, Site Explorer, webmaster Live). Et quand je vais lire le site http://performance.survol.fr/2008/04/pages-d-erreur/#more-20 ils disent pas du tout ça.
Allez, je mets ça sur le compte de la fatigue et te propose pas un jus de goyave mais du houblon sous forme liquide !! Façon compressé avec le chevelu et Ht1 en back-up !
Laisser un commentaire