L'effort de google pour (削除) diminuer ses frais de bande passante (削除ここまで)rendre le web plus rapide est vraiment louable. Ceci dit il pose quand même un léger problème dans la façon partielle (pas partiale) dont il est abordé. Pour beaucoup de (削除) Geeks à IPhone5 (削除ここまで)webmasters ce que dit google est parole d'évangile et doit être appliqué sans se poser de question. Ceci dit google n'est pas responsable de ce fait et ce n'est donc pas son procès que je fais ici.
Pour moi, modeste administrateur système ce qui fait la qualité et la rapidité d'un site web peut se résumer en deux points :
1) Son workflow
Un site web est une application et mérite d'être considérée comme telle. Et en tant que telle, il lui faut suivre un cycle de vie rigoureux comprenant notamment, une gestion des versions, des tests, une procédure de publication, un suivie des bugs, bref toutes les choses qu'on fait normalement et naturellement pour n'importe quelle application. C'est bien sûr souvent le cas lorsqu'il s'agit d'applications critiques développés pour des clients qui ont l'habitude de mener des projets informatiques, ou simplement par des gens sérieux qui savent ce qu'ils font. Mais beaucoup de web agencies ne fonctionnent pas ainsi. Le workflow le plus souvent constaté est :
On développe une charte graphique.
On colle un CMS sur la prod.
On colle quelques plugins.
On passe en prod et on oublie le truc jusqu'à survenue d'un problème.
Lorsque le problème survient :
On essaye de faire une mise à jour du CMS directement sur la prod.
On restaure un backup.
On achète de plus gros serveurs jusqu'à ce que ça marche.
On débute un nouveau projet en changeant de CMS
L'alibi le plus couramment admis est qu'il s'agit d'un CMS et donc que tout le wokflow de développement est assuré par ailleurs. Pourtant au quotidien je constate que là ou il faut un modeste serveur à certain pour faire tourner des dizaines de sites, certains peinent à en faire fonctionner un seul sur un cluster (toute chose égale par ailleurs) ou encore que l'absence de tests avec des données dans la base est sans doute la cause la plus fréquente de plantage. Notamment avec MySQL qui a des effets de seuil important.
Pour faire un site web rapide et de qualité, il faut donc :
avoir un environnement de dev séparé de la prod.
utiliser un gestionnaire de version.
utiliser un gestionnaire de bugs.
écrire un jeu de test cohérent avec l'activité finale (et surtout un jeu de données conséquent).
suivre les résultats des tests pour en déduire des régressions.
2) Le ressources
La rapidité de la réponse renvoyée par un serveur web dépend avant tout de deux paramètres qui sont, le temps d'exécution du script et son empreinte mémoire. C'est peut être con à dire mais un script qui s'exécute vite permet au serveur de répondre rapidement. Moins un script occupe de mémoire, plus il peut être exécuté simultanément un grand nombre de fois et avec plus d'efficacité.
Pour cela quelques conseils :
le contextes de dev doit limiter les ressources plus fortement que le contexte de prod
Par exemple pour php, il est de bon ton de travailler en dev avec un memory_limit et un max_execution_time plus bas que sur la prod ainsi qu'avec l'open_basedir activé et strict, un nombre d'extensions réduites, suhosin activé et configuré très strictement. Sur la prod on peut alors lâcher du lest pour assurer une bonne fluidité et éviter des plantages imprévus.
toute évolution doit être évaluée en terme de ressources.
L'impact d'ajout d'extensions ou d'augmentation des limites doit être soigneusement évalué. Ainsi que par exemple le moteur de stockage des sessions, la collecte de statistiques… La encore une évaluation sérieuse nécessite qu'il y ait des données dans la base.
Les réglages du serveur web doivent correspondre au cas général et pas au cas particuliers.
Les scripts gourmands (type génération de rapports, export, reindexation …) doivent être isolés et exécutés dans un contexte privé séparé du site public. L'upload de gros fichiers doit être effectué par parties afin de s'adapter au contexte global … Le cas typique est l'augmentation du timeout d'apache (essentiel pour résister aux dos type slow lorris) simplement parce qu'un script d'export de base de données qui pourrait très bien s'éxécuter en cron ou sur une autre instance apache met 3 heures à retourner des données
Les ressources externes doivent être gérée correctement.
Lorsqu'on fait appel à un web service, à une url externe, il faut s'assurer du comportement du script en cas indisponibilité de la ressource. Il faut écrire un vrai client, gérant les timeout, le cache, et les facilités prévues par le protocole (if-modified-since par exemple en http). Les simples fopen("http:// … sont à bannir.
Côté client il n'est pas toujours évident qu'aller chercher jquery chez google soit beaucoup plus efficace que de l'héberger sois même. Cela doit être encore un fois évalué.
3) Conclusion
Vu ainsi ce type de conseils peuvent sembler démesurés pour une petite agence sortant du site à 500 euros. Pourtant il s'agit d'une simple habitude de travail. De nombreux outils existent pour lancer des tests, remplir les bases et finalement lorsque l'habitude est prise c'est plus un gain de temps qu'autre chose.
Voilà c'était mes trois conseils à deux cents pour un web rapide. Ils n'ont rien d'incompatible avec ceux de google. Je pense juste qu'ils sont un préalable nécessaire. Comme il est dit dans l'article, mod_pagespeed est juste un moyen d'éviter de modifier immédiatement ses sites. Je n'ai pas de chiffres exacts mais j'imagine que le surcout machine est important, ne serais-ce que parce que le serveur doit avoir une vision globale de ce qu'est la page. Et c'est pour cela que je ne l'aime pas trop. Pour moi, le web rapide et qualitatif trouve son origine dans les consommateurs de caféine et pas dans ceux d'uranium.
# Chaudière à uranium et caféine
Posté par Joris Dedieu (site web personnel) . En réponse à la dépêche Mod_pagespeed : un accélérateur de pages Web. Évalué à 10.
L'effort de google pour
(削除) diminuer ses frais de bande passante (削除ここまで)rendre le web plus rapide est vraiment louable. Ceci dit il pose quand même un léger problème dans la façon partielle (pas partiale) dont il est abordé. Pour beaucoup de(削除) Geeks à IPhone5 (削除ここまで)webmasters ce que dit google est parole d'évangile et doit être appliqué sans se poser de question. Ceci dit google n'est pas responsable de ce fait et ce n'est donc pas son procès que je fais ici.Pour moi, modeste administrateur système ce qui fait la qualité et la rapidité d'un site web peut se résumer en deux points :
1) Son workflow
Un site web est une application et mérite d'être considérée comme telle. Et en tant que telle, il lui faut suivre un cycle de vie rigoureux comprenant notamment, une gestion des versions, des tests, une procédure de publication, un suivie des bugs, bref toutes les choses qu'on fait normalement et naturellement pour n'importe quelle application. C'est bien sûr souvent le cas lorsqu'il s'agit d'applications critiques développés pour des clients qui ont l'habitude de mener des projets informatiques, ou simplement par des gens sérieux qui savent ce qu'ils font. Mais beaucoup de web agencies ne fonctionnent pas ainsi. Le workflow le plus souvent constaté est :
Lorsque le problème survient :
L'alibi le plus couramment admis est qu'il s'agit d'un CMS et donc que tout le wokflow de développement est assuré par ailleurs. Pourtant au quotidien je constate que là ou il faut un modeste serveur à certain pour faire tourner des dizaines de sites, certains peinent à en faire fonctionner un seul sur un cluster (toute chose égale par ailleurs) ou encore que l'absence de tests avec des données dans la base est sans doute la cause la plus fréquente de plantage. Notamment avec MySQL qui a des effets de seuil important.
Pour faire un site web rapide et de qualité, il faut donc :
2) Le ressources
La rapidité de la réponse renvoyée par un serveur web dépend avant tout de deux paramètres qui sont, le temps d'exécution du script et son empreinte mémoire. C'est peut être con à dire mais un script qui s'exécute vite permet au serveur de répondre rapidement. Moins un script occupe de mémoire, plus il peut être exécuté simultanément un grand nombre de fois et avec plus d'efficacité.
Pour cela quelques conseils :
Par exemple pour php, il est de bon ton de travailler en dev avec un memory_limit et un max_execution_time plus bas que sur la prod ainsi qu'avec l'open_basedir activé et strict, un nombre d'extensions réduites, suhosin activé et configuré très strictement. Sur la prod on peut alors lâcher du lest pour assurer une bonne fluidité et éviter des plantages imprévus.
L'impact d'ajout d'extensions ou d'augmentation des limites doit être soigneusement évalué. Ainsi que par exemple le moteur de stockage des sessions, la collecte de statistiques… La encore une évaluation sérieuse nécessite qu'il y ait des données dans la base.
Les scripts gourmands (type génération de rapports, export, reindexation …) doivent être isolés et exécutés dans un contexte privé séparé du site public. L'upload de gros fichiers doit être effectué par parties afin de s'adapter au contexte global … Le cas typique est l'augmentation du timeout d'apache (essentiel pour résister aux dos type slow lorris) simplement parce qu'un script d'export de base de données qui pourrait très bien s'éxécuter en cron ou sur une autre instance apache met 3 heures à retourner des données
Lorsqu'on fait appel à un web service, à une url externe, il faut s'assurer du comportement du script en cas indisponibilité de la ressource. Il faut écrire un vrai client, gérant les timeout, le cache, et les facilités prévues par le protocole (if-modified-since par exemple en http). Les simples fopen("http:// … sont à bannir.
Côté client il n'est pas toujours évident qu'aller chercher jquery chez google soit beaucoup plus efficace que de l'héberger sois même. Cela doit être encore un fois évalué.
3) Conclusion
Vu ainsi ce type de conseils peuvent sembler démesurés pour une petite agence sortant du site à 500 euros. Pourtant il s'agit d'une simple habitude de travail. De nombreux outils existent pour lancer des tests, remplir les bases et finalement lorsque l'habitude est prise c'est plus un gain de temps qu'autre chose.
Voilà c'était mes trois conseils à deux cents pour un web rapide. Ils n'ont rien d'incompatible avec ceux de google. Je pense juste qu'ils sont un préalable nécessaire. Comme il est dit dans l'article, mod_pagespeed est juste un moyen d'éviter de modifier immédiatement ses sites. Je n'ai pas de chiffres exacts mais j'imagine que le surcout machine est important, ne serais-ce que parce que le serveur doit avoir une vision globale de ce qu'est la page. Et c'est pour cela que je ne l'aime pas trop. Pour moi, le web rapide et qualitatif trouve son origine dans les consommateurs de caféine et pas dans ceux d'uranium.
Joris