View Issue Details

IDProjectCategoryView StatusLast Update
0002856Common[All Projects] Generalpublic2019-11-04 23:08
ReporterXenosAssigned ToXenos 
PrioritynormalSeverityfeatureReproducibilityN/A
Status CloseResolutionfixed 
Product Version 
Target VersionFixed in Version 
Summary0002856: Cache des resources statiques
DescriptionLe principe serait de dire au navigateur de mettre en cache les ressources (js, css, png, etc) et de ne pas requêter le serveur du tout, pendant au moins (disons) 7 jours. L'intérêt est de réduire drastiquement le trafic réseau.

J'ai tenté une première approche dans Dracca en remplaçant les URLs de ces ressources dans les fichiers PHP par des appels à un "Html::resource", qui se chargeait de renvoyer l'URL de la ressource avec un "?hash=" le md5 du fichier.
J'ai même fait une inspection dans le plugin pour obliger à utiliser ça

MAIS
c'est hyper-lourd. C'est pas pratique. C'est pas toujours pertinent (le plugin demande de faire ce remplacement à des endroits incohérents).

Donc, je pense que c'est une mauvaise approche.
L'alternative que j'ai en tête est la suivante: il faudrait modifier le *script de déploiement*, pour remplacer les src="..." et autres href="..." actuellement existants par des src="...?md5=lemd5dfufichier".

Ainsi, il n'y aura aucun changement à faire dans mon code PHP.
De plus, c'est un élément spécifique au déploiment, donc, c'est cohérent de le faire dans le script de déploiment

En revanche, la difficulté sera de "tester" le bon fonctionnement de ce système. Là, je n'ai pas de solution...

Il faudra appliquer ça sur Eclerd, Dracca, Variispace
TagsNo tags attached.
Attach Tags

Activities

Xenos

Xenos

2019-11-04 23:08

administrator   ~0004201

Finalement, je suis parti sur le principe de faire une Phing task, lancable en local, qui recalcule les hash des urls des ressources (à partir d'un bon gros pattern regex pour les trouver dans les fichiers source!)
Cette task est lancée avant le deploy (un peu comme la doc), et si elle génère un diff, le deploy sera donc bloqué. Cela me permet de tester, en local, que tout marche bien, de lancer éventuellement une analyse de code via intellij et d'éviter ainsi toute mauvaise surprise du style "ah ben le deploy a foiré les URLs de certaines ressources et je n'ai aucune visibilité sur ce qu'il se passe!"

Reste éventuellement à l'appliquer à tous les projets

Issue History

Date Modified Username Field Change
2019-09-25 20:15 Xenos New Issue
2019-09-25 20:15 Xenos Status New => Accepted
2019-09-25 20:15 Xenos Description Updated View Revisions
2019-11-04 20:29 AutoUpdater Status Accepted => Resolved
2019-11-04 23:08 Xenos Note Added: 0004201
2019-11-04 23:08 Xenos Assigned To => Xenos
2019-11-04 23:08 Xenos Status Resolved => Close
2019-11-04 23:08 Xenos Resolution open => fixed