Niveau : débutant

Lors d'un précédent post, j'avais émis l'idée que les sites populaires étaient rapides, et que de mauvais temps de réponse (la latence) nuisaient à la fréquentation des sites web, puisqu'ils faisaient partie du "perçu" du visiteur.
Toutefois, j'en étais resté au stade de l'hypothèse, de l'opinion personnelle, étayée par un court article.

J'ai eu de bons retours, mais aussi certains doutes exprimés : en effet, optimiser coûte, si ce n'est en matériel, au minimum en temps développeur / administrateur, alors que ceux-ci pourraient être affectés à des tâches plus "productives".
Est-ce pertinent pour le management de mobiliser des ressources, d’alourdir les process, le tout pour des gains incertains ?
Surtout lorsque les budgets sont serrés, puisque tout le monde n'a pas les moyens humains et matériels de Google, de Facebook ou d'Amazon ...

Est-ce que la recherche des meilleurs temps de réponse a des bénéfices concrets et chiffrables pour l'entreprise, ou est-ce juste la marotte de quelques geeks idéalistes et bien trop pointilleux ?

"Speed [is] an undervalued and under-discussed asset on the web" - James Hamilton

Niveau : débutant

Depuis des décennies, les débits n'ont cessé de croitre, que ça soit côté visiteur (nous sommes passés du modem 56K, à l'ADSL, et maintenant la fibre), que côté hébergeur, ce qui nous permet de créer des sites web toujours plus impressionnants visuellement.

Pourtant, j'ai tendance à croire que la situation ne s'est pas franchement améliorée depuis 20 ans : à cette époque, nous accédions à Internet depuis notre domicile, via un câble physique, au débit constant.
Aujourd'hui, nous y accédons sans fil, depuis la rue, un hot spot public encombré, le wifi de l'entreprise, ou depuis le fond d'un restaurant bondé.
Et nous savons tous que les débits sans fil peuvent être fortement perturbés, ne serait-ce que par une cloison ...

Optimiser les contenus graphiques, qui sont les éléments les plus lourds d'un site, c'est permettre au visiteur de recevoir son contenu plus rapidement, quelle que soit la qualité de sa réception.
Et en même temps, faire des économies côté hébergeur (la bande passante montante coûte, disons-le franchement, un bras ...)
On ne réduit pas la taille des visuels parce qu'ils prennent de la place sur le disque du serveur qu'on loue ...
On réduit surtout la taille des visuels pour améliorer les temps de chargement du visiteur !

"JPEGs are for photographs and realistic images. PNGs are for line art, text-heavy images, and images with few colors. GIFs are just fail." - Louis Brandy

Niveau : débutant

Joomla! est un CMS (Content Management System) crée en 2005, et qui se répand progressivement. Il est aujourd'hui le 3e CMS Open Source, derrière Drupal et WordPress.
Sa souplesse et sa modularité font qu'il est tout autant adapté pour les sites web corporate, les sites promotionnels, les blogs, et mêmes les sites marchands.
Bien sûr, plus un framework est modulaire, et plus il est exigeant au niveau ressources, comme toute plateforme dynamique.
En tant qu'administrateur, vous aurez donc à héberger des sites Joomla!, un jour ou l'autre.
Dans cet article, j'explique brièvement son installation, ainsi que les "surprises" au niveau de son optimisation (Memcached ou autres) que j'ai eu avec la dernière version stable, la 3.2.1.
Tout ne fonctionne pas "out of the box", et je n'estime pas que Joomla! peut être mis en production, sans quelques optimisations.

Niveau : intermédiaire

Nous avons un serveur web, un accélérateur PHP, un serveur SQL, possiblement un reverse-proxy de type Nginx, et le tout ronronne tranquillement.
Le framework du site est assez lourd. Toutefois les machines sont puissantes, et les pages sont générées en une ou deux secondes, ce qui est tout à fait acceptable pour le visiteur.
C'est ce que j'appellerais une architecture "honnête", ou encore "you get what you pay for".

Toutefois, s'il y a des pics de fréquentation, si le marketing décide d'organiser une campagne de communication sans vous prévenir, si votre site commence à devenir viral, par un bon billet Twitter ou des partages Facebook, son accessibilité risque de se dégrader rapidement.
Les temps de réponse d'un site croissent exponentiellement et non pas linéairement, par rapport au nombre de visiteurs : plus les serveurs seront sollicités, et plus les temps de réponse vont se dégrader.
Les visiteurs vont s'énerver lorsque leur page ne s'affichera pas assez rapidement, et vont encore plus charger l'infrastructure, qui s'écroulera.

Mon expérience dans le domaine de l'hébergement web m'a appris qu'une architecture "honnête" ne suffit pas pour absorber les pics de fréquentation, qu'il faut parfois savoir tricher avec l'architecture, ou encore "hyper optimiser", pour avoir une infrastructure solide, résiliente, capable d'encaisser.
C'est quelque part, d'un point de vue métier, laisser au site web la possibilité de dépasser les attentes, plutôt que de vouloir à tout prix le limiter, en se basant sur des objectifs de fréquentation fixés sur le papier ...

L'un des moyens les plus efficaces pour améliorer les performances des sites web, c'est Memcached !