Optimisez la vitesse de chargement de votre site

  • 1,631 views
Uploaded on

Voici ce que vous apprendrez, ou confirmerez, dans ce document : …

Voici ce que vous apprendrez, ou confirmerez, dans ce document :
- Pourquoi la vitesse d’un site est un critère important ?
- Quels sont les outils pour travailler sur la vitesse d’un site ?
- Quels sont les critères pour déterminer la vitesse d’un site ?
- Quelles sont les solutions à apporter à chaque problème ?
- Etude de cas

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • Lien direct (la version slideshare a un bug en bas de doc) :
    http://www.webxfrance.org/dossiers/optimisez_la_vitesse_de_chargement_de_votre_site.pdf
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
1,631
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
65
Comments
1
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Les dossiers Webxfrance<br />Optimisez la vitesse de chargement de votre site<br />par Gregeek pour webxfrance.org<br />© Webxfrancejuillet 2011 v1.0<br />Le Code de la propriété intellectuelle n’autorisant, aux termes de l’article L.122-5, 2° et 3° a), d’une part, que les « copies ou reproductions strictement réservées à l’usage privé du copiste et non destinées à une utilisation collective » et, d’autre part, que les analyses et les courtes citations dans un but d’exemple et d’illustration, « toute représentation ou reproduction intégrale ou partielle faite sans le consentement de l’auteur ou de ses ayants droit ou ayants cause est illicite » (art. L. 122-4). Cette représentation ou reproduction, par quelque procédé que ce soit, constituerait donc une contrefaçon sanctionnée par les articles L. 335-2 et suivants du Code de la propriété intellectuelle.<br />Table des matières TOC o "1-3" h z u Keynote PAGEREF _Toc297284739 h 5Introduction PAGEREF _Toc297284740 h 6Pourquoi en aurais-je besoin ? PAGEREF _Toc297284741 h 6Quand est-ce nécessaire ? PAGEREF _Toc297284742 h 6Comment faire ? PAGEREF _Toc297284743 h 7Les différents outils PAGEREF _Toc297284744 h 7Performances globales de mon site PAGEREF _Toc297284745 h 7Performances de chaque page de mon site PAGEREF _Toc297284746 h 9Les critères PAGEREF _Toc297284747 h 13Éviter les requêtes incorrectes PAGEREF _Toc297284748 h 16Éviter d'utiliser CSS @import PAGEREF _Toc297284749 h 16Éviter d'utiliser les expressions CSS PAGEREF _Toc297284750 h 16Éviter d'utiliser document.write PAGEREF _Toc297284751 h 17Intégrer les ressources CSS peu volumineuses PAGEREF _Toc297284752 h 17Intégrer les ressources JavaScript peu volumineuses PAGEREF _Toc297284753 h 18Regrouper les images dans des sprites CSS PAGEREF _Toc297284754 h 18Reporter le chargement du JavaScript PAGEREF _Toc297284755 h 19Différer l'analyse du code JavaScript PAGEREF _Toc297284756 h 21Autoriser la compression PAGEREF _Toc297284757 h 21Exploiter la mise en cache du navigateur PAGEREF _Toc297284758 h 22Spécifier un en-tête "Vary: Accept-Encoding" PAGEREF _Toc297284759 h 23Activer la mise en cache des redirections vers la page de destination PAGEREF _Toc297284760 h 24Réduire la taille des ressources CSS PAGEREF _Toc297284761 h 25Réduire la taille des ressources HTML PAGEREF _Toc297284762 h 26Réduire la taille des ressources JavaScript PAGEREF _Toc297284763 h 27Réduire la taille de la requête PAGEREF _Toc297284764 h 27Limiter le nombre de résolutions DNS PAGEREF _Toc297284765 h 28Limiter le nombre de redirections PAGEREF _Toc297284766 h 29Optimiser les images PAGEREF _Toc297284767 h 30Optimiser l'ordre des styles et des scripts PAGEREF _Toc297284768 h 32Paralléliser les téléchargements à travers plusieurs noms de domaine PAGEREF _Toc297284769 h 34Privilégier les ressources asynchrones PAGEREF _Toc297284770 h 36Placer le code CSS dans l'en-tête du document PAGEREF _Toc297284771 h 38Supprimer le CSS inutile PAGEREF _Toc297284772 h 39Diffuser les ressources à partir d'une URL unique PAGEREF _Toc297284773 h 39Diffuser des images mises à l'échelle PAGEREF _Toc297284774 h 40Placer les contenus statiques sur des domains sans cookie PAGEREF _Toc297284775 h 40Spécifier un jeu de caractères PAGEREF _Toc297284776 h 41Spécifier les dimensions des images PAGEREF _Toc297284777 h 42Utiliser des sélecteurs CSS pertinents PAGEREF _Toc297284778 h 43Optimisation Mobile PAGEREF _Toc297284779 h 44Etude de cas PAGEREF _Toc297284780 h 45Conclusion PAGEREF _Toc297284781 h 53<br />Keynote<br />Voici ce que vous apprendrez, ou confirmerez, dans ce document :<br />Pourquoi la vitesse d’un site est un critère important ?<br />Quels sont les outils pour travailler sur la vitesse d’un site ?<br />Quels sont les critères pour déterminer la vitesse d’un site ?<br />Quelles sont les solutions à apporter à chaque problème ?<br />Etude de cas : marmiton.org<br />Introduction<br />« La vitesse est la forme d'extase dont la révolution technique a fait cadeau à l'homme. » - Milan Kundera<br />Oui, en à peine quelques années, la vitesse est devenue une préoccupation majeure dans notre navigation quotidienne. Il est déjà loin le temps où le streaming était impensable, le temps où des modems 56k monopolisaient nos lignes téléphoniques, le temps où le minitel était roi. <br />Dès lors que vous avez un site Internet, il va falloir penser à l’optimiser, à le rendre toujours plus rapide.<br />Pourquoi en aurais-je besoin ?<br />A quoi peut donc bien servir d’optimiser la vitesse d’un site ? Après tout les internautes trouvent bien l’information qu’ils cherchent quelle que soit la vitesse du site, et attendre quelques secondes de plus ça ne les tuera pas ! Certes…<br />Mais qu’en est-il de la fameuse expérience utilisateur ? Ce critère est désormais au cœur des algorithmes des moteurs de recherche. Et c’est bien légitime. Quel est l’objectif d’un moteur de recherche ? Offrir à ses visiteurs les résultats les plus pertinents pour une recherche donnée. Et si l’utilisateur à le temps de boire un café à chaque changement de page, il est évident qu’il sera déçu. La conclusion est donc toujours la même : ce qui est bon pour mon visiteur est bon pour mon référencement naturel.<br />La vitesse de chargement offre un plus grand confort à mes visiteurs, et c’est un critère important pour mon référencement naturel !<br />Quand est-ce nécessaire ?<br />Tous les sites Internet seraient bons à optimiser ? En fait … oui : on peut évidemment toujours faire mieux. Néanmoins il va de soi que les moteurs de recherche ont une certaine tolérance et admettent communément un temps d’attente raisonnable. Raisonnable ? Quelle précision ! Me voilà bien avancé ! <br />Il n’y a pas de valeur précise à ne pas dépasser. D’ailleurs plusieurs experts SEO (c’est-à-dire experts en référencement naturel) pensent que cette valeur varie en fonction du temps de chargement au niveau mondial. Autrement dit si demain tous les sites internet de la planète se chargent en 1 milliseconde – sauf le vôtre - vous risquez d’être très pénalisé ! Cependant à l’heure actuelle, un temps de chargement d’environ 2 secondes par page est une bonne cible.<br />Globalement il faut essayer de charger chaque page d’un site au maximum en 2 secondes <br />Comment faire ?<br />Les différents outils<br />Pas de panique ! Il n’est pas question pour vous de sortir votre chronomètre pour voir le temps de chargement de votre page ! Plusieurs outils existent pour vous faciliter la tâche. Comme toujours il y a plusieurs concurrents à chaque outil. Je ne traiterai ici que les plus classiques.<br />Performances globales de mon site<br />La première chose à faire est de savoir si votre site est perçu par les moteurs de recherche comme un site rapide ou lent.<br />Pour cela Google fournit l’excellent Webmaster Tools (Outils pour les webmaster) : <br />http://www.google.com/webmasters/tools<br />Je vais partir du principe que votre site y est déjà inscrit. Si ce n’est pas le cas je vous encourage GRANDEMENT à le faire en suivant la procédure :<br />https://www.google.com/support/webmasters/bin/answer.py?answer=35179&hl=fr<br />Pour connaitre la vitesse de votre site :<br />Une fois connecté au Webmaster Tools, vous accédez à la liste de vos sites. Cliquez sur le site de votre choix.<br />Dans la partie gauche, cliquez sur « Labos », puis sur « Performance du site »<br />Vous accédez alors à l’écran vous permettant en un coup d’œil de savoir si votre site est rapide ou lent. C’est très simple. Si vous êtes dans la zone verte, c’est bien - Si vous êtes dans la zone rouge, c’est pas bien !<br />Exemple de site lent :<br />Exemple de site qui a su améliorer sa vitesse de chargement :<br />Outre le temps de chargement moyen de votre site, il y a une autre information intéressante dans le texte au-dessus du graphe : les « points de données ». Il s’agit en fait d’un score sur la fiabilité des informations affichées. Lorsqu’il est inférieur à 1000, cela signifie que Google ne considère pas qu’il soit très utile pour lui de mesurer la vitesse de votre site. Autrement dit votre site est trop petit pour que Google y consacre des ressources importantes. Dans ce cas, la vitesse de votre site n’est pas votre priorité et vous devriez probablement commencer par passer plus de temps au contenu de votre site !<br />« Google Webmaster Tools » permet d’avoir une vue d’ensemble de la rapidité de mon site<br />Si votre site est dans la zone rouge il faut agir. La première chose à étudier c’est la qualité de votre hébergement. En effet même si votre site est parfaitement optimisé, un mauvais hébergement peut faire chuter votre vitesse de manière vertigineuse. Il existe globalement deux types d’hébergement : serveur mutualisé ou serveur dédié.<br />Sur un serveur mutualisé une machine partage ses ressources entre différents sites. En règle générale ces machines sont extrêmement puissantes (puisqu’elles doivent être capables de gérer un grand nombre de sites internet simultanément). Néanmoins imaginons que votre site, hébergé sur un serveur mutualisé, soit « voisin » d’un autre site sur le même serveur – et que cet autre site vient de réussir à multiplier son trafic, ou plus simplement qu’un nouveau très gros site arrive sur ce même serveur… que restera-t-il comme ressources pour vous ? Evidemment des systèmes existent pour limiter ce genre d’abus mais sur un serveur mutualisé vous serez systématiquement soumis à ce genre de problématiques. C’est pourquoi, si vous vous souciez vraiment de la vitesse de chargement de votre site, il est très recommandé de passer sur un serveur dédié.<br />Pour optimiser la vitesse de chargement d’un site mieux vaut l’héberger sur un serveur dédié<br />Mais sur quels critères choisir son serveur dédié ? Le processeur, la mémoire vive, le disque dur, et la bande passante sont les éléments clé. D’autres éléments peuvent entrer en jeu mais ce sont là les plus importants. En fonction du type de service que rend votre site, les critères sont plus ou moins importants :<br />Le processeur, c’est la puissance de calcul de la machine. Il faut le favoriser lorsque votre site doit effectuer des traitements (ex : nombreuses requêtes SQL simultanées, nombreux redimensionnement d’images, encodage de fichiers vidéos, etc…)<br />La mémoire vive, c’est la mémoire temporaire de la machine. Elle est utilisée dans énormément de traitements. Je vais donc faire simple : plus il y en a, mieux c’est.<br />Le disque dur, c’est l’espace de stockage. La plupart du temps il ne modifie la vitesse de votre site, mais certains disques sont plus rapides que d’autres – en particulier vous pouvez favoriser les disques SSD quand vous en avez les moyens.<br />La bande passante, c’est grosso-modo le diamètre du tuyau par lequel transitent vos données. Evidemment il faut que la bande passante soit maximale. Néanmoins cela a un cout important et il n’est pas toujours nécessaire d’avoir une si grande bande passante. Elle est surtout recommandée si vous hébergez beaucoup de media et que les internautes les téléchargent en masse (vidéos, photos).<br />Pour un serveur dédié il faut surtout s’intéresser au processeur, à la mémoire vive, au disque dur et à la bande passante<br />Performances de chaque page de mon site<br />Si votre site est globalement rapide, il n’en est pas moins utile d’optimiser la vitesse de certaines pages. Google Webmaster Tools vous donne aussi une liste (pas très précise mais c’est déjà un bon point de départ) des pages qu’il considère comme lentes.<br />Si votre site est globalement lent, et que vous avez déjà optimisé votre hébergement – ou que vous ne pouvez pas en changer, il va falloir travailler sur chacune des pages de votre site. En règle générale même si votre site a des milliers de pages il n’y a que quelques templates (formats de pages), c’est-à-dire que des paquets de pages ont une structure commune. Prenons par exemple le site http://www.wordreference.com (site de traduction) qui contient près de 8 millions de pages… En pratique il y a un format pour la page d’accueil, un format de page pour une recherche infructueuse, et un format de page pour une recherche ayant des résultats – donc seulement 3 templates. Vous l’aurez compris il n’est pas question d’optimiser les 8 millions de pages mais uniquement les 3 templates. De manière générale il est rare de dépasser les 10 ou 20 templates.<br />Pour optimiser toutes les pages de mon site, je simplifie en m’intéressant à des pages « type »<br />Pour étudier les performances d’une page, je vous conseille d’utiliser les outils suivants :<br />Le navigateur Firefox (http://www.mozilla-europe.org/fr/)<br />Le plugin (indispensable pour tout webmaster) Firebug https://addons.mozilla.org/fr/firefox/addon/firebug/<br />Le plugin de Google : PageSpeed (qui existe aussi pour Chrome) http://code.google.com/speed/page-speed/download.html#extension-rel-ff<br />D’autres outils concurrents existent (notamment YSlow de chez Yahoo). Ces outils ont des plus et des moins mais ce sont les plus classiques – je m’y limiterai donc.<br />Une fois les outils installés, lancez Firefox et appuyer sur la touche F12. Cela affiche la console Firebug :<br />Firebug est composé de plusieurs onglets, ceux qui nous intéressent ici sont Réseau et PageSpeed.<br />Cliquez sur Réseau. Si l’onglet est vide rechargez la page. Vous pouvez alors voir l’ensemble des ressources qui ont été chargées par votre navigateur. <br />URL contient l’adresse de la ressource<br />Statut contient le code retour http (on y reviendra plus tard)<br />Domaine … c’est le nom de domaine de la ressource…<br />Poids… c’est le « nombre de kilo-octets » de la ressource <br />Chronologie vous permet d’étudier visuellement l’ordre d’affichage des ressources ainsi que le temps qu’a pris chacune à se charger. De plus chaque élément chronologique est composé de plusieurs couleurs – nous les expliquerons plus tard.<br />Il y a de plus un trait vertical bleu et un trait vertical rouge. Le trait bleu correspond au moment où le code HTML de la page a été chargé, le rouge correspond grosso-modo au moment où la page est effectivement affichée. C’est le temps « rouge » qui est le temps ressenti par l’internaute et c’est également le temps « rouge » qui est pris en compte par les moteurs de recherche, et c’est donc lui que nous allons tenter de réduire. Comme dit plus haut il faut éviter qu’une page ait un temps de chargement supérieur à 2 secondes. C’est sur ce critère que vous allez décider s’il faut optimiser la page ou pas.<br />Cliquez maintenant sur l’onglet PageSpeed, puis cliquez sur le bouton « Analyze Performance » :<br />PageSpeed ne vous parle pas de temps de chargement, et malgré son nom il n’accélère pas non-plus le temps de chargement des pages. Mais à quoi sert-il donc ? En fait il effectue un diagnostic sur votre page selon des tas de critères, identifie les faiblesses potentielles dans l’optimisation de votre page, et vous donne un Page Speed Score c’est-à-dire une note sur vos bonnes pratiques en matière d’optimisation de vitesse. C’est donc un outil précieux !<br />Evidemment la page d’accueil de Google a un score quasi parfait. Pour vous faire une idée, un score inférieur à 70 est insuffisant, et un score au-dessus de 90 est un très bon score.<br />Des outils permettent de savoir si une page est lente et sur quels critères je dois travailler<br />Les critères<br />PageSpeed étudie une trentaine de critères pour établir votre score. Pour chaque critère il vous donne en plus les moyens de l’améliorer ainsi qu’une explication (en anglais) du pourquoi (pour cela cliquez sur l’intitulé du critère). Malheureusement ces explications sont très techniques et un peu obscures. Je vais donc m’efforcer de les expliquer ici avec un peu de vulgarisation.<br />Pour comprendre comment optimiser, il faut commencer par comprendre ce qui se passe entre un navigateur et un serveur. Le schéma classique est le suivant : <br />Un internaute tape l’adresse d’une page (ex : http://www.monsite.com/sousrepertoire/page.php?valeur1=test1&valeur2=test2)<br />Le navigateur interroge le fournisseur d’accès internet pour savoir sur quel serveur se trouve « www.monsite.com » (c’est ce qu’on appelle la Résolution DNS). En pratique le navigateur récupère l’adresse IP du serveur. Ce processus est assimilable à trouver le numéro de téléphone de quelqu’un dans l’annuaire.<br />Le navigateur demande au serveur ainsi trouvé de lui renvoyer le contenu qui se trouve sur la page demandée. Pour cela le navigateur envoie une Requête HTTP qui contient l’adresse de la page demandée mais aussi un tas d’autres informations, et notamment le Referer (c’est-à-dire l’adresse de la page où se trouve le lien sur lequel l’utilisateur a cliqué pour arriver à la page demandée), le User-Agent (c’est-à-dire le nom et la version du navigateur), les cookies (c’est-à-dire des données qui sont liées à votre activité sur le site et qui sont stockées par votre navigateur) , et éventuellement les données d’un formulaire.<br />Le serveur analyse la demande et renvoie la ressource demandée ainsi qu’un code de retour. La ressource peut-être une page HTML, une image JPEG, une vidéo, etc… Le code retour informe le navigateur de la réussite ou de l’échec de la demande. Les codes retours les plus importants sont les suivants : 200 OK : Tout s’est bien passé301 Moved Permanently : La page demandée a été déplacée à une nouvelle adresse – votre navigateur va donc envoyer une nouvelle demande avec la nouvelle adresse302 Move temporarily : Identique au code 301, à la nuance près que le serveur signale que c’est temporaire. Mais c’est juste informatif.403 Forbidden : L’internaute n’est pas autorisé à accéder à la ressource demandée. Le navigateur ne récupère donc pas la ressource et la requête a été envoyée pour rien.404 Not found : La ressource demandée n’existe pas. Le navigateur ne récupère donc pas la ressource et la requête a été envoyée pour rien.410 Gone : Pratiquement identique à 404 à une nuance près : en 410 le serveur renvoie volontairement ce code pour signifier que le contenu n’existe plus, alors qu’en 404 c’est un constat d’absence de la ressource.On le voit déjà : en 301,302,403,404 et 410 il y a des requêtes émises inutilement… il va donc falloir optimiser tout ça !<br />Le navigateur a récupéré sa ressource, et va éventuellement en chercher d’autres. Par exemple si l’internaute demande une page HTML, celle-ci contient des images, des fichiers javascript, des fichiers CSS, etc… pour chacune de ces ressources une requête sera émise.<br />Ce processus est toujours relativement long même si la ressource demandée est de petite taille. Ainsi, on le verra dans quelques lignes, il est intéressant de limiter le nombre de requêtes dans une page HTML. Maintenant que cela est clair passons aux explications des règles. Selon votre environnement les règles sont en français ou en anglais, la liste suivante recense les règles dans les deux langues. Parfois, curieusement, une règle en anglais est équivalente à deux règles en français… <br />Cette liste contient l’ensemble des critères utilisés par PageSpeed. Vous y trouverez le niveau d’impact de chaque règle, une explication détaillée du problème, et surtout une solution !<br />Utilisez cette liste comme un livre de recettes, et utilisez-la en fonction des alertes que remonte PageSpeed pour votre site. <br />Avoid bad requestsÉviter les requêtes incorrectesIMPACT VARIABLEDescriptionVotre page fait appel à des ressources inexistantes (code 404 ou 410). Ces appels sont superflus et ralentissent donc le chargement de la page. SolutionSoit il s’agit d’une erreur de votre part (ex : nom de fichier mal saisi) et il faut corriger ; soit le contenu que vous utilisez n’existe plus et il va falloir trouver un autre contenu similaire ou se débarrasser de cet appel.Avoid CSS @importÉviter d'utiliser CSS @importFAIBLE IMPACTDescriptionIl est possible d’intégrer un fichier CSS dans un autre grâce à l’instruction @import url("autrefichier.css"). Bien que cela puisse être pratique pour le développeur, cela n’est pas souhaitable en termes de performances. En effet en pratique, le premier CSS sera intégralement chargé et utilisé par le navigateur avant de se préoccuper du second. Du coup les temps de chargement sont allongés et l’utilisateur voit sa page bouger dans tous les sens avant d’en voir la version définitive.SolutionFusionnez vos fichiers CSS en un seul gros fichier.Avoid CSS expressionsÉviter d'utiliser les expressions CSSIMPACT MOYENDescriptionInternet Explorer ajoute une fonctionnalité au CSS : expression. En pratique cela permet d’utiliser du Javascript directement dans le CSS pour avoir des règles d’affichage dynamiques. Par exemple on peut écrire des choses comme width : expression((document.body.clientWidth-200)+’px’). Le problème c’est que pour obtenir ce dynamisme Internet Explorer recalcule constamment ces expressions, ce qui est particulièrement couteux en termes de performances. SolutionIl faut éviter ces expressions et les remplacer par un traitement plus standard en Javascript. Mais le plus souvent il s’agit d’une mauvaise utilisation des capacités du CSS et du HTML et il vaut donc mieux retravailler son code proprement.Avoid document.writeÉviter d'utiliser document.writeFAIBLE IMPACTDescriptiondocument.write est une fonction Javascript permettant d’ajouter un contenu dans la page HTML de manière dynamique même après son chargement. Cette règle n’interdit pas vraiment son utilisation, en fait elle déconseille de s’en servir pour charger des nouvelles ressources. Notamment des choses comme document.write('<script src="script.js"></script>'). En effet les navigateurs modernes optimisent l’ordre de chargement des ressources qu’ils trouvent dans la page HTML, mais avec une telle écriture cette optimisation ne peut pas être appliquée. SolutionQuand c’est possible il vaut mieux écrire directement le code HTML équivalent : <script src="script.js"></script>Combine external CSSIntégrer les ressources CSS peu volumineusesFAIBLE IMPACT DescriptionLe chargement d’une ressource - même petite - est assez couteux car il faut a minima le temps d’aller-retour entre le client et le serveur. Il est intéressant de regrouper ces ressources entre elles. SolutionPlutôt que d’appeler 5 fichiers CSS dans votre page HTML, mieux vaut tous les fusionner en un seul gros fichier CSS.<br />Combine external JavaScriptIntégrer les ressources JavaScript peu volumineusesFAIBLE IMPACT DescriptionLe chargement d’une ressource - même petite - est assez couteux car il faut a minima le temps d’aller-retour entre le client et le serveur. Il est intéressant de regrouper ces ressources entre elles. SolutionPlutôt que d’appeler 5 fichiers Javascript dans votre page HTML, mieux vaut tous les fusionner en un seul gros fichier Javascript.Combine images using CSS spritesRegrouper les images dans des sprites CSSGROS IMPACTDescriptionNon … un sprite n’est pas une boisson gazeuse… Un sprite est un regroupement de plusieurs images dans un seul et même fichier. En règle générale il s’agit des différents états d’un même objet. Par exemple un bouton peut avoir une apparence dans son état normal et une autre quand on passe la souris dessus. Dans ce cas le sprite sera constitué de 2 images collées l’une sous l’autre.Par exemple :Comme pour les fichiers CSS ou Javascript, le fait de fusionner plusieurs fichiers en un seul améliore les performances car il diminue le nombre de requêtes émises au serveur.SolutionMettons cet exemple en pratique :Dans un fichier CSS :a.bouton { display : block; /* Indispensable pour pouvoir spécifier les dimensions d’une balise <a> */ width : 326px; /* Largeur de l’image bouton.jpg */ height : 65px; /* Moitié de la hauteur de l’image bouton.jpg */ background-image : url(bouton.png);}a.bouton:hover { /* Concerne le cas où l’on passe la souris sur le bouton */ background-position : 0% 100%; /* 100% correspond à la hauteur de la balise <a>. Ici on décale le background de la hauteur d’un bouton -> on affiche la deuxième partie de l’image */}Et dans le fichier HTML :<a href="unepage.html" class="bouton"></a>Cette technique présente un autre avantage : quand l’utilisateur passe la souris sur le bouton, il n’y a pas les fameuses millisecondes de latence pendant lesquelles l’image est blanche jusqu’à chargement de la nouvelle image. L’expérience utilisateur est donc améliorée.Il s’agit ici d’un exemple simple mais vous pouvez également regrouper tous les boutons de votre site dans une seule et même image. Cela vous simplifiera la maintenance, et surtout améliorera les performances du site.Defer loading of JavaScriptReporter le chargement du JavaScriptGROS IMPACTDescriptionCette optimisation vient de l’idée que les traitements Javascript sur une page peuvent souvent être chargés après la page elle-même. Par exemple le script de Google Analytics (permettant d’avoir des statistiques de fréquentation d’un site) peut très bien être appelé une fois que la page a été entièrement affichée par le navigateur. L’internaute se fiche bien de ce script et ne devrait pas attendre qu’il soit chargé pour pouvoir visionner sa page. Cette optimisation devrait également être utilisée pour l’affichage de pubs : l’internaute arrive sur sa page, tout son « vrai » contenu s’affiche, et les pubs ne sont chargées qu’à partir de là.SolutionLa technique la plus simple consiste à utiliser l’attribut méconnu et pourtant extrêmement pratique : defer<script type="text/javascript" src="monscript.js" defer="true"></script>Avec cet attribut, le code javascript est bien chargé mais l’exécution du code ne se fera qu’une fois que la page aura été entièrement chargée. C’est un début mais pas encore ce qu’on aimerait. Il existe plusieurs solutions pour résoudre le problème dans son ensemble, elles sont plus ou moins élégantes, je vous propose la suivante (à placer à l’intérieur de la balise <HEAD>) :<script type="text/javascript">/** * Ajoute dynamiquement un fichier Javascript */function includeJS(src) { var script = document.createElement('script'); script.setAttribute('type', 'text/javascript'); script.setAttribute('src', src); document.getElementsByTagName('head')[0].appendChild(script); }/** * Une fois la page chargée... */(window.addEventListener || window.attachEvent)(window.addEventListener ? 'load' : 'onload', function() {// ... charge ce fichier JavascriptincludeJS('monscript.js');}, true);</script><br />Defer parsing of JavaScriptDifférer l'analyse du code JavaScriptIMPACT MOYEN DescriptionLorsqu’un navigateur tombe sur un bout de code Javascript il doit l’analyser, le décortiquer pour pouvoir faire ce que le programmeur a demandé. Cette analyse est assez lourde et ralentit donc le chargement de la page. Afin d’optimiser l’affichage, il faudrait faire en sorte que ce temps d’analyse soit pris une fois que la page est entièrement chargée, afin de permettre à l’internaute d’accéder à sa page plus vite. SolutionLa solution est identique à l’optimisation précédente. Je ne m’attarde donc pas…Enable compressionAutoriser la compressionGROS IMPACTDescriptionUn des critères majeurs dans l’optimisation du temps de chargement est le temps pris à télécharger les différentes ressources. Bien entendu plus la ressource est grosse plus le temps de téléchargement est important et donc plus la page est lente à s’afficher. Pour réduire autant que possible le temps de téléchargement les navigateurs permettent, de manière transparente, de télécharger des ressources compressées et les décompressent à la volée. Ceci est principalement utile pour les ressources de type texte (HTML, CSS, Javascript).SolutionLa plupart des serveurs récents sont correctement configurés pour cette optimisation. Il n’y a donc rien à faire ! Néanmoins si ce n’est pas le cas il faut configurer plusieurs fichiers. La procédure étant très longue je vous renvoie à l’excellent article : http://www.alsacreations.com/article/lire/914-compression-pages-html-css-gzip-deflate.html<br />Leverage browser cachingExploiter la mise en cache du navigateurSpécifier une technique de mise en cacheGROS IMPACTDescriptionAfin de limiter les requêtes inutiles et donc d’afficher plus rapidement les pages d’un site, les navigateurs et les serveurs utilisent un mécanisme appelé cache. Le principe est simple : L’internaute va sur la page d’accueil du site, le navigateur télécharge donc toutes les ressources de la page (HTML, CSS, Javascript, Images, …)L’internaute clique va sur une autre page, le navigateur devrait télécharger toutes les ressources de cette page égalementEn fait le navigateur a déjà récupéré bon nombre de ressources (les images du design, le logo, le fichier CSS, …) et n’a donc pas besoin de les télécharger au nouveauLes ressources mises en cache restent donc disponibles chez le client au cas où il en aurait à nouveau besoin une seconde fois. Mais plusieurs questions se posent :Combien de temps les ressources restent-elles sur le poste ? C’est un choix… on peut définir la durée que l’on veut (cf. Solution ci-après), mais en règle générale un cache de 10 jours est une bonne valeur.Si je change une image de mon site, mes anciens visiteurs verront-ils toujours l’ancienne ? Absolument ! Et c’est LE gros problème du cache. Il existe plusieurs techniques pour forcer la mise à jour. La plus propre (à mon avis) consiste à ajouter une variable en GET à l’URL, par exemple si vous avez un fichier style.css qui a changé, utilisez désormais style.css?version=2 . En effet le système de mise en cache se base sur le nom du fichier et ce ?version=2 change le nom du fichier mais pas son contenu.Toutes les ressources sont-elles mises en cache ?Là encore c’est un choix… mais en règle générale la totalité des ressources (images, CSS, JavaScript…) devraient être mise en cache (cf. Solution ci-après).SolutionDans la lutte contre les mauvaises performances il est donc primordial de se consacrer au cache. En pratique il y a une solution simple : le paramétrage du cache dans le fichier .htaccess :Si vous ne savez ce qu’est le fichier .htaccess, je résume : c’est un fichier que vous pouvez modifier à la volée et qui a des impacts sur le comportement de votre serveur. En général il se met à la racine de votre site.En mettant les lignes de code ci-dessous dans votre fichier .htaccess le cache sera déjà bien optimisé !<FilesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|swf|xml|txt|css|js)$"> Header set Cache-Control "max-age=864000, proxy-revalidate"</FilesMatch>Leverage proxy cachingSpécifier un en-tête "Vary: Accept-Encoding"Supprimer les chaînes de requête des ressources statiquesFAIBLE IMPACT DescriptionPrenons le cas d’une grande entreprise où des dizaines de postes naviguent sur Internet à partir de la même connexion ADSL. En pratique, il y a une sorte de poste central qui est connecté directement à Internet et les autres postes transitent par ce poste central. C’est ce qu’on appelle un proxy. Le proxy permet de contrôler les données qui entrent et qui sortent de l’entreprise mais c’est également un moyen de réduire la consommation de bande passante. En effet si plusieurs postes accèdent aux mêmes sites, il n’y a aucune raison pour télécharger plusieurs fois les mêmes ressources. Ainsi un système de cache sur ce poste permet d’améliorer les performances globales de la navigation dans l’entreprise.Ce comportement peut être demandé par le serveur du site.SolutionEn plus de la solution présentée pour Leverage browser caching il faut ajouter la ligne en gras dans le code ci-dessous :<FilesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|swf|xml|txt|css|js)$"> Header set Cache-Control "max-age=864000, proxy-revalidate" Header append Vary Accept-Encoding</FilesMatch>Make landing page redirects cacheableActiver la mise en cache des redirections vers la page de destinationFAIBLE IMPACTDescriptionDe manière générale il vaut mieux éviter les redirections (puisque cela ajoute une requête pour rien) néanmoins dans certains cas on ne peut pas faire autrement. C’est notamment le cas d’un site ayant une version standard, et une version mobile (ex : www.toto.com qui redirige vers iphone.toto.com). Hors si la navigation se fait via un proxy (cf. Leverage proxy caching) vous risquez d’avoir un site mobile sur un PC standard ou l’inverse…SolutionAjoutez au fichier .htaccessHeader append Vary User-Agent env=!dont-varyRemplacez la ligneHeader set Cache-Control "max-age=864000, proxy-revalidate"ParHeader set Cache-Control "max-age=864000, private"<br />Minify CSSRéduire la taille des ressources CSSFAIBLE IMPACT DescriptionUn fichier CSS bien écrit il y a toujours des espaces, des sauts de ligne, des commentaires, et autres tabulations. Bien que cela offre une très bonne lisibilité au fichier, en matière de performance c’est un peu dommage dans la mesure où tous ces caractères superflus pourraient ne pas être téléchargés sans pour autant impacter le rendu.SolutionPageSpeed inclut un outil appelé cssmin qui permet de ne garder que le code utile d’un fichier CSS. Pour récupérer la version optimisée cliquez sur la flèche à gauche de la règle et vous verrez tous les fichiers CSS qui ne sont pas optimisés et vous pourrez récupérer directement dans l’outil la version optimisée.En pratique je vous conseille le comportement suivant :Ecrivez vos fichiers CSS de manière lisible : avec des espaces, des commentaires et des indentations. Supposons que le fichier s’appelle style.cssUtilisez l’outil de PageSpeed pour récupérer la version optimisée (vous pouvez également utiliser ce site : http://tools.w3clubs.com/cssmin/) et enregistrez le fichier en le nommant style.optimized.css Dans votre page HTML remplacez votre <link rel="stylesheet" type="text/css" href="style.css"> par <link rel="stylesheet" type="text/css" href="style.optimized.css">Ainsi votre code sera toujours aussi maintenable et votre site aura de meilleures performances.Minify HTMLRéduire la taille des ressources HTMLFAIBLE IMPACT DescriptionSur le principe cette règle fonctionne sur le même principe que Minify CSS et a vocation à supprimer les caractères inutiles.SolutionEn pratique cette règle n’a pas vraiment de sens dans la très grande majorité des cas car le code HTML est généré à partir du code PHP, et prendre en compte cette optimisation serait trop complexe. De plus la compression gzip (cf. Enable compression) permet de limiter le poids effectif des espaces et des tabulations (un des principes de cette compression étant d’identifier les répétitions et donc de ne pas stocker AAAAAAAA mais 8A). Néanmoins cette règle est l’occasion de faire attention au poids des commentaires HTML.Un commentaire HTML est de type <!-- bla bla bla -->. Ce code, sans impact du point de vue de l’utilisateur est bien téléchargé inutilement. Evitez donc leur utilisation et favorisez les commentaires PHP : <?php /* bla bla bla */ ?>. Ceux-ci sont traités par le serveur et ne sont pas téléchargé par les clients.<br />Minify JavaScriptRéduire la taille des ressources JavaScriptFAIBLE IMPACT DescriptionLe principe est le même que pour Minify CSSSolutionLa solution est la même que pour Minify CSS !Minimize request sizeRéduire la taille de la requêteFAIBLE IMPACT DescriptionUne requête HTTP (qui est le protocole standard du web) contient un certain nombre d’informations : l’adresse de la page, le Referer (c’est-à-dire l’adresse de la page sur laquelle vous avez cliqué pour arriver à cette nouvelle page), le User-Agent (c’est-à-dire le nom et la version du navigateur), les cookies (c’est-à-dire des données qui sont liées à votre activité sur le site et qui sont stockées par votre navigateur), et éventuellement les données d’un formulaire. Toutes ces données mises bout à bout sont constituées d’un certain nombre de caractères (= octets) que l’on appelle « taille de la requête ». Or les requêtes sont émises par paquet de 1500 octets environ. L’idéal consiste donc à faire en sorte d’avoir une taille de requête d’au maximum 1500 octets pour n’émettre qu’un seul paquet.SolutionMalheureusement vous n’avez pas la main sur grand-chose…L’adresse de la page (qui prend aussi en compte les éventuelles données après le ?, ex : http://www.monsite.com/unsousrepertoire/unepage.php?query=toto)Vous pouvez vous efforcer de limiter la taille des sous-répertoires ou du nom des fichiers… mais le jeu n’en vaut pas la chandelleLe Referer : il est géré par le navigateur, il n’y a rien à faireLe User-Agent : il est géré par le navigateur, il n’y a rien à faireLes éventuelles données d’un formulaire : évitez les formulaires avec des champs qui ne sont pas utilisés. Mais là encore c’est une faible optimisation.Les cookies : c’est le seul point qui peut vraiment être amélioré de manière sensible. Certains sites utilisent les cookies pour accéder à un tas d’informations sur l’utilisateur (ex : les pages vues, les objets sur lesquels il a cliqué, etc…). Cela peut résulter en des cookies très volumineux, ce qui génère de grandes tailles de requête. Plutôt que de stocker des grands cookies utilisez les variables de session (http://php.net/manual/fr/features.sessions.php).En pratique seul un identifiant unique de l’internaute sera stocké comme cookie et toutes les autres informations seront stockées sur le serveur. La seule information qui transitera dans la requête http sera donc l’identifiant, et la requête s’en trouvera plus légère.Minimize DNS lookupsLimiter le nombre de résolutions DNSFAIBLE IMPACT DescriptionLorsqu’un navigateur souhaite accéder à une ressource, la première chose qu’il doit faire c’est la résolution DNS, c’est-à-dire récupérer l’adresse IP correspondant au nom de domaine. Dans la mesure où les ressources sont souvent sur les mêmes serveurs, les navigateurs optimisent et n’exécute cette phase qu’une fois par domaine (cela inclut le sous-domaine) et par session (c’est-à-dire tant que vous n’avez pas fermé toutes les fenêtres du navigateur).SolutionIl faut limiter le nombre de domaines utilisés. En pratique il est rare d’avoir besoin de cette optimisation car la plupart des développeurs le font sans même y penser… Cela peut néanmoins arriver si, par exemple, vous avez une page qui affiche un patchwork d’images venues d’autres sites. Dans ce cas il y aura autant de résolution DNS que d’images et il vaudrait mieux récupérer les images sur votre propre serveur afin de n’utiliser qu’un seul domaine.<br />Minimize redirectsLimiter le nombre de redirectionsIMPACT MOYENDescriptionUne redirection sert généralement à indiquer un nouvel emplacement pour une ressource ou encore pour traquer des clics. Il y a plusieurs cas dans lesquels des redirections sont mauvaises pour les performances :Des redirections multiples : A renvoie vers B et B renvoie vers CPour traquer des clics : on passe par une page intermédiaire qui fait perdre en générale environ une secondeLes redirections en Javascript : avec des pages du type <html><head><script type="text/javascript">window.location = "http://www.monsite.com/autre_emplacement.html";</script></head></html>SolutionPour les redirections multiples : au lieu de faire A > B > C faites directement A > CPour traquer les clics : plutôt que de passer par une page intermédiaire, intégrer le système de tracking directement dans le code PHP de la page de destinationPour les redirections Javascript : Remplacez-les par des redirections HTTP (plus performantes car le navigateur n’a pas besoin d’analyser le contenu de la page). Pour cela remplacez le code Javascript par le code PHP suivant (à placer au tout début de votre page) :<?php header('Location: http://www.monsite.com/autre_emplacement.html'); header("HTTP/1.1 301 Moved Permanently"); /* Uniquement si la page de destination doit être considérée par les moteurs de recherche comme la remplaçante définitive de la page d’origine ! */ die; /* Cette ligne, trop souvent négligée par les développeurs,est importante pour les performances */ ?>Une autre solution consiste à passer par le fichier .htaccess :RewriteEngine on RewriteRule ^emplacement.html$ autre_emplacement.html [L] /* ou [L,R=301] si redirection permanente */Optimize imagesOptimiser les imagesIMPACT MOYENDescriptionC’est une évidence mais le poids des images présentes sur votre site est un critère de vitesse. Il faut donc avoir les images les plus petites possibles.SolutionPageSpeed vous propose des images parfaitement optimisées sans perte de qualité :Vous pouvez visionner la version proposée par PageSpeed en cliquant sur « Optimized version » ou récupérer directement le fichier optimisé en cliquant sur « Save as ».En interne PageSpeed utilise « jpegtran » pour les fichiers JPEG (http://jpegclub.org/) et « OptiPNG » pour les fichiers PNG (http://optipng.sourceforge.net/).N’hésitez pas à remplacer systématiquement vos images par celles proposées par PageSpeed. Attention pour les fichiers JPEG car les fichiers optimisés proposés par PageSpeed ont l’extension .jpeg et non pas .jpg, ce qui prête parfois à confusion…<br />Optimize the order of styles and scriptsOptimiser l'ordre des styles et des scriptsFAIBLE IMPACTDescriptionLorsqu’un navigateur « lit » une page HTML, il le fait de haut en bas et télécharge les ressources au fur et à mesure de sa lecture. Autant que possible il télécharge les ressources en parallèle afin de réduire le temps de téléchargement. Néanmoins pour diverses raisons lorsqu’un navigateur télécharge un fichier Javascript il bloque le téléchargement des autres ressources tant que le fichier JavaScript n’est pas entièrement téléchargé, analysé et exécuté !Prenons un exemple fourni par Google. Si votre page est du type :<head><link rel="stylesheet" type="text/css" href="stylesheet1.css" /><script type="text/javascript" src="scriptfile1.js" /><script type="text/javascript" src="scriptfile2.js" /><link rel="stylesheet" type="text/css" href="stylesheet2.css" /><link rel="stylesheet" type="text/css" href="stylesheet3.css" /></head>Le chargement des ressources suivra ce schéma (en supposant que chaque ressource se charge en 100ms) :Soit un temps total de 300ms.SolutionIl faut reporter le Javascript le plus tard possible. Votre page devient ainsi :<head><link rel="stylesheet" type="text/css" href="stylesheet1.css" /><link rel="stylesheet" type="text/css" href="stylesheet2.css" /><link rel="stylesheet" type="text/css" href="stylesheet3.css" /><script type="text/javascript" src="scriptfile1.js" /><script type="text/javascript" src="scriptfile2.js" /></head>Le chargement des ressources suit le schéma suivant :Soit un temps total de 200ms.Cette optimisation doit également être appliquée pour les codes javascript dits « inline ». Par exemple : <head><link rel="stylesheet" type="text/css" href="stylesheet1.css" /><script type="text/javascript"> document.write("Hello world!");</script><link rel="stylesheet" type="text/css" href="stylesheet2.css" /><link rel="stylesheet" type="text/css" href="stylesheet3.css" /><link rel="alternate" type="application/rss+xml" href="front.xml" title="Say hello" /><link rel="shortcut icon" type="image/x-icon" href="favicon.ico"></head>Doit être remplacé par :<head><link rel="stylesheet" type="text/css" href="stylesheet1.css" /><link rel="stylesheet" type="text/css" href="stylesheet2.css" /><link rel="stylesheet" type="text/css" href="stylesheet3.css" /><link rel="alternate" type="application/rss+xml" title="Say hello" href="front.xml" /><link rel="shortcut icon" type="image/x-icon" href="favicon.ico"><script type="text/javascript"> document.write("Hello world!");</script></head>Parallelize downloads across hostnamesParalléliser les téléchargements à travers plusieurs noms de domaineIMPACT MOYEN DescriptionLorsque vous avez un grand nombre de ressources sur votre page, par exemple un grand nombre d’images, le navigateur lance les téléchargements en parallèle. Cependant il y a une limite du nombre de téléchargements en parallèle par domaine. Ainsi si vous avez par exemple 20 images à charger (img1, img2, …, img20), le chargement se fera grosso modo par paquets de 6 : img1 à img6, puis img7 à img12, puis img13 à img18, puis img19 à img20 Si par exemple chaque ressource se charge individuellement en 100ms, il y aura eu 4 chargements successifs donc 400 ms.SolutionMettez vos ressources sur un plusieurs autres domaines ou sous-domaines. La parallélisation ne sera alors plus plafonnée. Si par exemple vous créez un sous-domaine par paquets de 5 ressources :r0.monsite.com/img1.jpgr0.monsite.com/img2.jpgr0.monsite.com/img3.jpgr0.monsite.com/img4.jpgr0.monsite.com/img5.jpgr1.monsite.com/img6.jpgr1.monsite.com/img7.jpgr1.monsite.com/img8.jpgr1.monsite.com/img9.jpgr1.monsite.com/img10.jpgr2.monsite.com/img11.jpgr2.monsite.com/img12.jpgr2.monsite.com/img13.jpgr2.monsite.com/img14.jpgr2.monsite.com/img15.jpgr3.monsite.com/img16.jpgr3.monsite.com/img17.jpgr3.monsite.com/img18.jpgr3.monsite.com/img19.jpgr3.monsite.com/img20.jpgDans les mêmes conditions que plus haut, le temps de chargement passerait donc de 400 ms à 100ms.Evidemment stocker ses ressources sur un sous-domaine en fonction de son nom ou d’un autre critère est très contraignant. Pour vous simplifier la tâche je vous conseille de placer toutes vos ressources sur un nom de domaine dédié (cf. Serve static content from a cookieless domain) et de créer des sous-domaines qui sont en fait des alias. Ainsi, r0.monsite.com/img1.jpg sera identique à r1.monsite.com/img1.jpg ou à r18.monsite.com/img1.jpg. Ensuite utilisez la fonction PHP suivante :<?phpfunction getOptimizedImgPath($src) { static $cpt = 0; $subdomain = 'r'.ceil(($cpt++)/6); return $subdomain.'/monsite.com/'.$src; // Remplacez monsite.com par votre domaine}?>et remplacez vos images du type <img src="image.jpg"> par <img src="<?php echo getOptimizedImgPath('image.jpg') ?>">Vos images seront alors automatiquement affectées à un sous-domaine par paquets de 6.Prefer asynchronous resourcesPrivilégier les ressources asynchronesGROS IMPACTDescriptionGlobalement il s’agit de la même optimisation que Defer loading of JavaScript SolutionC’est la même que Defer loading of JavaScriptNote : Google Analytics propose désormais un code asynchrone prenant donc en compte cette optimisation. Le script type est donc devenu :<script type="text/javascript"> var _gaq = _gaq || []; _gaq.push(['_setAccount', 'UA-XXXXX-X']); _gaq.push(['_trackPageview']); (function() { var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true; ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s); })();</script><br />Put CSS in the document headPlacer le code CSS dans l'en-tête du documentIMPACT VARIABLEDescriptionLe CSS peut être utilisé de 3 façons : un appel à un fichier externe avec une balise du type <link rel="stylesheet" type="text/css" href="theme.css" />l’utilisation de règles directement dans la page. Par exemple :<style type="text/css">body { ... }</style>l’utilisation de l’attribut style dans le corps de la page :<div style="width : 320px; height : 250px"></div>La plupart des navigateurs tolèrent que les deux premières soient utilisées dans la partie BODY (alors qu’il est recommandé de les placer dans la partie HEAD). Néanmoins en plaçant ces codes dans la partie BODY, l’expérience utilisateur s’en trouve dégradée car les navigateurs ne peuvent pas pré-formater la structure de la page et cela provoque un affichage de la page qui bouge dans tous les sens avant de se stabiliser.SolutionIl faut, comme bien souvent, suivre les recommandations et placer au maximum les règles CSS dans la partie HEAD.<br />Remove unused CSSSupprimer le CSS inutileFAIBLE IMPACT DescriptionUn fichier CSS peut parfois contenir un très grand nombre de règles. Toutes ne sont pas utilisées et c’est donc autant de caractères inutilement téléchargés qui pourraient être supprimés.SolutionSauf dans certains très rares cas, cette optimisation est extrêmement difficile à mettre en œuvre car même si une règle n’est pas utilisée sur une page donnée, ce n’est peut-être pas le cas pour les autres pages du site... Je vous conseille donc de ne pas en tenir compte.Serve resources from a consistent URLDiffuser les ressources à partir d'une URL uniqueIMPACT VARIABLEDescriptionSi vous avez des ressources identiques accessibles depuis plusieurs adresses, vous ne pourrez pas bénéficier de la mise en cache (cf. Leverage browser caching )et vous augmenterez le nombre de résolutions DNS (cf. Minimize DNS lookups).SolutionFaites en sorte de ne pas avoir de doublons… Facile à dire, hein ? Effectivement mais je n’ai pas de recette miracle à vous proposer malheureusement.<br />Serve scaled imagesDiffuser des images mises à l'échelleIMPACT MOYENDescriptionVous avez une page avec une image, qui fait par exemple 320px par 200px, et vous voulez l’afficher en plus petite. Vous l’intégrez ainsi :<img src="image.jpg" width="160" height="100">Dans ce cas l’image chargée est inutilement lourde …SolutionRedimensionnez l’image avec un éditeur (Photoshop, GIMP, ou autre) et utilisez-la dans votre page.Serve static content from a cookieless domainPlacer les contenus statiques sur des domaines sans cookieIMPACT VARIABLEDescriptionLorsqu’un navigateur doit accéder à une ressource, il émet une requête HTTP. Dans les informations qui transitent, il y a notamment les cookies. Les cookies sont des informations stockées par le navigateur généralement à la demande du serveur. Les cookies sont utilisés par pratiquement tous les sites internet mais les données qui s’y trouvent sont très variables : identifiants de connexion, panier d’achat, etc… Ce mécanisme permet donc au code PHP de récupérer ces fameuses informations. Néanmoins elles sont aussi transmises lorsqu’il s’agit de télécharger une image. Dans ce cas les données transitent inutilement et c’est donc une source d’optimisation !SolutionLes cookies sont liés à un nom de domaine. Prenez donc un nom de domaine dédié à vos ressources. Prenons l’exemple de facebook.com, ils utilisent le domaine fbcdn.net pour stocker l’ensemble de leurs ressources. Par exemple leur logo est de la forme <img src="http://static.ak.fbcdn.net/rsrc.php/v1/zK/r/NGGPJRdOdhs.png"><br />Specify a character setSpécifier un jeu de caractèresFAIBLE IMPACT DescriptionLe charset (jeu de caractères) est assimilable à un alphabet. Selon la langue employée il faut donc utiliser tel ou tel charset. Mais en fonction du charset les caractères sont stockés sur 1 ou 2 octets. Le navigateur ne peut pas savoir a priori quel charset vous voulez utiliser donc ils en utilisent un par défaut (pas le même selon les navigateurs…) et partent avec un a priori sur le charset utilisé. Si le navigateur détecte que son charset n’était pas le bon, il va recommencer l’analyse de la ressource voire dans certains cas la re-télécharger. Il est donc important de renseigner le navigateur sur le charset à utiliser.SolutionIl y a plusieurs façons de spécifier le charset, la plus simple est de mette la ligne suivante tout en haut de la balise <head> :<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">Depuis HTML5 on peut également utiliser cette écriture :<meta charset="iso-8859-1">Ici j’ai choisi iso-8859-1 qui correspond à l’alphabet latin standard c’est-à-dire au français. C’est le cas le plus fréquent. Néanmoins si votre site est multilingue vous pourrez préférer utf-8.<br />Specify image dimensionsSpécifier les dimensions des imagesFAIBLE IMPACT DescriptionDans votre page vous intégrez vos images comme suit :<img src="image.jpeg">A priori rien de mal à ça… mais dans ce cas le navigateur doit aller chercher dans l’image sa largeur et sa hauteur afin de définir la taille de la « boîte » dans laquelle sera affichée l’image. Afin de ne pas bloquer l’affichage, le navigateur utilise donc généralement une boite vide, qui sera redimensionnée une fois que l’image aura été chargée (et que ses dimensions seront connues) – ce qui déplace généralement les autres boîtes pour faire de la place.SolutionMême si vous ne voulez pas redimensionner votre image, spécifiez de manière explicite la taille de celle-ci :<img src="image.jpeg" width="320" height="200">Ou<img src="image.jpeg" style="width:320px; height: 200px">Ainsi l’affichage global de votre page ne sera pas affecté quand l’image sera effectivement chargée.<br />Use efficient CSS selectorsUtiliser des sélecteurs CSS pertinentsFAIBLE IMPACT DescriptionLes règles CSS sont définies par un identifiant et un type d’affichage associé. Par exemple :ul.liste li { color : red }Ici l’identifiant est ul.liste li et l’affichage est color : red. La difficulté pour un navigateur consiste à identifier parmi toutes les balises d’une page celles qui correspondent à l’identifiant. Ce traitement est assez complexe, donc long et plus la règle est ciblée, moins le navigateur a de travail.SolutionEvitez d’utiliser des règles trop sommaire, et utilisez autant que possible les classes et les ID. Remplacez donc ul li.itempar quelque chose comme <br />ul#maliste li.item<br />Cela évitera au navigateur d’aller chercher tous les <UL> alors que la plupart ne contiennent pas des <LI> de classe item.<br />Optimisation Mobile<br />Optimiser un site mobile se fait pratiquement de la même manière. Les critères sont les mêmes, mais les exigences sont plus grandes dans la mesure où les connexions sont plus lentes (Edge, 3G, …).<br />Pour faire l’analyse de la version mobile de votre site, je vous conseille de passer par la version « online » de l’outil PageSpeed : http://pagespeed.googlelabs.com/<br />Saisissez l’URL de votre site, et cliquez sur la petite flèche toute à droite pour sélectionner « Obtenir des suggestions pour mobile ».<br />La suite est identique à l’analyse d’un site pour ordinateur.<br />Etude de cas<br />Après toute cette belle théorie, je vous propose de passer à la pratique. Je vais donc prendre un site très connu et voir tout ce qui ne va pas dessus, et ils auraient beaucoup à faire !<br />Puisque je vous ai fourni une liste de recettes pour améliorer les performances, j’ai choisi de partir sur le plus grand site de recettes de cuisine : http://www.marmiton.org <br />Bien entendu nous n’avons pas accès au Webmaster Tools et nous allons devoir nous limiter à l’étude des pages elles-mêmes. Qu’à cela ne tienne : nous nous limiterons même à la page d’accueil pour cette étude de cas.<br />Que nous dit PageSpeed ?<br />66/100 ! Ce score est très surprenant pour un site de cette notoriété. <br />Et malgré ma très bonne connexion internet le temps de chargement dépasse allègrement les 2 secondes :<br />On se situe donc entre 4 et 5 secondes pour le chargement de la page d’accueil. C’est beaucoup trop !<br />Quelles sont les règles à travailler d’après PageSpeed ? Il s’agit essentiellement de:<br />Exploiter la mise en cache du navigateur<br />Regrouper les images dans des sprites CSS<br />Limiter le nombre de redirections<br />Optimiser les images<br />Différer l'analyse du code JavaScript<br />Commençons par le commencement : Exploiter la mise en cache du navigateur :<br />On voit déjà plusieurs choses à améliorer : <br />en quelques lignes dans le fichier .htaccess, ils pourraient régler le cache sur une durée de 10 jours par exemple<br />toutes leurs images sont stockées sur le domaine www.marmiton.org, ce qui a pour conséquence de transmettre les cookies à chaque appel, et surtout ne permet pas la parallélisation des téléchargements. Dans la capture d’écran suivante on voit d’ailleurs très bien les « vagues » de téléchargement :<br />Ces téléchargements pourraient être lancés en parallèle avec un domaine dédié aux ressources et plusieurs sous-domaines associés.<br />Passons à la règle suivante : Regrouper les images dans des sprites CSS<br />Effectivement certaines images auraient pu être regroupées en sprites, en particulier les puce-****.gif . <br />Il aurait fallu <br />qu’ils créent une image puce.gif de ce type (ici zoomée x10 et avec un fond bleu pour mieux y voir) :<br />qu’ils mettent dans le CSS :<br />div.puce {<br />background-image: url(puce.gif) ;<br />overflow: hidden;<br />}<br />div.puce_actu {<br />background-position: 0px 0px;<br />width: 11px;<br />height: 10px;<br />}<br />div.puce_menusemaine {<br />background-position: 11px 0px;<br />width: 4px;<br />height: 5px;<br />}<br />div.puce_plusdiapo {<br />background-position: 15px 0px;<br />width: 4px;<br />height: 7px;<br />}<br />div.puce_plusedito {<br />background-position: 19px 0px;<br />width: 4px;<br />height: 7px;<br />}<br />div.puce_salon {<br />background-position: 23px 0px;<br />width: 4px;<br />height: 5px;<br />}<br />div.puce_typecommunaute {<br />background-position: 27px 0px;<br />width: 2px;<br />height: 2px;<br />}<br />et enfin qu’ils utilisent les images de cette manière dans la page :<br /><div class="puce puce_actu"></div><br /><div class="puce puce_menusemaine"></div><br /><div class="puce puce_plusdiapo"></div><br /><div class="puce puce_plusedito"></div><br /><div class="puce puce_salon"></div><br /><div class="puce puce_typecommunaute"></div><br />Règle suivante ! Limiter le nombre de redirections<br />Ici il n’y a malheureusement rien à faire. Marmiton utilise vraisemblablement la plateforme publicitaire de aufeminin et subit sa mauvaise optimisation.<br />Règle suivante : Optimiser les images<br />Comme le dit PageSpeed, ils auraient pu réduire la taille des images de 72,7 ko (ce qui représente tout de même 10% de l’ensemble des ressources de la page !)<br />Dernière règle : Différer l'analyse du code JavaScript<br />Il aurait fallu charger tous les fichiers Javascript après le chargement total de la page. La technique pour le faire est présentée dans les pages précédentes de ce dossier.<br />En prenant en compte ces règles, je pense qu’ils atteindraient entre 80 et 90 points sur le score de PageSpeed (pour rappel il est actuellement à 66 !), et le temps de chargement serait de l’ordre de 2 à 3 secondes (il est actuellement entre 4 et 5 secondes).<br />Bien entendu en ayant la main complète sur le site on pourrait encore largement améliorer les choses.<br />Conclusion<br />Optimiser la vitesse de chargement d’un site est un travail conséquent mais qui porte très rapidement ses fruits. Les retombées, que ce soit en termes de satisfaction des utilisateurs, d’utilisation de votre serveur, ou de référencement sont généralement assez impressionnantes.<br />Bien que le gros du travail soit fait « une fois pour toutes », je vous conseille de mettre en place une veille, par exemple mensuelle, afin de suivre l’évolution de vos temps de chargement. Pour cela un rapide coup d’œil dans Google Webmaster Tools et vous verrez si vous gardez toujours le bon cap.<br />Je dois régulièrement vérifier que mon site est toujours optimisé <br />Il y a également d’autres axes d’optimisation (mise en cache applicative, optimisation des requêtes SQL, …). N’hésitez pas à explorer d’autres pistes et vous trouverez peut-être vous-même de nouvelles optimisations ! <br />Je vous remercie pour votre attention et me tiens prêt à répondre à vos questions sur Webxfrance.org. Bonne optimisation à tous !<br />505460323542000<br />