MicroWA

En me posant des questions existentielles sur SandBox et jQuery, j’ai été faire un tour sur le site http://sndbx.org.
C’est le concours du meilleur CSS pour le thème SandBox.
Et le thème gagnant est vraiment chouette, clean, et tout et tout…
Donc le voilà ajouté sur mon site!

Ce n’est pas que je n’aime plus mon vieux thème horizontal en développement prolongé.
Loin de là, puisque l’idée initiale était de le retravailler!
Disons qu’au lieu de partir de zéro, on va partir d’une base consolidée.

En plus de cela, j’ai activé pour Apache le mod_deflate et ça booste bien le temps de chargement de la page (de 4s à 2s !).
On verra bien la charge du serveur ?!

Voilà jQuery 1.2 est disponible:
http://docs.jquery.com/Release:jQuery_1.2

Dans les documents, voilà un article très intéressant qui répond à mes questions sur la compression Javascript:
http://www.julienlecomte.net/(…)gzip-your-minified-javascript-files/

Il existe des “Packers” qui encodent le code Javascript… On se retrouve alors avec du code qui commence par un eval(…)
C’est alléchant au premier abord car on peut passer d’un script de 100K à 30K.
Le temps de chargement est alors moins long.
Mais le désavantage est que le code encodé doit être décodé! Ce qui prend aussi du temps.
Il faut donc savoir dans quel cas on gagne vraiment du temps.

Un autre argument à prendre en considération est le cache du navigateur.
La plupart des internautes utilisent le cache: par exemple, les images ne sont chargées qu’une fois à la première visite.
Quand on revient sur le site, l’image est déjà prête dans l’ordinateur de l’internaute et donc la page apparait plus vite.

C’est le même mécanisme pour les scripts Javascript.
Un code de 100K sera chargé une seule fois et ne nécessitera pas d’être décodé.
Alors qu’un code compressé de 30K sera aussi chargé une seule fois… mais devra être décodé chaque fois!

Et maintenant, on ajoute le dernier ingrédient: la compression du navigateur.
Pour réduire le trafic sur internet et accélérer les échanges, la plupart des navigateurs demandent aux serveurs web de … compresser les réponses!
On peut donc compresser (gzip ou deflate) les 100K de Javascript et le navigateur le décompressera de manière transparente.
Comme le navigateur utilise du code compilé et non une machine virtuelle Javascript, le temps d’exécution est plus rapide.

Au final, on a donc une seule décompression et un code plus compact sur le réseau.

Bien sûr, on peut aussi encoder le Javascript et le compresser pour le navigateur!
Mais le résultat surprenant est que un code encodé se compresse … mal, parce que déjà compressé…

Zend, l’éditeur spécialisé dans PHP, publie la version 1.0 de son Framework.
http://www.01net.com/(…)zend…version-finale-de-sa-bibliotheque-php…

La bibliothèque est open source et permet d’utiliser tout ou partie des composants.
A tester…

Beaucoup de conseils pour améliorer les performances de son serveur web…
http://docs.moodle.org/fr/Performance

Avec Dedibox, on peut louer un nom de domaine pour 5€/an HT et configurer le DNS. Le service DNS se dit intégral car on a le serveur DNS secondaire.
Mais je me suis aperçu qu’avec Gandi on pouvait utiliser 2 “wildcards *” et pas avec le service Dedibox.

Je m’explique…
La configuration voulue est:
Pour le front end
*.mondomaine.com in  A 111.111.111.111
Pour le back end
serveur1.mondomaine.com in A 222.222.222.222
*.serveur1.mondomaine.com in A 222.222.222.222

Il faut donc utiliser 2 wildcards *, mais l’interface Dedibox ne l’autorise pas!