Portrait Olivier Duffez

Olivier Duffez

Créateur de WebRankInfo,
consultant en référencement

Nombreux conseils pour optimiser la vitesse de chargement d’un site

La rapidité d’un site est devenue un critère pris en compte dans le référencement Google dès 2010… Comment améliorer le temps de chargement des pages de votre site ? Cet article de WebRankInfo fait un point complet sur la question.

Article mis à jour le 28/11/2015, publié initialement le 07/12/2009

Vitesse site Internet

Nombreux conseils pour augmenter la vitesse de son site Internet

Le temps de chargement d’une page, facteur pris en compte pour le positionnement dans Google

Google PageSpeedGoogle a annoncé officiellement qu’il tenait compte dans son algorithme de la rapidité des sites. C’est sans doute seulement dans les cas extrêmes que ce critère est important, mais il est conseillé malgré tout de faire en sorte d’avoir un site rapide.

Il y a de nombreuses façons de mesurer la rapidité : est-ce le temps de téléchargement du code HTML comme le font les robots ? ou également des fichiers externes (images, scripts, styles, etc.) ? est-ce une moyenne sur une zone géographique donnée ou sur d’autres critères de sélection des internautes ? sur quelle durée cette moyenne serait-elle calculée ?

Enfin, est-ce cohérent de la part d’un moteur de recherche de vouloir tenir compte de la rapidité ? Google semble vouloir en faire son cheval de bataille depuis 2010, mais n’est-ce pas une façon de continuer à s’imposer comme le leader des moteurs de recherche ? Cet article n’a pas pour objectif de répondre à ces questions, mais plutôt d’aider tous ceux qui gèrent un site web à le rendre plus rapide. Un site plus rapide plait aux visiteurs et se donne des chances pour une meilleure visibilité dans Google !

Améliorer la vitesse de chargement d’une page

Ne ratez surtout pas cet autre dossier : les 4 indicateurs-clés de performance de la vitesse d’une page (et les outils pour les mesurer, puis pour corriger les problèmes).

Réduire le poids des pages web

Pour réduire le poids d’une page Internet, voici quelques conseils de base :

  • Regrouper les styles CSS ensemble dans un fichier CSS externe (mais pas dans plusieurs !)
  • Regrouper les scripts JavaScript ensemble dans un fichier JS externe (mais pas dans plusieurs !)
  • Recourir à la compression GZIP (voir ci-dessous)
  • Exploiter la mise en cache (serveur ou client) : (voir ci-dessous)
  • Optimiser son code JavaScript (par exemple en utilisant le compilateur Closure Compiler de Google)
  • Utiliser le bon format de compression d’images : JPEG pour les photos et PNG pour les autres (simplification un peu rapide je l’accorde…)
  • Utiliser des sprites CSS (images combinant plusieurs images dans un seul fichier, affichées partiellement grâce aux styles CSS, ce qui permet d’avoir une seule image à télécharger au lieu de plusieurs)

Optimiser les CSS

Voici 13 astuces d’optimisation de vos feuilles de styles CSS :

  • Utiliser des sprites CSS
  • Combiner tous les fichiers CSS en un seul
  • N’utiliser que des CSS externes (pas de code CSS intégré dans la page HTML)
  • Toujours mettre le CSS dans l’entête HTML (head)
  • Utiliser Link plutôt que @import
  • Utiliser les raccourcis CSS pour regrouper plusieurs propriétés ensemble
  • Regrouper les styles très similaires
  • Réduire le nombre de retours chariot
  • Réduire les commentaires (exclure les caractères inutiles)
  • Utiliser les couleurs simplifiées standard (3 caractères au lieu de 6)
  • Remplacer 0px par 0
  • Supprimer les classes non utilisées
  • Utiliser des outils de compression CSS

Pour les détails lisez cet article (en anglais).

Améliorer la rapidité du site avec la mise en cache

La mise en cache consiste à conserver une copie de certains éléments pour éviter d’avoir à les reconstituer plusieurs fois. Le cache peut se situer sur le serveur (cache côté serveur) ou dans le navigateur de l’internaute (cache côté client).

Cache serveur

Renseignez-vous sur les dispositifs de mise en cache disponibles selon les technologies que vous utilisez. Avec PHP, vous pouvez tester par exemple Memcache ou bien un système de templates comme Smarty.

Cache client (navigateur)

L’objectif ici est de confier au navigateur de l’internaute le soin de ne pas redemander à chaque fois au serveur du site web de fournir des données, mais de puiser si possible dans une version locale enregistrée sur le disque dur lors d’une précédente visite.

Pour cela, il faut configurer les en-têtes HTTP Expires et Cache-Control qui permettent de fixer quand un élément mis en cache par le navigateur est périmé et doit par conséquent être mis à jour.

Sous Apache, ces éléments se configurent au travers de deux directives :

  • Expires : il s’agit de la date d’expiration du contenu
  • Cache-Control : c’est un paramètre plus évolué que Expires, apparu avec le protocole HTTP 1.1, qui permet de configurer certains détails

A noter qu’à partir de la version Apache 2.0, il est possible de configurer ces deux directives en même temps avec le module mod_expires. La date d’expiration peut être configurée en relatif ou en absolu. Il est conseillé de fixer un délai d’expiration long pour les fichiers statiques (par exemple 1 an) et court pour les fichiers dynamiques (par exemple 1 minute). Voyez la partie ressources en fin d’articles pour plus d’explications.

Compression GZip ou Deflate

Pour économiser de la bande passante (et donc accélérer les temps de téléchargement), vous pouvez aussi compresser vos données texte au format Zip. Depuis la version 1.1 du protocole HTTP, vous n’avez plus de souci à vous faire sur la question : compressez tout et les quelques navigateurs obsolètes qui ne gèrent pas la réception de données compressées se verront servir par votre site les données non compressées qu’il faut.

Pour compresser vos données, il suffit de configurer votre serveur, ce qui se fait en quelques lignes à peine sous Apache. Les version 1.3 et suivantes d’Apache se basent sur le module mod_gzip tandis que les versions 2 et suivantes se basent sur le module mod_deflate.

Voilà un exemple pour Apache 2.0+ qui configure la compression pour les fichiers HTML, PHP, TXT, XML, JS et CSS :

<IfModule mod_deflate.c>
<FilesMatch ".(html|php|txt|xml|js|css)$">
SetOutputFilter DEFLATE
</FilesMatch>
</IfModule>

Une autre solution consiste à spécifier cette option de cette façon :

AddOutputFilterByType DEFLATE text/html text/xml application/xhtml+xml text/plain application/javascript text/css

Entêtes LastModified et ETag

LastModified est un entête HTTP qui définit la dernière date de modification d’un fichier. Il est utilisé dans la gestion du cache client. Il existe aussi l’entête ETag mais vous pouvez commencer par utiliser uniquement LastModified.

Automatiser tout ça avec mod_pagespeed

Google a développé mod_pagespeed, un module pour Apache intégrant de nombreuses optimisations. Pour en savoir plus, lisez mon tutoriel sur le module pagespeed.

Réduire les temps de réponse

Voici quelques conseils pour réduire le temps de réponse (Round-Trip Time, c’est-à-dire le temps entre la demande du client et la réponse du serveur, sans inclure le temps de téléchargement des données) :

  • Minimisez le nombre de requêtes DNS en limitant le nombre de (noms de) domaines concernés par vos scripts et fichiers
  • Evitez les redirections
  • Comme vu précédemment, regroupez les fichiers CSS ensemble (idem pour les scripts JavaScript)

Autres solutions pour l’amélioration de la rapidité d’un site

Analyse de performance dans Google Search Console

En 2009, Google fournissait dans Search Console un rapport des performances de leurs sites web . Malheureusement, il a été supprimé ! Voici pour info les éléments qui y figuraient :

  • durée moyenne de chargement des pages du site (avec comparaison avec le reste du web)
  • quelques exemples de pages du site avec leur temps moyen de chargement
  • quelques exemples de pages du site avec des suggestions d’optimisation

Par contre, il reste toujours une autre analyse de la vitesse de votre site, cette fois-ci en termes de temps de téléchargement. Vous pouvez en effet surveiller l’activité de Googlebot sur votre site au travers de 3 graphiques, disponibles dans la rubrique Exploration > Statistiques sur l’exploration :

  • Nombre de pages explorées par jour
  • Nombre de Ko téléchargés par jour
  • Temps de téléchargement d’une page (en millisecondes)

Si vous détectez une hausse anormale du temps de téléchargement moyen des pages sur votre site (par Googlebot), posez-vous des questions sur les performances de rapidité de votre site ! Evidemment, n’utilisez qu’en dernier recours la solution consistant à demander à Googlebot de venir moins souvent crawler vos pages… Passez plutôt du temps à améliorer la rapidité de votre site ou bien investissez dans un meilleur hébergeur web !

Le problème de ce rapport est qu’il ne donne pas le détail page par page, ou rubrique par rubrique. Pour cela, j’ai une solution avec mon outil d’audit SEO en ligne !

Outils en ligne et extensions Firefox, Chrome, Internet Explorer

J’ai regroupé en fin d’article dans la rubrique Ressources un certain nombre d’outils ou d’extensions pour les navigateurs qui pourraient vous aider dans toutes ces optimisations.

Accélérer Google Analytics avec le code de tracking asynchrone

Google propose depuis très longtemps (2009) un code de tracking Google Analytics différent du code standard habituellement inséré en bas de page. Le code asynchrone génère dynamiquement une balise <script> qui effectuera le tracking. Avec ce code, le chargement de la page est indépendant du chargement du code de tracking, si bien que le chargement de la page s’effectuera en parallèle de celui du tracking.

Au final, vous gagnerez en rapidité et éviterez d’avoir une page qui n’en finit pas de se charger à cause d’un ralentissement ou d’une page des serveurs de Google Analytics. Cerise sur le gâteau, vous pouvez placer le nouveau code de tracking en haut de page, ce qui vous aidera à analyser tous vos visiteurs et pas seulement ceux qui attendent que votre page soit entièrement chargée.

Si vous souhaitez plus d’informations ou des conseils sur le code de tracking asynchrone de Google, on en discute dans le forum Google Analytics de WRI ainsi qu’en formation Analytics.

Autres conseils pour la rapidité

Le DNS de Google

Ca ne va pas augmenter la rapidité de votre site mais toujours bon à savoir : Google propose à tous les internautes qui souhaitent accélérer leur surf d’utiliser un serveur de DNS ultra-rapide. Le principe est le suivant : quand vous cherchez à accéder à un site (webrankinfo.com par exemple), vous ne connaissez que son nom de domaine mais pas l’adresse IP du serveur web qui gère le site. Internet nécessite donc un système qui fasse le lien entre les deux, c’est ce qu’on appelle les DNS.

Dans de nombreux cas, les internautes utilisent les DNS fournis par leur fournisseur d’accès. Hors ceux-ci ne sont pas toujours extrêmement rapides, occasionnant donc quelques délais avant qu’un site ne puisse s’afficher dans le navigateur.

Google propose son propre système gratuitement, intitulé Google Public DNS. Pour l’utiliser, il suffit de configurer sa connexion Internet pour définir les serveurs de DNS par leur adresse IP. Pour Google c’est assez simple : 8.8.8.8 pour le DNS primaire et 8.8.4.4 pour le DNS secondaire. De nombreux serveurs sont exploités sur la surface du globe afin de fournir le service le plus rapide possible.

Le problème est que ce service de Google lui permet une fois de plus de récupérer des informations privées sur les habitudes des internautes. Officiellement ces données ne sont conservées que 48h…

A noter qu’il existe déjà OpenDNS qui propose le même genre de service gratuitement.

Ressources

Conseils pour accélérer son site web

Outils en ligne et extensions pour l’accélération d’un site web

Je vous recommande spécialement 3 outils que j’ai pu tester :

Voici d’autres outils ou extensions qui pourraient vous servir dans toutes ces optimisations :

  • webpagetest.org
  • websiteoptimization.com
  • site-perf.com
  • gtmetrix.com
  • Page Speed et Yahoo YSlow sont des extensions Firefox complémentaires à Firebug effectuant plusieurs analyses de rapidité et fournissant des suggestions d’optimisation
  • Analyse des flux HTTP et HTTPS : via le proxy Fiddler 2 ou via l’outil HTTP Watch intégré à Firefox ou Internet Explorer
  • CSS Sprite Generator, un générateur d’images sprites CSS
  • mon.itor.us, un outil très complet d’analyse de votre serveur web : performances et disponibilité du serveur, rapports d’uptime, alertes, etc.
  • Wbox, une boîte à outils très complète : benchmark de temps de chargement de page, tests de charge du serveur et des applications, vérification de la configuration du serveur (noms d’hôtes virtuels, redirections, compression HTTP)

Si vous en connaissez d’autres, indiquez-les en commentaires avec quelques explications, merci ! N’oubliez pas de jeter également un oeil à ma liste d’extensions Firefox pour le référencement.

On discute de tout cela dans le forum WebRankInfo dans la discussion sur les techniques d’accélération du chargement d’un site web.

Cet article vous a-t-il plu ?

Cliquez pour voter !

Laisser un commentaire

Remarques :

  • Si vous souhaitez poser une question ou détailler un problème technique, il ne faut pas utiliser le formulaire ci-dessous qui est réservé aux avis. Posez votre question directement dans le forum Gmail de WebRankInfo. L'inscription est gratuite et immédiate.

  • En postant un avis, vous acceptez les CGU du site WebRankInfo. Si votre avis ne respecte pas ces règles, il pourra être refusé. Si vous indiquez votre adresse email, vous serez informé dès que votre avis aura été validé (ou refusé...) ; votre adresse ne sera pas utilisée pour vous envoyer des mailings et ne sera pas revendue ou cédée à des tiers.

52 commentaires

Djerba

Je me sert déjà de quelques outils proposés.
J’ai bien aimé l’astuce du tracking asynchrone avec Analytics. Et c’est ce qui nous manque vraiment :)
De nos jours, les mashups, gadgets, widgets…prennent du temps pour charger au coté du client !

Ex: en faisant appel à JQuery à travers la JSApi avec google.load(« jquery », « 1.3 »);
Est-ce une bonne pratique ou non ?

L’utilité de les regrouper à travers un seul serveur me parait convenable. « à tester ! »

On doit aussi essayer de réduire les requêtes simultanées.
Bravo pour ce tutoriel que je viens de marquer :)

Répondre
Olivier TASSEL

Bravo pour cet article complet.

Il est également possible d’optimiser la vitesse de son site en :
– utilisant d’autres serveurs web comme Nginx par exemple ou encore lighttpd.
– en supprimant les retours chariots et autres tabulations dans le code source des pages CSS et HTML (technique utilisé par Google notamment)
– …

Répondre
Léo, Propulsr

Bon résumé même si je ne suis pas tout a fait d’accord sur certains points :

# Regrouper les styles CSS ensemble dans un fichier CSS externe (mais pas dans plusieurs !)
# Regrouper les scripts JavaScript ensemble dans un fichier JS externe (mais pas dans plusieurs !)

pour réduire le poids des pages. Le bytes sauvées correspondent uniquement aux lignes de codes qui n’apparaissent pas dans le HTML. Vous pouvez aussi utiliser le @import dans un feuille de style pour en appeler d’autres mais le probleme ne sera pas résolu.
L’avantage principal de grouper les fichier est de réduire le nombre de requêtes DNS pas de réduire le poids des pages.

J’ai pas mal joué avec l’optimisation de mes sites ces dernières semaines et tous les sites/plugins parlent de ‘delivery of static content from a cookies-less domain » ce qui va a l’encontre de :

Minimisez le nombre de requêtes DNS en limitant le nombre de (noms de) domaines concernés par vos scripts et fichiers.

Car il faut créer un nouveau (sous-) domaine qui n’envoie pas de cookies avec les requêtes. Pareil pour le CDN, aucune mention ici (même si cela ne concerne que les sites à très fort trafic).

@Olivier Tassel – la suppression de retour de chariots dans les scripts est utilisé par Google (et autres) sous le terme ‘minify’. Google Page Speed vous donne d’ailleurs une version ‘minifiée’ de vos CSS lorsque vous testez une page.

Pour la gestion de cache, voici un exemple de script htaccess que j’utilise sur un site.

ExpiresActive On
ExpiresByType text/css « access plus 1 month »
ExpiresByType image/x-icon « access plus 1 year »
ExpiresByType image/png « access plus 1 month »
ExpiresByType image/gif « access plus 1 month »
ExpiresByType image/jpeg « access plus 1 month »
ExpiresByType image/jpg « access plus 1 month »
ExpiresByType text/javascript « access plus 1 month »
ExpiresByType application/javascript « access plus 1 month »
ExpiresByType application/x-javascript « access plus 1 month »
ExpiresByType application/x-shockwave-flash « access plus 1 year »
ExpiresByType audio/mpeg « access plus 1 year »

Je dois dire que le cache et la compression sont les variables les plus faciles à optimiser et elles m’ont fait gagner de précieuses secondes sur webpagetest.org.

Si seulement je pouvais améliorer mon TTFB wordpress maintenant !

Répondre
yves

firebug est très bien aussi pour mesurer le temps de chargement : à rajouter en ressources !

Répondre
Elia

tracking asynchrone de Analytics permet d’utiliser les variables additionnel genre _setDomainName ?

Répondre
Olivier TASSEL

@Léo
Le fait de regrouper les CSS et les JS ne permet pas seulement de réduire le nombre de requêtes HTTP : l’intérêt est de supprimer les éléments doublons (classes, id, fonctions,…) et donc de réduire le poids global.

Au delà de ses aspects, les conseils d’optimisation des requêtes SQL ainsi que du code (PHP,…) restent de mise !

Répondre
MrBark

Salut,

Bon tout d’abord je suis très choqué par cette histoire de dns google ! je n’étais meme pas au courant…
Comme quoi ca commence à aller très loin…
depuis quand google a-t-il mis en place ce « service » ?

Pour ce qui est de la rapidité, je ne suis pas neutre car mes sites de business sont vraiment très rapides, donc je ne souhaite qu’une chose: que google pénalise enfin les sites lents, c’est à dire mal faits en général.
Mais en était plus objectif, je pense que c’est un critère ridicule tant que les valeurs ne sont pas extrèmes :
l’internaute se moque totalement que la page prenne 0 ou 5 secondes à se charger si son contenu est intéressant.

Mais voila, comme je l’ai dit: pourvu que les sites ou les pages mettent plus de 2 secondes passent bien loin ! hihi :D

Personnellement je pense que ce critères est déja pris en compte depuis des années, au moins de manière binaire (« site lent ») pour les extremes.

Répondre
Moloson

Regroupé tout les CSS dans un seul et même fichier c’est pas bien, car on utilise pas obligatoirement toutes les propriétés dans une page, donc ça alourdi la taille du fichier pour rien :)
En plus il existe des scripts comme minify qui permettent de regrouper plusieurs CSS ensemble, après une petite règle de rewrite et ça devient « invisible » pour l’utilisateur ;)

Répondre
MaxR de Maxadi

Favoriser la rapidité du chargement des pages, c’est un peu comme un libraire qui conseillerait les livres ayant un miminum de pages, sous prétexte qu’ils se lisent plus vite.

Je suis d’accord avec MrBark, si la qualité est au rendez-vous, ce n’est pas quelques secondes de plus ou de moins qui va détourner l’attention de l’internaute intéressé.

Google prend beaucoup de mesures peu populaires ces temps-ci (exclusions de comptes Adwords, …). Vous ne trouvez pas ???

Répondre
Léo, Propulsr

@Olivier Tassel, oui il faut que j’aille bidouiller wordpress mais bon devoir le faire a chaque mise à jour ne m’enchante guère :)

@MrBank, l’annonce des DNS date de la semaine passée (jeudi si mes souvenirs sont exacts). Par contre je ne suis pas sur que l’internaute se moque si les pages d’un site mettent 5 secondes à se charger, et c’est d’ailleurs pour cela que Google pousse aujourd’hui les webmasters à s’intéresser à la vitesse de leur site.

Pour rappel ils fixent la limite entre rapide et lent (dans GWT) à 1.5sec.

Répondre
tro choi

Merci pour cet article!

Ca devrait forcer pas mal de gens a investir aussi dans un serveur dédié, et a optimiser les pages.
Les visiteurs seraient gagnants.

Répondre
MrBark

@Leo : 1.5s :D juste ce qu’il faut pour faire mon bonheur :)

PS: pour les css je ne suis pas d’accord non plus pour les regrouper en un seul fichier.
J’ai un site à la fois encyclopédie (domaine racine) , forum (sous domaine forum) et plateforme de blogs (sous domaine blog). Dans ce cas, j’ai fait un styles.css principal contenant ce qui est utilisé partout domaine racine, et aussi 2 autres pour ce qui n’est utilisé que sur le forum (styles-forum.css) et que sur les blogs (styles-blog.css).
Il est évident que dans ce cas il ne faut pas les regrouper car un visiteur qui n’affichera qu’un seul sous domaine sera bêtement ralenti.

En revanche, à la suite de cet article je me suis fait un perl tout bete pour simplifier mes css, et ca me gagne 11% sur ces fichiers, c’est à dire plus de 2KB sur un fichier de 20KB.
Voila :

$file =~ s/n //g;
$file =~ s/s / /g;
$file =~ s/(?<=D)0px/0/ig;
$file =~ s/(?<={) //g;
$file =~ s/ (?=})//g;
$file =~ s/ (?={)//g;
$file =~ s/;(?=})//g;
$file =~ s/(?<=;) //g;

Répondre
Dan166

Sujet passionnant, certes, et j’ai cherché quelque part par un tutoriel complet pour adapter mon site à cette nouvelle tendance…et je n’ai rien trouvé sur le web. Car, n’étant pas un pro comme la plupart d’entre vous, j’aurais besoin d’un script détaillé (css et html) pour appliquer la méthode. Si l’outil générateur de sprites est utile, je ne vois pas comment fabriquer les lignes html pour le faire fonctionner. Ayant passé 2 heures en vain sur la toile à faire ces recherches, je pense que celui qui créerait ce tutoriel ferait une super B.A.

Répondre
Léo, Propulsr

Pour les sprites CSS, il y a la trad de l’excellent article de alistapart par pompage :

Répondre
Olivier Duffez

Merci le Geek pour cet article intéressant (j’ai changé le lien pour pointer directement vers la bonne page)

Répondre
Dan166

Merci. On apprend plein de choses ici ! J’ai déjà divisé par 2 mon temps de chargement en plaçant mes images dans des id dans mes fichiers css.

Répondre
dbl5

Bonjour

Le code

SetOutputFilter DEFLATE

doit être mis en place dans le fichier de configuration du module mod_deflate ?

Répondre
Léo, Propulsr

@dbl5 non ce code va dans le fichier .htaccess du site

Répondre
Création site tunisie

Excellent article . Merci Olivier

Répondre
Visit Rome

Ce qui va grandement aider le chargement des pages notamment de blogs, en croissance exponentielle, (et la conséquente prise en compte par Google comme atout bénéfique en tant que critère de positionnement) sera aussi la canalisation des commentaires de ces blogs qui font moins de 140 caractères mais qui constituent un poids non indifférent dans le chargement d’une page web quand ils commencent à etre nombreux.

Il y aura donc plus de contenu, moins de commentaires et la vitesse relative au chargement de ces pages ne fera que faire jouir le positionnement de ces sites.

Répondre
Indiana jeux.com

Merci pour cet article. En effet, peut-être sera t-il ( encore ) plus utile quand google tiendra réellement compte du temps de chargement des pages. J’ai changé de serveur pour mon site indiana-jeux il y a un mois, suite à la charge croissante de trafic et à une erreur sur une de mes requêtes, certaines pages mettaient plus de 20 secondes à se charger. Maintenant c’est beaucoup plus rapide et je n’ai vu aucun changement dans mon positionnement et encore moins sur mon trafic. Je vais pas m’en peindre :)

Répondre
BOURLINGUEUR

Merci pour cet article, j’aimerai temps pouvoir déchiffrer les informations du page speed qui sont loin d’être évidente pour un non professionnel

Répondre
plusdefric

Moi j’ai pris conseil pour compresser mon fichier css après quelques test et quelques galère j’ai réussi a y arriver. merci

Répondre
audi

les CMS comme typo3 ou wordpress sont déjà optimisés?

Y ‘a des pluggins qui optimisent encore plus le poids (après optimisation photos…)? le serveur s’il est enorme pas besoin de plus de bande passante (la difference entre site en local ou petit serveur et gros serveur), non?

Répondre
jeux

Bonjour WRI,

J’ai en effet fait des test, et google prend en compte la rapidité de l’affichage d’une page pour le référencement, enfin c’est un des critères parmi XXX autres ;)
donc merci pour ton article, il est super complet et bien pratique !

Répondre
toupil

article très intéressant. j’utilise un certain nombre de ces optimisations, et je suis à moins d’une seconde sur ma page d’accueil.
merci !

Répondre
SpeedyWeb

Pour ceux qui sont chez 1and1 (pas testé ailleurs) et qui veulent compresser leur css et javascript:

Renommez vos .css et .js en .php et mettre en haut de vos fichiers:

pour le css:

entre deux balises php:
ob_start("ob_gzhandler");
header("Content-type: text/css; charset: utf-8");

pour les javascript:

entre deux balises php:
ob_start("ob_gzhandler");
header("Content-type: text/javascript; charset: utf-8");

Renommez dans vos sources html l’appel à ses fichiers en .php.

Voila vous venez de gagner quelques points à pagespeed :)

Répondre
Dakine

C’est justement lorsque je recherche les astuces pour accélérer mon site que WRI me l’envoi dans ma boite au lettre !

Peut t-on bêtement rassembler tous les scripts JS dans un seul fichier puis l’appeler dans la balise HEAD, ou il faut éditer chaque fichier php et tpl un par un ? (sur Prestashop dans mon cas)

Répondre
Djerba

Il y a aussi la technique de plus en plus utilisée, de regrouper toutes les images principales (icones, boutons, header, logo, etc etc) sur une seulle grande image. C’est une très bonne méthode pour limiter le nombre de chargement d’images.
Un très bon outil pour vérifier la vitesse de chargement de vos pages : pingdom.com

Répondre
Olivier Duffez

Regrouper les images, c’est ce qu’on appelle utiliser des sprites (indiqué dans l’article mais pas de manière assez explicite en effet)

Répondre
Eleanor

merci
j’utilise un certain nombre de ces optimisations.

Répondre
SpeedyWeb

Les sprites, ça dépend du site en fait…
Il faut quand même faire le rapprochement entre le gain en vitesse pure dépendant du nombre d’image du site à la base, sa capacité d’adaptation en cas de mise à jour et le temps passé à tout coder !
Si il faut refaire tout le css pour un changement d’image, c’est pas le but non plus ! Bref a utiliser mais que pour des projets très précis et à haute charge serveur !

Répondre
Programme télé

J’ai essayé l’astuce de @Léo en ajoutant ses lignes dans mon fichier .htaccess mais ça me fait une erreur 500. Quelqu’un sait il de quoi ça peut venir ? Merci

Répondre
SpeedyWeb

Si vous voulez voir un site à 100% à pagespeed, regardez içi,

http://www.nancy-immo.fr

deux ans de travail pour régler mes htaccess !

Répondre
seanthi

Bonjour,
Très intéressant comme article mais comment peut faire celui qui a fait son site avec joomla?????
Car j’ai remarqué que la plupart des sites sous joomla sont extrêmement lent à charger….
Merci

Répondre
jouer

Je dirais que pour joomla comme pour d’autres sites, dont le mien, la meilleure solution est de gérer un système de fichier cache, c’est à dire que si une page à été calculer via des requête SQL, pour générer cette page, si cette page la ne change pas, pourquoi la régénérer a chaque fois alors que l’on peut écrire le résultat dans u fichier, après y a juste à tester si la page est déjà généré…
par exemple avant, chaque page avait besoin de 0,02 à 0,20 suivant la charge du serveur pour se générer et s’afficher, maintenant c’est 0,00 !

Répondre
fogan

c’est vraiment cool votre truc. j’ai aime. merci

Répondre
Prestadget

Utilisez Smarty ? Surtout pas, le cache Smarty veut dire « template > Php », mais ça reste du Php, et surtout du Php généré automatique ! donc horriblement lent ….

Un système de templating ne peut que rajouter une couche de lenteur.

Vous parlez d’Apache ? Berk ! Performance et Apache dans la même phrase ;-(

Nginx !!!! Apache est fait pour les mutu., .htaccess etc …. pas pour un hébergement haute performance !

Enfin, la seule solution pour avoir un site performant ? le cache statique, soit avec un module spéciale en Php, soit avec un proxy (Varsnish, Squid ou encore Nginx). Il est surtout conseillé de donner ce type de contenu aux bots (qui n’ont pas besoin d’un panier, d’un login etc…).

Prestadget

Répondre
Olivier Duffez

Merci Prestadget pour cette analyse, on voit que tu t’y connais bien apparemment.

Répondre
Laurent

Bonsoir Olivier je lis vos articles depuis un moment.

Pensez vous que les valeurs suivantes renseignées dans un .htacess sont bonnes ?. Précision, mon site est fait sous joomla 1.5

Merci de votre avis

ExpiresActive on

ExpiresByType text/html A7200

ExpiresByType text/css A604800
ExpiresByType application/x-javascript A604800
ExpiresByType application/javascript A604800
ExpiresByType text/javascript A604800
ExpiresByType text/swf A604800
ExpiresByType image/jpeg A604800
ExpiresByType image/jpg A604800
ExpiresByType image/png A604800
ExpiresByType image/gif A604800

ExpiresByType application/x-shockwave-flash A604800
ExpiresByTYpe text/xml A604800

# 480 weeks

Header set Cache-Control « max-age=290304000, public »

# 2 DAYS

Header set Cache-Control « max-age=172800, public, must-revalidate »

# 2 HOURS

Header set Cache-Control « max-age=7200, must-revalidate »

Header set Cache-Control « public »
Header set Expires « Thu, 15 Apr 2015 20:00:00 GMT »

# KILL THEM ETAGS
Header unset ETag
FileETag none

Répondre
xgl

Ces techniques sont un minimum pour avoir un site assez rapide mais pour avoir un site extrêmement rapide, elles doivent être couplés avec une autre technique : le chargement de fragments.

En effet, une grosse perte de temps pour un navigateur est lié au travail de régénération complète d’une page alors qu’une grande part de ce travail est le même d’une page à une autre pour pas mal de site : header, footer, sidebar, navigation. Autrement dit, pourquoi tout recharger d’une page à une autre alors que seul une petite partie change ? Autant ne charger que cette partie, des fragments de la page.

Ceci à en plus l’avantage de ne faire transiter qu’un faible volume de données par rapport à une page complète et nécessite moins de travail du serveur qui n’a pas la page complète à générer. Et avec une bonne gestion du cache navigateur, on minimise le trafic réseau, un système de cache côté serveur permettant lui de minimiser sa charge.

Ce chargement de fragments ne peut bien sûr se faire que via des requêtes AJAX et nécessite une bonne phase d’architecture logiciel à la conception du site selon sa complexité, d’autant qu’il faut conserver une structure de site ayant de multiples URL indexables par les moteurs de recherche (ou si on souhaite que le site fonctionne aussi sans Javascript) et non une structure de WebApp, ce qui est plutôt le cas si on fait tous les chargements en Ajax.

Pour cela, HTML5 apporte un élément fondamental, l’History API qui permet de gérer le contenu de la barre d’URL du navigateur et les actions à réaliser suite à un clic sur les boutons Next et Back du navigateur (cette API est implémentée depuis un certain temps dans Firefox, Chrome, Safari et Opera et dans le futur IE 10).

Ainsi on peut donc, sur un clic qui normalement charge une nouvelle page, ne charger que les fragments nécessaires via de l’AJAX, les injecter dans le DOM et avec l’History API, changer l’URL dans la barre du navigateur.

Cette technique est notamment intégrée dans le framework jQuery Mobile : http://jquerymobile.com/

Des sites utilisent cette technique, évidemment Google quand vous changer de page dans les résultats de recherche. Mais aussi des sites moins connus, comme le site de Pernod Ricard : http://pernod-ricard.fr (sur Chrome 22 ou Firefox 16, la vitesse est assez bluffante).

Répondre
Olivier Duffez

Merci xgl, c’est très intéressant. Est-ce que toutes ces technologies sont compatibles SEO ? Notamment, ça génère toujours des URL différentes pour des contenus différents (même si toute la page n’est pas concrètement rechargée) ?

Répondre
xgl

Oui ça reste compatible SEO, c’est aussi ce que je veux dire par « il faut conserver une structure de site ayant de multiples URL indexables », ça nécessite juste un peu plus de réflexion pour bien le faire (architecture logiciel).

Répondre
Denis TRUFFAUT

Pour répondre à Olivier, c’est SEO-friendly, du moins sur le papier.

https://developers.google.com/webmasters/ajax-crawling/

C’est cependant complexe à mettre en place, surtout si on veut passer mass data dans le fragment (cryptage, base64), et on obtient au final des urls à rallonge dépourvues de mots clés.

J’ai testé pendant un moment dans le cadre d’un search AJAX, mais je suis rapidement repassé au GET classique.

En plus, l’History API est buggée sous Chrome avec les formulaire : les états sont réinitialisés au lieu d’être sauvegardés, ce qui donne quelques incohérences dans le cadre d’un search. Du coup il faut recharger quasiment toute la page (résultats + filtres) et on perd l’intérêt de l’AJAX.

Pour continuer sur la lancée de Prestadget, je plussoie NginX et l’absence de moteur de templating.

Répondre
xgl

Par chargement de fragments je ne faisais pas référence à cette technique :

https://developers.google.com/webmasters/ajax-crawling/docs/getting-started

qui est effectivement laborieuse à mettre en oeuvre, mais de chargement de fragments comme on peut le faire avec jQuery (http://api.jquery.com/load/).

En résumé, il faut toujours avoir un site avec des « URL différentes pour des contenus différents » (donc SEO-friendly), mais au clic sur un lien, on ne laisse pas faire le navigateur, on va chercher les fragments en AJAX qu’on injecte dans le DOM et on gère l’historique et la barre d’URL avec l’History API. Et là ça speed !

Pour ce qui est de l’HTML 5 History API, il ne faut pas oublié que seul la position du scroll dans la fenêtre est sauvegardée (ce qui est d’ailleurs de trop), pour le reste c’est de la responsabilité du développeur de gérer le contexte (mots recherchés, options diverses, etc.) via les méthodes pushState() et replaceState() et l’évènement popstate.

Pour un exemple d’un search AJAX :

http://pernod-ricard.fr

L’historique y est géré : après plusieurs recherches des back navigateur ramènent bien les recherches et résultats précédents de façon immédiate.

Répondre
Peters Frederic

Est ce qu une valeur de 400 millisecondes est acceptable ? J ai déjà fait tout ce que je pouvais pour l optimisation mais je peux encore améliorer en changeant le CPU de mon serveur je crois :)

Mon site est locations-de-vacances.fr, d après les tests sur webpagetest il est déjà bien optimisé ( sauf le CDN mais ca j’ai pas encore trouvé de solutions bon marché )

Répondre
bugbug

Bonjour

Je développe actuellement un site pouvant tester les critères de vitesse avec yslow et google speed, il pourra vous aider à mieux optimiser la vitesse de chargement de votre site

http://fr.speed-and-seo.com/

Répondre
lesjouets

Bonjour,

Merci beaucoup pour ces informations, j’ai travaillé par les conseille de @Léo en ajoutant ses lignes dans mon fichier .htaccess mais ça me fait une erreur 500 aussi. Quelqu’un sait il de quoi ça peut venir ?
je l’ai appliqué pour un site de vente de jouets qui demande bcp de ressources images lesjouets.ma

Merci

Répondre
crither-web thomas christine

Bonsoir,
Depuis quelques jours, je travaille mon RM Tech, des améliorations apparaissent et je vous en remercie. je dois encore faire des choses (backlist internes..)
Apparemment, d’après GMETRIX et pagespeed insight il semblerait que je dois travailler sur le javascript.
Dans votre article : vous écrivez « Regrouper les scripts JavaScript ensemble dans un fichier JS externe », que j’ai retrouvé d’ailleurs sur d’autres articles, seulement, je n’arrive pas à savoir comment faire. Auriez-vous par hasard un support qui pourrait m’aider? ou me donner une piste?
Je voulais faire la demande sur le forum, mais j’avoue que je ne savais pas dans quel topic le mettre, vous voudrez bien m’en excuser.
A bientôt, crithèrement vôtre crither-web Christine Thomas

Répondre
Olivier Duffez

Pour l’optimisation des Javascript, le mieux est de poser la question dans le forum Développement web, en créant un nouveau topic pour cette question.
Content que RM Tech fournisse plein d’idées d’amélioration SEO !

Répondre