Lire en direct les logs apache est une obsession de geek nerd parano. C'est le trainspotting du dev. Des lettres blanches sur fond noir, à l'espacement fixé, commandées dans un terminal qui se déroule dans une fièvre syncopée. Dans un silence glaçant. Ou feutré (oui, parce que le bruit d'imprimantes à aiguilles, on trouve ça que dans les films d'Hollywood).
Imbitable, lourd, cette “occupation” permet de se tenir au courant des dernières tentatives d'attaque automatisées, de bots de moteurs de recherche, des comportement incohérents de sites, des kikoolol qui piquent vos images pour les mettre dans leurs skyblogs, les gougnafiers qui pompent votre site pour les mettre avec de la pub... Mais aussi d'analyser le comportement de logiciels clients, les navigateurs, pour mieux optimiser vos applicatifs.

Prenons mon site professionnel

Dedans, il y a une image en .png ARGB (relire l'article à ce sujet), mais j'établis une simple discrimination dans la CSS pour servir au brontosaure MSIE6 la “même” image (forcément moins jolie) en .png palettée. Comme ceci :

h1 {
	background : url(dascritchcomIE6.png);
}

html > body h1 {
	background : url(dascritchcom.png);
}

Dans les faits (à une seule exception, lire plus bas), et jusqu'à la semaine dernière, tous les navigateurs ne chargeaient qu'une seule image. MSIE6 chargeait la sienne, les autres la normale. Mais jamais les deux à la fois.

Petit gourmand, va.

Prenons Google Chrome (User-agent déclaré : « Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.29 Safari/525.13 » . Risible en complexité), et voyons ce qui se passe avec :

Comme on le remarque, Google Chrome charge les deux images. Mais n'en affichera au final qu'une seule. À l'heure où j'écris ces lignes, Google Chrome n'est disponible que depuis une semaine. Et n'est même pas au stade de Béta. Ce qui veut dire qu'il est très très loin d'être optimisé ou même sécurisé (d'ailleurs, il est fortement recommandé de ne pas surfer n'importe où avec !).
L'optimisation ici consisterait à ne charger que les images réellement utilisées. Safari, Opera, MSIE et Firefox ne chargent les images décrites dans les CSS que si le moteur éprouve le besoin de les afficher. Si un bloc est déclaré dans votre CSS comme ayant grosbalourd.jpg en background, mais que la balise en question n'est pas dans votre page HTML, normalement, le navigateur ne le charge pas. Ce n'est pas le cas avec Google Chrome.

En fait, ce comportement se retrouve dans Konqueror, le navigateur web de l'environnement KDE sous Linux, dont le moteur KHTML a été la base qu'Apple a choisie pour créer Webkit pour son Safari. Néanmoins, Apple a optimisé en supprimant ce comportement, ce qui n'est pas le cas de l'équipe de Google Chrome.
Hypothèses :

1. Soit c'est un défaut d'optimisation. Et dans ce cas, il est totalement prématuré de travailler à ce stade d'écriture sur l'accélération et l'optimisation des ressources d'un logiciel aussi complexe alors que d'autres choses sont à coder en priorité. Surtout qu'ils en sont qu'à la version “0.2.149.29”.
2. Soit c'est une volonté de Google dans son navigateur de rendre encore plus réactive les actions dynamiques (manipulations JS+DOM comme les appels AJAX/JSON), vu que l'intention du moteur de recherche (décrite dans la bd par Scott McCloud) en pré-cachant les éléments graphiques de décoration. Mais surtout de rendre encore plus attractives ses applications web, de manière à ce qu'elles ne souffrent pas de la comparaison avec les logiciels (Google Documents versus Microsoft Office, par exemple)

Si c'est la deuxième option qui est vraie, ce choix peut rendre l'affichage d'un site extrêmement lent lors du premier chargement, et Google Chrome extrêmement lourd sur des CSS très complexes. Par exemple, le cas où un site a de très nombreuses pages, de très nombreuses sections et que chacune a un habillage poussé et que le tout est dans une seule CSS pour des raisons de facilité de maintenance. Encore plus si des versions pour MSIE6, pour d'autres médias (impression, mobile,...) sont inclus toujours dans le même document CSS.

Vues les volontés communes des navigateurs open-source d'accélération du moteur Javascript (l'interpréteur bytecode du SquirrelFish dans Webkit, l'arrivée du JIT dans TraceMonkey de Gecko, et le code pré-machine virtualisé du V8 de Google) pour rendre les applications web dynamiques encore plus réactives, ce... particularisme (?) pourrait se répercuter dans les autres navigateurs modernes. Et donc devenir la norme, et donc obliger à repenser certaines CSS (j'en ai vu qui approchaient les 120ko) voir le design général d'un site. Pas mal de web-designers et web-developpeurs vont devoir remettre en cause leurs méthodes de travail.

À propos de modernité des navigateurs, rappelons que MSIE est incapable de garder en cache les éléments dynamiques comme les images dans les CSS, ce qui rend la navigation sur certains sites pénibles. Par exemple, chaque fois que sur mon site vous allez dans la colonne de droite choisir une puce, MSIE recharge la puce, ce qui la fait clignoter. Ce comportement aberrant oblige les webdesigners à développer des techniques comme le sprite.

Dis-moi d'où tu viens...

Autre chose que l'on remarque, c'est la colonne Referee. C'est une des méthodes pour déterminer pourquoi un élément d'un site a été chargé (il en existe plusieurs), et les origines de traffic comme je l'avais précédemment expliqué. Dans le cas des logs Apache, cette colonne est parfois renseignée. Car ce champ est déclaratif lors de l'envoi d'une requête à un serveur web (il se fait avant les cookies). Opera, les proxys d'entreprises,... ne renvoient pas d'information. Seul le moteur Gecko (celui de Firefox) indique qu'il charge une image parce qu'elle est décrite dans la CSS, les autres font référence au document HTML.

Néanmoins, le raisonnement ne se fait pas jusqu'au bout, puisqu'une image appelée par un Javascript (DOM, AJAX, JSON, etc...) est referée comme venant du document HTML. Un manque de cohérence dans la politique Firefox qui mérite bien un ticket bugzilla.

À noter que certains lecteurs de flux RSS basés sur Webkit (tous ceux sur Mac) renvoient improprement l'adresse racine du site.

Moralité

Ami développeur qui travaille en entreprise, quand tu t'emmerdes, ouvre ta console, loggue-toi en ssh à ton serveur, et lis tes logs apache. À défaut, tu peux toujours naviguer avec links pour lire bashfr.
De loin, ça fait illusion.