Commentaires sur : Astuce EzPublish pour optimiser les images

Par : Simon

Simon — Tue, 28 Jul 2009 21:25:39 +0000

Je vois, ça me semble en effet être une solution déjà plus réaliste. J’avais également pensé à une solution du même type sans pour autant la tester. Il s’agirait de faire ces optimisations lors des heures creuses (par exemple de 3h à 5h du matin en FR) en faisant appel à un fichier PHP « compressant » les images uploadées pendant la journée.
Bref… quoi qu’il en soit il faudra dans tout les cas passer par des phases de tests pour voir quelle solution est la plus adaptée.
Merci en tout cas pour tout ces précieux conseils que tu prêches à travers ce site 😉

Par : Éric

Éric — Tue, 28 Jul 2009 17:52:16 +0000

J’avoue que je me place dans la situation confortable où les ressources serveurs ne sont pas un problème majeur. Sinon il faut faire des compromis, et effectivement optipng n’est pas forcément a priorité.

Par contre rien ne t’empêche de gérer une file de traitement offline asynchrone. Tu acceptes l’upload, tu l’utilises tel quel, mais en différé, via une file (histoire de ne pas saturer le serveur de traitement), tu vas recompresser les images et les optimiser. Si tu as du délai parce que trop d’upload au même moment, les images resteront non optimisées un peu plus longtemps, c’est tout.

De manière générale, indépendamment de l’optimisation des images, il est toujours bon de gérer des traitements hors ligne et asynchrones. Un exec() directement sur l’upload c’est effectivement dangereux.

Par : Simon

Simon — Tue, 28 Jul 2009 17:31:25 +0000

Je te remercie pour cet article intéressant.
A vrai dire j’ai récemment eu cette réflexion concernant un projet. J’ai en effet après moultes problèmes et erreurs php réussi à faire tourner jpegtran lors de chaque upload avec la commande relativement compréhensible suivante:
exec(« jpegtran -copy none -optimize -perfect -progressive $src $cible »);
Je me demande pourtant si ce genre de procédé ne risque pas de dégrader les performances dans un premier temps. En effet, à chaque upload le serveur devra faire une compression lossless.
Avec des petits tests en local, c’est encore réalisable avec des jpeg (et encore je ne sais pas ce que ça donne si des centaines de personnes upload en même temps) mais par contre avec du png et des logiciels comme pngcrush ou optipng, le temps de calcul est réellement long si on met les options de « compression » au maximum.
Donc, après un trèèès long commentaire vient enfin la question:
Est-ce qu’il ne s’agit pas là de ces améliorations qui ne le sont finalement pas ? Des améliorations qui ont au final l’effet inverse…

Par : Éric

Éric — Sun, 26 Jul 2009 20:08:46 +0000

Tout à fait, je corrige

Par : Chris

Chris — Sat, 25 Jul 2009 15:48:53 +0000

Il doit manquer un lien vers une ressource externe, non ? Je suppose qu’il s’agit de cet article : http://pwet.fr/blog/optimisation_des_images_generees_par_ez_publish ?