Performances Web Mobile

  • 525 views
Uploaded on

Optimiser les performances de son site pour un affichage confortable sur mobile.

Optimiser les performances de son site pour un affichage confortable sur mobile.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
525
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
31
Comments
1
Likes
6

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Optimiser les performances de son site pour un affichage confortable sur mobile Willy Leloutre, intégrateur Webdimanche 23 septembre 2012
  • 2. Quels sont les enjeux La France est en 30e position, des pays où les connexions Internet sont les plus rapides. (Avec une moyenne de 4.9 mbit/s). Les connexions mobiles ont elles un débit moyen de 350 Ko/s avec des pointes à 1 Mo/s. (sources http://www.akamai.fr). Selon Google, lexpérience mobile est 1.5 fois plus lente que celle sur Desktop. La 4G devrait permettre d’atteindre des débits (nomades) plus raisonnables ! Début des travaux : 2014. Le trafic mobile représente désormais 10% du trafic web mondial. 880 millions de mobiles (Android / IOS ) sont arrivés sur le marché en un peu plus de cinq ans. (sources www.lukew.com). Les mobiles atteignent 87% de la population mondiale, cest plus répandu que nimporte quel autre média de masse. (sources www.lukew.com). État des lieux du trafic Internet : http://www.akamai.fr/enfr/stateoftheinternet/dimanche 23 septembre 2012
  • 3. Le front-end, cest du lourd ! 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". Notamment les images qui peuvent représenter plus de 50% du poids total des ressources à télécharger. images scripts rich media css font htmldimanche 23 septembre 2012
  • 4. Les erreurs courantes • Multiplication des requêtes dappels aux fichiers CSS, JS, IMG • Sources CSS et Javascript non compressés • Arbre DOM comportant trop de nœuds • Sur-imbrication de sélecteurs CSS • Inversement, sélecteurs trop évasifs (*) • Surcharge de Hack CSS • Redimensionnement des images en CSS • Utilisation dimages graphiques pour les bordures, les ombres et dégradés • Mauvaises pratiques des frameworks CSS (Blueprint, Boilerplate, 960gs, Skeleton, ...) • Mauvaises pratiques des Data URI • Surutilisation de la sécurisation SSL • Chargement de fonctionnalités inutiles sur mobiledimanche 23 septembre 2012
  • 5. Les bonnes pratiques • Optimisez le poids de vos images (smushit.com) • Rassemblez vos images à laide de sprites (draeton.github.com/stitches/) • Unifiez et compressez vos scripts (cssdrive.com, refresh-sf.com/yui/) • Utilisez les classes conditionnelles, une bonne alternative aux commentaires conditionnels et aux hacks Css ! • Dans la mesure du possible préférez les CSS3 aux images • Charger uniquement ce dont vous avez besoin à laide des média queries, des chargeurs de scripts et polyfills. (http://requirejs.org/) • Utilisez le lazy-loading sur les images, c’est à dire ne téléchargez l’image que lorsqu’elle est sur le point d’être affichée (OnScroll). • Globalement, respectez les bonnes pratiques de conception web. (csslint.net, http://csslisible.com/)dimanche 23 septembre 2012
  • 6. Le serveur prend le relais • Héberger les ressources (images, médias) sur plusieurs domaines favorise la parallélisation. • Mais attention à ne pas maximiser le nombre de requêtes DNS. Le coût de recherche DNS peut être dix fois plus important sur mobile à cause de la latence que sur Desktop. Un sous-domaine fonctionne aussi ! (media.mondomaine.fr) • Utiliser HTML5 localStorage pour stocker vos datas, scripts et images (encodés en base64). Technique choisie par LinkedIn mobile, Bing ou GMail. Attention ! Le cache des navigateurs mobiles est beaucoup plus petits que celui des navigateurs de bureau (4Mo environ). • Déployez votre site sur un CDN. Cela consiste à distribuer le contenu statique (images, scripts ..) de votre site suivant la localisation physique de l’utilisateur.dimanche 23 septembre 2012
  • 7. Trés bien, mais en production ? Comment utiliser toutes ces pratiques en production ? Une première approche : Demandez de laide à votre éditeur IDE préféré, pour ma part SublimeText ou Netbeans. Ils auront sûrement quelques outils à disposition... • CSSLint (erreurs de conception) • JSMinifier (minifier le JavaScript) • YUI Compressor ( minifier JS et CSS)dimanche 23 septembre 2012
  • 8. Profiter des nouvelles technologiesdimanche 23 septembre 2012
  • 9. Les préprocesseurs CSS Avec les préprocesseurs Css • Profitez des variables et des héritages de classes pour favoriser une approche DRY (Don’t Repeat Your CSS). • Minifiez vos styles en production • Générez automatiquement vos sprites dimages • Unifiez vos Css avec limport de feuilles de style partielles • Encodez nativement vos backgrounds en data-uri,... Certains préprocésseurs Css proposent des compilations en Javascript côté front-end. Attention en production il faudra "précompiler" votre code Less et déployer un bon vieux style.css.dimanche 23 septembre 2012
  • 10. Les Polyfills, Script loader, ... ? Quel script loader choisir ? http://goo.gl/qbkVG RequireJS est un "script loader" modulable, qui fournit entre autre un outil doptimisation permettant de combiner vos sources et de les minifier. http://requirejs.org/docs/start.html Enquire.js est une bibliothèque apportant la puissance des Media Queries en Javascript. Il est utile par exemple pour charger vos scripts selon le format du périphérique (device) utilisé. http://wickynilliams.github.com/enquire.js/ YepNope est un chargeur de scripts conditionnel et asynchrone (ultra-rapide). Ce polyfill est inclus nativement dans Modernizer, une bibliothèque JavaScript qui détecte les fonctionnalités accessibles dans le navigateur de lutilisateur. http://modernizr.com/dimanche 23 septembre 2012
  • 11. Profiter... des nouvelles technologies OU PAS ! ● Faut-il charger des images rétiniennes pour les appareils disposant de cette technologie ? ● Devons nous laisser le choix aux internautes et mobinautes de lactiver ou non ? ● Il faut savoir que les images "rétiniennes" seront plus lourdes à charger que les images standard... Mon avis est que les connectivités réseaux ne permettent pas aujourdhui de fournir du retina sur des mobiles connectés en 3G !dimanche 23 septembre 2012
  • 12. Mythe ou réalité ? @media (min-bandwidth: 25Mbps) {} @media (max-bandwidth: 10Mbps) {}dimanche 23 septembre 2012
  • 13. Des images responsives Nous navons pas parlé des images responsives !dimanche 23 septembre 2012
  • 14. Mesurer, comparez ! ● http://mobitest.akamai.com/ ● https://developers.google.com/speed/ ● http://yslow.org/ ● http://validator.w3.org/mobile/ ● http://www.opquast.com/ ● http://gtmetrix.com/ ● http://www.browserscope.org/dimanche 23 septembre 2012
  • 15. Un exemple ? ● leklub.fr/blog 25 secondes de chargement sur Iphone 4 en 3Gdimanche 23 septembre 2012
  • 16. Sans laspect social : 13.26 secondes de chargementdimanche 23 septembre 2012
  • 17. Sans script superflu : 12.53 secondes de chargementdimanche 23 septembre 2012
  • 18. Sans Google font ! 11.81secondes de chargementdimanche 23 septembre 2012
  • 19. Images compressées : 4.78 secondes de chargement Avec optimisation des CSS pour mobile...dimanche 23 septembre 2012
  • 20. Mobile Ready ! 1.68 secondes de chargementdimanche 23 septembre 2012
  • 21. Les optimisations réalisées • Feuilles de styles CSS unifiées • Images compressées • Image darrière-plan chargé uniquement si écran > 640px • Suppression des styles IE (classes conditionnelles) • Google font chargé uniquement si écran > 640px • Chargement asynchrone des scripts Javascript* • Chargement des widgets sociaux uniquement si écran > 960px* * En test sur le blog Attention ! PageSpeed, YSlow, ... sont des outils d’évaluation. Ils ont été mis en place pour aider les développeurs à avoir une vision d’ensemble de l’optimisation de leurs pages et synthétisent l’ensemble des tests sous forme d’un score global.dimanche 23 septembre 2012
  • 22. Et testez ! Les outils de mesure ne remplacent pas les tests en situation réelle !dimanche 23 septembre 2012
  • 23. Testez, ... mais comment ! Avec Opéra mobile émulator ! Non, cet outil peut être utile pour vaguement tester la "responsivité" de son site, mais en aucun cas les performances réseaux. Pour simuler un réseau 3G, on pourra utiliser des proxys via WiFi qui dégradent volontairement la connexion. Je vous invite à tester Trickle (Linux), Network Link Conditioner (OSX 10.6) ou Slowy App (OSX 10.5).dimanche 23 septembre 2012
  • 24. Quelques ressources utiles http://stevesouders.com/ http://www.lukew.com/ http://blog.goetter.fr/ http://www.webperformancetoday.com/ http://wdfriday.com/ http://letrainde13h37.fr/ https://twitter.com/#!/search/webperf Atelier de travail sur les bonnes pratiques Webperf https://checklists.opquast.com/webperf/workshops/dimanche 23 septembre 2012
  • 25. Conclusion La performance est un élément essentiel pour une bonne expérience utilisateur (sur mobile) mais pas uniquement. Attention à ne pas surestimer les configurations technologiques de nos utilisateurs. Cest un travail de longue haleine, qui sécoule sur toute la durée de vie du site.dimanche 23 septembre 2012
  • 26. Merci ! willy@leloutre.com Twitter: @wleloutre ? Des questions ?dimanche 23 septembre 2012