Webdesign Friday (#wdfr) - La communauté des webdesigners francophones

Les vendredis Webdesign !Chaque semaine, un nouvel article par un professionnel du Web.

Introduction à la performance pour le Web mobile

Introduction à la performance pour le Web mobile

Préambule : le “Web mobile” n’existe pas. Il n’y a qu’un seul Web et il ne change pas de visage selon votre périphérique de connexion. Le terme de “Web mobile” demeure cependant relativement parlant pour évoquer “le Web en situation de mobilité”, c’est pourquoi je me permets de l’employer au cours de cet article.

Notre génération a jusque là été habituée à une évolution du Web prévisible et contrôlable : des écrans de bureau de plus en plus larges et des types de réseaux et connexions internet de plus en plus rapides.

La démocratisation des périphériques mobiles (smartphones, tablettes et consorts) introduit de nouvelles contraintes et un inversement brutal de la tendance : les écrans deviennent subitement minuscules, et la connectivité en pâtit aussi : au mieux, votre mobile bénéficiera d’un réseau Wi-Fi, au pire… de rien du tout. En passant par les stades 3G et Edge / UTMS.

En résumé, plus le marché mobile explose, plus nous – concepteurs Web – devront intégrer des contraintes inédites de “responsive web design” et de “performance web mobile”.

Selon Google, 6 personnes sur 10 quittent irrémédiablement un site web qui n’a pas été “optimisé pour le mobile” en terme de rapidité d’affichage, et il est vivement déconseillé de dépasser des temps de chargement de plus de 4 secondes pour vos pages si vous souhaitez conserver vos clients “mobinautes”.

La notion de performance web

La performance web, c’est à dire tenir compte de tous les possibilités permettant d’accélérer le temps de chargement d’une page web, est devenu une évidence incontournable dans le domaine du Web mobile.

Ces possibilités sont nombreuses et variées et l’objet de cet article est d’en dévoiler quelques unes.

Entendons-nous bien, il ne s’agit pas ici d’entrer dans les méandres techniques de chaque solution – un livre entier serait nécessaire – mais de se limiter à une introduction superficielle, à un recueil de bonnes pratiques générales.

Comme tous les conseils, certains sont bons à prendre, d’autres ne vous concerneront peut-être pas et d’autres encore seront à prendre avec des pincettes, voire être contre-productifs en fonction de votre architecture déjà en place.

En guise d’introduction, je vous invite à commencer par tester vos pages web sur les outils dédiés en ligne suivants :

Steve Souders, gourou de la performance web, a conclu que plus de 80% du temps passé par le navigateur à charger une page dépend du côté “front-end”. C’est donc sur ce point que nous allons nous concentrer prioritairement (même si l’aspect serveur, telle que la mise en cache, ne doit pas être délaissé pour autant).

golden-waterfall

Répartition des temps de traitement navigateur entre front et back

media queries et performances sont sur un bateau…

Les media queries CSS3 et plus généralement la philosophie “responsive web design” forment un ensemble de techniques permettant d’adapter rapidement un design existant sur plateformes mobiles.

Le principe étant de modifier instantanément les styles CSS, donc de réorganiser la page ou de masquer des éléments superflus, dès lors que des critères de largeur d’écran sont respectés.

Voici un exemple d’application classique des media queries :

body { background: url(concombre_big.jpg); }
@media (max-width : 640px) {
 body { background: url(concombre_small.jpg); }
}

Et là, vous êtes déjà à côté de la plaque !

En effet, un navigateur mobile respecte les deux conditions à la fois (les styles globaux et ceux pour écrans de moins de 640px), il va donc en toute logique d’abord charger l’image… puis la masquer.
En terme de performances, c’est exactement le type de comportement à éviter à tout prix.

L’une des solutions réside dans l’usage de media queries exclusifs, par exemple :

@media (min-width : 641px) {
 /* styles pour grands écrans */
}
@media (max-width : 640px) {
 /* styles pour petits écrans */
}

Mais on se heurte immédiatement à un nouveau problème de taille : les navigateurs qui ne reconnaissent pas les media queries (notamment IE6 / IE8) ne bénéficieront d’aucun style CSS. La page s’affichera au format HTML brut.

Là encore, les solutions existent, et là encore elles sont multiples et aucune n’est parfaite. Certaines emploient des commentaires conditionnels pour pallier aux déficiences d’Internet Explorer, d’autres se basent sur des alternatives JavaScript telles que Respond qui émule les media queries sur les anciennes versions d’Internet Explorer.

Une solution intermédiaire qui me séduit de plus en plus est de distinguer 3 parties dans le fichier CSS :

  1. les styles de base, qui doivent être affichés sur tous les supports même déficients
  2.  les ressources lourdes, qui doivent être chargées uniquement sur écrans larges
  3.  les styles et adaptations spécifiques pour petits écrans

Grâce aux classes conditionnelles, nous pourrons également faire profiter de cette méthode les anciennes versions d’Internet Explorer sans douleur.

Voici un exemple concret :

/* styles pour tous */
body {width: 960px; background: #fff;}
/* ressources lourdes uniquement */
@media (min-width : 641px) {
 body { background: url(concombre_big.jpg); }
}
/* ressources lourdes aussi pour IE6-IE8 */
.oldie body { background: url(concombre_big.jpg); }
/* styles pour petits écrans */
@media (max-width : 640px) {
 body { width: auto; background: url(concombre_small.jpg); }
}

Cette méthode a actuellement ma préférence car ne nécessite pas de fichier CSS (donc de requête) supplémentaire, ni d’alternative et de traitement via JavaScript.

Quelle que soit la technique adoptée, l’essentiel reste – de loin – d’éviter de charger de multiples ressources pour rien si vous les masquez sur mobile.

C’est bien mais… ce n’est pas suffisant

Une fois que cette première grosse épine du pied retirée, ne croyez pas sorti d’affaire pour autant car bien évidemment, d’autres points importants sont à prendre en considération dans la quête d’un affichage le plus rapide possible sur mobile.

À travers cette introduction, je vous propose de parcourir cinq axes déterminants de la performance web mobile du côté du navigateur :

  1. Quelques généralités
  2. Réduire les requêtes,
  3. Minifier / compresser,
  4. Ne charger que le nécessaire,
  5. Profiter des technologies modernes.

Quelques généralités

Quelques principes de base, issus des études de performances classiques de bureau sont évidemment applicables dans le monde du Web mobile, en voici certains :

  • Placez les appels de styles CSS au début (dans l’élément <head>) et les scripts (JavaScript, jQuery) en bas de document (avant </body>).
    Ceci pour faciliter les temps de traitement du navigateur.
  • Utilisez tant que possible des sélecteurs CSS “performants”.
    Cela signifie qu’il est préférable d’éviter le sélecteur universel *, de même que les expressions comme div#toto au profit de #toto, ou nav ul li a à remplacer par nav a par exemple,
  • Hébergez les ressources (images, médias) sur plusieurs domaines différents.
    Cette technique favorise leur téléchargement en parallèle. Un sous-domaine fonctionne aussi (ex. media.alsacreations.com), et un domaine sans cookies est encore plus performant.
  • N’utilisez pas @import.
    Car cette méthode empêche la parallélisation des fichiers CSS (sauf cas particuliers et si maîtrisé)
  • Chargez vos ressources en asynchrone et/ou différé.
    HTML5 propose les attributs async (asynchrone : le script est chargé dès que possible, quel que soit l’ordre d’apparition dans le HTML) et defer (différé : le script est exécuté à la fin du chargement de la page)
    Voici un exemple :

    <script type="text/javascript" src="/scripts/slideshow.js" defer></script>

Réduire les requêtes

Les requêtes HTTP sont le cauchemar des périphériques mobiles. Chaque requête, aussi minime soit-elle, est coûteuse en temps de connexion et l’on ne sait que trop bien qu’une connexion nomade est très fragile et précieuse.

De plus, certains appareils ont la fâcheuse tendance à ne pas permettre les téléchargements parallèles : ils attendent la fin du chargement d’une ressource pour entamer la suivante.

Débusquer les requêtes inutiles est devenu le lot de tout intégrateur sur mobiles. Voici quelques pistes à suivre sur ce thème :

  • Une feuille de styles unique.
    Faire plusieurs appels de feuilles de styles est coûteux en performance (surtout sur iOS et Internet Explorer qui ne parallélisent pas leur chargement), il est vivement conseillé d’essayer d’unifier les styles dans un minimum de fichiers.
    Le Saint-Graal se présente sous la forme d’un fichier unique comme nous l’avons détaillé dans la partie précédente.
  • Réunissez les images d’illustration en une seule ou aucune.
    C’est le concept des sprites CSS et des images encodées en Data URI / base 64.
    De nombreux générateurs “Sprites / Data URI” sont disponibles, le plus séduisant et intuitif actuellement est : http://draeton.github.com/stitches/.
  • Pensez aux caractères spéciaux pour certains symboles ou pictogrammes.
    Saviez-vous que même les polices de caractères classiques (dites “websafe”) contiennent un très grand nombre de caractères spéciaux mal connus, sous réserve que vous serviez votre page web en encodage unicode UTF-8 ?
    La technique est décrite ici : http://ikwebdesigner.com/special-characters/
  • Essayez d’unifier les scripts dans un minimum de fichiers.
    Il existe d’excellents outils pour cela, tels que Google Minify.
  • Séparez les scripts de base (indispensables) des autres.
    Vous pourrez ainsi plus aisément ensuite choisir de ne pas charger les fichiers non essentiels.
    Par exemple :

    <script type="text/javascript" src="/scripts/essentiel.js"></script>
    <script type="text/javascript" src="/scripts/plein_de_scripts.js"></script>
    

Minifier / Compresser

Le poids des ressources à télécharger (fichiers, fontes, images, documents), est un élément à surveiller constamment. Pour chaque type de fichier, il existe des outils permettant de réduire le surpoids:

  • Minifiez les styles CSS.
    De nombreuses parties de vos styles CSS sont parfaitement inutiles, donc pesantes pour le navigateur : les espaces, les retours à la ligne, les commentaires, etc. Les outils en ligne tels que YUI compressor, CleanCSS ou CSScompressor suppriment toutes des lourdeurs et permettent de réduire le poids d’une feuille de style de parfois plus de 30%.
  • Compresser fichiers externes.
    JavaScript, mais aussi fichiers de fontes (par exemple privilégiez .woff qui est mieux compressé que d’autres formats de police pour le même rendu) peuvent également être compressés.
  • Compresser les images du site.
    Un certain nombre d’outils optimisent le traitement de compression de vos images. Les plus performants (ImageOptim, Smushit, jpegmini, PNGGauntlet) sont capables de vous faire économiser plusieurs centaines de Ko sans perte de données visuelle.

Ne charger que le nécessaire

Même optimisées, compressées et triturées au maximum, certaines ressources demeureront toujours excessives à charger. C’est le moment de se demander si toutes ces ressources sont bien nécessaires sur un périphérique mobile et s’il n’était pas plus pertinent de ne les proposer que lorsque l’internaute dispose de meilleures conditions.

Voici quelques conseils pour éviter de surcharger les mobiles et tablettes de médias et éléments inutiles :

  • Ne chargez certaines images que sous condition (largeur d’écran).
    Voici un exemple de script permettant de remplacer les images de classe “kiwi” par leur équivalent en grande taille uniquement si la taille de l’écran est supérieure à 640px (par ex: image_small.jpg devient image_big.jpg) :

    if(screen.width>640) {
       var img_list = document.getElementsByTagName('img');
       var i = 0;
       while (element = img_list[i++]) {
          if (element.className == 'kiwi') {
             var url = element.src;
             var posUrl = url.lastIndexOf('_');
             var preUrl = url.substring(0,(posUrl+1));
             var newUrl = preUrl+'big.jpg';
             element.src = newUrl;
          }
       }
    }
  • Ne chargez certain scripts gourmands que sous certaines conditions (largeur d’écran).
    L’exemple suivant permet de charger slideshow.js que si la taille d’écran est supérieure à 640px :

    if(screen.width>640) {
       var bigjs = document.createElement('script');
       bigjs.src = 'slideshow.js';
       bigjs.type = 'text/javascript';
       document.getElementsByTagName('body')[0].appendChild(bigjs);
    }
    
  • Employez les Mediaqueries pour la vidéo et le son.
    C’est peu connu (car encore peu supporté par les navigateurs), mais il est parfaitement possible de tirer profit des media queries pour offrir un chargement intelligent des fichiers vidéos et audio :

    <video>
       <source src="une_video_mini.mp4" type="video/mp4" media="(max-device-width:640px)">
       <source src="une_video.mp4" type="video/mp4" media="(min-device-width:641px)">
    </video>
    
  • Évitez des frameworks tels que jQuery, jQuery Mobile, jQuery UI si inutiles.
    Un bon nombre de sites web incluent des librairies telles que jQuery par défaut, sans forcément s’en servir, ou pour des usages basiques tels que le ciblage de sélecteurs.
    Sachez que ces ressources ne sont pas négligeables à charger et traiter et qu’elles ne sont pas toujours aussi indispensables qu’on ne le croit.
    Deux outils peuvent peut-être les remplacer avantageusement : Sizzle, qui reprend les sélecteurs jQuery, et jquip.js (jquery in parts) qui ne pèse que 6.6ko et qui couvre 90% des fonctions de jQuery.

Profiter des technologies modernes

Le monde du Web mobile, malgré son extraordinaire pluralité n’en demeure pas moins séduisant : la technologie évolue, les processeurs sont de plus en plus performants, les navigateurs sont souvent à la pointe du progrès. Bref, les possibilités offertes dépassent de loin celles proposées par un bon nombre de navigateurs de bureau (qui a dit IE6 ?).

Il ne faut pas hésiter à exploiter toutes les technologies d’avant-garde déployées par le W3C :

  • Privilégiez CSS3 autant que possible plutôt que d’autres technologies.
    Certains test démontrent que JavaScript est dix fois plus long à être interprété sur smartphone que sur ordinateur classique. C’est sûrement le moment de se mettre à CSS3, plus performant que JavaScript pour les effets graphiques et le confort (animations, scrolls, slideshows, etc.)
  • Privilégiez HTML5 en général.
    Pour de multiples raisons : doctype plus court (donc quelques octets de gagnés au chargement), géolocalisation, web offline, gestion du cache, mais aussi pour l’ergonomie et les champs <input> de type email, url, search, number, tel, etc.

Conclusion

En guise de conclusion, je pouvais difficilement me soustraire à l’exercice de soumettre mon site web personnel à l’ensemble des conseils que j’ai pu livrer dans ce billet.

Raphaël Goetter

Goetter.fr - Site de Raphaël Goetter

J’ai donc passé au crible goetter.fr et voici les conclusions que j’ai pu en tirer :

  • Non optimisé, le poids de la page d’accueil approchait les 400ko et un temps de chargement de 4 secondes sur mobile,
  • Après quelques modifications et environ une demi-journée de travail, je suis parvenu à un poids de 100ko et moins de 2 secondes de chargement. Soit un temps d’affichage divisé par plus de 2 et un poids total divisé par 4,
  • Le score de Google Page Speed online est passé de 77/100 à 97/100,
  • Les progrès les plus flagrants ont été constatés après les actions suivantes : unification des styles CSS (1 seul fichier), chargement de l’image de fond et des scripts superflus uniquement sur grand écran,
  • Contrairement à mes prévisions, la compression de toutes les images n’a eu qu’un effet assez négligeable.
Temps de chargement de goetter.fr sur mobile

Temps de chargement de goetter.fr sur mobile après optimisation

Et vous ? Avez-vous fait vos tests de performance ? Avez-vous d’autres techniques pour accélérer l’affichage des pages en situation de mobilité ?

A propos de l'auteur : Raphaël Goetter

Appartient à la grande famille des webmasters du dimanche. Créateur et administrateur du site Alsacreations.com, communauté libre d'apprentissage web spécialisée dans les standards. Expert et Formateur en langages HTML et CSS. Auteur de divers livres techniques chez Eyrolles: "CSS avancées, vers HTML5 et CSS3", "CSS2, Pratique du design web", et des Mementos XHTML, CSS2 et CSS3.

  • http://twitter.com/L_Demontiers Laurent DEMONTIERS

    Excellent article,complet, clair et très bien documenté. Merci pour ce partage d’expérience.

  • noclat

    Merci beaucoup pour cet excellent article plein d’astuces et de ressources ! Par contre j’ai quelques questions sur l’optimisation des sélecteurs CSS :
    • J’avais lu (pas de source, pardon) que div#toto était mieux que #toto tout court, car l’interpréteur ne scannera pas tous les éléments à la recherche de #toto, mais uniquement les div. Qui croire ?
    • “nav a” est indéniablement mieux que “nav ul li a”, mais est-il préférable à “nav > ul > li > a” ?

  • http://twitter.com/walterstephanie Stéphanie Walter

    Excellent article merci :) C’est vrai qu’on ne pense pas assez souvent aux caractères spéciaux des polices websafe, ça peut éviter de charger une image, jolie astuce.
    Je me permet de compléter sur jQueryMobile, ayant eut à optimiser une application HTML5 phonegap pour BlackBerry avec. C’est vrai que jQueryMobile est “gros” et en plus il faut charger jQuery, mais j’ai récemment découvert qu’on pouvait télécharger uniquement certains composants de l’UI en passant par github https://github.com/jquery/jquery-mobile/tree/master/js . Ça peut-être une solution intéressant si on ne veut utiliser que certaines parties du framework. L’exemple typique ici c’est les transitions, si on en utilise qu’une, autant ne pas charger les autres. Il en va de même pour la feuille de style de jQueryMobile qui vient avec les 5 sets de couleur, on peut très bien éliminer les déclarations dont on a pas besoin (perso le set tout jaune je ne l’utilise pas), ce qui permet des gains, certes minimes, mais c’est déjà pas mal. Une solution que nous avons également testé était de mettre toutes les pages de notre application dans un fichier HTML, jQueryMobile utilise ensuite un système d’ancres pour naviguer entre les “pages” du document. Une perte légère de temps au chargement de l’application MAIS une fluidité ensuite non négligeable entre les pages.
    Ça demande plus de boulot en amont, mais ça vaut le coup niveau gains.

  • http://twitter.com/STPo Christophe Andrieu

    Chouette article.

    Je trouve pour ma part un peu alarmiste le foin qu’on fait autour des libs JS “trop lourdes” pour le mobile : jQuery bien minifié et tout par exemple, ça pèse 24Ko : c’est l’équivalent en poids et en requête d’une petite image et si c’est appelé sur un CDN genre Google c’est possiblement déjà en cache et ça coûte rien. J’ai vraiment du mal à considérer prioritaire de s’en passer, bien coder son JS maison derrière me semble déjà largement plus pertinent…

    Sinon tant que j’y suis le script pour charger les grosses images en fonction du viewport c’est quand même dommage parce que ça fait charger deux fois l’image, il existe des solutions côté serveur moins coûteuses non ?

  • Felipe

    1/ #toto est préférable à div#toto parce que le navigateur regarde d’abord dans les identifiants s’il le trouve puis si le reste du sélecteur colle aussi. Lui éviter d’avoir à vérifier si c’est bien un div et pas un ul ou autre est un gain de temps.

    2/ Je pense que le plus court est le mieux (je crois avoir lu que > était un gain de perf mais pas si énorme que ça. Enlever 2 éléments du sélecteur devrait être un bien plus gros gain de temps).

    Sinon en général, la perf des sélecteurs CSS est d’une priorité bien plus basse que d’optimiser le poids des images et le nombre de hits sur le serveur.

  • goetter

    Christophe : pour les solutions côté serveur moins coûteuses, oui bien sûr il y en a.
    Comme annoncé je me suis volontairement limité aux actions à mener du côté client et comme annoncé il ne s’agit que d’une introduction : chaque “conseil” mériterait d’être détaillé, soupesé et comparé à d’autres… mais ça mériterait un livre entier sur le sujet ;)

    Pour jQuery et autres lourdeurs, j’ai simplementé écrit de les éviter… si inutiles. C’est pas un bon conseil ? :p

  • noclat

    Merci pour ces précisions !

  • http://www.screenfeed.fr/blog/ Screenfeed

    Super article, merci Raphaël.

    Il y a cependant quelques points que je trouve étranges, ou ayant des inconvénients :

    1- “Ne chargez certaines images que sous condition” : 2 inconvénients, grand écran + pas de JS (bon c’est sûr, au bout d’un moment il faut arrêter de se focaliser sur le no-js et aller de l’avant, après tout on fait de la magie, pas des miracles xD). Il faudrait également rajouter un event sur le redimensionnement de la fenêtre car le script est exécuté seulement au chargement de la page (enfin il me semble, à voir le code, je me trompe peut-être), et prévoir l’effet inverse.

    2- “Ne chargez certain scripts gourmands que sous certaines conditions” : voir dernier point de mon 1.

    3- HTML5 : doctype plus court pour économiser quelques octets. Sérieux? OK on économise une centaine de caractères mais quand même, je pense que le gain est insignifiant (ça dépend du poids total de la page tu me diras ^^).

    Je suis tout à fait d’accord pour le CSS3 (il faut tout de même faire gaffe à ne pas trop en faire, trop de transitions/animations peuvent mener à une consommation égale au flash). De plus, utiliser du CSS3 évite de surcharger le dom en créant des balises supplémentaires inutiles, etc., qui au final vont alourdir la page. Méfiance encore, certaines propriétés CSS3 peuvent avoir un effet néfaste sur les perfs : j’ai lu je ne sais plus où un test où des box-shadow très larges (blur ou spread importants) ralentissaient le scroll de la page par exemple ou les transitions. Je pense donc que c’est une histoire de compromis.

    Encore merci pour cet article instructif :)
    Greg

  • http://twitter.com/_Stephane_ Stéphane Castrec

    Merci pour l’article.
    Vraiment bien.
    J’espère pouvoir suivre ces conseils avec GWT.

    twitter: @_stephane_

  • http://twitter.com/_Stephane_ Stéphane Castrec

    Merci. Un très bon article vraiment intéressant.
    J’espère pouvoir suivre au maximum ces conseils avec GWT.

  • goetter

    Merci pour le retour.
    Tu as également raison, comme d’autres, mais je ne peux que répéter qu’on ne peut pas faire un article d’introduction sans rester parfois trop superficiel voire éluder certains aspects.
    Ce que tu dis est vrai… mais nécessiterait bien plus qu’un simple article.

  • Nico

    De sages conseils que voilà ! :)

    Quelques confirmations :
    - pour les navigateurs mobiles, ne pas inclure certains javascripts non indispensables comme jQuery apporte un réel plus en perfs, j’ai fait qq essais via détection de UA (oui c’est mal, mais faut bien démarrer quelque part) ou via chargement conditionnel comme tu l’as fait dans ton article, 
    - sans aller jusqu’à une approche mobile first complète, déjà virer tous les effets javascripts à la noix permet de bien calmer le jeu, au pire si le client râle sur ses sacro-saints effets, mettez-lui quelques transitions CSS, il sera tout content et vous lâchera les baskets… expérience vécue !
    - de manière générale, les versions mobiles sont à penser sans animations Javascript (si possible), car en général, même si le fichier est léger au chargement, l’effet rame pas mal sur certains smartphones un peu poussifs ! Ou alors faut des smartphones ou des tablettes assez pêchues point de vue perfs, l’ipad 2 est pas mal notamment.
    - sinon vivent les Data-URL pour les petites images type icônes CSS, pour peu qu’ils soient utilisés dans des CSS qui bénéficient de la compression GZIP ou Deflate et de la mise en cache, ça permet de bons gains !

    Quoi qu’il en soit, les conseils de base sont toujours incontournables : produire de la CSS très efficace, bien optimisée, avec des propriétés bien factorisées, le tout combiné à une structure bien légère, ça permet d’envisager l’avenir sereinement. Quand vous avez une CSS de 4ko non compressée pour la version desktop/petit écran/print… C’est que vous avez bien travaillé.

    Sinon, l’utilisation d’un cache manifest permet de stocker qq fichiers en local chez l’internaute (un genre de super cache), ça peut booster le rendu des pages (en tout cas, page speed online le conseille)

  • Pingback: mobile / tablet | Pearltrees

  • Pingback: Les acteurs du Web en ont parlé [#28] | Le blog des nouvelles technologies : Web, Technologies, Développement, Interopérabilité

  • Benoît Boucart

    Merci pour l’article! Très intéressant.

    Concernant jQuery: j’emploie celle de Google CDN (pour profiter du cache).

  • http://twitter.com/benoitboucart Benoît Boucart

    J’ai récemment regardé cette présentation très intéressante: http://www.paris-web.fr/2011/conferences/un-navigateur-comment-ca-marche.php

    Elle parle notamment de ne pas employer div#toto. Voir aussi: https://developer.mozilla.org/en/Writing_Efficient_CSS

  • http://twitter.com/benoitboucart Benoît Boucart

    Ah ça me rassure. J’ai également compris ta phrase comme “jQuery est tellement inutile!” :-)

  • http://www.screenfeed.fr/blog/ Screenfeed

    Oui bien sûr Goetter, je suis tout à fait d’accord, le sujet est tellement vaste que pour rentrer dans les détails il faudrait plus d’un article. Mon intervention avait que pour seuls buts de donner un avis personnel est justement, quelques petits détails supplémentaires aussi.
    Je me suis mis au responsive depuis peu de temps, donc ce genre d’article est toujours bon à lire pour moi.

    Une de tes remarques dans l’article m’a titillé, donc j’ai fait un petit test rapide. Il s’agit du passage où tu parle du “double background” vers le début :
    “En effet, un navigateur mobile respecte les deux conditions à la fois (les styles globaux et ceux pour écrans de moins de 640px), il va donc en toute logique d’abord charger l’image… puis la masquer.”

    J’ai donc tenté la chose avec Firefox et je n’arrive pas à la même conclusion : seul le dernier background est chargé. J’ai pu constater cela dans l’onglet “Réseau” de Firebug puis avec les plugins de “Page Speed” et “YSlow”. Les 3 me disent la même chose : le 1er background n’apparait pas dans les ressources chargées par le navigateur.
    Donc si ce que tu dis est juste je vois 2 possibilités :
    – Soit ces outils ne laissent pas apparaitre cette image car elle est remplacée par une autre plus tard.
    – Soit un navigateur mobile se comporte différemment et charge les 2 images quand même (ou bien c’est spécifique à Firefox ? Mais ça revient au même).

    Qu’en pense tu ? As tu pu constater toi même ce double chargement de fond et si oui, avec quel outil ?

    C’est un test que je voulais faire depuis longtemps mais comme il me semblait logique que seule la dernière image soit chargée, je n’ai jamais pris le temps de le réaliser jusqu’à aujourd’hui.

    A+
    Greg

    Nota : mes 2 déclarations sont dans la même feuille de style, l’une au début et l’autre à la fin.

  • goetter

    Il y a effectivement une grosse différence à faire entre les navigateurs de bureau et les mobiles.
    Il est de notoriété publique que les performances des navigateurs mobiles sont moindres.
    Par exemple, je viens de faire un test avec Blaze.io en simulant un Android 2.2 et le résultat montre bien que toutes les images sont chargées : http://www.blaze.io/mobile/result/?testid=120408_4A_5VE

    Mais ton intervention est très intéressante puisqu’en testant sur d’autres mobiles (iphone3, iphone4, android3), je remarque que ce problème de multiple chargement n’est plus présent.

    Cependant, je conseille tout de même de faire très attention, car on voit bien que tous les mobiles ne sont pas sur un pied d’égalité.

  • noclat

    Merci pour ces liens, très intéressant en effet =)

  • Flo

    Pour rebondir les perfs CSS, ce n’est pas la première fois que j’entends parler du manque de perf avec l’utilisation du sélecteur *.
    Connaissez-vous un site qui mesure cela ? Pour un puriste, ce sélecteur serait réellement à bannir ?
    Pour reprendre la demonstration de felipe, contrairement à div#toto, avec le selecteur * le navigateur n’a pas besoin de savoir de quel type de balise il s’agit, peu importe qui il rencontre il applique le style (ça c’est ma logique simpliste).

  • Spout

    Article très intéressant.
    Je voulais quelques précisions concernant la feuille de styles unique pour réduire les requêtes.
    J’utilise, pour ma part, un fichier PHP qui compresse mes feuilles de styles dans un fichier unique. cette méthode me permet de ne pas avoir ma CSS dans un seul fichier et donc de mieux segmenter mon code CSS.
    Cette technique a-t-elle un/des inconvenant(s).

    merci de votre aide.

  • Felipe

    Si j’ai bien compris, toi tu travailles avec plusieurs fichiers sur le serveur mais les navigateurs ne téléchargent qu’un seul fichier CSS qui est la concaténation de tous tes fichiers de travail ?

    L’important pour la performance est le nombre de requêtes alors avec une seule c’est nickel :) Et tu adoptes la méthode de travail qui te convient le mieux, ça n’a ici pas d’influence sur la perf côté client.
    Il existe de très rares exceptions, exemple si un pan de ton site nécessite à lui seul la moitié des CSS ; dans ce cas-là tu veux pas forcément faire télécharger ce gros morceau quand le visiteur arrive sur la page d’accueil. Et encore, faudrait que ça soit plus d’une dizaine de ko (au pif). Un cas plus courant ce sont les styles de l’administration du site. Les clients n’ont pas besoin de les charger, uniquement les admins et contributeurs.

  • Spout

    Voilà c’est ça. Pour précision, le fichier final est un php qui supprime aussi les espaces blanc, les commentaires et tout ce qui n’est pas très utile. ce qui permet de gagner encore quelques octets. mon appel dans l’html se fait ainsi :

    Après je suis contient que c’est une question d’organisation mais je trouve que c’est beaucoup plus simple à entretenir quand on a plusieurs fichiers CSS bien commenté. Je ne crois pas que les développeurs mettent tous leur JS ou PHP dans un seul fichier.

    vu que je trouve cette méthode plus intéressante que de mettre tous mon style dans un seul fichier CSS, je me demandais si en fait elle ne comportait pas des problèmes que je ne connaissais pas.

    merci pour ta réponse.

  • Pingback: [Dossier] Comment créer un site web moderne tourné vers le futur ? | Webcercle

  • Pingback: Vers des sites web performants - problématiques et solutions

  • Pingback: TP de janvier 2013 | Espace Formation de Kréaclic

  • Clémence.Izm

    Excellent article facile, didactique et concret, sans parler des commentaires qui complèmente la publication. J’aime! Merci!

  • wpdil

    Excellent article, its is very useful, Thanks for sharing. wpdil

Live Tweet

Dans le Blog

Newsletter

Vous souhaitez être tenu au courant des dernières nouvelles concernant le WDfriday, événements, conférences, barcamps, etc… ?

N'hésitez pas à vous inscrire à notre newsletter !