Media queries, taille d'image et chargement

Hello.

En théorie, le navigateur n'est censé télécharger que les background correspondant aux sélecteurs qui "matchent" des éléments de la page.

Dans la pratique, un bug de Webkit fait que ce n'est pas tout à fait vrai.

Pour plus d'infos, lire cet article en anglais d'Eric Daspet : Useless downloads of background images in Android

Salut,

Si l'une de tes images est déclarée dans une règle CSS qui n'est pas contenue dans une règle @media ciblant spécifiquement un média avec une requête de média spécifique, elle sera chargée par tous les supports susceptibles d'appliquer la règle CSS.

Autrement dit :

element {
  background-image: url(chemin-vers-ton-image-1);
}
@media only screen and (max-device-width: 640px) {
  element {
    background-image: url(chemin-vers-ton-image-2);
  }
}
/* Les deux images sont chargées par les supports répondant à la règle @media */

@media only screen and (min-device-width: 641px), screen and (min-width: 641px) {
  element {
    background-image: url(chemin-vers-ton-image-1);
  }
}
@media only screen and (max-device-width: 640px) {
  element {
    background-image: url(chemin-vers-ton-image-2);
  }
}
/* Seule l'image 2 est chargée par les supports répondant à la seconde règle @media */

Autre solution : n'utiliser qu'une seule image et jouer avec la propriété CSS 3 background-size.
Modifié par Victor BRITO (13 Mar 2012 - 15:37)

Merci à tous, j'avance doucement mais surement.
Je retiens que je pourrais mettre des images en background différentes selon les médias mais ça ne marche pas pour tous les mobiles utilisant Android dans sa version antérieure (il doit y en avoir encore beaucoup) à cause du bug de webkit. Dans ce cas là j'obtiens même l'inverse de ce que je voulais puisque je charge toutes les images, les petites et les grandes

Je ne retiens vraiment la solution d'une seule image à redimensionner car ça sera forcement l'image la plus grande donc la plus lourde que je devrais rétrécir, je n'y gagne pas grand chose en termes de performance.

Tant pis, je vais devoir penser à un design simple avec peu d'images ou des images à mettre en "papier-peint", c'est à dire des petites images à répéter et qui seront les mêmes quel que soit la taille des écrans.

Merci encore

Une autre possibilité à tester.

Tu fais ton site via une approche mobile first.

Tu charges ta feuille de style pour les mobiles et tous les navigateurs.

Ensuite via une media queries dans un lien vers une feuille de style tu charges les media queries au dela d'une resolution.

Ensuite pour IE qui ne supporte pas les media queries, tu charges une feuille de style spécifique à IE < 9.

<link rel="stylesheet" href="css/style.css">
<link rel="stylesheet" href="css/mediaqueries.css" media="(min-width:Xpx)">
<!--[if (lt IE 9) & (!IEMobile)]>
	<link rel="stylesheet" href="css/ie.css">
<![endif]-->

Avantage pas de dépendance avec javascript, inconvénient IE < 9 au dessus de ton point de rupture ne sera plus responsive mais fluide.

Tu peux gérer ça avec Sass ou less (ou autre préprocesseur CSS), pour simplifier la maintenance.

J'aime assez l'approche, ça me rappelle cet article : Leaving Old Internet Explorer Behind dont l'idée principale est de partir d'une approche mobile first, et de servir le même contenu aux vieux IE qu'aux mobiles.

Florian_R a écrit :
J'aime assez l'approche, ça me rappelle cet article : Leaving Old Internet Explorer Behind dont l'idée principale est de partir d'une approche mobile first, et de servir le même contenu aux vieux IE qu'aux mobiles.

J'ai oublié de publier ma source. (Rendons à Cesar...) L'exemple est de http://nicolasgallagher.com/mobile-first-css-sass-and-ie/ . (auteur de normalize.css)

Avec un seul bémol dans sa manière de voir les choses pour IE, je n’inclurait pas personnellement tous les styles "mediaqueries" dans la feuille pour IE, juste le point de rupture dans la tranche 768 - 1024.

J'ai tenté de l'intégrer sur mon html5-boilerplate perso https://github.com/rs459/ht5bp-mootools-compass quand sass sera passé en 3.2 stable je pourrais reprendre l'exemple et l'adapter.
Modifié par rs459 (16 Mar 2012 - 13:39)

Merci,

A quel point se situe la perte de perfromance pour toi ? la requête HTTP supplémentaire ?

Les classes conditionnelles redondantes dans la partie supérieure (IE 768-1024 par ex), et dans la mediaqueries classique (non-ie lt 9) qui seront inutilisés ?

Cela mérite des benchmark's pointus, difficile à réaliser.

Première page > requête HTTP sup > puis mise en cache.

Première page > pas de requête HTTP sup mais traitement par respond.js sur des navigateurs connus pour être très lent en Jscipt.

Quid du cas de la seconde page ? respond.js devra mettre un gestionnaire d’évènement en place (onresize + timer), modifié la feuille de style (cloner j'imagine comme IEPP), puis générer un reflow, repaint.

Sans oublier la manière de charger respond.js qui peut générer une requête HTTP
en plus. (idéalement inclut dans html5shiv ou modernizr).

rs459 a écrit :
Cela mérite des benchmark's pointus, difficile à réaliser.

Webpage Test est ton ami.
Modifié par Florian_R (19 Mar 2012 - 13:02)

rs459 a écrit :
Merci,

A quel point se situe la perte de perfromance pour toi ? la requête HTTP supplémentaire ? ).

Oui et non.

Que ce soit sur iPhone ou iPad, Safari mobile ne semble pas gérer les téléchargements simultanés : les fichiers de styles sont chargés l’un après l’autre et le navigateur attend que le dernier soit chargé avant de poursuivre le chargement de toutes les autres ressources de la page !


http://media.tumblr.com/tumblr_lx0opqPGnp1qciej1.png

Tandis que la même page de test contenant une feuille de style unifiée a mis 1.95s a être intégralement chargée sur iPhone 4, soit près d’une seconde de différence pour une page de moins 2ko !

http://media.tumblr.com/tumblr_lx0oqt5MH01qciej1.png

Le test : http://blog.goetter.fr/post/15024485059/requetes-parallelisation-et-mobiles
Modifié par Raphael (19 Mar 2012 - 13:28)