Quand on a plein de pages JS et CSS, le client doit les appeller une à une, ce qui conduit à un traffic intense entre le client et le serveur.

Pour optimiser ça, il est possible de concaténer automatiquement toutes ces pages en une seule, pour ainsi réduire les appels.

Et pour éviter de devoir faire un script par "type" d'appel, ce script prend en paramètre les fichiers à inclure.

J'utilise ce script conjointement à celui-ci, pour la compression et la mise en cache.

Le script:

<?php
/*
 * Fichier de mise en commun des scripts.
 * Ici, c'est du JS
 */

include 'script.php' // ça, c'est le script dont je parle plus haut, qui se trouve aussi sur le forum.


header("Content-type: text/javascript");
//Pour le css:
//header("Content-type: text/css");

// instantiation du gestionnaire de sortie..
$out = output::get_instance("clean");

// ajout de l'observateur de compression GZ
$out_gz = new gzip();
$out->add($out_gz);

// ajout de l'observateur/gestionnaire de cache
$l_cache = new little_cache(md5( $_SERVER["REQUEST_URI"]));
$out->add($l_cache);

// le format de l'url est fichier.php?s[0]=fichier1&s[1]=fichier2&s[2]=fichier3 etc...
// $_GET["s"] est donc un tableau qui contient l'intitulé, sans extension, des fichiers à charger
$styles	= $_GET["s"];

foreach ($styles as $style)
	{
	// ici je n'autorise que certains carctères, c'est léger comme protection, mais il me semble que ça suffit.
	$style=preg_replace("#[^\.A-Za-z0-9_]#","",$style);
	
	// J'ajoute simplement le contenu du fichier à ce qui est renvoyé.. rien de très complexe.
	if ($echo = file_get_contents("./".$style.".js")) echo $echo."\n";
	}

Du côté html, je me retrouve donc avec un unique LINK: voilà voilà

Je tiens à apporter une précision : le cache

Il faut savoir que votre navigateur mémorise chaque fichier lié à une page en cache sur votre poste.
Cela permet, lorsque vous naviguez sur un site dont chaque page inclu script1.js, de ne le télécharger qu'une seule fois, même si vous naviguez sur 4 pages html différentes.

En utilisant la technique ci-dessus, vous allez bloquer cette technique.
Prenons un exemple.
site1
page1 inclus [script1, script2, script3]
page2 inclus [script2, script4, script5]
page3 inclus [script1, script2, script5]

Avec la technique de Berzemus, vous allez donc télécharger 3 gros script JS, et dans ces 3 fichiers se trouverons 2 fois le script1, 3 fois le script2, et 2 fois le script5.

Donc, mon avertissement est le suivant : la technique indiqué ci-dessus est à utiliser uniquement si vous avez des fichiers qui sont inclus dans toutes vos pages, et pas pour les scripts appelés ponctuellement.

Zeus dit bien vrai (dans le cas ou vous ne spécifiez pas de règle particulière pour le cache côté client), c'est mieux de l'utiliser pour des pages dont vous aurez un besoin constant (le package de base, dira-t-on).

Pour ma part, je l'ai surtout utilisé dans une application quasi 100% JS/Ajax, qui n'a besoin que d'un seul (et gros) chargement.

Je note juste une précision:

Je suis tombé sur cet article-ci:
http://yuiblog.com/blog/2007/01/04/perf ... ch-part-2/

Des gens très motivés ont enquétes sur le cache côté client des utilisateurs de yahoo. Ils ont découvert que malgré les optimisations diverses pour le cache côté client, 40 à 60% des utilisateurs arrivaient avec un cache vide, et même 20% des toutes les pages vues n'avaient aucun élement en cache côté client.

Pour les citer:

there are a significant number of users that will always have an empty cache. This goes back to the earlier point that reducing the number of HTTP requests has the biggest impact on reducing response time. The percentage of users with an empty cache for different web pages may vary, especially for pages with a high number of active (daily) users. However, we found in our study that regardless of usage patterns, the percentage of page views with an empty cache is always ~20%.

Alors, conclusion; le cache c'est bien, il faut l'utiliser, mais il ne faut pas trop se reposer dessus

De toute façon, le meilleur cache, c'est le cache d'opcode, puis le cache de page statique, directement sur le serveur