je laisse en exercice au lecteur le soin de choisir le moyen de détection

Tiens je n’avais pas rebondi là-dessus. Qui a une idée à soumettre sur le sujet ?

Si tu as détecté ton utilisateur comme potentiellement lent (je laisse en exercice au lecteur le soin de choisir le moyen de détection), tu lui proposes la version bas débit avec un gros lien en haut pour retourner vers la version full (au cas où ton moyen de détection est foireux). Si par contre, il a choisi volontairement la version mobile (ie tu lui as collé un cookie), tu ne conserves qu’un lien classique de switch.

Mais :
– si possible basés sur un ralentissement constaté (donc sur la fonctionnalité) pas sur le user-agent (par contre le user agent peut être une raison de proposer en gros en gras sur une page intermédiaire si c’est un user agent de portable)
– de toutes façons proposer un moyen de passer par dessus l’auto détection avec un choix de l’utilisateur

En revanche le cookie et un jeu côté serveur, ça me plaît. Voir http://www.mezzoblue.com/ qui propose un jeu de liens en bas de page : c’est l’utilisateur qui fait le switch.

L’intérêt : j’ai un bas débit, je choisis « mobile », j’ai un iPhone, je choisis « écran » même si je suis en mobile, parce que je suis en 3G – et puis j’ai un mauvais réseau sur mon iPhone, hop je rebascule sur « mobile », et ainsi de suite.

Ca tient principalement au fait que les versions mobiles sont étudiées côté bande passante, cache et quantité d’information. On y met le contenu, dépouillé au maximum, et uniquement le contenu utile.
Pour les versions classiques ils croient que tout le monde a 24Mb/s, 15ms de latence et un Core 2 récent.

Pour ta proposition non, ce n’est pas possible techniquement. Sur une mauvaise connexion les requêtes HTTP coutent chères. Pour connaitre le poids d’un fichier il faudrait déjà faire une requête. Mais surtout ce n’est pas en sucrant les images de contenu qu’on va éviter le problème. Ces grosses images je les veux. Par contre je peux avoir des images de moins bonne qualité, mieux optimisées, etc. Par contre je ne veux pas de ces multiples effets javascript inutiles, de ces design chargés avec 50 image de décoration, etc. Même sans la CSS le sites que j’ai tenté étaient difficiles à charger.

Mais ceux qui ne veulent pas faire de version bas débit peuvent déjà tenter d’améliorer la situation de leur page d’accueil, il y a du boulot à faire pour des résultats concrets et utiles.

Pour Google Reader c’est l’exemple même du fait que bas débit ne veut pas dire peu de contenu. Ca veut dire un contenu adapté : un ration contenu/interface important, un chargement progressif qui me laisse lire le contenu pendant que le reste arrive, que du contenu utile, etc.
Eux n’ont pas de version bas débit, mais la version actuelle passe déjà très bien même à très bas débit justement.

Par « mobile » on pense plutôt à des smartphones et PDA… Je ne suis pas sûr que mélanger « mobile » et « bas débit » soit une bonne idée ? Les usages mobiles sont encore à définir, et à mon sens bien que les progrès des ihm (zoom) aient été énormes ces dernières années on ne va pas offrir les mêmes services à un utilisateur consultant un site sur PDA et un autre sur un micro…

Concernant un accès « bas débit », on pourrait aussi envisager un système sur le navigateur qui permet de ne pas charger les images de plus de n Ko etc… peut être est-ce que cela existe déjà ?

Par ailleurs vous parlez de Google Reader… Avec le RSS il y a toujours un gros fichier à récupérer… Est-ce que l’on y gagne aussi en performances si l’on est en bas débit ?

Mais plus qu’une redirection automatique, un lien en haut de page « Problèmes de chargements ? essayez la version légère » ne coute pas grand chose à faire.

Pour la vitesse de Google Reader, tu as certainement le bénéfice du CDN Google aussi.

Et pour le comble du site mobile plus utile que la version classique, je propose http://voyages-sncf.mobi .

Personnellement, les sites mobiles me servent également avec mon eee pc 701, car avec une diagonale aussi faible, ces sites sont parfait 🙂