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 :

• Le testeur de temps d’affichage mobile de Blaze.io (société privée),
• Google PageSpeed Mobile en ligne (voir onglet “mobile”),
• Le Validateur mobileOK du W3C.

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).

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.

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 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é ?