Tous les conseils pour accélérer son site web

merci pour cet article

 

J'avais entendu, il y a quelques temps, qu'il fallait mieux scinder ces feuilles CSS pour ne pas avoir trop de propriétés inutiles sur une feuille de style.
Par exemple, sur mon site, j'ai en gros deux types de pages. J'avais donc fait une feuille de style pour les particularités de chacun des types de page (style1.css et style2.css) et une feuille de style pour tout ce qui est commun (base.css). Et donc style1.css appelle base.css et style2.css appelle aussi base.css.

Est-ce que ce genre de méthode est à proscrire ou est-ce que Google dit de n'utiliser qu'une seule feuille de style pour se prémunir contre des sites utilisant les 10 même feuilles de style sur toutes les pages ? (par exemple un site appelant style1.css, style2.css et base.css sur toutes les pages ne devrait effectivement utiliser qu'une feuille de style)

 

Merci très intéressant cet article

Dans le cas ou ce critère va être ajouté réellement à algo, je m'inquiètes de la prochaine étape : conforme W3C?

Si google se met à être conforme W3C tous les générateurs de code vont prendre une sacré claque dans la gueule !
Car il faudra s'attendre à une nouvelle offensive de google et tous ces sites ayant bénéficié de l'aide de ces softs s'en verront pénalisé ?
S'en compter les grosses firmes comme Adobe, Microsoft qui gagnent de l'argent avec leurs softs !!

A vouloir trop en faire, il va finir par se mordre la queue et se mettre beaucoup de monde à dos!

 

La rapidité du site apporte quelque chose de palpable au "client" de google. La conformité "W3C" apporte un confort à l'utilisateur beaucoupmoins visible.

 

la rapidité de nos jours ..... avec les débits qui augmente à tout va, ca ne sera qu'une question de millième de seconde.

Au temps du 56K ! Oui la la rapidité d'un site pouvait jouer et être visible par l'utilisateur ou Google !
Mais maintenant avec le haut débit que même des régions reculées commencent à connaître, le critère rapidité est moins important.
Et plus on avancera dans le temps et plus ça ira vite notamment avec la démocratisation de la fibre et il y a plus rapide encore !


PS: Rumeur = le plus vieux média du monde.

 

la rapidité dépend majoritairement de la charge du serveur et il suffit d'aller sur un site hébergé par OVH et bien mutualisé pour comprendre ce que cela veut dire. Du coup, Google va pénaliser ceux qui ne savent pas offrir du confort à leurs utilisateurs et pourquoi pas

 

La première optimisation à faire est d'abandonner Apache pour héberger son site web.
Sinon, la section où ça "parle" des DNS google est assez marrante. Déjà ils sont lents (10'000 % plus lents que ceux de nos FAI)

 

merci pour l'article, on va regarder de plus près le code de tracking asynchrone

 

Bonjour olivier,

je pense que la rapidité d'un site ne va pas se jouer a la milliseconde, mais plutot à l'echelle humaine, je crois que google pense surtout aux sites qui rame à cause d'un script pourri ou bien d'un serveur pas assez puissant (donc penible pour le visiteurs), le genre de site ou tu ferme la fenetre frustré d'avoir attendu.

Donc optimiser le css, c'est du pipi de chat je pense.

 

Tout d'abord, je rejoins netwee sur le fait que nous ne sommes plus à l'époque du 56k (même s'il faut prendre en considération le nouveau surf iphone, 3G, ...).

Ensuite, il est vrai que la plupart des ces optimisations ne font que gagner quelques millisecondes mais comme le dit steph@ne, optimisation va de paire avec charge. À titre d'exemple, je pense au sprite CSS, ce genre de gain sera néanmoins visible sur un serveur très sollicité.

Donc au final point vue application toute optimisation est bonne à prendre, en revanche j'espère que Google ne jouera pas sur des temps de réponse indifférenciables pour l'humain mais bien de réelle latence.

Les plus grands secrets et révélations se trouvent dans les vieux livres d'histoire abîmés et poussiéreux, de la même manière un site mal optimisé ne remet pas en cause la richesse de son contenu.

 

j'allais le dire, ça augmente fortement

 

Google tools me dit que mon site est 65% plus lent que la plus part des sites. Le pieds hein? La majorité des sites c'est dix pages avec rien dedans, normal quoi... Le script de mon site doit faire un aléatoire pour pick up les images dans la bdd avant de les charger et met 5s pour ça, surement une seconde en plus avec adsense.
Je veux bien que ça soit un critère déterminant, mais il faut aussi segmenter par rapport à la nature des sites.
Enfin bon ça me changera pas la vie de tte manière.

 

La je trouve que c'est de la tyranie. Que l'on ne doive pas avoir un site lent j'applaudis mais nous obliger à utiliser les google open DNS, je ne suis pas d'accord. d'autant plus que je n'ai pas tout compris!

 

Merci Olivier pour cet article.

Pour tous ceux qui pensent que la vitesse n'est plus un critère déterminant... n'oubliez pas tous les pays moins développés, mais néanmoins francophones. Pour ceux qui vivent de la pub, il y a là un gros marché ^^

 

Google me suggere dans le labo de virer les pubs (les siennes), et de virer analytics !
Il perd la boule

 

Pour gérer le Cache-Control avec le fichier .htaccess
Il suffit de copier coller ce script

Code:

<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Cache-Control "public, max-age=290304000"
</FilesMatch>

<FilesMatch "\.(xml|txt)$">
Header set Cache-Control "max-age=172800, public, must-revalidate"
</FilesMatch>

 

+1 avec Marie-Aude

J'ai récemment fait une optimisation sur une boutique en ligne dont la cible est... l'Afrique francophone !

Dans certains coins, les cybercafés affichent royalement 28Kbits/s en débit... Autant vous dire que les homepages de 800 Ko façon RdC ou CDiscount, c'est même pas en rêve.

Là on traque le moindre Ko superflux (compression CSS / JS, utilisation de GZip, optimisation des images, du code, etc.) ; j'ai réussi à passer d'un poids moyen de 320 Ko/page à 180 Ko environ... pas une mince affaire.

De la même manière, tout dépend d'où est fait le test, car si on teste par exemple la vitesse de chargement d'un site hébergé en France depuis un outil ricain, c'est en secondes que ça se joue. Et inversement (ndlr : tests réalisés sur ce fameux site)

 

Je ne sais pas si Google apprécie un site web "plus rapide", mais les visiteurs oui. C'est évident, si le site rame, il vont même pas afficher la page complètement !

 

Salut,

Pour ceux que ca intéresse et comme ca n'apparait pas dans la liste des outils fournis par Olivier voila un petit outil en français bien pratique pour optimiser/compacter les CSS.
http://cleancss.com/

Bye,

 

c'est l'outil que je viens d'utiliser et j'en suis bien satisfait, ça m'a permis de franchir la première étape : 1 seul fichier CSS et optimisation de celui-ci. (avant 2 fichiers de 20ko et 4ko, maintenant 1 fichier de 10ko)

 

Si ça devient le cas, ça serait très inquiétant car :

Je suis du même avis que dorian53, pour le positionnement dans les pages de résultats, je ne vois pas le rapport entre pertinence/richesse du contenu d'un site et le fait que le site rame à l'affichage. 8O :roll:

 

Bien vu et optimisation en vue, après le petit CSS compresseur avez vous de tuyaux pour l'utilisation du GZIP ?
Concernant les DNS, ce sont ceux de GG.... ????! Que pouvons nous faire pour pallier à cela ?

 

Bon alors moi, pour etre dans l'air du temps et gziper les css et les js j'ai testé aves succès depuis hier et je propose :

dans le htsaacss :

Code:

RewriteRule ^(.*).(css|js)$ /compcss.php?file=$1.$2&ext=$2 [L]

et dans le fichier nomé compcss.php

Code:

<?php
$file = $_GET['file'];
$ext = $_GET['ext'];
if ($ext == 'css') {
   header("Content-type: text/css; charset: ISO-8859-1");
} elseif ($ext == 'js') {
    header('Content-Type: application/x-javascript');
}
header("Cache-Control: must-revalidate");
$offset = 60 * 60 ;
$ExpStr = "Expires: ".gmdate("D, d M Y H:i:s",time() + $offset)." GMT";
header($ExpStr);
if ((ini_get('zlib.output_compression') != true) && function_exists('ob_gzhandler')) {
   ob_start("ob_gzhandler");
}
echo (file_get_contents ($file));
?>

et allez hop, du css et du js gzipé pour les navigateurs qui le supportent (pour ceux que ca interessent je peux commenter les lignes pour expliquer.

 

Google cherche surement à développer un Web plus rapide...

Si on arrive à générer des pages plus légères, cela signifie aussi moins de tonnes de Ko à mettre en cache pour le moteur... Google cherche peut être à économiser sur le poids des pages indexés et pour cela, il compte sur nous ...

Après, le web plus rapide est nécessaire pour les navigations sur appareils mobile par exemple car il est vrai qu'on se rend moins compte du temps de chargement des pages avec nos super connexion ADSL devant nos ordi avec des processeurs dual core et j'en passe !!!

Sachant que la rapidité des requètes est l'un des secret de la réussite de Google, il semblerait logique que celui-ci offre des résultats à la fois pertinents et rapides aux internautes...

D'autre part, l'actualité de ces derniers mois concerne beaucoup l'écologie, l'économie des ressources, le développement durable... pour préserver la planète (ex Sommet de Copenhague)

Nous allons surement devoir commencer à économiser des Ko... et à grande échelle, cela aura peut être un impact sur l'environnement !!!

 

Pourquoi pas la logique se tient et nous ferions tous un geste car nous soavons tous que les serveurs de GG sont dans un pays ne faisant pas trop d'effort coté CO2, donc si nous tous faisons un geste, c'est la Planete qui y gagne (ET google dans tout ça il y gagne ?)..... Soyons citoyens. 8)

 

Bonjour,

Pourrais-tu expliquer pour quelles raisons tu préconises l'abandon d'apache ? Par quel serveur proposes-tu de le remplacer ? Merci.
A plus

 

je ne vois pas trop le rapport, car la page envoyée zippée doit être dezippée pour être lue par le navigateur ou par gg, donc le changement :roll: Alors une page envoyée zippée par un serveur va consommer des ressources pour être zippée, envoyée sur le réseau, puis consommer des ressources du pc de l'internaute pour être dezippée dans le navigateur :wink:

lighttpd ?

 

Si les mod expire et deflate ne sont pas installés sur le serveur mutualisé où est hebergé notre site... On fait comment M'sieur ?

 

Merci Ludo-animation. Je comprends à peu près le code. Mais je ne vois pas pourquoi le header avec un charset pour le CSS et pourquoi ISO et pas UTF ? et pourquoi un charset est-il nécessaire ?

Code:

if ($ext == 'css') {
   header("Content-type: text/css; charset: ISO-8859-1");

 

J'ai oublié de mettre le charset sur le JS (je corrige) , ca depend des gouts, tu peut aussi bien metre utf8, et meme ne pas en metre du tout. Je met iso parce que si tu as du JS qui t'envoi des msg en francais ex : alert( "vos données ont été sauvegardées") les é ne vont pas passer en utf8.

 

Merci, pour ta réponse.

 

assez marrant, rapproché de https://www.webrankinfo.com/forum/veesual-moteur-visuel-sponsorise-par-goog ... l#p1119398 vu que le plus rapide reste d'aller directement chez le fournisseur de SERP :mrgreen:

 

Et quels sont-ils ces navigateurs ?

Déjà merci pour le script.
Et oui, je suis intéressé par les commentaires des lignes. s.t.p. ^^

Sauf que ce n'est pas ce que je lui demande. C'est un moteur de recherche, je lui demande tout simplement d'afficher de manière pertinente des résultats suivant des mot-clés que je lui donne.

Un site qui lag à l'affichage peut-être bien plus riche en terme de contenu et plus pertinent en terme de résultat sur une requête qu'un site qui est 10.000 fois plus rapide. Pour moi, ça ne tient pas la route ...

Allez, fini le métier de webdesigner ! Fini les designs personnalisées des sites ! On va tous afficher nos pages en y mettant que le contenu réel, sur une page toute blanche. C'est sur que comme ça, ça sera moins lourd et ça s'affichera plus vite ! lol :lol: :lol: :lol:

 

Au préalable, il faudra savoir ce qui intéresse réellement l'internaute au niveau rapidité d'accès : est-ce le temps de téléchargement ou bien, le plus important quand même, le moment où la page sera opérationnelle ?
Et là, avec la grande mode du web 2.0 où tous les sites se ressemble en utilisant les même scripts de 150 ou 200 Ko, juste pour afficher une liste déroulante, même si tu zippes tes js, ils mettront 1/10°sec de moins à être téléchargés sur ton PC, mais exactement le même temps à être exécutés sur le PC, voire même plus, car il faudra qu'au préalable le navigateur dezippe ton js

 

Le gzip va compresser ce qui aura pour effet d'économiser de la bande passante par exemple, mais pour ce qui est de la rapidité...

 

C'est marrant ça...

Google n'EST PAS le web. Google ne FAIT PAS le web. Google FAIT PARTIE du Web.

 

Ué mais depuis quelques années, google cherche à se tailler un grosse part du web ! Entre tous les services qu'il propose, toutes les entreprises qu'il rachete...

Certe, google n'est qu'une partie du web, mais une bien grosse partie quand même !!!

 

Salut,

Perso pour le Gzip etc je rajoute ca dans le htaccess :

Code:

AddOutputFilter DEFLATE css js

<FilesMatch "\.(jpg|png|gif|ico|css|ico|swf|js)$">
Header set Expires "Thu, 24 Feb 2012 20:00:00 GMT"
Header set Cache-Control "max-age=94608000"
Header unset Last-Modified
Header unset ETag
FileETag None
</FilesMatch>

Bye,

 

Pouvez vous nous décrire la démarche, si je comprends bien, cela signifie que toutes les images ont une date de péremption et un cache-control (?)

Merci pour vos éclaircissements !

 

Tres interessant. Je viens de tester mon site sur webpagetest.org, et j'ai pas mal de chose à optimiser.
Pour gagner de precieuse MS ou S, j'ai noté

-compression gzip(méthode donnée au dessus)
-cache control (méthode donnée au dessus)
-un seul fichier css + optimisation (http://cleancss.com/)
-google analytics en mode asynchrone

Avec tout ça, c'est deja pas mal.

 

Bonjour

J'ai une 'tite question sur le Gzip... Je n'ai pas en totalité analysé le code donné préalablement, mais il me semble que ce code compresse au niveau serveur, et décompresse également au niveau serveur : du coup c'est le contenu non compressé qui passe dans les tuyaux non ?

Ou y'a un truc que j'ai mal saisi (possible, j'ai pas trop dormi :mrgreen: ) ?

 

Bonjour,

J'ai testé la méthode de compcss.php sans succés, mon hébergeur semble un peu réfractaire, mais ce fut un test rapide ( :wink: )
Il va falloir étudier cela mais l'optimisation de css ma fait gagner 17% déjà pas mal... est-ce la meilleure méthode en passant par le htacess ? car cela plante facilement le site.

 

17% de quoi ? de taille ? de temps de transmission (y compris la durée pour zipper le fichier) ? d'exécution ?

 

Pas mal, la taille de mootools passe de 90.4kB à 27kB (page speed). Je veux bien que tu insère les commentaires pour mieux comprendre ce script ;-)

 

Bonsoir,

je viens de lire l'article et j'ai juste survolé vos posts mais j'aurais une petite question.
je ne saisi pas le sens de :

Par contre, je vais afficher 3 publicités en javascript (openX) sur mon site.
Cela veut-il dire que je dois regrouper tous les codes dans un seul fichier .js externes ?
Alors que les 3 emplacements pubs sont situés à différents endroits sur la page ? :/

Et comment je fais alors pour l'appeler en fonction du code que je souhaite ?

Merci pour vos retours,

Cordialement,

 

Pour mon site principal, Google m'affirme que 63% des sites sont plus rapides que le miens. 90% des pages sont fait en HTML sans accès à une BD et contenant que le script pub Adsense. Les pages s'affichent en moins de 3 secondes sur un Iphone et en moins de 1 seconde sur un PC. 88% de mes visiteurs utilisent un PC et 94% sont des internautes français.
Le CSS est ultra optimisé, le design est hyper léger.

Je ne suis vraiment sûr de la pertinence de leur valeur. Pour moi, c'est plutôt 80% des sites qui sont plus lents que le mien.

 

C'est a priori la taille du CSS.

Concernant le GZIP j'ai testé le script sans succès.

 

Mon site est plus lent que 63% des sites.
Dû en particulier à Adsense, xiti, analytics et autres scripts d'affiliation.
En plus mon site contient beaucoup de photos (voyages) (j'ai mis le cache expires à 1 an). Gzip n'est pas dispo chez Online.
Si je suis les reco de GG, je ne mets que du texte, pas de pub ni de mesures, autres que l'analyse des logs à postériori, et ça va aller beaucoup plus vite.
J'ai fait ça en 1995 : que du texte, pas de tableaux (ça n'existait pas), pas d'images, pas de script (sur le serveur).
A quoi sert la fibre optique et les serveurs à x ghz ? Je ne parle pas de vidéo online, et en streaming HD !
GG va déclasser ses maps, et youtube !.
Faudrait rester sérieux, quand même. :roll:

 

Non je pense que GG veux faire un geste pour la planète et réduire ses consommations de serveurs (enfin j'aime à penser cela) et si il est plus rapide avec le fibre il aura un train d'avance par rapport à la concurrence.

Espérons que toutes les mises en oeuvre apporterons leurs lots de bonnes positions dans les SERPS, aller GG un petit cadeau de noël pour les WRISTES :wink:

Bonnes fêtes à TOUS

 

je connais le problème, notamment pour les scripts pourrit de chez google comme les API et ADSENSE et GA, qui ralentissent l'affichage des pages, le plus gonflant c'est que eux font des recommandations via PAGESPEED qu'eux même ne suivent pas dans leurs API et leurs différents services, alors certains pourrait argumenter qu'on ne nous à pas obliger à les mettre encore moins à les utilisées, mais tout de même ça n'est pas une raison.

le plus drôle à un moment données j'avais suivit les recommandation PAGESPEED pour certaines choses, et résultat des course mon site était encore plus lent qu'avant :mrgreen: un comble!!!!

perso là j'ai viré un script PHP à la con de tracking des robots type google et yahoo et bing, et ça à nettement amélioré les choses, j'avais même suspecter se script de faire des choses problématiques pour moi ou mon serveur et de bouffer trop de ressources serveur.

 

ça semblait être bien partis et puis finalement non, j'ai rien changer à mes pages ni à mon serveur depuis plus de 3 semaines et paf( le chien, oui je sais :wink: ) mon site s'affiche lentement près de 2.2 seconde pour la page d'accueil pour j'ai rien changer dans le script ni dans le HTML, ni le script de la map.




du coup en catastrophe j'ai remis un bout de code que j'avais viré récemment de mon .HTACCESS un truc du genre:

Code:

RewriteRule ^(.*).(css|js)$ /compcss.php?file=$1.$2&ext=$2 [L]

dont le fichier compcss.php contient:

Code:

<?php
$file = $_GET['file'];
$ext = $_GET['ext'];
if ($ext == 'css') {
header("Content-type: text/css; charset: ISO-8859-1");
} elseif ($ext == 'js') {
header('Content-Type: application/x-javascript');
}
header("Cache-Control: must-revalidate");
$offset = 60 * 60 ;
$ExpStr = "Expires: ".gmdate("D, d M Y H:i:s",time() + $offset)." GMT";
header($ExpStr);
if ((ini_get('zlib.output_compression') != true) && function_exists('ob_gzhandler')) {
ob_start("ob_gzhandler");
}
echo (file_get_contents ($file));
?>

comme ça histoire de bon ça ne semble pas faire grands chose, tous du moins pour le moment.



alors la question que je me pose, est ce que c'est due au fait que les serveurs de google sont un peux dans le caca, depuis un temps certains et que l'affichage de l'API google prends plus de temps que d'habitude, par rapport à avant ou j'étais bien à 1.2 Secondes pour la racine du site.

 

Bon, j'ai mis
- le cache en place,
- compacté le code css et les pages html un peu grosses.
- supprimé les tableaux (il parait que cela ralentit l'affichage car il faut calculer l'emplacement des cases)
- rapatriées les images externes (pubs) (ou en cours) sur mon serveur (mutualisé), aussi des js externes.
- mis des images en sprites.
- Supprimé les maps de Google embed, (remplacé par une image statique et un lien).
- Supprimé aussi le moteur de recherche google intégré (tables et code lourd)
- supprimé les widgets des annonceurs et autres vendeurs > images statiques et liens
bref supprimé tout ce qui faisait dynamique
mon site est en html statique,

Résultat : affichage en moins d'une seconde au lieu de > 3s.
mais cela passe parfois à 3 secondes, à cause du script G+, google analytics et Adsense.
Merci Google ! (et encore je ne mets pas d'images dans Adsense)
Les moins utiles sont G+ et analytics (Xiti le fait et c'est beaucoup moins lourd).
Je pense qu'il ne reste plus qu'à imprimer mon site de voyages, en faire un gros bouquin,
on pourra ainsi tourner la page en moins d'une fraction de seconde. ;-))
Et chaque année je sortirai une mise à jour.
Dire que j'ai internet > 2Go/s - un ordi puissant, la 3G sur iphone, bientôt la 4G. Wifi v...ment rapide,
et je refais le web comme en 1994 : la 1ere version n'avait pas les tableaux (netscape 0.9 !), on mesurait le trafic à partir du serveur (webtrends).
Mais au moins le 0,0001% de mes visiteurs pourra consulter le site à 9,6 kbps sans compression.

pff ... !