1485 sujets

Web Mobile et responsive web design

Bonjour

l' expression critical semble concernée le temps de chargement de la première page ( html/DOM puis css/CSSOM puis javascript puis les fontes et les images ) .

Chaque paramètres citées peuvent être optimisé dans le but de réduire le délai

Pour HTML on peut utiliser les templates clients basés sur AJAX /JSON qui ne rechargera les données nouvelles suivantes qu'après interaction avec l 'utilisateurs ( hammer backbones ) . Quand sont chargés les css/image/js relatifs à ces templates ? ( DOM template ? !)

Pour javascript l on a require.js qui ne charge les composants widget que lorsque l on en a besoin . En gros a chaque widget correspond un module ou fichier js avec ces dépendances et fichiers de traductions ( javascript =json)).

Pour css il y a l inclusion du code css ( selecteur propriété/Valuer) le plus important directement dans le fichier html client et le code css moins important sera téléchargé et utilisé plus tard grâce à un script . Comment se contenu est générer dans le cas d'un site responsive avec des médiaqueries ? Faut il privilégier le concept mobilefirst et définir le contenu CSS inline comme celui en relation avec le code css relatif aux mobile ?
Si on se connecte avec écran desktop , on chargera les données mobiles puis dektop écran alors que l on souhaite mobile desktop inline puis desktop !! Comment gére t on ça actuellement pour ne charger que le code css critique pour le desktop en mode mobile first ? . Et donc avoir en ccs : mobile critique -> desktop critique -> desktop css


Pour les images il y a sprite dans raster et pattern SVG dans svg et image base64 dans css qui sont plus sur la taille du contenu "absolu" comparé à srcset reative au caractérisique du périphérique .


Pour les @fontface voir filament group qui propose de ne télécharger qu une seule des fontes disponibles sur le serveur : celle supporté par le navigateur .Le principe est basé sur plusieurs libraries :
WOFF2 feature test
loadCSS(filament group)
cookie utility( filament group)

Merci
Modifié par 75lionel (27 Jul 2015 - 23:37)
Salut,

Si tu utilises Backbone (ou autre MVC coté client), il sera important d'avoir un premier rendu côté serveur. Comme ça si le javascript ne charge pas (problème réseau, pare-feu, désactivé par l'utilisateur, etc...) tu auras ton contenu quand même affiché. Ca veut aussi dire que le navigateur pourra optimiser le chargement des resources sur la page et n'aura pas à attendre toutes les dépendances de ton framework avant de charger ces resources.

Selon ton site, chargé tous les widgets séparément peut ralentir le chargement. Si c'est fait en async c'est passable mais tant qu'on est coincé avec HTTP1, minimiser les requêtes est important. (Ce ne sera plus trop un problème une fois que HTTP2.0 sera bien répandu et stable)

Pour le css, certains scripts existent pour générer ce code. Ils chargent ta page et regarde ce qui est en première de couverture (Above the fold) et garde le css utilisé pour cette partie mais je ne recommanderais pas de faire ça. Le mieux c'est de faire ça manuellement en vérifiant chaque breakpoint.
Je pense que l'optimisation mobile n'est plus entièrement vrai car au final les mobiles se connectent en wifi et 4G. Ce qui est parfois bien mieux que certains réseau ADSL auquel tu te connectes avec ton ordinateur.
(ce que j'essai de dire la c'est qu'il faut pas se concentrer seulement sur le mobile mais desktop aussi biensur).

L'important avec cette optimisation est de tester. Tu peux appliquer les meilleures techniques préconisé par les meilleurs experts, chaque cas reste unique.

Il est aussi important d'être conscient que la technique mobile-first ne s'applique pas uniquement au css mais si tu charges tes widgets en async j'imagine que tu en es déjà conscient.

Pour les images, tu peux également utiliser un programme appelé imageOptim (ou équivalent). Ce programme va optimiser la compression de ton image et enlever toutes les metadata inutiles pour le web. (Appareil photo utilisé, geolocalisation etc...)

Il faut faire attention en utilisant l'inclusion des images en base64 car ces données ont tendances à bien alourdir ton css ce qui au final peut être pénalisant.

Je ne sais pas si j'ai répondu à tout mais j'espère avoir clarifié quelques points.
Personnellement je ne serais pas aussi catégorique concernant l’optimisation pour le mobile.
Certes, les téléphones et couvertures réseaux sont de plus en plus puissant, mais ça ne justifie pas qu'il faille se concentré beaucoup plus sur la partie desktop que mobile.

En réalité c'est même l'inverse, la navigation desktop est petit à petit détrôné par le petit mobile (Iphone ou Smarphone). Ceci dépend des thèmes utilisé par le site, mais il y a encore deux ans les utilisateurs était à 40% mobile - aujourd'hui nous sommes plus sur du 60/70%;

Pour ces raisons, le mobile ne doit pas être négligé.Il faut contraire y penser sérieusement, et non pas adapté le bureau au mobile mais répondre à une demande mobile sur du mobile.
Je pense que je n'ai pas du formuler ça au mieux mais ce que j'essayais de dire c'est que la plupart des articles qu'on trouve sur le web parlent d'optimiser pour le mobile.

Evidemment c'est primordiale d'optimiser pour les mobiles mais il faut surtout pas oublier le desktop nonplus.

Au final de faire la distinction mobile / desktop pour moi n'est plus trop valable (à pars au niveau de la taille d'écran biensur) puisque de nos jours quelqu'un peut aussi bien avoir un mobile a 2 balles qui tournent sur un 2G/3G merdique aussi bien qu'un mobile aussi puissant qu'un desktop qui tourne sur du 4G (ce qui en general représente une vitesse d'environ 14M)

Et dans le cas des desktop tu as évidemment un tas de modele puissant avec de bon network mais tu peux aussi bien être en tethering ou avoir un notebook qui supporte pas trop la consommation qu'entraine certains sites riche en CSS/JS etc... Smiley smile