Annonces Google

Vous êtes ici : Dossiers référencement > Webmastering

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

Par , le 28 novembre 2015

La rapidité d'un site est devenue un critère pris en compte dans le référencement Google en 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. Que ce soit pour le seul bien de leurs visiteurs ou pour celui de leur 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.

A propos de l'auteur : Olivier Duffez Olivier Duffez sur Google+ Olivier Duffez sur Twitter Olivier Duffez sur Facebook Olivier Duffez sur Pinterest Olivier Duffez sur LinkedIn

Consultant en référencement, Olivier Duffez a travaillé pour les plus grands sites (Doctissimo, FNAC,...). Il édite le site WebRankInfo qu'il a créé en 2002, devenu la + grande communauté francophone sur le SEO (+300.000 membres, 1,5 million de posts). Il est aussi cofondateur de Ranking Metrics, leader des formations webmarketing en France (SEO, AdWords, Analytics, réseaux sociaux) et éditrice de la plateforme MyRankingMetrics (crawler et audit SEO en ligne).

Article (Comment rendre son site plus rapide : toutes les solutions) publié par WebRankInfo dans la rubrique Webmastering. Si vous souhaitez publier un extrait de cet article sur votre site, assurez-vous de respecter les conditions générales d'utilisation de WebRankInfo.

50 commentaires

  • Djerba a dit le

    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 :)

  • Olivier TASSEL a dit le

    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)
    - ...

  • Léo, Propulsr a dit le

    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 !

  • yves a dit le

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

  • Elia a dit le

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

  • Olivier TASSEL a dit le

    @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 !

  • MrBark a dit le

    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.

  • Moloson a dit le

    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 ;)

  • MaxR de Maxadi a dit le

    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 ???

  • Léo, Propulsr a dit le

    @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.

  • tro choi a dit le

    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.

  • MrBark a dit le

    @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;

  • Dan166 a dit le

    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.

  • Léo, Propulsr a dit le

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

  • site Des Geeks et des lettres a dit le

    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

  • Olivier Duffez a dit le

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

  • Dan166 a dit le

    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.

  • dbl5 a dit le

    Bonjour

    Le code

    SetOutputFilter DEFLATE

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

  • Léo, Propulsr a dit le

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

  • Création site tunisie a dit le

    Excellent article . Merci Olivier

  • Visit Rome a dit le

    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.

  • Indiana jeux.com a dit le

    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 :)

  • BOURLINGUEUR a dit le

    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

  • plusdefric a dit le

    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

  • audi a dit le

    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?

  • jeux a dit le

    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 !

  • toupil a dit le

    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 !

  • SpeedyWeb a dit le

    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 :)

  • Dakine a dit le

    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)

  • Djerba a dit le

    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

  • Olivier Duffez a dit le

    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)

  • Pingwy a dit le

    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/

  • Eleanor a dit le

    merci
    j'utilise un certain nombre de ces optimisations.

  • SpeedyWeb a dit le

    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 !

  • Programme télé a dit le

    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

  • SpeedyWeb a dit le

    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 !

  • seanthi a dit le

    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

  • jouer a dit le

    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 !

  • fogan a dit le

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

  • Prestadget a dit le

    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

  • Olivier Duffez a dit le

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

  • Laurent a dit le

    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

  • xgl a dit le

    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).

  • Olivier Duffez a dit le

    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) ?

  • xgl a dit le

    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).

  • Denis TRUFFAUT a dit le

    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.

  • xgl a dit le

    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.

  • Peters Frederic a dit le

    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é )

  • bugbug a dit le

    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/

  • lesjouets a dit le

    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

Postez un commentaire !

Les champs marqués du signe * sont obligatoires. L'adresse email ne sera pas affichée.

En postant un commentaire, vous acceptez les CGU du site WebRankInfo.

Annonces Google

Catégories des dossiers

Consultez les dossiers par thématiques :

Annonces Google

Formation référencement et webmarketing

Venez chez Ranking Metrics vous former au référencement, à Google AdWords et Analytics ainsi qu'aux réseaux sociaux ! Plus de 4000 entreprises sont déjà venues (Dossier possible OPCA, DIF...).

Préparés et animés par Olivier Duffez (WebRankInfo) et Fabien Faceries (AgentWebRanking), 2 professionnels reconnus dans le domaine, nos modules sur le référencement naturel sont très complets tout en laissant une grande place à l'interactivité pour répondre à toutes les questions des participants.

Pour connaître le plan détaillé de chaque module, le prix, les dates et les lieux, consultez le site de Ranking Metrics (organisme de formation).

Hébergement web

Hébergement web mutualisé et dédié

Pour un bon référencement, il faut un bon hébergeur. Testez Sivit by Nerim, l'hébergeur choisi par Olivier Duffez pour son site WebRankInfo.

A partir de 3€ HT/mois.