Comment rendre son site plus rapide : toutes les solutions – Web Rank Info

WebRankInfo : la plus grande communauté francophone du référencement
Olivier Duffez
Créateur de WebRankInfo,
consultant en référencement
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.
Publié le 28/11/2015. Auteur : Olivier Duffez
Article mis à jour le 28/11/2015, publié initialement le 07/12/2009
Google 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 !
Pour réduire le poids d'une page Internet, voici quelques conseils de base :
Voici 13 astuces d'optimisation de vos feuilles de styles CSS :
Pour les détails lisez cet article (en anglais).
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).
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.
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 :
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.
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 :
Une autre solution consiste à spécifier cette option de cette façon :
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.
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.
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) :
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 :
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 :
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 !
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.
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.
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.
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 :
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 ?
53 commentaires
Bonjour et merci pour le super partage. J'apprécie énormément la qualité de votre contenu. On ressent la quantité d'heures que vous passez dans l'écriture de vos articles de blogs et de la passion que vous y mettez.
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
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 !
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
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/
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é )
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.
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.
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).
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).
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) ?
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
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
Merci Prestadget pour cette analyse, on voit que tu t'y connais bien apparemment.
c'est vraiment cool votre truc. j'ai aime. merci
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 !
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
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 !
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
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 !
merci
j'utilise un certain nombre de ces optimisations.
En effet la rapidité d'un site Internet est devenu quelque chose d'important. Autant pour google que pour les internautes.
Voici un autre article de blog qui fait le rapprochement entre rapidité de site – google – ergonomie :
http://blog.pingwy.com/2011/02/comment-ameliorer-la-rapidite-et-lergonomie-de-mon-site/
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
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)
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)
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 🙂
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 !
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 !
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?
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
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
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 🙂
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.
Excellent article . Merci Olivier
@dbl5 non ce code va dans le fichier .htaccess du site
Bonjour
Le code
SetOutputFilter DEFLATE
doit être mis en place dans le fichier de configuration du module mod_deflate ?
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.
Article sympathique, cependant on peut trouver d’autres configurations et astuces. Perso. j’ai trouvé les armes ultimes pour augmenter la réactivité : http://desgeeksetdeslettres.com/blog/web/plugin-reduire-cache-css-blog-wordpress
Merci le Geek pour cet article intéressant (j'ai changé le lien pour pointer directement vers la bonne page)
Pour les sprites CSS, il y a la trad de l'excellent article de alistapart par pompage :
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.
@Leo : 1.5s 😀 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;
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.
@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.
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 ???
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 😉
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 😀
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.
@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 !
tracking asynchrone de Analytics permet d'utiliser les variables additionnel genre _setDomainName ?
firebug est très bien aussi pour mesurer le temps de chargement : à rajouter en ressources !
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 !
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)
– …
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 🙂
Les commentaires sont fermés
Inscription à la newsletter
Catégories
Consulting SEO
Envie d'améliorer votre référencement ?
Consultant SEO depuis 2003, j'ai une très grande expérience en audit et consulting. Que ce soit pour une demande ponctuelle, pour un audit ou du long terme, je peux vous aider.
WebRankInfo / Tous droits réservés 2022 – Mentions légales – Me contacter

source