[Astuces] Minimiser le temps de chargement de vos pages web

Bien (trop?) résumé, bien présenté, une reco' !

J'ajoute : mettre les appels de scripts JavaScripts en fin de page !
... et limiter les requêtes HTTP (minimiser le nombre de requêtes vers des fichiers, donc fusionner les CSS et JavaScripts et créer des CSS Sprites avec les images).

 

>> J'ajoute : mettre les appels de scripts JavaScripts en fin de page !

dans ce cas là, deferer l'appel plutôt (defer=defer)

 

Pas compris :-/
En pratique, ça donne quoi ?

 

reco

 

J'utilise personnelement Google Closure : http://code.google.com/intl/fr/closure/ Pour les javascripts.
Et YUI compressor : http://developer.yahoo.com/yui/compressor/ Pour les CSS.
Avec une politique fortement inspirée de celle de GitHub : http://gist.github.com/238291

Tous les javascripts (pareil pour les css) sont dans un répertoire /javascripts/ de mon application.
Les javascripts à la base de ce dossier ne seront pas compressés.
Tous les autres seront compressés à hauteur d'un fichier par répertoire.

Ainsi si j'ai, en développement :

Code:

- javascripts
|- jquery
|-- jquery-version.js
|- mon_application
|-- fichier.js

J'aurai, en production :

Code:

- javascripts
|- bundle
|-- jquery.js
|-- mon_application.js

Les fichiers sont compressés lorsque je déploie l'application (avec capistrano).

Lorsque je lance mon application dans son environnement de développement, ce sont automatiquement les javascripts et css non compressés qui sont inclus (tous les fichiers sont inclus. Ainsi, même en développement, je suis sur de ne pas avoir de conflit).
Lorsque je la lance en staging ou en production, c'est les versions minifiées qui sont inclues.

Note : je ne bosse pas en PHP mais en ruby.
Mais cette même technique (compression lors du déploiement) est tout à fait adaptable sur une application PHP ou tout autre langage.

 

Bonjour,
sympa le résumé :wink: il ne reste plus qu'a tester avec http://developer.yahoo.com/yslow/ pour voir le gain de performance
e-kiwi : je n'ai pas compris non plus...........

 

Ce qui peut être mis dans le fichier .conf d'apache n'a rien à faire dans le .htaccess car celui ci est lu et interprété à chaque requête donc ça ralentit forcément :wink: (remarque: le rewriting peut également être localisé dans la section Virtual Host du fichier .conf d'apache) Pour des performances optimums, l'idéal est de ne pas avoir de fichier .htaccess (il y a des alternatives) Dans le cas ou vous pouvez vous passer du .htaccess, veillez à fixer AllowOverride à none dans votre conf apache pour lui signaler de ne pas chercher de fichier .htaccess. Si vous n'êtes pas convaincu, voici un extrait de la doc apache :

Code:

However, in general, use of .htaccess files should be avoided when possible. Any configuration that you would consider putting in a .htaccess file, can just as effectively be made in a <Directory> section in your main server configuration file.

There are two main reasons to avoid the use of .htaccess files.

The first of these is performance. When AllowOverride is set to allow the use of .htaccess files, Apache will look in every directory for .htaccess files. Thus, permitting .htaccess files causes a performance hit, whether or not you actually even use them! Also, the .htaccess file is loaded every time a document is requested.

Further note that Apache must look for .htaccess files in all higher-level directories, in order to have a full complement of directives that it must apply. (See section on how directives are applied.) Thus, if a file is requested out of a directory /www/htdocs/example, Apache must look for the following files:

/.htaccess
/www/.htaccess
/www/htdocs/.htaccess
/www/htdocs/example/.htaccess

And so, for each file access out of that directory, there are 4 additional file-system accesses, even if none of those files are present. (Note that this would only be the case if .htaccess files were enabled for /, which is not usually the case.)

The second consideration is one of security. You are permitting users to modify server configuration, which may result in changes over which you have no control. Carefully consider whether you want to give your users this privilege. Note also that giving users less privileges than they need will lead to additional technical support requests. Make sure you clearly tell your users what level of privileges you have given them. Specifying exactly what you have set AllowOverride to, and pointing them to the relevant documentation, will save yourself a lot of confusion later.

Note that it is completely equivalent to put a .htaccess file in a directory /www/htdocs/example containing a directive, and to put that same directive in a Directory section <Directory /www/htdocs/example> in your main server configuration

Enfin, Il est possible d'activer la compression au niveau de PHP dans le php.ini avec les parametres zlib.output_compression à On et zlib.output_compression_level par exemple à -1; en complément , pour charger une page PHP d'un seul tenant, réglez le paramètre output_buffering à la taille maximum de vos pages PHP.

Optimiser ses images, ses fichiers js et css c'est bien mais il ne faut pas négliger les temps de réponse du serveur WEB en évitant de lui faire faire des chose plus ou moins utiles :mrgreen:

 

à se propos pagespeed est maintenant compatible avec le dernier firefox 3.6, pagespeed est maintenant en 1.6.

 

Merci pour l'outil de compression d'image

 

Merci à tous pour ces infos.

En me renseignant sur les sprites css, je suis tombé sur cet excellent outil : http://spriteme.org/

PS : moi non plus je n'ai pas compris "dans ce cas là, deferer l'appel plutôt (defer=defer)"

 

Est-ce que toutes ces méthodes fonctionnent avec tout les hébergeurs ?
Car j'ai eu quelques petits bug pour les compressions dernièrement !

 

Compresser les js et css chez l'hébergeur est une mauvaise idée. Cela réduit la bande passante mais augmente la quantité de CPU utiliséepour transférer les données à l'utilisateur.

Il faut compresser les données lors du déploiement de l'application. Pas à chaque chargement de page.

 

Donc si je comprends bien l'on travail la décompression en client et non en serveur, est-ce cela ?

 

Il faut faire le travail de minification/concaténation une seule fois lors du déploiement (c'est à dire lors de la copie des fichiers sur le serveur).

 

defer...
ex. de syntaxe <script defer> etc.
Cet attribut indique que le script ne contient pas de "document.write", et donne une indication aux navigateurs qu'ils peuvent continuer le rendu de la page et différer l'exécution du script. Rem. Firefox (je ne sais pas quelle version) ne supporte pas cet attribut. Si un script peut être retardé dans son exécution, il peut également être déplacé en bas de page HTML.

 

Alors ça, je vais tester car je ne savais tout simplement pas.
Au vu du nombre de règles de rewriting que j'ai ça va être rigolo.

par contre les process apache seront plus gourmands en mémoire non ?

 

Et on oublie aussi notre ami le 304 not modified, Expire .... Enfin bref le protocol HTTP ... :mrgreen:

Sinon pour le defer ... j'avais fait quelques tests et ça changeait rien dans l'ordre de chargement du js du moins sous FF.