Salut,
J'ai acheté et lu le récent bouquin «Eco-conception web», parce que je voulais moi aussi dégrossir un peu le sujet. Pour le coup, le bouquin en question est très orienté "pratique" et patterns… normal, vu que c'est un recueil de fiches de bonnes pratiques.
C'est pas mal mais je trouve qu'il manque juste une approche plus générale et peut être plus théorique qui aurait pu venir apporter une petite prise de recul après la lecture des fiches.
Pour les fiches de bonnes pratiques elles-mêmes, ça ne fait certainement pas de mal de les lire/relire
Il y a des choses évidentes, d'autres moins, certaines bonnes pratiques sur lesquels on se félicite d'être 100% opérationnel et d'autres qui tiennent plus du doux rêve bisounours… 
A part ce bouquin, je ne vois pas d'autres ressources vraiment spécialisées sur le sujet.
Modifié par audrasjb (05 Oct 2013 - 10:41)
J'ai acheté et lu le récent bouquin «Eco-conception web», parce que je voulais moi aussi dégrossir un peu le sujet. Pour le coup, le bouquin en question est très orienté "pratique" et patterns… normal, vu que c'est un recueil de fiches de bonnes pratiques.
C'est pas mal mais je trouve qu'il manque juste une approche plus générale et peut être plus théorique qui aurait pu venir apporter une petite prise de recul après la lecture des fiches.
Pour les fiches de bonnes pratiques elles-mêmes, ça ne fait certainement pas de mal de les lire/relire
Il y a des choses évidentes, d'autres moins, certaines bonnes pratiques sur lesquels on se félicite d'être 100% opérationnel et d'autres qui tiennent plus du doux rêve bisounours… A part ce bouquin, je ne vois pas d'autres ressources vraiment spécialisées sur le sujet.
Modifié par audrasjb (05 Oct 2013 - 10:41)
Salut, tu as Opquast qui a une liste appelé Green IT http://checklists.opquast.com/greenit
Edit : il y a aussi cette conférence Paris Web : http://www.dailymotion.com/video/xpfv2p_le-web-developpement-durable-green-it-a-toutes-les-sauces_tech
Modifié par benj (05 Oct 2013 - 13:47)
Edit : il y a aussi cette conférence Paris Web : http://www.dailymotion.com/video/xpfv2p_le-web-developpement-durable-green-it-a-toutes-les-sauces_tech
Modifié par benj (05 Oct 2013 - 13:47)
Merci de tout les liens. Je vais les consulter.
ÉDIT : J'ai vu qu'il fallait compilé son PHP. Des retours ?
ÉDIT 2 : Donc plus l'affichage est rapide (en PHP) et moins ça consomme ?
édit 3 : plusieurs questions relatif au PHP. Pourquoi vaut mieux utiliser l'apostrophe que les guillemets ? Pourquoi utiliser ++$i au lieu de $i++ ?
Modifié par doc mcfly (05 Oct 2013 - 14:18)
ÉDIT : J'ai vu qu'il fallait compilé son PHP. Des retours ?
ÉDIT 2 : Donc plus l'affichage est rapide (en PHP) et moins ça consomme ?
édit 3 : plusieurs questions relatif au PHP. Pourquoi vaut mieux utiliser l'apostrophe que les guillemets ? Pourquoi utiliser ++$i au lieu de $i++ ?
Modifié par doc mcfly (05 Oct 2013 - 14:18)
a écrit :
plusieurs questions relatif au PHP. Pourquoi vaut mieux utiliser l'apostrophe que les guillemets ? Pourquoi utiliser ++$i au lieu de $i++ ?
Les deux sont légèrement plus rapides.
Mais bon, c'est vraiment du peanuts... ne pas oublier que « premature optimization is the root of all evil ». C'est pas ça qui va te faire gagner beaucoup de temps. C'est bon à savoir pour la théorie et les belles histoirs, mais en pratique l'intérêt est quasi nul.
Explication du pourquoi c'est à peine plus rapide en théorie :
* Pour les apostrophes au lieu des guillemets: les variables et les constructions entre accolades ne sont pas étendues dans les chaînes entre apostrophes. Aucune tentative d'expension n'est faite, donc il y a un léger gain de temps. Pour les chaînes purement constantes on est certain que c'est vraiment plus rapide. Par contre, le débat n'est pas clos à savoir lequel d'entre :
echo '...', $x, '...';
echo '...' . $x . '...';
echo "...$x...";
echo <<<'END' ... END, $x, <<<'END' ... END;
echo <<<END ... $x ... END;
est vraiment le plus rapide et dans quel cas. Avis aux trolleurs.
* Pour $i++ vs ++$i, cela tient au fait que dans la notation postfixée, $i avant incrément doit être retourné. Lors de l'exécution de $i++, la valeur de $i est d'abord stockée, $i est incrémenté, puis la valeur stockée est retournée. Avec ++$i, la valeur est incrémentée puis immédiatement retournée sans nécéssiter de stockage intermédiaire.
Utiliser l'un plutôt que l'autre n'a aucune incidence si $i est un nombre et si $i++ ou ++$i ne se trouve pas dans une expression qui utilise la valeur. Dans une boucle for, donc, ça ne change rien, mais on peut avoir un intérêt théorique à modifier son code pour pouvoir remplacer $tableau[$i++] par $tableau[++$i]...
La conséquence du stockage intermédiaire est plus frappante en C++ quand on manipule des classes avec opérateur ++ surchargés (les itérateurs par exemple). ++i plutôt que i++ évite des copies ! Mais en php, je ne crois pas qu'on puisse surcharger les opérateurs de toute façon, donc intérêt 0,0.
Vive les belles théories... vous venez d'élargir votre culture mais vous avez surtout perdu 5 minutes.
Modifié par QuentinC (06 Oct 2013 - 08:40)
Bonjour,
Non, n'importe quelle optimisation d'image a bien plus d'effet que ça (1 ou plusieurs ordres de grandeur !).
Réutiliser son matériel (pro) ou acheter d'occase ce qui était le matériel dernier cri (perso).
Choisir son CMS en fonction des contraintes du projet puis de sa gourmandise. Faire une première étape d'optimisation (liaison avec bases de données surtout et cache, sans insister sur aucun détail)
Les animations et JS qui servent à rien, à dégager.
Optimiser le front end (performance web), si nécessaire avec des outils pour créer automatiquement les sprites par exemple ou optimiser avec le moins d'actions possible (prepros, grunt, SASS, Build de ST2, etc, etc) et optimiser le serveur web par la même occasion. Sans rogner sur l'accessibilité ou la durée de vie / facilité de maintenance du projet de préférence !
Un des premiers constats de la perf web : le code HTML généré arrive assez vite la plupart du temps. C'est 10% du problème. Les CSS 20%, JS 30 et images 40 (ouais j'ai inventé les pourcentages sauf les 10%).
Viser la simplicité (ça va souvent de pair avec la perf web et les économies de bande passante/processeur/mémoire/temps) : KISS
Modifié par Felipe (06 Oct 2013 - 14:33)
Non, n'importe quelle optimisation d'image a bien plus d'effet que ça (1 ou plusieurs ordres de grandeur !).
Réutiliser son matériel (pro) ou acheter d'occase ce qui était le matériel dernier cri (perso).
Choisir son CMS en fonction des contraintes du projet puis de sa gourmandise. Faire une première étape d'optimisation (liaison avec bases de données surtout et cache, sans insister sur aucun détail)
Les animations et JS qui servent à rien, à dégager.
Optimiser le front end (performance web), si nécessaire avec des outils pour créer automatiquement les sprites par exemple ou optimiser avec le moins d'actions possible (prepros, grunt, SASS, Build de ST2, etc, etc) et optimiser le serveur web par la même occasion. Sans rogner sur l'accessibilité ou la durée de vie / facilité de maintenance du projet de préférence !
Un des premiers constats de la perf web : le code HTML généré arrive assez vite la plupart du temps. C'est 10% du problème. Les CSS 20%, JS 30 et images 40 (ouais j'ai inventé les pourcentages sauf les 10%).
Viser la simplicité (ça va souvent de pair avec la perf web et les économies de bande passante/processeur/mémoire/temps) : KISS
Modifié par Felipe (06 Oct 2013 - 14:33)
a écrit :
Ouais OK. Donc si le temps de chargement (PHP) est inférieur à 0.001 (je dis au pif), on se préoccupe pas de ce genre de détail ?
Non. Ou alors si tu dois te préoccuper de ce genre de détails en pratique, tu es devenu fou. C'est juste des belles théories, certes plus ou moins vraies, mais il y a beaucoup mieux à faire avant avec un impact beaucoup plus direct et perceptible: mise en cache intelligente côté serveur et client, compression des données statiques côté serveur, ne pas en faire trop sur la qualité des images, n'utiliser javascript que quand ça a vraiment une utilité concrète, ne pas utiliser AJAX à tout va (à propos de ce dernier, je n'ai pas de chiffres, mais je suis à peu près sûr qu'à la longue on y perd dans 90% des cas, avec les problèmes de référencement, de navigation et d'accessibilité que ça implique, même si on gagne un peu parce qu'il y a une partie de HTML qu'on ne recharge pas).