Après un premier aticle rédigé en 2010 et qui portait sur le portage d’un site sur mobile, puis un second sur les best practices de conception, voici une to do list centrée autour d’un aspect essentiel des sites mobiles : la rapidité !
64% des utilisateurs de smartphones attendent des sites qu’ils s’affichent en moins de 4 secondes. Etes-vous surpris ? Mieux encore, les gens s’attendent à ce que les sites s’affichent au moins aussi rapidement sur leurs appareils mobiles que sur leurs ordinateurs de bureau.
Comme vous le savez sans doute, environ 80% du temps nécessaire pour afficher une page web est partagé entre le traitement côté client et le chargement des ressources telles que des feuilles de style, les fichiers de script et les images. Ainsi, les trois principales stratégies pour améliorer les performances – pour les visiteurs à la fois de bureau et mobiles – sont les suivantes :
- Réduire le nombre de requêtes HTTP nécessaires pour aller chercher les ressources pour chaque page.
- Réduire la taille de la charge utile nécessaire pour satisfaire chaque demande.
- Optimiser les priorités de traitement côté client et l’efficacité de l’exécution du script.
Comme vous le savez sans doute aussi, les utilisateurs mobiles sont confrontés à des problématiques de performance quand il s’agit de mettre en œuvre les stratégies ci-dessus. Ces défis comprennent:
- Des réseaux plus lents (ce qui explique pourquoi la réduction des demandes et la charge utile est importante)
- Des navigateurs mobiles plus lents à analyser HTML et plus lents à exécuter JavaScript (l’optimisation du le traitement côté client est cruciale)
- Une taille de mémoire cache beaucoup plus petite que celle des navigateurs de bureau (nécessitant de nouvelles approches s’appuyant sur un stockage local des ressources réutilisables)
Il existe un certain nombre de tactiques fondamentales et avancées que vous pouvez utiliser pour relever ces défis. En voici les principaux. Iils sont décrits de manière plus précises dans le livre blanc de Strangeloop sur l’optimisation des sites Web mobiles.
Réduire les requêtes
1. Consolider les ressources
Aujourd’hui, il s’agit d’une pratique courante, donc je ne vais pas l’expliquer ici, mais je tiens à souligner que la consolidation des ressources peut être une arme à double tranchant pour les navigateurs mobiles. Réduire les demandes accélère le chargement de la page lors du premier appel, mais leur mise en cache n’est pas aussi efficace. Donc, si vous utilisez cette technique, assurez-vous de mettre en balance avec les techniques pour optimiser le stockage local (voir ci-après).
2. Utiliser la mise en cache du navigateur et le stockage en local
La mise en cache est une technique essentielle pour obtenir des performances acceptables, mais les caches des PC de bureau et des mobiles ne sont pas identiques. En effet, les caches des navigateurs mobiles sont généralement beaucoup plus réduits que sur les machines de bureau, ce qui envoie les données plus rapidement. Le cache du navigateur traditionnel ne fonctionne pas bien pour les appareils mobiles. Heureusement, la spécification HTML5 Web Storage, qui a été mis en œuvre dans tous les navigateurs de bureau et mobiles, offre une excellente alternative pour la mise en cache par le navigateur.
3. Intégrer les ressources au format HTML pour la première utilisation
Si une ressource n’a pas une forte probabilité d’être déjà en cache (comme dans un contexte mobile), il est souvent préférable d’intégrer cette ressource en HTML de la page – une technique appelée «inline» – plutôt que de la stocker en externe avec le lien ad hoc.
L’inconvénient de l’inlining est que le poids de page peut devenir élevé. Il est donc essentiel pour une application web qui utilise cette stratégie d’identifier si la ressource est nécessaire et si elle est déjà mise en cache sur le poste client. Par ailleurs, la demande doit générer un code pour stocker la ressource sur le client alors du premier envoi de ce inline. C’dest pourquoi l’utilisation de HTML5 localStorage sur les appareils mobiles (tel que décrit ci-dessus) est une excellente option pour l’inlining.
4. Utilisez les événements HTML5 serveur
L’objet HTML5 EventSource et les événements Server-Sent permettent au code JavaScript dans le navigateur donnent un accès beaucoup plus efficace depuis le serveur vers le navigateur, que le serveur utilise pour envoyer des données dès qu’elles sont disponibles, ce qui élimine la surcharge HTTP de la création de requêtes multiples.
5. Éliminer les redirections
Lorsque les utilisateurs tentent d’accéder à un site standard à partir d’un appareil mobile, cela génère souvent un aller-retour supplémentaire vers le client et vers le site mobile, consommant plusieurs centaines de millisecondes sur les réseaux mobiles. Pour des raisons évidentes, il est plus rapide de livrer la page Web mobile directement en réponse à la demande initiale, plutôt que de délivrer un message de redirection qui appelle ensuite la page mobile. Et par courtoisie pour les utilisateurs qui préfèrent voir le site du bureau sur leur appareil mobile, vous pouvez fournir un lien sur le site mobile qui propose de supprimer ce comportement.
Réduire les charges
6. Compression et minimisation
La compression et la minimisation sont les meilleures pratiques de base. Les techniques de compression comme gzip réduisent les charges utiles. Les réponses qui incluent des textes, y compris HTML, XML, JSON, Javascript et CSS, peuvent être réduits à hauteur de 70%. La minimisation, qui est habituellement appliquée uniquement aux scripts et feuilles de style, élimine les caractères non essentiels tels que les espaces, les caractères de nouvelle ligne, et les commentaires. les fichiers minimisés sont réduits d’environ 20% en moyenne.
La minimisation réduit non seulement la consommation de bande passante et de latence, mais elle peut aussi faire la différence entre un objet mis en cache et qui est trop grand pour la mémoire cache sur un périphérique mobile particulier. La compression Gzip n’est d’aucun secours à cet égard, car les objets ne sont pas mis en cache par le navigateur tant qu’ils n’ont pas été décompressés.
7. Redimensionner des images
Les images sont une des principales causes de perte de performance. Sur les appareils mobiles, les images haute résolution occasionnent un gaspillage massif de la bande passante, le temps de traitement, et l’espace du cache. Pour accélérer le rendu des pages et réduire la bande passante et la consommation de mémoire, redimensionnez dynamiquement les images dans votre application, ou remplacez les images avec des versions plus petites pour les sites mobiles. Ne perdez pas de bande passante en comptant sur le navigateur pour adapter une image haute résolution en largeur et en hauteur.
Une autre option consiste à charger initialement une version très basse résolution d’une image pour obtenir la page aussi vite que possible, puis la remplacer par une version haute résolution sur le onload ou le ready event, après une première inreaction de l’utilisateur.
8. Simplifiez les pages avec le HTML5 et les CSS 3.0
La spécification HTML5 comprend de nouveaux éléments structurels, tels que les en-tête, nav, article, et pied de page. L’utilisation de ces éléments sémantiques rend une page plus simple et plus efficace que quand elle est constituée de div imbriquées et de balises span. Une page simple est plus petite et plus rapide à charger et un DOM plus simple signifie une exécution plus rapide du JavaScript. Les nouvelles balises sont rapidement adoptées dans les nouvelles versions des navigateurs, y compris les navigateurs mobiles. Maximiliano Firtman a créé un excellent tableau qui montre les fonctionnalités HTML5 prises en charge par les ordinateurs de bureau et les navigateurs mobiles .
De même, de nouvelles fonctionnalités CSS 3.0 peuvent aider à créer des pages légères en fournissant un support intégré pour des éléments comme des dégradés, des bordures arrondies, des ombres, des animations, des transitions et autres effets graphiques qui nécessitaient auparavant de charger les images.
Optimiser le traitement côté client
9. Différer le rendu HTML
Sur les appareils mobiles, charger et afficher une page avec beaucoup de HTML peut être plus lent que charge le HTML en premier puis ensuite le rendu. Une approche consiste à entourer le code HTML dans une balise de commentaire, puis d’utiliser JavaScript pour supprimer le commentaire, chargez le DOM, et rendre la page.
Vous pouvez également veiller à ce que l’utilisateur voit la page plus rapidement en retardant le chargement et tout contenu qui est « en dessous du pli » de la zone initialement visible. Afin d’éliminer la nécessité de repositionner le contenu après le chargement du reste de la page, remplacez les images avec un espace réservé qui spécifie la bonne hauteur et la largeur.
10. Différer le chargement et l’exécution de scripts
L’analyse du JavaScript peut prendre jusqu’à 100 millisecondes par Ko de code sur certains appareils mobiles. Beaucoup de bibliothèques de scripts (tels que les scripts qui prennent en charge les interaction avec les utilisateurs, comme par exemple glisser-déposer) ne sont nécessaires qu’une fois le rendu terminé. Le téléchargement et l’analyse de ces scripts peuvent donc être reportés après l’événement onload. La même logique s’applique à l’exécution du script : Reporter autant que possible après onload.
Le script de report peut être à votre propre initiative, ou être exécuté par des tiers. Les scripts mal optimisés pour les publicités, les widgets sociaux ou les analytics peuvent bloquer une page de rendu, et ajouter parfois de précieuses secondes au chargement de la page. Vous aurez également besoin d’évaluer soigneusement l’utilisation des bibliothèques de script comme jQuery pour les sites mobiles, surtout si vous utilisaez uniquement quelques objets du framework.
11. Utiliser Ajax pour l’amélioration progressive
JavaScript asynchrone avec XML (AJAX) est une technique pour utiliser l’objet XMLHttpRequest et récupérer les données à partir d’un serveur web sans rafraîchir la page où le code est exécuté. AJAX permet à une page d’afficher les données mises à jour dans une section d’une page sans reconstruire la totalité de la page. Cela peut permettre à votre application de charger une version dépouillée d’une page rapidement, puis de remplir le contenu détaillé lorsque l’utilisateur visualise la page.
L’AJAX est également une des techniques d’optimisation recommandées pour les réponses standard: en-têtes de cache, compression gzip, minification, la consolidation des ressources, etc
12. Mettre en œuvre un préchargement intelligent qui s’adapte au type de connexion réseau
Certaines techniques ne doivent être utilisées que combinées avec du code pour détecter le type de connexion mobile. Par exemple, le préchargement des ressources en prévision de futures demandes est intelligent, mais il ne peut être mis en oeuvre que si (1) la bande passante de l’utilisateur est mesurée et (2) qu’une partie de ces ressources peuvent s’avérer inutiles.
Sur Android 2.2 +, la propriété navigator.connection.type retourne des valeurs qui vous permettent de faire la différence WiFi à partir de 2G/3G/4G connexions. Sur le Blackberry, vous pouvez vérifier la valeur de blackberry.network pour obtenir des informations similaires. En outre, la détection côté serveur des données d’en-tête User-Agent ou toute autre information intégrée dans les demandes peuvent alerter votre demande le type de connexion utilisé.
13. Utilisez Web Workers HTML5 pour le multi-threading
La spécification Web Worker en HTML5 introduit une exécution multi-thread concurrente dans le monde de la programmation JavaScript. Pour améliorer la performance des sites mobiles, le code Web Worker peut être utile pour le préchargement de ressources qu’un utilisateur est susceptible d’avoir besoin de compléter les actions futures, en particulier lorsque la bande passante de l’utilisateur n’est pas mesurée. En utilisant le code multithread qui utilise des objets Web Workers (et peut-être localStorage pour mettre en cache les données), les opérations qui préchargent des ressources peuvent s’exécuter sur un flux séparé sans affecter les performances de l’interface utilisateur.
14. Remplacer les événements OnClick avec des événements tactiles
Sur les appareils à écran tactile, l’événement onclick ne se déclenche pas immédiatement quand un utilisateur appuie sur l’écran. Au lieu de cela, l’appareil attend jusqu’à une demi-seconde (300 millisecondes sur la plupart des appareils), donnant à l’utilisateur la possibilité de lancer une autre geste au lieu d’un simple clic. Ce retard peut entraver de manière significative la performance réactive que les utilisateurs attendent. Pour résoudre ce problème, préférez l’événement touchEnd. Cet événement se déclenche immédiatement lorsque l’utilisateur appuie sur l’écran.
Vous pouvez toujours vouloir gérer l’événement onclick pour vous assurer que le navigateur modifie l’apparence du bouton pour afficher un état cliqué, et pour supporter les navigateurs qui ne gèrent pas les événements tactiles. Pour éviter l’exécution de code en double sur les événements touchEnd et onclick, ajoutez un gestionnaire d’événements Click qui appelle preventDefault et stopPropagation si le clic est le résultat d’une action de l’utilisateur qui a déjà été traitée par touchEnd.
15. Prendre en charge le protocole SPDY
Parmi les goulots d’étranglement qui affectent les sites Web, qu’ils soient de bureau ou portable, on note l’inefficacité de la couche applicative des protocoles HTTP et HTTPS. En 2009, Google a commencé à travailler sur un protocole alternatif nommé SPDY qui aborde certaines de ces limitations. Comme les serveurs Web mettent en œuvre SPDY, votre site sera en mesure d’utiliser ce protocole pour tout utilisateur disposant d’un navigateur qui le supporte. Google SPDY rapports d’essais des améliorations entre 27% et 60%.
Comme je l’ai mentionné ci-dessus, il s’agit d’un joli aperçu de haut niveau de ces stratégies mobiles amplifiantes. Si vous êtes à la recherche pour plus de fond, ainsi que comment faire renseignements, consultez le livre blanc de Strangeloop.
Source