Améliorez la performance de vos interfaces mobiles avec RESS

Voilà près de deux ans que l’on vous parle de responsive design, cette technique permettant d’adapter la mise en page d’un site web en fonction du terminal utilisé. Largement documenté et utilisé par des sites à très large audience (Microsoft, Vogue, Time, Starbucks, ZDnet…), le RWD semble avoir conquis les développeurs d’interfaces mobiles. Il existe à ce sujet de nombreux frameworks pour accélérer vos développements comme HTML5 Boilerplate, Boostrap, Foundation, Gumby ou encore Gravity (cf. Five awesome open-source front-end frameworks).

Mais le responsive design n’est pas la solution parfaite, car cette technique repose sur l’affichage ou non de certains éléments dans la page. Le problème est que tous les éléments chargés sont les mêmes, les images et fichiers javascript sont ainsi chargés, mais complètement sous-exploités par les smartphones. De même, les éléments tiers (bannières publicitaires ou plugins sociaux) sont chargés inutilement ou intégrés à l’arrache. Vous l’aurez compris, la performance de ces interfaces est donc un gros problème. Or, le temps d’affichage est un facteur-clé de succès de premier ordre.

Heureusement pour améliorer les performances il est possible de ne charger que les éléments dont vous avez besoin, voire de charger des éléments spécifiquement adaptés à un type de terminal. Cette technique a un nom, et c’est Luke Wroblewski qui l’a trouvé le premier : RESS = Responsive Design + Server Side Components. L’astuce consiste donc à détecter le type de terminal et à charger les éléments qui lui correspondent (images, fichiers HTML et javascript…). Dans l’exemple ci-dessous, il existe deux versions du header et du footer sur le serveur (pour desktop et pour mobiles), seule la version correspondant au terminal utilisé est chargée :

Cette technique est donc l’évolution logique du responsive design, car elle permet d’optimiser les temps de chargement, aussi bien pour les fichiers HTML et javascript que pour les images. Des explications plus détaillées sont disponibles ici : RESS, Server-Side Feature-Detection and the Evolution of Responsive Web Design.

Il existe également de nombreuses présentations didactiques sur le sujet, notamment ici :

http://fr.slideshare.net/slideshow/embed_code/12944955?rel=0

Et ici :

http://prezi.com/embed/oatkfalylq7l/?bgcolor=ffffff&lock_to_path=1&autoplay=no&autohide_ctrls=0

Je vous invite à consulter également cette étude de cas sur le très beau site de l’université de Notre-Dame : Reinventing the Wheel, the Innovation Behind Notre Dame’s Unique New Homepage. Des sites à fort volume comme CNN ou WordPress ont déjà adopté RESS.

RESS est-il donc la solution ultime pour avoir des sites optimisés en fonction du terminal ? Oui, à condition que la détection fonctionne correctement. La détection du type de terminal est donc le talon d’Achille de cette technique. Pour en savoir plus, je vous recommande Server-Side Device Detection: History, Benefits And How-To.

Nous nous retrouvons donc avec trois options pour déployer du contenu ou un service en ligne :

• Un site unique en responsive design (qui n’utilise pas la détection, mais qui ne règle pas le problème de performances) ;
• Un site en RESS (bien optimisé, mais qui repose la détection) ;
• Une version mobile du site (très bien optimisé, mais qui repose également sur la détection).

Comme toujours, il n’y a pas de bon ou mauvais choix, uniquement des compromis à faire en fonction de vos ressources et compétences. Pour vous aider, je vous propose enfin ces deux articles qui étudient les avantages et inconvénients de ces trois solutions : Responsive Design, Device Experiences, or RESS? et A Comparison of Methods for Building Mobile-Optimized Websites.

Si vous avez des retours d’expérience, n’hésitez pas à les partager dans les commentaires.