Media Queries CSS3 et Client/Serveur…

Suite a une remarque et une discussion intéressante avec l’ami Mathieu B. via FaceBook sur les Medias Queries, j’ai voulu vérifier comment cela se passait précisément du côté de la relation client/serveur. Sitôt dit…

Car nous avons plusieurs méthodes d’utilisation, chacune ayant des avantages et inconvénients.

Le résultat ne présente pas trop de surprise… mais au moins, on est sûr!

Media Query ?

Les Medias Queries sont des propriétés CSS (depuis CSS2, mais optimisées en version CSS3) qui permettent d’adapter une page HTML à différents types d’écrans ou matériels.

Ils sont notamment à la base des feuilles de styles qui ne s’appliquent que dans certains cas telles l’impression, les écrans mobiles ou de tailles réduites… Et largement utilisées dans la mode actuelle du responsive web design que nous connaissons avec iPhone, Android et autres télés connectées (parmi plusieurs méthodes, mais le propos du jour n’est pas là).

Pour les utiliser, nous avons donc deux syntaxes à disposition.

La première syntaxe consiste à glisser un attribut media dans la balise link de l’entête:

<link rel="stylesheet" media="all" href="tout.css" type="text/css" />
<link rel="stylesheet" media="print" href="papier.css" type="text/css" />

La seconde étant de mettre, dans une seule CSS (tout.css) une sorte de test limitant le contenu à un média particulier.

@media print {
...
}

Notons que dans ce cas, la spécification via link fait 73 caractères, là où celle inclut dans la css n’en comporte que 15.

Pour plus de détail, l’article très complet d’Alsacréation me semble incontournable. Il nous permettra de voir que l’attribut media peut prendre des valeurs complexes:

screen and (min-width: 200px) and (max-width: 640px)

Jeu de test

L’idée de mon test du jour est donc de voir si les css sont appelées par le client uniquement si nécessaire, ou chargées d’office et appliquée si besoin.

Deux fichiers nous intéresseront: une page html et access.log d’Apache (ainsi que 4 fichiers CSS, qui ne contiennent pour ainsi dire rien).

La page est plus que simple, et (pour la partie qui nous préoccupe), va contenir 4 lignes pour appeler les CSS (j’ai simplifié l’écriture):

<link href="./tout.css" rel="stylesheet" type="text/css" />
<link media="screen and (min-width: 400px)" href="./min400.css" ... />
<link media="screen and (max-width: 400px)" href="./max400.css" ... />
<link media="print" href="./papier.css" ... />

Nous aurons donc tout.css qui s’appliquera dans tous les cas (car media n’est pas précisé, il est donc équivalent à all), papier.css en impression, et les deux autres en fonction de la taille de l’écran de l’utilisateur.

Ne reste plus qu’à appeler la page dans le navigateur (en grand écran) et regarder que dit Apache. Si seules 2 css se chargent, c’est que le navigateur fait le tri, si les 4 se chargent, c’est qu’il appelle tout le monde pour se tenir prêt à s’adapter à toutes les situations.

Petit tour vers les logs Apache:

127.0.0.1 - - [22/Jun/2012:05:03:32 +0200] "GET / HTTP/1.1" 200 438
127.0.0.1 - - [22/Jun/2012:05:03:32 +0200] "GET /tout.css HTTP/1.1" 200 75
127.0.0.1 - - [22/Jun/2012:05:03:32 +0200] "GET /min400.css HTTP/1.1" 200 75
127.0.0.1 - - [22/Jun/2012:05:03:32 +0200] "GET /max400.css HTTP/1.1" 200 75
127.0.0.1 - - [22/Jun/2012:05:03:32 +0200] "GET /papier.css HTTP/1.1" 200 75

C’est sans appel (ou plutôt si): le navigateur charge tout le monde.

Ce qui, quelque part, me déçoit un peu. Mais bon, si les navigateurs étaient intelligents, cela se saurait…

Que faut-il en conclure ?

L’avantage d’utiliser plusieurs lignes <link> (et donc plusieurs fichiers CSS) est de pouvoir mieux s’organiser, mieux faire les réglages. On sait facilement que papier.css concerne l’impression, et ne contiendra que ce qui est utile à l’optimisation de l’impression, souvent des display:none pour les menus, headers, footer et autres (pour mémoire: ne négligez pas ceci, cela sauvera quelques arbres).

L’inconvénient, on vient de le voir, est que le navigateur va multiplier les requêtes serveur.

Bien sûr, n’avoir qu’une seule CSS va inverser les avantages/inconvénients. Tout sera mélangé dans une CSS, rendant la mise au point d’icelle (un peu) plus complexe. Mais le nombre de requête sera limité à une seule.

Du point de vue poids des fichiers, ce sera a peu prêt équivalent, on l’a vu au début de l’article: 73 octets pour la balise link, 15 pour le test. Sauf que 4 appels CSS équivalent à autant de requêtes HTTP, donc à l’expédition des entêtes correspondant.

Un petit appel à wget nous permet d’en évaluer la taille:

wget -O- --save-headers "http://localhost/papier.css"

Ce qui me donne 300 et quelques octets de plus (par CSS).

HTTP/1.1 200 OK
Date: Fri, 22 Jun 2012 06:11:01 GMT
Server: Apache/2.2.11 (Win32) PHP/5.2.9-2
Last-Modified: Fri, 22 Jun 2012 05:29:07 GMT
ETag: "3600000006fcef-42-4c30a2b1b3fd0"
Accept-Ranges: bytes
Content-Length: 66
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/css

(précisons au passage que cela dépend un peu de la configuration de votre serveur)

Et donc… ?

Donc d’un point de vue mise au point, il me parait plus intéressant de travailler avec plusieurs CSS distinctes, chacune ayant un rôle précis, avec la balise <link> précisant le media de chaque. Une fois que tout fonctionne, les réunir dans un seul fichier permettra d’optimiser le poids et les accès pour nos amis internautes.

On pourra en profiter aussi pour nettoyer la CSS, afin de gagner encore en ressources: retirer les commentaires, les tabulations et espaces superflus…

C’est là où des outils tels SASS ou LESS sont intéressants (des compilateurs de CSS), voire CodeKit.

[edit]: le lendemain de l’article, je tombe sur One, Two or Three… Intéressant et allant dans le même sens :-)