Quand on regarde se qui se passe, entre l’envoie d’une requête par le navigateur et l’affichage du résultat, on est frappé par l’incroyable gâchis, à tous les niveaux.
Incroyable à un niveau difficile à imaginer. Intuitivement, je dirais au moins 1000, mais la réalité est sans doute bien plus élevée.
1000 ? 1000 quoi ?
1000, entre ce que ferait un système avec des performances optimisées, et ce qu’on fait actuellement.
Un exemple croustillant :
La page à afficher contient du Javascript.
Ce javascript est envoyé en texte sur le réseau. Il prend donc une bande passante correspondante.
De plus, il est bien souvent dans un fichier à part. Cela veut dire un échange spécifique, entre le client et le serveur, pour ramener ce script sur le client.
Bon, le script est là…. Le navigateur doit analyser ce texte, caractère par caractère, pour transformer tout ça en un programme exécutable.
Si, à la place, on avait un « bytecode » : un code binaire universel (comme le java par exemple, ou le flash), il y aurait, sur le client, une lecture incroyablement plus rapide, pour un code beaucoup plus léger.
Des exemples comme celui là, il y en a des dizaines, des centaines, qui s’accumulent les uns aux autres…
C’est toute la chaîne Internet / Web qui est construite sans aucune réflexion de performance, comme si les ressources étaient illimitées.
Résultat, pour mettre en ligne des services, avec des temps de réponse raisonnable (moins d’une seconde… une éternité pour un ordinateur), on doit mettre en œuvre des monstres de puissance : batterie de serveurs octo-processeurs, giga octet de Ram, systèmes de cache, … Bref, un système capable de performances hallucinantes… Tout ça pour servir quelques pages web à la seconde… Pages qui ne comportent en général aucune complexité au niveau des calculs…
Comment en est-on arrivé là ?
Simplement, très simplement : grâce à Mr Moore, ou, pour être plus précis, à l‘incroyable évolution de la puissance des machines.
Pourquoi optimiser, si les machines gagnent un facteur 2 tous les 18 mois tant côté serveurs que côté client ?
La question suivante est naturellement : mais que va-t-on devenir ?
Je veux dire : va-t-on continuer à « gâcher » à ce point les ressources IT ou les choses vont elles « naturellement » évoluer, pour aller vers un peu plus de raison…
toujours difficile et risqué de répondre…
Je pense que les choses vont évoluer, avec des sauts technologiques, poussés par des nouvelles solutions, qui seront acceptées, parce qu’elles trouveront un axe malin pour se propager…
Google peut naturellement être un acteur de ces révolutions à venir, ils travaillent à plusieurs niveaux pour optimiser un peu « tout ce bazar » !
Je vois ce que tu veux dire.
Malheureusement, ta pensée pourrait être transposée pour toutes les facettes de la vie d’un produit quelconque surtout de notre temps.
Pourquoi réparer un objet légèrement abimé ou cassé mais réparable alors que nous pouvons en acheter d’autres tout beau tout neuf au Carrefour du coin ?
C’est une mauvaise habitude de la gestion et de l’utilisation des ressources.
Les ressources ne sont pas inépuisables.
Je pense qu’internet avait besoin de cette simplicité de code (et donc de lourdeur et aberration techniques) pour se développer.
Si tout les langages web avaient étés dès le début des langages compilés, la création internet n’aurais pas prise comme elle l’a fait ses 10dernieres années.
Je pense que les framework (javascripts par exemple, ou d’images fonctionnelles) sont justement un pas vers ce à quoi tu voudrais tendre le web. Le second pas, serait d’intégrer ces framework dans les navigateurs, afin d’envoyer uniquement le code exécutant.
Mais sans être d’accord avec toi sur les “bytecode” (que je traduit par langage compilé, corrige moi si je me trompe), je suis totalement d’accord sur le fait qu’il y a d’ÉNORMES sources d’optimisation dans l’internet actuel.
Effectivement, nombreuses sont les opérations inutiles qui sont réalisées à chaque chargement de page. En revanche, on peut d’ores et déjà optimiser grandement la rapidité d’un site Web en mettant en place quelques quick-wins qui augmenteront TRES sensiblement les performances côté navigateur. Et pas besoin d’un octo-processeur comme tu dis…
En effet, d’une manière générale, 80% du temps de réponse global d’une page se situe côté client. Entre le download des nombreuses ressources statiques (CSS, Javascript, Images), leur interprétation, jusqu’à l’affichage complet de la page avec tous les comportements dynamiques qui vont bien, il il y a du boulot à réaliser pour le navigateur. Mais en quelques étapes, on peut gagner ENORMEMENT de performances. Par exemple :
1. Diminuer le nombre de ressources statiques (CSS, Javascript, Images) et donc de requetes HTTP. Cela implique de faire des Image maps / CSS sprites, de regrouper les Javascripts en un seul fichier + un passage au Minifier pour réduire la taille du fichier. Idem pour le CSS. Comme les navigateurs sont « capés » à 2 requêtes simultanées par host, on a vite un bottleneck à ce niveau là. Avec cette technique, on évite cela.
2. Passer tout ca au GZIP.
3. Ajouter les entetes HTTP « Expires » et « Cache-Control » qui vont bien pour éviter de redownloader inutilement les fichiers CSS / JS / IMG à chaque changement de page.
4. Mettre les scripts JS en bas de page, car ils bloquent le download simultané du navigateur (même sur des hosts différents), comme recommandé dans les HTTP/1.1 specification…
Je n’ai rien inventé. Tout vient de là : http://developer.yahoo.com/performance/rules.html
Enfin, côté serveur, avec un bon petit système de caching (memcache par exemple), on peut alléger considérablement le nombre de requêtes SQL et soulager les serveurs, qui auront déjà été fortement soulagés par la diminution de requêtes « inutiles » avec la mise en place des optimisations front-end…
Bref, beaucoup (vraiment BEAUCOUP) moins de gachis sans avoir à toucher et refondre complètement l’existant.
Oui bien sûr, on peut faire pas mal d’optimisation… Mais ça fait faire de drôle de choses, et demande une maîtrise technique finalement assez complexe.
Je ne suis pas d’accord.
La séparation du javascript par exemple permet une évolution simplifiée du code.
Et qu’en est il des personnes et postes ne pouvant pas l’executer.
Le web actuel obéit à des norme qui faccilite son évolution et son adaptation à tous les postes et tous les clients.
C’est pas parce que java est portable ou que flash transporte tout en un que c’est performant, que c’est viable en terme d’évolution …
Il suffit de faire tourner une fois un site en java pour en être vacciner à vie (et j’en ai vu tourner plusieurs, des petits et des très gros …)
Optimiser un site classique en revanche apporte son lot d’économie et de performance.
Compression des fichier, compression & optimisations des css et js, un seul css, un seul js, optimisation des images, optimisation du serveur (header, cache, cookies …), sprite css …
Ce sont des solutions simples à mettre en place. Qui s’insèrent parfaitement dans la vie et l’évolution d’un projet sans handicaper lourdement.
Selon moi le problème est plutôt que les professionnels du web n’utilisent pas suffisamment ces techniques et technos.
Pour s’en convaincre, il suffit de regarder de grosse structure comme amazon, google, yahoo et d’observer la construction de leur site internet et l’architecture sur laquelle ils reposent. Aucun ne tourne en java ou n’utilise a outrance le flash.
En effet, la remarque n’est pas nouvelle et le net ne serai pas ce qu’il est aujourd’hui si nous avions utilisé du bytecode pour afficher des pages Web.
Quand on voit les problemes rencontrés par Java et Flash pour que les Runtime soient portées sur tout les systemes, et que tout les systemes soient portés sur toutes les architectures..
Nous n’aurions pas un développement du Web aussi impressionant que nous l’avons aujourd’hui.
Et pour que cela change, il faut que les DSI changent, que les architectures changent, que les analyses développeurs et autres développeurs changent et que tout le monde aient conscience des bonnes pratiques de développement. Malheureusement, nous n’irons jamais dans cette direction, car l’argent qui est le moteur de nos actions ne nous guides pas vers un monde parfait, mais vers un monde de profit.
Thomas Tourlourat.
« Oui bien sûr, on peut faire pas mal d’optimisation… Mais ça fait faire de drôle de choses, et demande une maîtrise technique finalement assez complexe. »
@françois tu es sérieux?
Ce genre de procédé est mutualisable. Et l’admin système, réseau et même le développemnt nécessitent de vrais compétences techniques, théoriques et méthodologiques.
Le vrai problème c’est que beaucoup de vendeurs de vents et script kidies s’auto-proclament grands chantres de rien.
Le vrai problème est là. Il y’a trop de bonimenteurs.
En parlant de Google, tu as vu ce projet => http://googlewebmastercentral.blogspot.com/2009/06/lets-make-web-faster.html
@Martin> Oui, c’est ce genre de trucs qui me faisais parler de Google…
Derrière tout ça, il y a une question clé : pourquoi les formats d’échanges doivent ils être en texte ?
Je vais proposer un petit billet 😉