Optimiser un site pour navigateur mobile

[gab_wri]

Bonjour à tous,

************************************
* Constat
************************************
Google analytic et pingdom m'indiquent une grande utilisation des navigateurs mobiles. Sur ces navigateurs les temps de chargements sont mauvais. Les temps de chargement sur les navigateurs mobiles (chrome mobile, ff mobile, android browser) sont en moyenne de 10 s (temps relevés sur pingdom). Sur navigateurs desktop les temps de chargement sont en moyenne de 4 à 5 s (temps relevés sur pingdom). Le navigateur android browser est le moins performant et un des plus utilisé.

************************************
* Questions
************************************
Existe t-il des bonnes pratique de développement pour ces navigateurs ?

En vous remerciant d'avance pour vos informations.

 

[spout]

http://browserdiet.com/fr/

 

[colonies]

Il y a des bons conseils et de mauvais conseils sur cette page.
- utiliser un CDN pour charger jQuery est la plupart du temps une mauvaise idée
- data-uri est à proscrire quasiment tout le temps dans les CSS.
- combiner les fichiers est une technique qui fonctionne plus ou moins bien selon les cas. Il vaut souvent mieux charger deux fichiers de 20 ko qu'un fichier de 40 ko par exemple. C'est un bon conseil pour les petits fichiers en grand nombre, mais à partir d'une certaine taille, combiner ralentit le chargement.
- les sprites d'images n'ont pas que des avantages, c'est une décision à prendre au cas par cas. Les sprites sont plutôt une mauvaise idée pour les sites servis par SPDY.
- les JPEG progressifs ne sont pas appréciés des utilisateurs d'après des études réelles. Ce conseil est sortit sans aucune base concrète sur de simples suppositions, à un moment où Safari n'affichait les JPEG progressifs qu'une fois l'image totalement chargée, c'est dire si c'était bien réfléchi.

Enfin, il n'y a rien sur la configuration du serveur, même pas les choses basiques comme "assurez-vous que GZip est activé" ou la configuration des Expires (plus complexe, ceci dit).
Je comprend bien que ces conseils s'adressent aux développeurs front, mais quand même. Après tout mettre un htaccess n'est pas plus compliqué que de minifier une CSS (même s'il vaut mieux proscrire les htaccess, il y a beaucoup d'hébergements par Apache où les htaccess sont activés).

 

[spout]

Tu peux poster une issue sur leur github si tu veux

 

[colonies]

Ca ne servirait pas à grand chose. Il existe de très très nombreuses listes de ce genre, toutes contenant leur lot de simplifications, manques, erreurs. Et parfois une liste qui donnait de bons conseils devient une liste à éviter parce que le comportement des navigateurs a changé et mettre en place leurs optimisations devient contre-productif.

En fait le problème c'est surtout de vouloir faire une liste concise qu'on puisse suivre sans se poser de questions.

En ce moment, ce livre http://chimera.labs.oreilly.com/books/1230000000545 est excellent et ne concerne que la partie réseau.
Mais voilà, il fait 400 pages et demande un investissement de temps conséquent pour un webmaster isolé. Alors on fait des listes simplifiées, des conseils "en gros" mais il n'y en a que très peu qui fonctionnent vraiment toujours, pour tout le monde.

Réduire le poids des images avec des techniques lossless : sans problème, il n'y a aucun effet négatif.
Choisir un format plutôt qu'un autre, déjà c'est nettement plus aléatoire.

Réduire le nombre de requêtes : euh... attend voir, comment tu comptes faire ça ? Comment tu vas créer ton sprite ? Est-ce que tu as vraiment intérêt à faire un sprite avec 40 images si seulement 2 s'affichent par page ?

data-uri ? oui, tu évites une requête mais ça oblige à charger les images qui ne sont pas forcément dans la page, et si tu les mets dans la CSS ça l'alourdit.
Comme la CSS doit être chargée pour que la page s'affiche c'est pas forcément une bonne idée. Et si tu changes une seule image intégrée à la CSS, le navigateur doit la recharger. Si les mises à jour sont rares ou toujours couplées à un changement de la CSS, ça peut tout de même être intéressant... faut voir.

Les Javascript en fin de page ou en async : oui s'ils ne servent qu'à de petites améliorations graphiques. Sinon c'est plus délicat : si certains boutons ne fonctionnent qu'une fois le script chargé, ça n'est pas forcément une bonne chose.
si l'utilisateur peut essayer d'interagir sans succès car les scripts ne sont pas chargés, il risque de déduire que "ça ne fonctionne pas". malheureusement, quasiment personne ne prévoit d'indiquer à l'utilisateur qu'il doit encore patienter un peu dans ce genre de situations.

Et la liste pourrait s'allonger pendant des centaines de pages... ce que certains ont fait du reste. Mais tout le monde ne prend pas (ou n'a pas) le temps de les lire.

Finalement l'optimisation des perfs c'est un peu comme le SEO : les techniques évoluent, il y a quelques règles constantes valables et beaucoup d'autres qui sont variables avec d'éventuels effets négatifs en cas de mauvaise utilisation. Heureusement, il n'y a pas de sanction aussi violente qu'un blacklistage en cas d'erreur.

 

[spout]

Sa question était:

Existe t-il des bonnes pratique de développement pour ces navigateurs ?

Le lien que j'ai donné répond en partie a sa question non? Je n'ai pas dis que c'était une liste exhaustive.
On attend ta liste de bonnes pratiques go :mrgreen:

 

[colonies]

je ne dis pas qu'il faut qu'elle soit exhaustive, je dis qu'il y a des conseils qui peuvent avoir des effets négatifs.

si tu veux vraiment mes conseils :
- activez la compression GZip si ça n'est déjà fait
- configurez les headers Expires pour optimiser l'utilisation du cache
- optimisez les images. un soft comme ImageOptim est très bien (OS X)
- pour les PNG 24-bit avec peu de couleur, utilisez plutôt du PNG8 + vrai alpha (ImageAlpha sous OS X)
- placez les CSS avant le javascript
- si l'en-tête de votre site n'utilise pas de javascript, placez les javascripts après (dans le body, donc)

Si le site est en HTTPS :
- utilisez SPDY
- pas de CDN pour les ressources externes

Si le site est en HTTP :
- limitez le nombre de ressources CSS + JS à 6 et équilibrez leurs poids. Si vous ne pouvez pas en avoir moins de 6, référencez les ressources supplémentaire avec l'adresse IP de votre serveur.
- limitez les appels à des serveurs externes en particulier pour les ressources bloquantes si votre site n'a pas une audience internationale (avec de longues distances) : JQuery sur votre serveur, polices sur votre serveur et non sur Google Fonts, etc.
- évitez de multiplier les sous-domaines sur votre propre site pour les ressources (static.monserveur.com + img.monserveur.com + js.monserveur.com = trois requêtes DNS => à proscrire)

Evitez les reflows :
- définissez les tailles d'image dans le HTML ou les CSS.
- si vous appelez des scripts externes ayant un impact graphique (boutons sociaux...), placez-les dans un div de taille prédéfinie assez grande pour éviter les reflows.

Minifiez les JS et CSS
Organisez les propriétés CSS par ordre alphabétique

Si les actions des utilisateurs sont prévisibles, utilisez link rel=prefetch

Il peut être intéressant d'utiliser link rel="dns-prefetch" si d'autres domaines ont une forte probabilité d'être appelés plus tard

Evitez les imbrications de code HTML et règles CSS complexes et inutiles en particulier pour les versions mobiles :
body div#global div#header div#bt-login => #global-header-bt-login
Firefox propose une vue 3D bien pratique pour avoir un aperçu des imbrications du DOM.


SERVEUR DEDIE
-------------------
Si votre site est en PHP :
- utilisez une version récente. Si vous ne le pouvez pas, au minimum activez APC.

Serveur (OS) :
- si votre noyau est ancien vérifiez la taille initiale de la fenêtre de congestion TCP. 10ko est un minimum.

Si votre serveur est Apache :
- DESACTIVEZ LES .htaccess !
- éliminez les headers inutiles (ServerSignature off...)

Il faut bien sûr optimiser les configs des serveurs web et sql mais là... tout dépend du serveur, de votre trafic, de vos données.

 

[spout]

Ben voilà parfait

Si votre site est en PHP :
- utilisez une version récente. Si vous ne le pouvez pas, au minimum activez APC.

Depuis PHP 5.5, c'est OpCache qu'il faut utiliser.

Si votre serveur est Apache :

Installez Nginx :mrgreen:

 

[colonies]

Depuis PHP 5.5, c'est OpCache qu'il faut utiliser.

Depuis 5.5 c'est activé par défaut donc il n'y a rien à faire, c'est pour ça que je parle d'anciennes versions.

NGinx est très bien mais n'est pas purement équivalent à Apache et migrer n'est pas toujours facile.
La différence de vitesse entre Apache et NGinx vient principalement du support d'htaccess.

 

[lambi521]

Si votre serveur est Apache :
- DESACTIVEZ LES .htaccess !

Pourquoi ce conseil, quels sont les inconvénients ? C'est la 1ère fois que j'entends cela

 

[colonies]

Parce que les support des htaccess provoque plein des accès au filesystem.
Les htaccess peuvent être modifiés à tout moment, donc pour CHAQUE appel à un fichier (que ce soit un script, une image, une css, un js...), Apache cherche les htaccess pouvant modifier son comportement : dans le dossier même mais aussi tous les dossiers parents.
Par exemple si tu appelles un fichier dont le chemin est /images/intl/drapeaux/gb.png
Apache va chercher s'il existe :
/images/intl/drapeaux/.htaccess
/images/intl/.htaccess
/images/.htaccess
.htaccess
Fort heureusement, les disques ont des caches donc ça ne provoque pas d'accès physiques dans 99% des cas mais les appels au FS prennent quand même du temps.
Plus d'explications et des benchs ici :
http://www.eschrade.com/page/why-you-should-not-use-htaccess-allowover ... roduction/

 

[spout]

Depuis 5.5 c'est activé par défaut donc il n'y a rien à faire, c'est pour ça que je parle d'anciennes versions.

C'est installé par défaut, pas activé (php.ini-production: ;opcache.enable=0)

La différence de vitesse entre Apache et NGinx vient principalement du support d'htaccess.

N'importe quoi: Thread based server vs Event based server.

 

[colonies]

Effectivement c'est désactivé par défaut.

Mais t'es sûr que tu t'y connais en performances et en optimisations ?
http://www.webpagetest.org/result/141020_X1_PE2/1/details/

 

[spout]

Oui je sais, c'est plombé par la carte Google Maps, plus les assets multiples que je n'ai pas encore combiné/minifié... le ferais qd j'aurais le temps...
Tu connais l'expression: "C'est les cordonniers les plus mals chaussés ?"

 

[Leonick]

Si votre serveur est Apache :
- DESACTIVEZ LES .htaccess !

comment gres-tu les réécritures ? et la gestion des accès (htpasswd) ?

 

[salva]

C'est la 1ère fois que j'entends cela

C'est stipulé dans la documentation Apache.

Les fichiers .htaccess ne doivent être utilisés que si vous n'avez pas accès au fichier de configuration du serveur principal. L'utilisation des fichiers .htaccess ralentit le fonctionnement de votre serveur http Apache. Il est toujours préférable de définir les directives que vous pouvez inclure dans un fichier .htaccess dans une section Directory, car elles produiront le même effet avec de meilleures performances.

Source. Toute la page est intéressante à lire.

Ps: Leonick ça devrait répondre à ta question

 

[Leonick]

oui, mais si je comprends bien, pour éviter de devoir lire de multiples fichiers htaccess, on préfère charger le fichier de configuration apache : ce qui fait qu'un fichier htaccess dans un répertoire qui ne serait utilisé qu'une fois par semaine, pour le backoffice, va devoir être lu et chargé en mémoire pour des millions de visiteurs ?

 

[salva]

Non, si les directives sont incluses dans le http.conf tu ne peux pas mettre de htaccess dans un répertoire. C'est du soi l'un, soit l'autre.
Tu utilises dans ce cas une section Apache directive pour chaque dossier qui possédait un htaccess.

<Directory "/home/www">

Le contenu de httpd.conf n'est lu qu'une fois au démarrage du serveur. Contrairement au htaccess.

ps pas sur d'avoir compris la question

 

[colonies]

oui, mais si je comprends bien, pour éviter de devoir lire de multiples fichiers htaccess, on préfère charger le fichier de configuration apache : ce qui fait qu'un fichier htaccess dans un répertoire qui ne serait utilisé qu'une fois par semaine, pour le backoffice, va devoir être lu et chargé en mémoire pour des millions de visiteurs ?

De toute façon le fichier de conf d'apache est toujours utilisé mais il n'est chargé et interprété qu'une fois au lancement d'Apache.

Je le répète : si tu actives .htaccess, Apache vérifiera s'il existe des .htaccess dans toute l'arborescence du DocumentRoot jusqu'au dossier du fichier demandé tout le temps, pour toutes les requêtes.
Et ces vérifications sont lourdes, bien bien plus lourdes que le test qui consiste à vérifier si un fichier correspond au chemin concerné par ton ancien .htaccess (la directive <Directory> contenant les tests qui étaient avant dans un fichier htaccess).

 

[Leonick]

De toute façon le fichier de conf d'apache est toujours utilisé mais il n'est chargé et interprété qu'une fois au lancement d'Apache.

c'est à dire que si sur ton dédié tu as des dizaines ou centaines de sites, ton fichier de conf va mettre en mémoire les directives de milliers de répertoires, y compris ceux de sites ne faisant qu'une dizaine de visites par jour et donc quand apache va tourner, il devra parcourir les milliers de paramétrage de repértoires

 

[colonies]

on parlait de cas concrets mais bon ok, partons dans les délires : non il ne va pas parcourir toutes les directives de tous les sites mais seulement celles du VirtualHost concerné.
Ensuite je ne sais pas comment Apache est programmé mais j'imagine que c'est un minimum optimisé donc par exemple qu'il va utiliser une hashtable pour trouver les règles adéquates. Fais un tableau associatif avec 100.000 éléments : est-ce que c'est super lent d'accéder à une valeur pour autant ?
non.

Et quand bien même toutes les directives prendraient 10Mo de RAM ou même 100Mo, c'est rien du tout par rapport au gain de perfs que ça apporte.

Maintenant soyons réalistes : si tu as autant de sites sur une machine (mettons une centaine), c'est sans doute qu'ils ont des propriétaires différents. Il n'est pas question de laisser tout le monde modifier joyeusement le fichier de conf principale, c'est bien pour ça qu'il y a des .htaccess.
Mais là on parle de mutu. C'est pas par hasard si j'avais mis ce conseil sous SERVEUR DEDIE.

 

[salva]

@Leonick
Il parait évidant que cette solution n’est pas adaptée à tous les cas.
Si tu avais suivi et lu le lien que j’ai fourni, tu ne poserais pas la question :mrgreen:

 

[lambi521]

Merci pour tous ces conseils, je ne savais pas, ça pourra être une piste à améliorer plus tard.

Pour l'instant, bien que je n'y connaissais rien du tout à Apache, j'ai réussi mon URL rewriting mes redirections et ma compression par le .htaccess, je suis sur un mutu et j'ai de très bon temps de réponse, donc c'est très bien comme ça

 

[Leonick]

@Leonick
Il parait évidant que cette solution n’est pas adaptée à tous les cas.
Si tu avais suivi et lu le lien que j’ai fourni, tu ne poserais pas la question :mrgreen:

si, parce que tu peux très bien avoir des centaines de (petits) sites, sans pour autant être un mutu : soit que tu as toi-même une constellation de sites, genre les sites ayant un sous-domaine pour chaque ville en France ou bien les plateforme de blog, qui ne permettent pas aux personnes ayant un blog de modifier la config en htaccess. Donc dans ces cas les 2 solutions pourraient être utilisées, mais pas sur que ça ne ralentisse pas le serveur.
Car, il me semble, que les tests de ce genre sont effectués par rapport à 1 site : soit on intègre tout dans le fichier config et on mesure les temps d'accès, puis la même chose avec htaccess. Mais il ne me semble pas avoir vu le même type de tests à haut volume ; on intègre des centaines de directives de redirections et de contrôle d'accès et on chronomètre les temps d'accès

il ne faut pas oublier qu'il n'y a pas qu'un seul process apache qui tourne en mémoire. Et que chacun chargera l'intégralité des fichiers de config apache

 

[colonies]

soit que tu as toi-même une constellation de sites, genre les sites ayant un sous-domaine pour chaque ville en France ou bien les plateforme de blog

dans un cas comme dans l'autre ça n'est qu'un site.

 

[Leonick]

forum.webrankinfo.com et www.webrankinfo.com ne sont qu'un seul site ? :roll:

 

[colonies]

c'est différent, ce sont deux codes distincts.
Mais dans un site avec des SD sour chaque ville ou dans une plate-forme de blog, oui c'est le même code qui tourne derrière et il n'existe pas de dossiers correspondant aux URL. C'est simplement de l'URL rewriting avec catch-all sur le sous-domaine.

 

[HawkEye]

Ca part en n'importe quoi ce topic :roll:

 

[Leonick]

bon, au delà de cette option htaccess ou non, je pense qu'il faut optimiser les images par rapport à la taille du navigateur : un écran hd de 4,5" n'a pas besoin d'avoir la même qualité d'image que pour un desktop de 28". Et ça peut faire gagner pas mal en taille d'image

 

[salva]

Donc dans ces cas les 2 solutions pourraient être utilisées, mais pas sur que ça ne ralentisse pas le serveur.
Car, il me semble, que les tests de ce genre sont effectués par rapport à 1 site : soit on intègre tout dans le fichier config et on mesure les temps d'accès, puis la même chose avec htaccess.

Pour savoir si une solution est préférable à une autre, il faut faire des tests.
Je peux affirmer que dans mon cas, c’est-à-dire jusqu’à 3 joomla sur le serveur, il n’y a pas photo.
Dans la configuration ci-dessus, intégrer le htaccess dans la conf Apache, c’est l’adopter.
J’avais quelques 5000 redirections et le serveur ne sourcillait pas d’un poil. A contrario, avec le htaccess dans les dossiers le serveur était à la rue.

 

[colonies]

franchement je ne vois pas ce qui peut justifier 5000 redirections dans la conf d'Apache.
mais bref, il faudrait carrément faire des topics séparés parce que comme le dit HawkEye, ça part un peu en n'importe quoi.

 

[gab_wri]

Bonjour @tous,

Merci pour vos nombreuses réponses et vos réactions.

I) Sujet du topic
Beaucoup d'interventions sortent du cadre de la question que j'avais posée. Je n'ai surement pas été clair quand je l'ai posée. Je vais donc la préciser.

==========================================================================================================
Je voulais savoir si pour les navigateurs mobiles uniquement (chrome mobile, opera mobile, android browser ...) il y avait des bonnes pratiques à suivre et/ou des développements spécifiques à faire pour le front (seulement pour ces navigateurs).
==========================================================================================================

Cette question peut se rapprocher de celle que l'on se pose quand on développe pour des versions anciennes versions de IE. Par exemple pour IE6, le site doit avoir des commandes css ou js spécifiques à ce navigateur ...


II) Pourquoi je pose cette question
Les navigateurs mobiles sont de plus en plus utilisés (je l'ai remarqué sur pingdom, google analytic...) Si les temps de chargements du site sont très corrects pour les navigateurs de bureau, ils sont moins bons pour les navigateurs mobiles (en particulier pour android browser). Deux pistes sont envisageables:

- Les réseaux utilisés par les mobiles sont moins performants
- Certains navigateurs peuvent avoir des difficultés à interpréter certains javascripts ou commande css (je pense à Android browser qui commence à être ancien mais est très utilisé). Quels sont les développements spécifiques (s'ils existent) à faire en front (css / js / html) pour ces navigateurs .

Ce topic porte uniquement sur la deuxième piste.

II) Vos idées
Beaucoup de posts sont intéressants mais ils ouvrent des nouveaux débats. Certains mériteraient un nouveau topic.
- Sprout à fourni un très bon lien sur un livre d'or sur l'optimisation en général du front. Colonies à proposer des nuances et un livre complet sur l'optimisation.
- La discussion est ensuite partie sur l'optimisation serveur, les .htacess. Là encore des sujets qui méritent d'être débattus mais dans un autres topic.

Je vous remercie pour l'intérêt porté à ce topic.

 

[colonies]

Tu ne veux pas nous donner l'adresse de ton site ?
Ca serait beaucoup, beaucoup plus simple de te dire quoi améliorer que de se lancer dans de longues discussions générales (même "limitées" au mobile).

 

[gab_wri]

Tu ne veux pas nous donner l'adresse de ton site ?
Ca serait beaucoup, beaucoup plus simple de te dire quoi améliorer que de se lancer dans de longues discussions générales (même "limitées" au mobile).

Bonne remarque
http://sushimanleninja.com/

 

[colonies]

On sent qu'il y a déjà eu une volonté d'optimiser mais :
- quelques tests d'optimisation des PNG montrent que tu peux nettement réduire leurs tailles
- sans javascript, les images ne s'affichent pas correctement... mais elles s'affichent quand même, comme quoi il y a un problème avec ton lazy loading. Lazy loading que je proscrirais de toute manière.
- as-tu besoin de tous ces scripts ? Je n'ai aucune idée précise de ce qu'ils font sur tes pages, mais tu en as quand même pour plus de 125ko avec JQuery, jQuery-migrate, Modernizr... Franchement, à regarder ton site on se demande si 5ko de javascript pur ne suffirait pas, au moins sur l'accueil. Au minimum, corrige ton code pour que les images s'affichent à la bonne place sans javascript.

 

[Leonick]

pour moi, l'histoire de l'optimisation serveur ne s'applique pas qu'au seuls navigateurs mobiles.
Moi je vois plutôt 1 version spécifiquement mobile mais responsive. Pourquoi responsive et que mobile ? j'ai parlé des résolutions et qualités images : si l'image est légèrement dégradée, cela ne se verra quasi pas sur un écran 5", par contre, sur un 21 voire 27" ça se remarquera.
Ensuite, il faut une adaptation de l'interface à une utilisation digitale : une icone 16x16 accolée à une autre interface de link (image ou texte) sera très difficilement accessible sur un écran 4".
Le flash : de bas, il me semble, aucun appareil mobile ne le reconnait

 

[gab_wri]

Salut

Merci pour vos réponses

I) vos réponses
@colonies
- pour les png : tu as raison. Je l'avais noté. Je dois faire cela.
- lazy loading no js : Je n'avais pas testé sans js. Je vais regarder ce qu'il se passe.
- scripts en générale : non je n'ai pas besoin de tous ces scripts. Je suis actuellement en train de faire le tri.

@ Leonick
Merci pour ces infos. En effet l'interface n'est pas encore optimale pour un affichage mobile

II) La question initale
La question était de savoir s'il y avait des techniques de programmations js et d'intégration spécifiques aux navigateurs mobiles. On pouvait faire le parallèle avec le développement pour les versions versions d'IE où il fallait utiliser des feuilles de style et des js spécifiques (on parle aussi de hack).
- J'ai trouvé des pages listant des hack css pour les navigateurs mobiles : http://browserhacks.com/
- A confirmer : mais les navigateurs mobiles courant (chrome mobile, ff mobile) utilisent certainement les mêmes moteurs que leur version bureau. On peut s'attendre que ce qui marche sur la version bureau de ces navigateurs, marche sur la version mobile. J'ai juste trouvé une page qui mentionnait des problèmes js pour android brwoser (http://stackoverflow.com/questions/17595646/javascript-not-working-on- ... id-browser).

Conclusion
J'ai trouvé peu d'info pour l'intégration et le développement JS, spécifiques aux navigateurs web mobiles courants. Android browser est le navigateur à surveiller le plus : il est ancien et encore très utilisé (une sorte de ie6 du mobile ). Le mieux est de tester sur un téléphone android ou sur un émulateur (si vous en connaissez un bon, n'hésitez pas à le partager ).

Je vais demander au modo de clore ce topic. Si certains trouvent des infos, ils pourront en rouvrir un. En attendant voici quelques mots clefs à taper dans google pour trouver de l'info sur ce sujet : "mobile browser hack", "mobile browser emulator", "android browser javascript"...

Merci encore pour vos interventions

 

[Leonick]

On peut s'attendre que ce qui marche sur la version bureau de ces navigateurs, marche sur la version mobile.

pas vraiment : opera mini pour android et opera pour android ne fonctionnent pas exactement de la même façon

Le mieux est de tester sur un téléphone android ou sur un émulateur (si vous en connaissez un bon, n'hésitez pas à le partager )

tu peux maintenant installer android sur ton pc desktop

 

[colonies]

il y a très peu de différences entre les navigateurs mobiles et les navigateurs desktop*, pour la simple et bonne raison qu'on tient encore compte de navigateurs dépassés sur desktop (IE8 et, dans un très moindre mesure, IE9).

browserhacks : quel rapport avec un développement spécifiquement mobile ? de plus les hacks ne sont vraiment pas une technique "propre". Une bonne reset stylesheet est généralement suffisante (la plupart des personnes qui utilisent des hacks se retrouvent avec des CSS compliquées et illisibles simplement parce qu'elles n'ont pas de reset stylesheet).
stackoverflow : relis le sujet, ça n'est pas un problème d'Android Browser.

les grosses différences entre mobile et desktop sont surtout au niveau de la lenteur/instabilité du réseau pour de nombreux utilisateurs et la faible puissance des mobiles (du moins d'une partie). il faut limiter au maximum les ressources externes bloquantes et possibles SPOF (CSS et JS qui en plus prend plus de temps à être interprété) et il y a un plus grand intérêt à combiner les ressources que sur desktop.

pour le reste il peut y avoir des différences entre les versions desktop et mobiles mais à partir du moment où tu supportes IE 8 ou 9, peu importe : n'importe quel navigateur mobile digne de ce nom et vraiment utilisé est capable de faire pareil.
caniuse permet de comparer ce qui est disponible sur les différents navigateurs :
http://caniuse.com/#comparison (le tableau est mis à jour dès que tu coches/décoches un navigateur, il faut penser à scroller).

* edit : à part opera mini, effectivement, mais on s'en fout complètement

 

[gab_wri]

Salut à tous

@colonies et @Leonick : merci pour vos deux dernières interventions. Elles ont répondu très clairement à ma question.

Je fais un résumé pour les internautes qui se poseraient une question similaire à la mienne
Question : Y a t'il des techniques de programmations js et d'intégration spécifiques aux navigateurs mobiles ?
* Non, exception de faite d'opéra mobile (5 % de mon traffic)
- les css et le html est interprété de la même manière sur les navigateurs desktop courants (firefox, chrome, ie 9 + ..., safari) et les navigateurs mobiles courants (chrome mobile, ff mobile, safari mobile, android browser ...)
- les api js sont aussi bien supportés par les navigateurs desktop courants et les navigateurs mobiles courants.

* La différence du bon affichage d'un site sur mobile et desktop ne dépend pas (ou faiblement) du navigateur mais
- du réseau moins performant lorsque le site est affiché sur mobile
- des processeurs moins véloces sur mobile (sur le smartphone un peu ancien) : le javascript est exécuté moins vite.

* Pour qu'un site s'affiche bien sur mobile, il convient de travailler au maximum les techniques classiques (dans le sens des techniques que l'on utilise aussi pour l'affichage sur desktop) d'optimisation d'un site :
- page html légère
- images légères
- éviter les ressources externes
- utiliser le js avec parcimonie.

------------------------------------------------------------------------------------------------------
Merci pour vos interventions
@leonick : je vais regarder pour installer android sur mon PC desktop.
@caniuse : merci pour le lien vers caniuse.

 

[Leonick]

il faut juste faire attention au fait que, même sur desktop, le js n'est pas compris de la même façon par tous les navigateurs. Et sur mobile c'est plus flagrant. Qu'en plus l'héritage css n'est pas compris non plus pareil : du genre tr+td {}, ainsi que les box relatives aux div
donc attention à ne pas non plus trop utiliser des paramètres préfixés, du genre -moz, etc... car, au final, certains effets se feront sentir sur l'héritage des class

 

[colonies]

mon dieu... :roll:

 

[Leonick]

mon dieu... :roll:

pour quelle raison dis-tu ça ?

 

[colonies]

mon dieu... :roll:

pour quelle raison dis-tu ça ?

il fait un très bon résumé, pourquoi en rajouter avec des trucs généraux et complètement exagérés ?

le JS est, globalement, interprété de la même manière par tous les navigateurs. il peut y avoir des variations dans les objets manipulés comme par exemple dans l'accès aux events, mais elles sont moins fréquentes sur mobile parce que les moteurs sont plus récents. De toute façon les problèmes rencontrés sont globalement les mêmes que sur desktop.
l'héritage CSS "n'est pas compris pareil" sur mobile... mais où tu as vu ça ? l'héritage est rodé depuis des années et des années, ça fonctionne.
TR+TD : c'est quoi le problème ? et ce n'est pas de l'héritage mais un sélecteur.
les "box relatives aux div" : ça ne veut rien dire. Utilises-tu une reset stylesheet ? je n'en ai pas l'impression.
les attributs préfixés perturbent l'héritage des classes : où tu as vu un truc pareil ?

et ça fait suite à la mauvaise compréhension des htaccess et aux hypothèses fantaisistes, au conseil douteux visiblement basé sur aucune expérience de faire une version desktop et une version mobile "responsive" (essaye et on en reparle au bout d'un an. note : je suis dans ce cas depuis des années), ou à celui d'installer Android sur PC : si tu avais essayé de travailler de cette manière, tu aurais vite cherché une solution moins lourde et inefficace. On utilise généralement Chrome avec Emulation dans Outils de développement pour dégrossir le travail, puis on teste téléphone en main. Non seulement ça va beaucoup plus vite mais en plus on obtient de bien meilleurs résultats.

Je rajoute un outil pour le développement : Speed Limit sous OS X qui permet de simuler une connexion lente avec une interface très simple http://mschrag.github.io/ , très pratique combiné à Chrome/Emulation pour avoir une idée très proche de la version mobile en conditions réelles.
Je ne suis que rarement sous Windows et je ne connais pas d'équivalent aussi simple mais c'est bien sûr possible également, avec Fiddler par exemple : http://www.telerik.com/fiddler (beaucoup plus riche, l'équivalent OS X serait plutôt Charles http://www.charlesproxy.com/)

 

[Leonick]

au conseil douteux visiblement basé sur aucune expérience de faire une version desktop et une version mobile "responsive"

je suppose que pour dire ça tu as regardé le code html envoyé par gg pour ses serp selon que tu sois en navigateur mobile ou desktop ? c'est évidemment le même code, avec du js et du css qui sont dans des fichiers externes, comme indiqué dans les directives de gg aux webmasters ?? :roll:

 

[colonies]

oh mais si tu t'appelles Google pas de problème ! tu peux même faire une appli pour iOS, une appli pour Android, des variantes iPad etc...
tu t'appelles Google ? tu as autant d'employés pour se charger de tout ce travail ? tu as déjà essayé de maintenir deux fois plus de pages sur une longue durée pour voir si c'était simple ?

 

[Leonick]

j'ai du mal à comprendre pourquoi tu parles de maintenir 2 ou plusieurs pages ? même dans un développement perso, ça n'est pas dur de faire un template avec conditions et dans les CMS, c'est la base de pouvoir faire son template avec conditions.
donc non, on n'a pas besoin de créer autant de pages que l'on a besoin de code html différents
après, comme tu fais des includes dans tes templates, si tu souhaites modifier le contenu du <head>, rien de plus facile : tu modifie le fichier include.
les applis c'est autre chose, là c'est obligatoirement du développement spécifique. Mais, de toutes façons, pour moi plus de 80% des applis ne se justifient pas : un simple site mobile suffirait. Elles ont donc été créées soit parce que la webagency a réussit à convaincre son client que c'était indispensable, soit c'était pour faire le buzz auprès de ses clients, soit c'est pour récupérer des infos des utilisateurs (parce que, franchement, une appli qui va te calculer ton poids idéal, a-t-elle besoin d'avoir accès à tes sms, ton carnet d'adresses et ta géolocalisation ?)