If (BP < 56k) then CSS dépouillé

Salut à tous,

Je ne suis pas codeur. Ma question risque d'en faire rire plus d'un, mais au moins, j'aurai eu le pouvoir d'illuminer leur journée un bref instant, donc ce n'est pas du temps perdu...


Récemment, j'ai mis mon blog en ligne, conforme w3c xhtml strict, erreurs corrigés, compatibilité de rendu FF/IE, etc. seulement, sa lecture est confortable sur l'adsl, mais cela le sera moins sur un 56K, la page mettra environ 20 sec. à charger (peu ou prou), en partie à cause de divers éléments graphiques chargés en php (dans le contenu des billets) ou par les css (pour le design). Mais l'ensemble reste trés raisonnable.

Ma première réflexion a été de me dire : j'ai optimisé mes images, j'ai optimisé le xhtml, les css, je ne peux plus rien faire, ou sinon ce sera au détriment du webdesign. Comme les 56K ne représentent plus qu'une minorité de malchanceux de l'arrière-pays, tant pis, ils attendront.

Mais dernièrement, je me suis posé une question simple pour contenter (éventuellement) tout le monde :

est-il possible, par l'intermédiaire du Javascript, de tester rapidement le débit, ou le type de connexion (par la modulation par exemple) dont dipose un internaute ?

Pas besoin d'un test précis, juste de savoir s'il est en 56 k et moins. L'objectif serait le suivant :

a écrit :
si (débit <= 56k), alors chargement d'un CSS dépouillé
sinon chargement du CSS normal

Mon raisonnement tient la route, je pense, mais je ne sais pas du tout s'il est réalisable, et c'est donc ce que je vous demande.

Merci.

Modifié par Nawak (09 Mar 2007 - 19:41)

Bonjour,

Faisons simple:

Non.

Nawak a écrit :
mais au moins, j'aurai eu le pouvoir d'illuminer leur journée un bref instant, donc ce n'est pas du temps perdu...

Gagné !

La question est intéressante mais je crains fort que Laurent Denis ait raison relativement à une mesure directe et fiable par l'intermédiaire de JavaScript.
Je crois néanmoins, car on n'en n'est pas à 50 Kb/s près dans l'estimation, qu'il peut exister un moyen de l'estimer très approximativement.
Je réfléchis j'éssaye et te recontacte.

Comme promis.

J'ai trouvé une solution.

Attention : Du fait de l'imprécision des timers qui rendra une erreur sur la détection exacte de la fin , de... tout ce qui fait que Laurent Denis a justement répondu non à ta question, cela ne donnera évidemment pas une mesure exacte.

Mais cela donne une approximation suffisante pour distinguer :

Un modem 28 k d'un modem 56 k d'une connexion haut débit, d'une connexion locale.

Et comme... ces débits sont eux-même des approximations moyennes...

Je sais, j'ai éssayé.

Comme... c'est à mon tour d'illuminer ta journée... je ne te livre que le principe en pseudo code...
A toi de t'amuser à le coder.

Si tu n'y arrives pas, je te donnerai mon code.

Principe : On télécharge un fichier, on mesure le temps nécessaire à ce téléchargement et on divise la taille du fichier par le temps mis pour le téléchargement.
---------
Fonction qui initialise le calcul
.....initialisation du moment de début. (getTime sur un objet obtenu avec new Date)
.....initialisation du téléchargement (set du src d'un objet obtenu avec new Image)
.....initialisation d'un compteur de boucles
.....armement de la boucle d'attente (fonction boucle armée par un setTimeout et un délai de disons 100 ms)
----------
Fonction de boucle
.....incrémentation du compteur de boucles
.....Si ce compteur atteint une valeur trop élevée (telle que 100*compteur est irréaliste eu égard à la taille de l'image à télécharger)
..........Appel de la fonction de résultat avec un parametre négatif
.....sinon
..........Si le téléchargement est terminé (Test de la propriété complete de l'objet image)
...............Initialisation du moment de fin (getTime sur un autre objet date)
...............Appel de la fonction de résultat avec le débit (Taille fichier en octets/ Différence des deux dates) en paramètre
..........sinon
...............réarmement de la boucle d'attente avec setTimeout
------------
Fonction de résultat
.....Un switch case sur la valeur du paramètre.

Nota 1: Sois un peu large relativement aux bornes de tests de la valeur du débit :

parametre négatif : Pas de connexion
Entre 0 et 3.5 : Modem 28k
Entre 3.5 et 6.5 : Modem 56 k
Entre 6.5 et 100 : Adsl haut débit
Supérieur à 100 : Local.

Voilà. J'espère avoir répondu à ta question.

Nota 2 : Prends un fichier un peu gros (32k) pour limiter les erreurs...
Enjoy !
Modifié par aCOSwt (14 Mar 2007 - 10:04)

Julien Royer a écrit :
Salut,

Les objets Image gèrent les événements load, error et abort qui sont bien plus fiables qu'une boucle avec un test sur la propriété complete.

Exact mais j'avoue que je connais pas les conditions exactes de survenance des ces événements. Priorités relatives... délais... masquages... ? Je ne sais pas comment ils sont gérés en interne.
Alors je recours au bête polling qui est, ce dit en passant, la méthode traditionnelle de mesure de n'importe quel phénomène sous un OS en temps partagé.
Modifié par aCOSwt (14 Mar 2007 - 10:19)

aCOSwt a écrit :
Alors je recours au bête polling qui est, ce dit en passant, la méthode traditionnelle de mesure de n'importe quel phénomène sous un OS en temps partagé.

Sauf que JavaScript est justement un langage événementiel.

Julien Royer a écrit :
Sauf que JavaScript est justement un langage événementiel.

Soit. Mais cela ne change en rien la nature de L'O.S qui supporte l'implémentation.
J'ai toujours eu beaucoup de mal à comprendre comment intégrer proprement une gestion événementielle sous un O.S. non temps réel.
J'ai collaboré avec SAP sur leur couche de gestion événementielle. C'est vraiment sujet à cauchemards. Au point que même quand ça marche, on se demande toujours comment ça peut.

Il n'empèche, si tu as des pistes de documents relativement à la gestion bas niveau des événements javascripts, je suis intéressé.

Salut,

Pardon pour la réponse tardive, j'étais en Bretagne ces derniers jours, d'où mon sevrage forcé d'internet (hmm... je ne veux pas insinuer par là que ce sont des sauvageons, mais que j'avais simplement d'autres chats à fouetter).

a écrit :
Nota 2 : Prends un fichier un peu gros (32k) pour limiter les erreurs...

Ok, le principe fonctionne, et donc, oui, c'est possible dans une certaine mesure. Mais comme l'objectif premier était d'optimiser et d'alléger éventuellement un site, il me fallait une fontion simple, courte, efficace pour savoir si j'avais affaire à un débit raisonnable (ou pas), et ce, en moins de temps qu'il ne faut pour le dire.

Le fait de charger un fichier qui sera aussi lourd que ma page enlève tout l'intérêt à la chose, si ce n'est la beauté du sport et le plaisir de se triturer le cerveau pour parvenir à ses fins.


Mais je te remercie de t'être penché sur le problème !
Bonne journée.

Modifié par Nawak (17 Mar 2007 - 14:43)