• #10. Enregistrement du mot de passe (plus besoin de le taper à chaque fois)
• #09. Encore plus rapide !
• #08. Création de contacts ajoutée.
• #07. Ajoutez une photo à votre profil.
• #06. Vous pouvez mettre une image en plus ou à la place du titre de l’événement.
• #05. Un événement peut avoir lieu à plusieurs dates.
• #04. Vous pouvez mettre le prénom et/ou le nom de l’invité dans votre mail.
• #03. Vous pouvez distribuer un lien publique pour votre événement.
• #02. Créez des équipes ou des voitures dans laquelle vos invités se placent.
• #01. Certains de vos invités peuvent co-organiser.

Nooxt v3 est avant tout une réécriture totale ce qui nécessite une vigilance particulière : c’est pourquoi une version beta est déjà en cours d’utilisation, parallèlement à la version courante. Cela permet d’étendre la période de test pour avoir un produit final qui ne présente pas trop de surprises (on va appeler les bugs comme ça désormais, c’est plus sympathique).

Merci aux courageux beta-testeurs et n’hésitez pas à me contacter si vous voulez en être. (Vous devez avoir un compte Nooxt.)

Ils attendent patiemment le moment où ils pourront confirmer la moindre des allégations collectées et ainsi dispenser au monde quelques lumières sur le futur de l’organisation numérique d’événements. Je préfère avoir la primeur de l’exclusivité même si ça me coûte de les contraindre à jeter leur dossier cartonné orange à la poubelle.

Voici donc une image compilant quelques extraits de Nooxt v3, en exclusivité mondiale.

Cette fois-ci encore, partons du principe que vous n’avez pas la main sur le matériel (taille de la bande-passante,…) et focalisons-nous sur le logiciel. Et il y a fort à faire !

Taille et format des images

Réduisez la taille de vos images au minimum, c’est-à-dire ajustée à la taille affichée. Non seulement cela réduit le poids de l’image mais cela évite au navigateur de la redimensionner, ce que certains d’entre eux (Internet Explorer…) font mal.

D’autre part, choisissez le format approprié pour votre image. Et là, il n’y a pas de règle : le JPEG, le GIF et le PNG donnent des résultats variables suivant les images ; du coup, on ne peut pas passer à côté du test. Lorsqu’il y a peu de couleurs dans l’image, le PNG l’emporte souvent.

Minimiser le code Javascript et CSS

Les codes Javascript et CSS (s’ils existent) contiennent vraisemblablement des tabulations, des commentaires, des retours à la ligne,…. Autant de caractères qui sont parfaitement inutiles pour le navigateur (ils le sont seulement pour vous, pour vous relire). Dès lors, pourquoi ne pas les supprimer ?

Evidemment, ne faites pas le travail manuellement, des outils existent :

• pour le CSS, en PHP, CSSMin ;
• pour le JavaScript : JSMin

Sur les fichiers CSS de Nooxt, par exemple, on gagne ainsi 20%.

Minimiser le HTML

Si l’on réduit la taille des fichiers JavaScript et CSS, pourquoi ne pas faire de même sur le code HTML ? Pour les sites dynamiques (où chaque page est générée sur mesure par le serveur lorsque l’internaute la lui demande), l’inconvénient de cette opération est double :

• elle fait travailler plus intensément le serveur,
• elle augmente la durée de génération de la page, ce qui déplace donc le problème.

Sur Nooxt, je fais quand même cette minimisation lorsque l’on se connecte au site depuis un mobile, là où le temps de transmission est beaucoup plus déterminant que le temps de génération de la page. Pour cela, cette simple ligne supprime tous les caractères d’espaces successifs (tabulation, espaces, retour à la ligne) par un seul espace :

$sortie = preg_replace('~[\s]+~',' ',$entree);

Compression GZip

Lorsque vous envoyez des documents par mail, vous pensez sans doute à réduire sa taille en faisant une archive .zip. Pourquoi ne pas faire de même avec votre site internet ?

Certains navigateurs autorisent la réception de code compressé en GZIP (aussi bien la page HTML, que les codes JS et CSS). Pour vérifier si le navigateur qui visite votre site accepte ce format, il suffit de vérifier ses en-têtes. En PHP, cela consiste en vérifier que la chaine $_SERVER['HTTP_ACCEPT_ENCODING'] contient le terme “gzip”.

Pour faire la compression en particulier, l’opération est relativement simple pour les fichiers CSS et JS. Il suffit de compresser les fichiers et d’appeler les fichiers compressés (si le navigateur peut les lire, encore une fois !), par exemple :

<script type="text/javascript" src="fichier.js.gz"></script>
<link rel="stylesheet" href="fichier.css.gz" type="text/css" />

Avec cette compression, le fichier CSS de Nooxt a été réduit de 76% supplémentaires !

Chipotons

La performance est un défi toujours renouvelé (les sportifs en savent quelque chose), et il est toujours possible de faire mieux. Voici donc un paragraphe pour chipoter.

Plutôt que d’appeler les fichiers avec des noms à rallonge, Nooxt utilise des répertoires de 2 ou 3 lettres, pour l’essentiel. Ainsi “version3/images/icones/fichier.png” sera plutôt appelé “v3/i/ic/fichier.png”. De la même manière, les noms des classes et id du code HTML sont des noms courts, dans la mesure du possible.

Dans les images (GIF, PNG ou JPEG), des informations inutiles sont automatiquement ajoutées par le logiciel qui compose l’image (Photoshop, par exemple). Il est possible de leur faire perdre une taille avec des outils tels que Pngcrush ou Optipng pour le PNG, JHead pour le JPEG, ou le fameux SmushIt qui fait ça en ligne !

Dans le prochain épisode…

Bien. Vous avez maintenant un site internet généré vitesse grand V et d’une taille réduite au maximum.  Mais ça n’est pas fini : il faut que le navigateur récupère tout ça et l’affiche. Et, là aussi, il y a du boulot.

Figure 1 — D’abord, l’idée d’avoir une flêche en haut et en bas, ainsi qu’un repère sur le positionnement actuel, pose les bases.

Figure 2 — Ensuite, l’innovation a été de rendre le repère proportionnel au contenu entier (plus la barre grise est grande, plus l’utilisateur voit une large portion du contenu entier).

L’ascenseur selon Google Wave

Si vous êtes comme moi, cela fait très longtemps que vous n’avez pas cliqué sur l’ascenseur ou ses flèches… Avec les ascenseurs de Google Wave, on prend acte du fait que la plupart des souris sont équipées de molette et qu’il n’est plus nécessaire de consacrer ces larges espaces à ce type de navigation.

Figure 3a — L’ascenseur ne prend plus de place : ni en largeur (il est à cheval sur le bloc), ni en hauteur (il ne va pas jusqu’au bas du bloc, un petit taquet indique jusqu’où il descend).

Figure 3b — Ici, on est tout en bas (l’ascenseur est au taquet, pour ainsi dire).

Figure 3c — On peut aussi descendre page par page en cliquant sur les flêches. Dans ce cas, l’ascenseur ne descend pas (sinon, pour aller de page en page, on courrait après !) : seul son ombre descend. L’ascenseur rejoindra sa bonne position (celle de la figure 3c) lorsque que la souris quittera la zone.

Nous verrons si cela se généralise… Notons, pour conclure, que des téléphones portables (tels que l’iPhone) n’affichent l’ascenseur que lorsque l’utilisateur bouge dans la page — était-ce une source d’inspiration ?

Il en est peut-être de même pour les mérous, qui se disent : « tiens, ce rocher ressemble à un mérou. » Sauf que c’est relativement difficile à prouver puisqu’il n’existe pas de système de eye-tracking (captage du regard) pour mérou. Cela existe pour les hommes.

Sur les sites web en particulier, un visage attirera naturellement votre regard, comme le montre cette image sur laquelle ont été placés les résultats du captage. (Plus c’est rouge, plus il y a de regards.)

Ce qu’il est intéressant de noter est que lorsque le visage regarde une zone, l’internaute va naturellement y jeter un oeil (l’article). Regardez plutôt, justement :

Une sorte de “Derrière-toi !” que l’on aurait tort de ne pas utiliser car redoutablement efficace…

Le test exclusif offert avec votre article

°_° : Si vous voyez un visage et non des degrés, vous n’êtes pas un mérou.

Mesurer

Trouver le problème, c’est trouver la solution ; sortons donc notre micro-chronomètre pour mesurer le temps que le script mets à s’exécuter.
Voici une petite fonction PHP (cadeau !) qui fonctionne comme un chronomètre.

function michronometre(){
global $_MICHRO;
list($usec, $sec) = explode(" ", microtime());
if(isset($_MICHRO)){
return ((float)$usec + (float)$sec)-$_MICHRO;
}else{
$_MICHRO=((float)$usec + (float)$sec); return 0;
}
}

Appelez une première fois la fonction (michronometre();), le compteur démarre. Regardez le compteur à n’importe quel moment pour voir le temps affiché (echo michronometre();).
Vous pouvez le regarder à différents endroits de la page pour voir quelle portion de code est à inspecter pour optimiser.
Le temps obtenu sera d’autant meilleur que votre serveur est bon. Mais de manière générale, on fait avec ce qu’on a…
En ce qui concerne Nooxt, la page la plus complexe est produite en un peu plus d’une demi-seconde.

Syntaxes PHP

Pour gagner quelques microsecondes, jetez un oeil à la syntaxe de votre code PHP : les “switch” sont plus performants que les “if…elseif…else”, les guillemets simples que les guillemets doubles (même si c’est moins vrai, voire même faux sur les dernières versions de PHP),…
Le site The PHP Benchmark répertorie des tests de rapidité pour différentes syntaxes.
Cela dit, n’espérez pas tirer grand chose de ce côté là.

Base de données

Le plus chronophage (un joli néologisme typiquement SSII-ien) restent les appels à la base de données : tentez de regrouper vos requêtes en une seule (avec les jointures et les SELECT imbriqués) et, évidemment, banissez les requêtes au sein de boucles.

Cache des pages et des données

Pour savoir comment mettre en cache une page, il suffit de distinguer deux grands types de pages :

• les pages entièrement dynamiques qui devront être différentes à chaque chargement puisqu’elles vont chercher des nouvelles données ;
• les pages qui sont modifiées une fois pour toute côté serveur.

Pour les premières, une page HTML sera affichée beaucoup plus rapidement : vous pouvez soit la produire manuellement (en copiant-collant le code généré HTML par le PHP dans un fichier HTML), soit activer le cache de votre moteur de template (si vous en avez un).
Pour les secondes, le recours au PHP sera obligatoire. Mais, au sein d’une même page, vous pouvez distinguer ce qui nécessite réellement un recalcul à chaque chargement de la page… et les autres.
Sur Nooxt, pour calculer des probabilités de présence, des statistiques sont réalisées sur tous les événements puis appliquées à l’événement en cours. Pour éviter ces deux calculs à chaque page, le premier est calculé une fois pour toute et est stocké en session (dans la variable $_SESSION).

Attendez, je n’ai pas fini de

Lorsque vous faites des “echo” ou “print_r”, les informations ne sont pas envoyées aussitôt : ce n’est qu’à la fin du script que tout est envoyé d’un bloc. Mais pourquoi attendre que toute votre page ne soit calculée avant de commencer à l’envoyer à votre internaute ? Vous pouvez demander au serveur de faire parvenir au client ce qui a déjà été affiché en utilisant la fonction flush() [edit: et ob_flush(), merci Thomas].
L’usage le plus courant est d’utiliser cette fonction juste après le “</head>” dans le code HTML, pour que le navigateur puisse commencer à charger les fichiers externes pendant que le reste de la page est généré.

Dans le prochain épisode…

Votre page a été générée aussi rapidement que possible mais parviendra-t’elle à la vitesse de l’éclair au navigateur ? Melany avouera-t’elle son adultère à Jason ?

Cette tendance positionne les sites web en concurrence directe avec les applications installées sur les ordinateurs et, à cet égard, l’utilisateur attend d’eux exactement la même chose : la quasi-instantanéité. Il n’est plus acceptable d’attendre quelques secondes pour accéder à l’information. Pour preuve, la moitié des utilisateurs place la lenteur de chargement comme la principal raison pour laquelle ils quittent un site (source).

Particulièrement vrai sur mobile

D’autre part, grâce à BlackBerry et à l’iPhone, l’internet mobile n’est plus un terrain de jeu technologique mais une vraie perspective de développement. Des centaines de millions de téléphones seront bientôt des navigateurs internet.

Les débits proposés imposent fatalement un recul par rapport aux connexions sur un ordinateur : les informations sont moins rapidement transmises sur un téléphone que via l’ADSL. On ne saurait se satisfaire de cette limitation technique : l’utilisateur ne réduit pas ses exigences à la baisse en passant sur son mobile.

Voilà donc qui introduit l’importance de développer un site web rapide. Cette série de 4 billets livrera quelques clefs pour cela sur trois aspects :

• du côté serveur,
• la communication serveur-client,
• du côté client.

Précisons qu’il ne sera abordé que des actions qui peuvent être menées par un webmaster sur son site web ; le découpage supra indique l’origine du problème, pas l’origine de la solution !

(Je m’engage donc à faire encore 3 billets sur ce blog !)

Les internautes voient aléatoirement l’un des deux designs et le taux de conversion est calculé dans l’un et l’autre cas. L’outil est tout simple ; ce qui nous intéresse en revanche ici, ce sont les résultats.

L’équipe qui s’occupe du projet fait l’amitié à la planète de livrer quelques exemples de résultats sur leur blog, duquel j’ai extrait quelques exemples. (Les images sont petites, mais ça permet d’avoir une vue d’ensemble. Vous trouverez aux liens indiqués les images en taille réelle et parfois d’autres essais.)

LA.com

Lequel des deux formulaires gagne ? L’un des deux a fait peur aux internautes, partis fissa sur une autre page, avec donc 20 % d’inscription en moins.

Le gagnant est le premier. Regardez d’un coup d’oeil comme il a l’air plus simple ; la première colonne est la première regardée (si ce n’est la seule). Sur la première page, on a l’impression que le formulaire ne fait que 3 champs. Sur le second, on a les 4 cases à cocher et ensuite les 3 champs, soit deux fois plus de questions à se poser… (Article sur le blog)

Pacific Hills

Le calcul des taux de conversion comparés est ici un petit peu particulier : les deux écrans contenaient chacun un numéro de téléphone différent. L’objectif était de mesurer celui qui aboutissait au plus d’appels. Lequel des deux gagne ?

C’est la seconde qui gagne. Je ne vais pas m’attarder dessus : la zone centrale est clairement mise en avant parce que c’est la seule sur fond blanc, et l’image du téléphone de la même couleur que le numéro (rouge !) est d’une efficacité redoutable. (Article sur le blog)

37 signals

Cet exemple-ci n’est pas tiré du même blog ; je l’ai pris directement de l’excellent Signal vs Noise. Le meilleur des 3 générera 30% de plus d’inscription que le pire…

Le gagnant est le second. Ce qu’il faut retenir c’est qu’il ne faut pas perdre de temps : le titre lui-même doit être un argument (contrairement au premier). Aussi, les citations qui disent que le produit est génial (sans blague ?) ne servent à rien, il vaut mieux insister sur le fait que c’est rapide (“Moins de 60 secondes !”). (Article sur le blog)

Safe Software

L’une des deux pages va provoquer plus de téléchargement… Laquelle ?

C’est la seconde. Oui, l’inénarrable photo d’un blanc sans âge beau-mais-pas-trop qui sourit à la vie parce que télécharger des logiciels ça lui donne envie de croiser les bras et de montrer ses dents au ciel, n’a servi à rien. Et la flêche verte non plus. (Article sur le blog)

Si vous avez d’autres exemples, n’hésitez pas à les poster en commentaire !

(via Mike Lightman et Swiss Miss)

Un petit peu plus d’un mois après, il est temps de jeter un oeil aux chiffres de fréquentation, et surtout aux performances du serveur (c’était le point qui m’effrayait). Je ne vais pas jouer avec vos nerfs et commencer par la conclusion : tout s’est bien passé.

Plus de 2 fois + de visites

Le lancement a provoqué une hausse de fréquentation prévisible et espérée, qui s’est stabilisée en février, signe que ça n’était pas qu’un simple coup.
Comme je l’avais annoncé il y a quelques semaines, j’ai suivi attentivement les performances du site (je répertorie le temps de chargement de chaque page). Quelques corrections ont été faites au fil de l’eau et il faut maintenant autour de 0,5 s. au serveur pour générer une page, en moyenne.
Il y a encore un petit peu de marge de manœuvre mais ça me semble une bonne base ; tant mon serveur que les visiteurs sont contents, je continue l’aventure !