juil 13

Introduction

Beaucoup de principes sont généraux à tous les frameworks, qu’ils s’agissent d’un site Magento, Prestashop, WordPress, Drupal, etc… Certains Framework ou plugins de ces solutions vous aident nativement à le faire, d’autre n’ont pas cette possibilité ou cette richesse en stock.

J’ai récemment refais le site de NBS System (ma société) de A à Z avec nos amis de l’agence DnD et forcément, on s’est un peu intéressés à l’optimisation. C’est un chemin complexe mais passionnant alors autant vous faire partager quelques trouvailles dans le domaine.

Je ne reviens pas sur le pourquoi, optimiser c’est bien, améliorer l’expérience utilisateur c’est bien, avoir un meilleur référencement naturel car on charge vite, c’est bien. De toute façon vous surfez sur un Blog, il faudra bien justifier cela à votre boss un jour donc on va dire que c’est pour le bien d’Internet et la préservation de la bande passante.

Après en société, vous pourrez faire les malins et expliquer qu’en optimisant votre site, vous avez participer à éviter l’Exaflood, ca ne fait pas tomber les femmes mais coté entretient d’embauche, sur un malentendu, vous forcerez l’admiration.

Comment Analyser

Nos deux amis : Yslow et PageSpeed. Ces deux plugins fonctionnent sous Firefox et vous donnent un point de vu sur ce qui est propre, bien fait et ce qui ne l’est pas. Pagespeed, celui de Google, est plus nouveau et un poil plus complet, il tourne évidemment aussi sous Chrome. Yslow est celui fournit par Yahoo depuis des années, il est très intéressant également, personnellement, j’utilise les deux.

Je vous conseil aussi le site websiteoptimization qui vous donnera aussi de préciseuses infos. Evidemment, passer sans erreur le XHTML validator est important également, même si c’est pas toujours simple.

En complément, je me dois de citer l’excellent site www.gtmetrix.com. Pour ceux qui comme moi utilisent Opera ou qui ont un browser exotique et qui n’ont pas nativement ces plugins, c’est bien utile d’avoir à la fois Yslow et Pagespeed au même endroit, dans une même page.

Pagespeed :

pagespeed screenshot

Yslow :

yslow screenshot

GT Metrix :

gtmetrix

Lire les résultats

Evidemment le but est atteindre le rating maximum, soit A/A ou 100%/100%.

C’est pour ainsi dire impossible donc si on peut aller à une note très intéressante, ca sera déjà pas mal. Ceci va en plus réduire le temps de chargement de la page et donc nous faire passer sous la barre d’1,5 seconde et donc améliorer la façon dont nous considère Google.

Dans l’immédiat, on voit que Pagespeed à un peu plus de critères mais on retrouve 70% de points communs soit une forme ou une autre alors je vais les grouper par types.

Pagespeed : « Parallelize downloads across hostnames »
Yslow : Use Cookie-free domains
Pagespeed : Serve static content from a cookieless domain

C’est quasi comparable, dans le principe il s’agit de permettre aux browsers qui viennent de télécharger vos contenus de sites depuis plusieurs serveurs distincts afin de leur permettre d’établir plus de connexions simultannées. En gros, pour ne pas saturer les serveurs, les browser ne s’authorise que 6 à 15 connexions vers un même serveur, c-a-d qu’ils ne téléchargent que 6 à 15 éléments simultanéments et attendent pour demande les suivants que des connexions se libèrent.

C’est paramétrable du coté du client, sur le navigateur mais on ne va pas demander à chacun de modifier son paramétrage de navigateur donc il vaut mieux utiliser plusieurs serveurs, quand cela est possible, pour servir le contenu, notamment static. Ici, seul le hostname compte, vous pouvez avec le même serveur physique derrère un www1, www2 etc…

Avoir 4 serveurs qui distribuent le contenu va permettre aux navigateurs d’aller beaucoup plus vite pour récupérer les contenus. Un petit regret ici, il aurait été plus simple d’intégrer un variable sur le nombre de thread concourrant accepté directement dans le handshake http 1.1. Ca aurait permis d’accélérer en basse charge et de diminuer pendant les pics. On peut aller plus loin aussi en servant depuis plusieurs endroits, sur un domaine différents « cookieless ».

Ce n’est pas très compliqué à faire en réalité. Le plus simple c’est d’enregistrer un nom domaine différent de celui du site, par exemple static-nbs-system.com et de mettre un CNAME dans la zone DNS qui pointe sur l’enregistrement A du site (en l’occurence nbs-system.com). Ensuite on configure le service web pour fournir les ressources statiques depuis ce nouveau domaine, on interdit de poser les cookies sur ce domaine et dans les pages web on appelle les ressources statiques sur ce domaine. On peut bien sûr reproduire le schéma avec n host sur ce nouveau domaine, static1.blablabla, static2.blablabla etc…

Ca à l’air bien sur le papier mais si le framework le gère pas, il va falloir éditer des fichiers de config, des fichiers php ou HTML ou encore jouer de la commande sed pour automatiser le remplacement de l’url. (pour sed, vous pouvez voir l’article ici)

Je ne sais pas si ca à une influence sur la SEO par contre. Vu que le nom et l’URL des ressources statiques participe à la SEO on m’a dit, je ne sais pas l’impacte.
Faible je suppose vu que ce sont des plugins de moteurs de recherche qui conseillent ce mouvement… Un pro de la SEO pour m’éclairer ?

Yslow : « Use a Content Delivery Network (CDN) »

L’idée est un peu la même mais à une petite nuance prêt. Yslow conseil l’usage d’un CDN de manière absolu, un qui soit connu pour le reprérer. Pagespeed lui conseille de multiplier les sources servant les fichiers. L’idée de fond reste proche, servir le plus vite possible les éléments, depuis des sources spécialisées. Soit vous prenez un CDN connu (Akamai, limewire etc…) soit votre prestataire à le sien, soit vous en prenez un gratuit.

Dans les deux derniers cas, Yslow ne connaitra probablement pas votre CDN et vous devrez malgré tout trainer une mauvaise note sur ce sujet… Ca n’empêche pas d’avoir un A cependant car pour Yslow, c’est un point moyennement important. Et puis soyons honnête, avoir un CDN (Content Delivery Network) ce n’est utile que pour des sites qui servent à destinations de plusieurs pays distants, dans la majorité des cas, un serveur de ressources statiques suffit.

Yslow : « Add Expire headers »,
Pagespeed : « Leverage Browser Caching »

Ca joue beaucoup, ca compte beaucoup et, bonne nouvelle : c’est facile à faire !

Avec Apache, un petit tour dans la configuration, on ajoute le mod Expire et le mode Etags et on met les lignes de configurations suivantes :

LoadModule expires_module /usr/lib/apache2/modules/mod_expires.so
ExpiresActive On

FileETag MTime Size
<IfModule mod_expires.c>
 ExpiresActive on
 ExpiresByType image/jpg "access plus 6 months"
 ExpiresByType image/jpeg "access plus 6 months"
 ExpiresByType image/gif "access plus 6 months"
 ExpiresByType image/png "access plus 6 months"
 ExpiresByType text/ico "access plus 6 months"
 ExpiresByType image/ico "access plus 6 months"
 ExpiresByType image/icon "access plus 6 months"
 ExpiresByType image/x-icon "access plus 6 months"
 ExpiresByType application/x-shockwave-flash "modification plus 6 months"
 ExpiresByType text/css "access plus 1 week"
 ExpiresByType text/javascript "access plus 1 week"
 ExpiresByType text/html "modification plus 1 week"
 ExpiresByType text/xml "modification plus 2 hours"
 ExpiresByType image/vnd.microsoft.icon "access plus 6 months"
 ExpiresDefault "access plus 1 week"
 #Header set Cache-Control "max-age=86400, public"
</IfModule>
<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|swf)$">
 Header set Cache-Control "max-age=290304000, public"
</FilesMatch>

Voila, on a indiqué à Apache qu’on calculait la fraicheur d’une ressource en fonction de la date d’accès et de sa taille  (FilteEtag MTime  Size) et ensuite on lui a donné, par type de ressources, un temps d’expiration du cache. En résumé, quand votre navigateur récupère une donnée, il a le droit de la garder 6 mois si c’est un jpg par exemple, 1 semaine si c’est un javascript.

Evidemment, il faut le paramétrer en fonction de votre site et de la fréquence à laquelle vous mettez vos éléments à jour. Enfin, autre format, les 3 dernières lignes mettent une expiration à 480 semaines par défaut sur les ressources du type cité.

Si vous développez, il est fortement conseillé d’avoir une préproduction sur laquelle vous n’avez pas ces lignes, afin d’avoir le résultats de vos modifications instantanément et pas 480 semaines plus tard :)

Les deux plugins considèrent, à juste titre, que c’est un point important.

Yslow : Compress components with Gzip
Pagespeed : Enable Gzip compression

Il peut y avoir un peu débat sur celui-là, et encore. En gros le débat serait que sur un serveur dont le CPU est chargé, faire du Gzip en plus, ca aggrave le problème… Oui et non. Déjà, l’algorithme Zip est ultra rapide et optimisé, ca prends très peu de ressources à processeur moderne. En plus, servir plus vite c’est aussi diminuer sa charge de travail quelque part (on peut traiter plus de monde).

Coté débat, nous chez NBS, en matière de serveur E-commerce, on a tranché, c’est oui.

<IfModule mod_php5.c>
   php_flag zlib.output_compression on
</IfModule>
<IfModule mod_deflate.c>
 SetOutputFilter DEFLATE
 AddOutputFilterByType DEFLATE text/*
 DeflateFilterNote ratio
# Patch pour les navigateurs qui ne supportent pas
 BrowserMatch ^Mozilla/4 gzip-only-text/html
 BrowserMatch ^Mozilla/4\.0[678] no-gzip
 BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# Humm compresser les images, ce n'est pas utile, loin de là
 SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
 SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2|sit|rar)$ no-gzip dont-vary
 SetEnvIfNoCase Request_URI \.pdf$ no-gzip dont-vary
</IfModule>

Bon, c’est assez simple et explicite, on compresse tout ce qui est textuel, on désactive pour les vieux Mozilla 4 et les IE, on ne compresse pas les images.

Ca réduit bien les transferts mine de rien :

Type Uncompressed Compressed Win doc / HTML 44,5 14,8 67% js 25,1 10,4 59% js 57,2 19,7 66% js 0,9 0,4 56% js 90,4 29,8 67% js 17,4 8,1 53% css 30,9 6 81% économie 177,2 Ko 33%

C’est tangible et appréciable, ca économise de la bande passante des deux cotés, c’est tout bon !

Yslow : Minify Javascript and CSS
Yslow : Remove duplicate Javascript and CSS
Pagespeed : Combine external JavaScript
Pagespeed : Minify Javascript
Pagespeed : Removed unused CSS
Pagespeed : Minify CSS
Pagespeed : Combine external CSS

Okay, ca fait beaucoup d’un coup mais c ‘est la même logique derrière.

Le principe de fond : on regroupe les CSS et les Javascript en deux fichiers au lieu de 15, on les nettoye des bouts de codes ou expressions non utilisées, on les « minify » (on les densifie, on enlève les espaces et les choses inutiles).

L’idée est bonne mais ca fait un code peu maintenable, alors le conseil du pro : on fait son site sur la préproduction et on se fait un script bash de mise en production qui fait le ménage et compacte  le tout au moment de la mise en production. Comme cela, on a une préproduction qui reste efficace à maintenir avec des fichiers lisibles et un production optimisée.

Pour réaliser ces optimisations, deux possibilités voir même beaucoup plus. Pagespeed à la gentillesse de fournir certains fichiers optimisés directement depuis le plugin. On le sauve, on le met sur la production et hop, c’est finit. Pour optimiser ses CSS on a aussi le site cssoptimiser ou le cssclean. Bref ce ne sont pas les outils qui manquent. Pour les combiner, ca dépend de la technologie, sous Magento on a Fooman speedster, sous WordPress il y a CSS-JS-Booster de mémoire, parfois vous devrez tout simplement le faire à la main.

Evidemment enlever le code inutile des JS et/ou des CSS, c’est un impératif.

En réduisant le nombre de fichiers, on réduit le nombres de requêtes HTTP, on économise des transferts, de l’overhead, bref, là encore c’est du tout bon.

Personnellement, j’ai massivement utilisé les fichiers directement issus de Pagespeed quand il m’en proposait, c’est parfait.

La plupart du temps, ces modifications sont considéré comme importantes par les plugins.

Yslow : Avoid CSS expressions
Pagespeed : Use efficient CSS Selectors

J’ai regroupé ces deux là car ils touchent aux CSS et à leur optimisation. C’est un réel enjeu car les navigateurs se débrouillent plus ou moins bien avec les CSS et cela peut engendrer des délais du coté de l’utilisateur.

Yahoo Yslow nous dit d’éviter les expressions CSS, ce qui permet de changer dynamiquement un CSS si le browser est redimensionné par exemple. Le problème c’est que ces expressions sont appelées tout le temps, pendant la génération de l’affichage, au redimensionnement, parfois pendant le scrolling. Du coup ca charge un maximum le navigateur client. Ceci étant tous les frameworks ou presque évite ca comme la peste, vous ne devriez pas avoir de soucis avec. Sinon, il faut s’en passer et réécrire les portions du CSS qui utilisait ce système.

Google Pagespeed nous indique pour sa part qu’il est préférable d’utiliser des CSS selector efficaces. Ouiiiiiii, c’est à dire qu’on est pas contre, mais c’est quoi la différence entre un bon et un mauvais CSS selector ? C’est comme la chasse. Le bon chasseur, il voit… okay… on reprend.

Le but c’est d’éviter d’appliquer une clef de sélection peu efficace à un grand nombre d’éléments car cela pénalise les performances du navigateur. Mais cela va plus loin c’est plus une connaissance générale de la grammaire CSS qu’il faut avoir.

Par exemple, il vaut mieux :

  • utiliser une classe pour appliquer un style à de nombreux élements
  • privilégier le mécanisme d’héritage
  • utiliser des règles spécifiques
  • utiliser des class et ID plutot que des sélecteur de type Tag
  • éviter les qualificateurs redondants (ex : ID selectors par class et class selectors qualifiés par un tag selector)
  • éviter les sélecteurs descendants, surtout pour ceux qui pointe des ancêtres redondants (par exemple bidy ul li a {…} est un sélecteur redondant puisque tous les éléments sont des descendants de ce tag)
  • utiliser des sélecteurs de class plutot que des sélecteurs descendants
  • si vous devez utiliser un selecteur descendant, préférez un « child selector » qui nécessitera moins d’interprétation.
  • dans le cas d’IE, évitez les :hover pour les éléments qui ne sont pas des liens
  • si vous utilisez :hover sur des éléments qui ne sont pas des ancres, testez là sous IE 7 & 8 pour être sur que ca fonctionne.

Ok j’ai fais mon possible pour le traduire de l ‘anglais mais ce n’est pas mon domaine non plus alors si vous n’avez rien compris, allez à la source, ici. C’est un métier développeur Web, moi je vous le dis…

Yslow : Avoid HTTP 404 (Not Found) error
Yslow : Avoid URL redirects
Pagespeed : Avoid bad requests
Pagespeed : Minimize redirects

Ne riez pas et surtout vérifiez que vous n’en avez pas. Sur un site normal, en production normal, on ne doit pas tomber tous 3 objets sur un 404, ni même sur un 301 ou un 302. Qu’il y ait du rewriting temporairement pour maintenir une compatibilité, why not, que ce soit les 3/4 des URLs, encore plus vers un autre domaine, c’est  à proscrire.

Les 404, on s’en doute, c’est mal, d’autant plus que c’est surtout votre SEO qui va prendre. Mais les redirections prennent du RTT (pas des vacances, du Round Trip Time, des voyages allers/retours), ce qui ralentit l’ensemble.

Là aussi, c’est important, plus pour Pagespeed que pour Yslow qui tolère les 404 et dégrade moins la note.

Pour trouver vos 404, les google webmaster tools peuvent vous aider, les plugins, dont Firebug vous les donnent, des sites sont aussi disponibles pour vous aider à les trouver. Personnellement, j’utilise Firebug, ca me suffit. (oui ok, je n’utilise pas que Opera, c’est vrai)

Yslow : Do not scale images in HTML
Pagespeed : Specify image dimensions
Pagespeed : Optimize images
Pagespeed : served scaled images

Alors, là on est sur de la logique pure et dure…

Si je prend une image en 800×600, que je la pose sur le serveur et que je l’affice dans du 400×300, j’ai transféré une image 2 fois trop grosse pour rien (en fait 4 fois trop grosse, faite la multiplication). Donc je dois servir des images de la taille de ce qui va être affiché.

Je dois aussi spécifier les dimensions directement si possible (ca accélère le rendu des navigateurs) et bien sur, ne pas les redimensionner par du HTML, ce qui va à l’encontre de la précédente optimisation et aussi du fait qu’on a directement des images de la bonne taille.

Pour ce qui est d’optimiser les images sans pertes de qualité, le plugin fournit tout seul les versions optimisées… C’est pas le bonheur ca ?

Du bon sens on vous dit !

Yslow : Put CSS at the top
Pagespeed : Optimize the order of styles and scripts
Pagespeed : Put CSS in the document head

Le principe de fond c’est de charger les données dans l’ordre le plus efficient. Il faut que le début de la page puisse se charger le plus vite possible pour « visuellement occuper le terrain ». Si les images arrivent en dernier mais que tous les scripts sont chargés, le site est techniquement quasi fonctionnel mais inregardable.

Dans la première demi seconde, on doit donc passer les CSS pour « préparer le terrain », formater la page et commencer à afficher du texte et des images puis faire passer les images nécessaires puis enfin le Javascript.

Une fois la page chargée, c’est rare qu’un utilisateur clic instantanément, il prend le temps de la lire un minimum avant de cliquer, le Javascript peut donc arriver un peu en retard, de même s’il se charge d’une animation, on peut patienter 1 seconde de plus, c’est moins génant qu’une page blanche.

Bon ca tient de la bonne parole inapplicable parfois. Par exemple WordPress continue de charger les JS en début de page en version avant 3.0 (je n’ai pas vérifié sur la 3.0). Sous Magento, selon votre site, vous aurez peut être besoin de certains JS rapidement. Bref, ca se fait bien en général mais le cas particulier est légion.

Yslow : Reduce cookie size
Pagespeed : Minimize request size

Là encore, on essaye de réduire la données « inutilement » transférée.
L’idée c’est d’arrêter de transférer des cookies pour des ressources qui en ont aucun besoin, comme les images.

Chaque cookie par le navigateur transféré va consommer un peu de bande passante et de temps, pour rien et des millions de fois sur un an. Je n’ai pas compté combien cela peut faire en arbre sur un an mais le bilan carbon des cookies inutiles est lamentable. D’une manière générale, réduire la taille des requêtes, des cookies et leur nombre au minimum.

Alors Google et Yslow sont relativement d’accord, il faut servir les fichiers statiques depuis un domaines qui ne pose pas de cookies dans la transaction.

Yslow : Make fewer HTTP requests

Un croustillant celui-là. Ca à l’air anodin mais on pourrait faire un post rien que sur lui…

J’aurais bien fait mon lache et laissé ca de coté si ce n’était pas justifié mais là… On va devoir le traiter, c’est pas un détail.

Welcome to the CSS Sprites world !

Un sprite c’est quoi ? C’est globalement innofensif, c’est une image avec plein de morceau dans laquelle on découpe le bout dont on a besoin à un moment donné pour l’afficher. Oui, jusque là, ca à l’air innoffensif, attendez la suite.

Voici le CSS sprite du site NBS System, sur lequel Aymeric de l’agence Dnd (notre web agency) à sué sang et eau :

CSS sprite

Si on résume la chose, c’est une image qui se comporte comme une carte. Quand on a besoin d’un bout de celle-ci, onva taper aux coordonnées X/Y qui vont bien et on on obtient ce que l’on a demandé. L’intérêt c’est qu’au lieu d’aller chercher 50 icones, on prend directement une grosse image, on fait donc 49 transferts http de moins avec toute l’économie d’overhead que ca représente.

Du coup dans son CSS on change son image par :

.blog .widget .header{height:42px;background:url(images/sprite.png) no-repeat 3px -258px;}

Ca n’occupe aussi qu’une socket du navigateur au lieu de 50, ce qui part groupe de 10 impose 5 volées de récupération des données. (voir le paragraphe précédent et le leverage browser cache).

Donc tout cela est merveilleux sauf que notre site, il vient rarement avec des sprites tout fait. Le graphiste lui, il fait des icones, il les fournit à l’intégration qui fait un CSS et du HTML et du coté sprites, il considère plus que c’est des boissons gazeuses.

Alors comment on génère ses sprites ? Deux cas pour démarrer. Soit vous êtes fort chanceux et vous avez évitez la problématique des dégradés et des ombres et ca va considérablement faciliter votre travail. Soit vous avez un beau site mais vous allez y passer du temps à vos sprites…

On peut le faire à la main, avec amour, mais ca prend un peu de temps… Quoiqu’il arrive, il faut passer par le stade préprod / prod, comme pour les compilations de JS /CSS sinon c’est pas facile à maintenir.

Bonne nouvelles : Il existe des générateurs.
Mauvaise nouvelle : Ca marche pas toujours et pas dans tous les cas.

Trois bonnes pistes sérieuses :

Il existe aussi un truc super bien je pense qu’à utilisé Aymeric pour mon site mais ce petit cachotier n’a pas voulu me dire son nom… Peut être une trouvaille ou un développement maison, je vais le cuisiner, n’hésitez pas à envoyer pleinnnnnnn de mails à l’agence DnD jusqu’à ce qu’ils lachent l’info !

En complément : un article assez complet traduit en Français ici. Sous WordPress il y avait Csprite qui était pas mal mais qui n’est plus maintenu… Un autre article pas mal du tout ici.

Un moyen de générer vos CSS sprites avec Photoshop aussi ici.

A l’époque où je faisais une fixation sur les CSS sprites, j’avais trouvé un binaire opensource assez formidable qui permettait de commenter un CSS normal et de le compiler après coup en un CSS utilisant un Sprite, tout en générant le sprite au passage. Top. Mais j’ai perdu la bookmark pour le moment alors dès que je l’ai retrouvé, je corrige ce post, si vous voyez de quoi je parles, postez moi un petit commentaire.

Les derniers points

Yslow : Reduce the number of DOM elements

Les objets DOM (Document Object Model) nécessitent d’être tous chargés et parsés avant que les interprêtations Javascript (notamment) ne démarrent. Donc plus d’objets, plus de taille et donc de transfert, plus de mémoire utilisée, plus de temps de traitement, plus de délai avant que toute la page ne soit prête.

Réduite la taille du DOM est donc important dans une certaine mesure.

C’est d’autant plus vrai que les surfers ont de plus en plus de pages ouvertes en tabs, si tout le monde force en Javascript et pose des DOM énorment, les browsers se tapent des indigestions et … ca rame. C’est une question d’hygiène globale du browser quelque part :)

Yslow : Make favicon small & cacheable

Parfois, je n’aimerai pas être une mouche chez Yahoo. Celui qui a sortie celle-ci est légèrement « tatillon » quand même, voir dypterophile sodomite à tendance compulsive.

Bon la Favicon, en faire une petite, c’est pas trop dur. Optimisée non plus. Par contre, la rendre cachable, ca a été un poil énervant car Apache n’aimait pas le mime/type ico ou gif/jpg donc ca ne parait jamais dans le module mod_expire…

Très pénible jusqu’à ce que je trouve le type mime des favicons :

ExpiresByType image/vnd.microsoft.icon "access plus 6 months"

Et voila, c’est caché, d’un coup l’Internet va plus vite… ou pas.

Yslow :  Avoid AlphaImageLoader filter

Oui alors si certains sont encore assez téméraires pour tenter d’afficher des images transparentes, style png, dans un IE datant d’avant la version 7, je penses qu’il a d’autres priorité en terme d’optimisation que ce que je racontes là.  Les soins psychiatriques et une URL de download d’Opera, Firefox ou Chrome.

En gros si vous jouer avec de la gif / png transparente, IE ne gère pas ca très bien, au mieux ca le ralentit, parfois ca le fait planter, on a même vu des failles de sécurité grave sur ce sujet…

Donc forcément, il faut éviter de proposer une bouteille de vodka à un alchoolique, là c’est pareil, pas de png transparente pour IE.

Pagespeed : Minify HTML

Alors là, forcément, on s’affronte à un problème. Soit on a un framework (magento, drupal, wordpress etc…) qui fait ca tout seul, bref du php qui génère du HTML, soit on a fait le sien. La deuxième catégorie devient rare et dans la première, sans toucher au core, on a peut de moyen d’action en général.

La plupart des outils proposent un système de templates qu’on peut optimiser mais c’est parfois coton. A voir mais sur le site de NBS par exemple, pour 7,9 Ko à réduire, il me met un malus de 27% sur ce point et me dégrade la note à C… Abusif je trouve mais bon, soit.

Pagespeed : Specify a cache validator

L’idée c’est de donnée la méthode par laquelle on vérifie que la ressource est fraiche ou non. Sous Apache, ca se fait par l’intermédiaire du paramètre :

FileETag MTime Size

Là on précise à Apache qu’on décide que la ressource à changé si soit la date de modification à changée, soit la taille.

Pagespeed : Specify a Vary:Accept-Encoding header

Allez, devinez, c’est encore pour IE… Comme quoi on peut faire un produit ultra pourrit et l’imposer sur le marché. Ca on peut pas enlever ca à Microsoft. Je n’ai rien contre eux sur le fond mais sur le navigateur, ils ont vraiment pourrit le web.

Notre ami IE donc, ne support pas les Vary headers. Du coup, si il trouve dans le header d’une ressource autre chose que User-agent et Accept-encoding, il ne la cache pas… Dans le principe, totalement se passer du Vary header est le mieux.

Pagespeed : Specify a character set early

Dès qu’on précise le character set, le navigateur peut démarrer certaines interprêtation, dont Javascript. Avant il ne sait pas comment interpréter les données, il est donc conseillé de le faire vite. En fait rien ne s’oppose à le faire le plus tôt possible et tous les framework standard le font en général.

Yslow : Make JavaScript and CSS external

Avoir des fichiers séparés pour les CSS et les JS permet de les stocker en cache et de ne pas les transférer dans le HTML à chaque échange ou chaque page. Donc il vaut mieux ne pas mettre son JS et son CSS directement dans le code HTML et faire un include de fichiers externes, c’est beaucoup plus propre et simple.

Yslow : Make AJAX cacheable

En fait sur ce point, ce qu’il faut comprendre derrière le laconique « Make Ajax Cacheable » c’est « Make Ajax requests results cacheable ».

Faire un requête ajax en background pour fluidifier le trafic c’est top mais ne pas stocker la ressource récupérer en cache c’est gacher ce premier transfert, reconsommer de la bande passante, participer activement à la déforestation des ours en pologne, bref, c’est le mal.

Yslow : Use GET for AJAX requests

oUn Get est plus valable qu’un POST car avec un GET on transfert le headers et les données en même temps, ca évite un transfert inutile. Cependant, si vous avez des requêtes un peu longues, IE n’accepte pas les requêtes de plus de 2Ko. Qui a dit « encore IE » ? Pas de dénigrement, on est là pour progresser, tous ensemble, même les browsers qui partent avec de sérieux handicapes de conception.

Les vrais pervers tenteront donc de transférer en GET, des images PNG transparentes de plus de 2 Ko, en laissant le vary-header avec un IE. Là normalement, on a tout bon pour avoir un beau blue screen :)

Yslow : Reduce DNS lookups
Pagespeed : Minimize DNS lookups

Une résolution DNS prends entre 10 et 100 ms en gros. Pendant ce temps, le browser doit attendre que la résolution se fasse. Si on peut lui éviter d’avoir à résoudre beaucoup de noms et/ou hostnames différents, c’est plutot positif. Cela va aussi à l’encontre des multiplication hostname sur un domaine différents pour paralléliser les download quelque part.

Une fois résolu, la réponse reste en général dans un cache local, on peut donc décemment imaginer que multiplier les hostnames (par exemple 4 statics) est correctement rentable et n’impose pas trop de lookups.

Pagespeed : Remove query strings from static resources

Typiquement ca :

http://www.nbs-system.com/wp-includes/js/jquery/jquery.js?ver=1.3.2

La paramètre « ?ver=1.3.2″ empèche certains proxys (dont Squid notamment) de cacher la ressource.

Pagespeed : Serve resources from a consistent URL

Pour les ressources partagées sur de multiples pages ou sites, il vaut mieux que la référence se fasse par rapport à une unique URL.
Cela permet notamment de ne pas renvoyer de fichier depuis plusieurs endroits différents, provocant des ns lookups d’ailleurs. L’exemple donné par Google c’est que si monsite.exemple.com et tonsite.exemple.com utilise le même JS, autant qu’il soit servit directement depuis un seul des deux sites, comme ca il sera déjà en cache dans le browser quand on ira de l’un à l’autre.

Autres optimisations

D’une manière général, il y a beaucoup d’autres optimisations, plus systèmes celles-ci, j’en parlerai prochainement, peut être directement sur le blog de NBS System. Les reverses proxy, les compilations de noyaux, les optimisations de .htaccess etc…

Mais bon, on a déjà de quoi s’amuser un peu là non ? :)

Je paye ma tournée au premier qui nous sort son site en A/A, ensuite celui qui nous passe un site Magento en A/A et pareil pour celui qui fait 100%/100% (sans tricher). Ca fera trois tournées mais elles seront largement méritées, chacunes d’elles !

PS : La doc de Google sur ces sujets est excellente, n’hésitez pas à la consulter.

Vous pouvez également lire l’article d’Arnaud ici : http://bit.ly/ban1Pm

écrit par Philippe Humeau \\ tags: , , , ,