[spip-dev] Comment se passer du pipeline affichage_final ?

Bonsoir,

Dans la série des questions d'optimisation des performances, je voudrais savoir quelles sont les alternatives au pipeline affichage_final qui ne permet pas de bénéficier du cache.

En l'occurence, je suis en train de concevoir un plugin qui permet d'automatiser la parallélisation des téléchargements de ressources (CSS, JS, images, etc.) dans le navigateur, pour qu'il obtienne l'ensemble plus vite.

Un premier brouillon est à l'œuvre sur http://gasteroprod.com/ depuis aujourd'hui. En regardant le code source, vous pouvez voir que ces ressources sont servies depuis http://static.gasteroprod.com/ plutôt que http://gasteroprod.com/ si elles sont liées depuis le HTML (pas encore traité le cas depuis les CSS ou JS, mais du coup ça répartie bien).

Malheureusement, je passe pour cela par le pipeline affichage_final, de cette façon :

function parallelizer_affichage_final($page) {
  $page = liens_absolus($page);
  $page = preg_replace('/("|\')http:\/\/([^\/]+)\/(local|themes)\/([^"\']+)\.(png|jpg|gif|css|ico|rdf|js)("|\')/mi', '$1http://static.$2/$3/$4.$5$6', $page);

  return $page;
}

Du coup, ce traitement est fait sur l'intégralité de la page à chaque requête, alors que le faire juste avant enregistrement en cache serait bien plus astucieux.

Que puis-je faire ?

-Nicolas

Bonsoir,

Dans la série des questions d'optimisation des performances, je voudrais savoir quelles sont les alternatives au pipeline affichage_final qui ne permet pas de bénéficier du cache.

En l'occurence, je suis en train de concevoir un plugin qui permet d'automatiser la parallélisation des téléchargements de ressources (CSS, JS, images, etc.) dans le navigateur, pour qu'il obtienne l'ensemble plus vite.

Un premier brouillon est à l'œuvre sur http://gasteroprod.com/ depuis aujourd'hui. En regardant le code source, vous pouvez voir que ces ressources sont servies depuis http://static.gasteroprod.com/ plutôt que http://gasteroprod.com/ si elles sont liées depuis le HTML (pas encore traité le cas depuis les CSS ou JS, mais du coup ça répartie bien).

Oui, c'est typiquement l'implémentation d'un CDN (même si en fait le CDN est finalement servi par le même serveur) pour les ressources statiques.

Malheureusement, je passe pour cela par le pipeline affichage_final, de cette façon :

function parallelizer_affichage_final($page) {
$page = liens_absolus($page);
$page = preg_replace('/("|\')http:\/\/([^\/]+)\/(local|themes)\/([^"\']+)\.(png|jpg|gif|css|ico|rdf|js)("|\')/mi', '$1http://static.$2/$3/$4.$5$6', $page);

return $page;
}

Du coup, ce traitement est fait sur l'intégralité de la page à chaque requête, alors que le faire juste avant enregistrement en cache serait bien plus astucieux.

Il faut comprendre que le cache ne stocke pas du html pur, mais une combinaison de html et de php (inclusions, formulaires, balises dynamiques...) qui doit être executé à chaque hit.
Ainsi il n'est pas possible, en cache, de traiter tout le html qui sera envoyé au navigateur.
Si tu veux vraiment faire ce traitement avant la mise en cache, tu peux utiliser le pipeline recuperer_fond, ou #FILTRE qui s'appliquera alors sur la combinaison du html et du php. Attention donc à ce que tu y fait.

Alternativement, je pensais qu'on pourrait traiter les urls a la source (les urls de local/ sont toutes generees pas spip, les urls de IMG/ viennent des #URL_DOCUMENT ou variante...) pour donner une url sur un CDN quand il est paramétré.
Cela dit je n'ai pas encore écrit une ligne de code pour faire cela.

Cédric

Dans la série des questions d'optimisation des performances, je voudrais savoir quelles sont les alternatives au pipeline affichage_final qui ne permet pas de bénéficier du cache.

En l'occurence, je suis en train de concevoir un plugin qui permet d'automatiser la parallélisation des téléchargements de ressources (CSS, JS, images, etc.) dans le navigateur, pour qu'il obtienne l'ensemble plus vite.

Un premier brouillon est à l'œuvre sur http://gasteroprod.com/ depuis aujourd'hui. En regardant le code source, vous pouvez voir que ces ressources sont servies depuis http://static.gasteroprod.com/ plutôt que http://gasteroprod.com/ si elles sont liées depuis le HTML (pas encore traité le cas depuis les CSS ou JS, mais du coup ça répartie bien).

Oui, c'est typiquement l'implémentation d'un CDN (même si en fait le CDN est finalement servi par le même serveur) pour les ressources statiques.

Effectivement.

Malheureusement, je passe pour cela par le pipeline affichage_final, de cette façon :

function parallelizer_affichage_final($page) {
$page = liens_absolus($page);
$page = preg_replace('/("|\')http:\/\/([^\/]+)\/(local|themes)\/([^"\']+)\.(png|jpg|gif|css|ico|rdf|js)("|\')/mi', '$1http://static.$2/$3/$4.$5$6', $page);

return $page;
}

Du coup, ce traitement est fait sur l'intégralité de la page à chaque requête, alors que le faire juste avant enregistrement en cache serait bien plus astucieux.

Il faut comprendre que le cache ne stocke pas du html pur, mais une combinaison de html et de php (inclusions, formulaires, balises dynamiques...) qui doit être executé à chaque hit.

Ah oui ! :frowning:

Ainsi il n'est pas possible, en cache, de traiter tout le html qui sera envoyé au navigateur.
Si tu veux vraiment faire ce traitement avant la mise en cache, tu peux utiliser le pipeline recuperer_fond, ou #FILTRE qui s'appliquera alors sur la combinaison du html et du php. Attention donc à ce que tu y fait.

Mouais, périlleux...

Alternativement, je pensais qu'on pourrait traiter les urls a la source (les urls de local/ sont toutes generees pas spip, les urls de IMG/ viennent des #URL_DOCUMENT ou variante...) pour donner une url sur un CDN quand il est paramétré.

Excellente idée !

Cela dit je n'ai pas encore écrit une ligne de code pour faire cela.

Je n'ai pas suivi les évolutions de generer_url_* depuis longtemps, mais je vais creuser le sujet.

Merci !

-Nicolas

function parallelizer_affichage_final($page) {

z ? :slight_smile:

$page = liens_absolus($page);

ouch, c'est cher, est-ce utile ?

$page = preg_replace('/("|\')http:\/\/([^\/]+)\/(local|themes)\/([^"\']+)\.(png|jpg|gif|css|ico|rdf|js)("|\')/mi', '$1http://static.$2/$3/$4.$5$6', $page);

avec des strpos et et des substr_replace tu dois pouvoir coder quelque
chose qui va 10 fois plus vite que ce preg, et tu auras de nouveau la
conscience tranquille. Il n'est pas INTERDIT de faire du php à chaque
hit, il faut juste s'assurer qu'il est efficace

-- Fil

function parallelizer_affichage_final($page) {

z ? :slight_smile:

Le plugin s'appelle pour l'instant « Parallelizer », en anglais, oui. Mais ça fait un peu « Panzer », je pourrais changer avant de le mettre sur la zone...

$page = liens_absolus($page);

ouch, c'est cher, est-ce utile ?

J'ai besoin des URL absolues dans la suite, ça « simplifie » mon traitement.

$page = preg_replace('/("|\')http:\/\/([^\/]+)\/(local|themes)\/([^"\']+)\.(png|jpg|gif|css|ico|rdf|js)("|\')/mi', '$1http://static.$2/$3/$4.$5$6', $page);

avec des strpos et et des substr_replace tu dois pouvoir coder quelque
chose qui va 10 fois plus vite que ce preg

Mais il faut boucler à la main, du coup, n'est-ce pas ? Vue l'étendue des cas possibles, j'ai du mal à croire que ça puisse être plus rapide, mais je peux étudier ça.

et tu auras de nouveau la conscience tranquille. Il n'est pas INTERDIT de faire du php à chaque
hit, il faut juste s'assurer qu'il est efficace

Oui, effectivement.

-Nicolas

* cedric.morin@yterium.com tapuscrivait, le 22/09/2010 21:33:

Alternativement, je pensais qu'on pourrait traiter les urls a la source (les urls de local/ sont toutes generees pas spip, les urls de IMG/ viennent des #URL_DOCUMENT ou variante...) pour donner une url sur un CDN quand il est paramétré.
Cela dit je n'ai pas encore écrit une ligne de code pour faire cela.

Est-ce que ce n'est pas ce qu'ARNO* a déjà fait et documenté ici :
http://www.paris-beyrouth.org/tutoriaux-spip/article/parallelisation-des-chargements
?

-- RealET

Ah, pas mal le coup du #FILTRE{filtrer_images_page} !

Globalement, c'est ce que je fais depuis déjà pas mal de temps, à part ce #FILTRE que je ne connaissais pas. Je mettais les URL en dur dans mes squelettes.

-Nicolas