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

WRInaute discret
La dernière optimisation (avant la prochaine) relative au site fraîchement publié vient d'être faite et je pense que ça pourrait en intéresser plus d'un, il s'agit de minimiser un maximum le temps de chargement des pages web:

  • Optimisation des images
  • Compression gzip - deflate
  • Minify des css et des js - compression

Optimisation des images
J'ai opté pour cet outil très pratique:PngOptimizer
Il diminue significativement le poids de vos images sans en altérer la qualité.
Téléchargement: http://psydk.org/PngOptimizer.php

Compression Gzip - deflate
Etant sous Windows, j'ai rencontré quelques soucis pour activer le module Gzip (dll), j'ai donc opté pour le module deflate présent nativement sous Apache2, il suffit de l'activer...

Et d'ajouter dans votre htaccess le code suivant:
Code:
# Compress output
AddOutputFilterByType DEFLATE text/html text/css text/plain text/xml application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

Pour tester si le module est actif et donc, la compression:
http://www.gidnetwork.com/tools/gzip-test.php

Minify des css et js
J'ai opté pour Minify URI Builder
Magnifique.
Téléchargement: http://code.google.com/p/minify/

Tester le temps de chargement de vos pages
Avec Yslow de Yahoo qui s'intègre à firebug.
http://developer.yahoo.com/yslow/

Pour que le tout soit vraiment parfait, il faut encore jouer avec les modules mod_expires et mod_headers, je vous laisse fouiner, j'ai n'ai pas (encore) été jusque là.

Wala, j'éspère que ce sera utile :)
 
WRInaute passionné
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).
 
WRInaute accro
>> J'ajoute : mettre les appels de scripts JavaScripts en fin de page !

dans ce cas là, deferer l'appel plutôt (defer=defer)
 
WRInaute accro
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.
 
WRInaute passionné
millenium a dit:
Compression Gzip - deflate
Etant sous Windows, j'ai rencontré quelques soucis pour activer le module Gzip (dll), j'ai donc opté pour le module deflate présent nativement sous Apache2, il suffit de l'activer...

Et d'ajouter dans votre htaccess le code suivant:
Code:
# Compress output
AddOutputFilterByType DEFLATE text/html text/css text/plain text/xml application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

Pour tester si le module est actif et donc, la compression:
http://www.gidnetwork.com/tools/gzip-test.php

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:
 
WRInaute accro
à se propos pagespeed est maintenant compatible avec le dernier firefox 3.6, pagespeed est maintenant en 1.6.
 
WRInaute impliqué
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)"
 
WRInaute impliqué
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 !
 
WRInaute accro
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.
 
WRInaute impliqué
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).
 
WRInaute discret
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.
 
WRInaute impliqué
fandecine a dit:
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 :

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 ?
 
WRInaute discret
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.
 
Discussions similaires
Haut