1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    juin 2016
    Messages
    142
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2016
    Messages : 142
    Points : 4 736
    Points
    4 736

    Par défaut La largeur de la bande passante d’Internet ne rend pas pour autant la navigation plus rapide

    La largeur de la bande passante d’Internet ne rend pas pour autant la navigation plus rapide
    et un développeur Web explique pourquoi

    Dans un billet de blog, le designer et développeur Nick Heer a vivement décrié ce qu’il appelle le « bullshit web ». Pour lui, le terme « bullshit web » décrit le manque de lien entre la description faite de l’internet actuel et la réalité. Il écrit que la connexion Internet moyenne aux Etats-Unis est environ six fois plus rapide qu’il y a dix ans. Cette vitesse élevée permet peut-être de visionner des films en HD, en 4K ou encore de voir des photos plus détaillées, mais une grande partie de ce que nous voyons n’est qu’une accumulation de déchets, ajoute-t-il.

    Il cite en exemple un article de CNN qui a mis plus de 30 secondes à se charger. La page contenait 11 polices web (414 Ko), 4 feuilles de style (315 Ko), 20 cadres, 29 requêtes HTTP XML (environ 500 Ko) et environ une centaine de scripts ; un grand nombre de ressources n’étant pas directement liées aux informations sur la page. Certains des scripts n’existaient même qu’à des fins de surveillance et de publicité. Précisant que presque toutes les pages d’articles de CNN contenaient des vidéos à lecture automatique, Nick Heer a tenu à rappeler à quel point ces vidéos sont moins appréciées du grand public.

    Nom : Augmenter-la-Bande-Passante-Internet.jpg
Affichages : 6543
Taille : 28,8 Ko

    Les images d’en-tête et les polices web sont autant d’éléments qui, sans pour autant être intrusifs sur le plan offensif, sont souvent inutiles. Établissant un parallèle avec la circulation routière, le développeur commente que la construction de routes plus larges ne réduit pas le temps de déplacement d’un point à un autre. Cela incite juste plus de gens à conduire. Il ajoute que c’est exactement la même situation avec Internet mais avec une bande passante plutôt qu’une voie et des octets plutôt que des voitures.

    Partant de l'hypothèse selon laquelle toute bande passante supplémentaire offerte aux développeurs Web sera immédiatement exploitée, la seule solution envisageable pour Nick Heer serait de réduire la quantité d'octets à transmettre. Et même si on construit spécialement une réplique exacte mobile de chaque page pour être plus rapide, ces répliques dépendent entièrement d’octets supplémentaires. C’est la prémisse d’AMP, un ensemble d'éléments HTML standard et d'éléments spécifiques sur une page spécialement légère qui nécessite un fichier JavaScript de 80 kilo-octets pour être chargé correctement.

    Une série de facteurs fait qu’AMP dépend de Google pour afficher son balisage de base. Ce qui, pour une plateforme aussi ouverte que le web, semble tout particulièrement étrange. Ainsi, selon Nick, si AMP a eu du succès, ce n’est donc pas forcement parce que les pages AMP sont meilleures (même si c’est un élément non négligeable), mais plutôt parce que Google l’a voulu. Il vous suffit de lancer une recherche sur Google pour en avoir la preuve, dit-il. Vous ne verrez que des pages AMP au carrousel d’actualités situé au-dessus des résultats de recherche. Google aurait même ouvertement admis qu’elle faisait la promotion des pages AMP et que le carrousel d’actualités était limité à ces seules pages.

    L’entreprise insiste sur le fait que les pages AMP sont plus rapides et donc meilleures pour les utilisateurs. Nick Heer informe cependant que les pages AMP ne sont pas intrinsèquement plus rapides que les pages non-AMP et que Google a un conflit d'intérêt évident dans la promotion du format. Le secret de la rapidité apparente du format AMP, c’est qu’il restreint les types d'éléments pouvant être utilisés sur une page et limite considérablement les scripts pouvant être utilisés. Ainsi, si vous disposez d’un hôte relativement rapide et que vous n’utilisez pas de scripts sur votre page, vous pourrez obtenir une vitesse comparable à celle des pages AMP.

    « Le bullshit a un effet cumulatif. En isolement, les quelques secondes nécessaires pour charger une partie supplémentaire de surveillance JavaScript ne sont pas très importantes. Il en est de même pour le temps nécessaire pour masquer une boite d’abonnement email ou pour arrêter une vidéo en lecture automatique. Toutefois, ces actions se combinent sur une seule page web, puis sur plusieurs sites web et ces augmentations de temps minimes en apparence finissent par devenir un miasme tourbillonnant de frustration et de douleur », commente Nick Heer.

    Il continue en écrivant que les utilisateurs ont commencé à réellement prendre les choses en main. L’utilisation des bloqueurs de publicité dont certains bloquent même les scripts de suivi est en pleine expansion. Les utilisateurs choisissent désormais de ne plus laisser le « bullshit web » leur dicter comment naviguer. Et c’est un choix que Nick Heer estime que les utilisateurs ne devraient pas avoir à faire. Il estime qu’il relève de la responsabilité des développeurs de faire en sorte que les utilisateurs n’aient pas à affronter de pareilles situations. « Nous ne tolérerions pas un tel comportement intrusif plus généralement, alors pourquoi devrions-nous le trouver acceptable sur le web », conclut-il.

    Il convient cependant de rappeler que la grande majorité des utilisateurs d’Internet n’ont absolument aucune idée de ce qu’est un script et que même après avoir suivi un cours complet sur le sujet, ils ne seraient toujours pas en mesure de bloquer efficacement les scripts.

    Source : Billet de blog

    Et vous ?

    Qu'en pensez-vous ?
    Quelle serait la cause de la lenteur du net malgré la largeur des bandes passantes à votre avis ?
    Pensez-vous comme Nick que la technologie AMP de Google n'est pas vraiment la solution ? Pourquoi ?
    Comment pensez-vous qu'on peut régler ce problème ?

    Voir aussi

    Comment contourner la censure sur Internet ?

    Que se passe-t-il en une minute sur Internet en 2018 ? Quelques statistiques intéressantes qui soulignent la grande activité sur le Web

    La technologie AMP de Google est une menace pour le web ouvert, selon un développeur évoquant des pratiques anticoncurrentielles et monopolistiques

    Google veut propulser de nouveaux standards Web inspirés de sa technologie AMP pour rendre l'ensemble du Web plus rapide

    Le projet AMP de Google est censé être open source et améliorer l'expérience utilisateur mais des rapports remettent en cause ce projet
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre expérimenté
    Homme Profil pro
    Chargé de projet
    Inscrit en
    novembre 2015
    Messages
    385
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Chargé de projet
    Secteur : Industrie

    Informations forums :
    Inscription : novembre 2015
    Messages : 385
    Points : 1 513
    Points
    1 513

    Par défaut

    Les bloqueurs ne répondent pas à toute la problématique soulevé dans cet article ==> ils n'empêchent pas l'envois des scripts non tolérés depuis le site ils se contentent d’empêcher leur affichage ce qui fait que les scripts sont toujours envoyés et pourrissent toujours la bande passante j'ai bon ?
    Pour ne pas passer pour un boulet :
    http://coursz.com/difference-entre-r...-et-gddr4.html

  3. #3
    Membre confirmé

    Homme Profil pro
    Développeur Java
    Inscrit en
    février 2007
    Messages
    155
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Distribution

    Informations forums :
    Inscription : février 2007
    Messages : 155
    Points : 584
    Points
    584

    Par défaut

    Je découvre AMP avec beaucoup de retard.
    C'est quoi ce truc qui sert strictement à rien !
    Ça pallie à l'incompétence des développeurs web mais si un site web est développer avec une idée de performance, AMP c'est nul.

    Un site avec le moins possible de JS (voir pas du tout) et de dépendance extérieur c'est ce qui a de mieux.
    Petit pensée à ceux qui font du Angular / Vue / React avec leur centaines de kilo de dépendance.

    J'ai fait des cours d’accessibilité de page web y'a 10 ans et la taille des pages était un critère important (maintenant les certifications ont baissé les bras et c'est juste un conseil). Et c'est de ça qu'on parle la. Tailles et multiplicité des ressources.
    Bon après le web y'a 10 ans et maintenant c'est pas pareil (mais bon le HTML5 et CSS3 devrait presque suffire à tout faire non ?).

    Donc je pense honnêtement que AMP c'est encore une vieille techno qui a de bons objectifs mais qui est clairement une mauvaise direction. Et en plus Google sponsorise sur leur moteur de recherche ... Donc si tu fais bien sur le site normal et que tu as pas d'AMP qui ne servira à rien, tu sera moins bien référencé qu'un site faisant de la merde mais qui a une version AMP ?
    L'expérience est une lanterne que l'on porte sur le dos et qui n'eclaire jamais que le chemin parcouru.

    La nature fait les choses sans se presser, et pourtant tout est accompli.

  4. #4
    Membre éprouvé

    Homme Profil pro
    Développeur PHP/Symfony // Mentor OpenClassrooms
    Inscrit en
    octobre 2014
    Messages
    202
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hautes Alpes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur PHP/Symfony // Mentor OpenClassrooms
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : octobre 2014
    Messages : 202
    Points : 1 268
    Points
    1 268
    Billets dans le blog
    3

    Par défaut

    @Angelsafrania Je n'irais pas jusqu'à dire que c'est nul si je découvre à peine la technologie, il semble important de bien comprendre l'outil et surtout, de le pratiquer pleinement avant de juger.

    Pour avoir pas mal trifouiller AMP et mis en place pas mal de solution proposée, il est tout à fait acceptable d'user d'AMP et ce, malgré que Google le recommande et le vende alors que des solutions tierces existents.

    Il faudrait voir à ne pas oublier que de nos jours, ce ne sont pas tant les pages qui sont lentes mais bien les contenus chargés qui deviennent lourds inutilement, une feuille CSS ou un fichier JS, ça n'a jamais détruit le chargement d'une page, une image non-optimisée/non-compressée, oui, ça flingue très rapidement l'expérience et les performances.

  5. #5
    Membre expert Avatar de Zefling
    Homme Profil pro
    Développeur Web
    Inscrit en
    avril 2007
    Messages
    917
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : avril 2007
    Messages : 917
    Points : 3 234
    Points
    3 234

    Par défaut

    Citation Envoyé par Angelsafrania Voir le message
    Je découvre AMP avec beaucoup de retard.
    C'est quoi ce truc qui sert strictement à rien !
    Ça pallie à l'incompétence des développeurs web mais si un site web est développer avec une idée de performance, AMP c'est nul.
    Perso, j'avais regardé puis quand après une analyse du truc, je voyais pas l'intérêt de le mettre en place.
    J'ai aussi essayé l'installation d'un module de compression de pages apache (aussi de Google), mais à part flinguer mon disque avec du cache à gogo et péter quelques uns des mes scripts, j'avais pas l'impression de gagner beaucoup sur du gzip.

    Citation Envoyé par Angelsafrania Voir le message
    Petit pensée à ceux qui font du Angular / Vue / React avec leur centaines de kilo de dépendance.
    Pour Angular la comparaison est un peu foireuse, car une fois chargée, c'est une grosse parties de l'ensemble qui ne sera plus rechargé à chaque changement de page, tout est déjà en mémoire. Il y a juste le démarrage qui est bien lourd, c'est comme lancer une application.
    Mon blog de développeur web.

    Projet : BakuJS

  6. #6
    Membre confirmé

    Homme Profil pro
    Développeur Java
    Inscrit en
    février 2007
    Messages
    155
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Distribution

    Informations forums :
    Inscription : février 2007
    Messages : 155
    Points : 584
    Points
    584

    Par défaut

    Citation Envoyé par Zefling Voir le message
    Pour Angular la comparaison est un peu foireuse, car une fois chargée, c'est une grosse parties de l'ensemble qui ne sera plus rechargé à chaque changement de page, tout est déjà en mémoire. Il y a juste le démarrage qui est bien lourd, c'est comme lancer une application.
    C'est pas vraiment foireux parce que pour avoir accès à une page en particulier (ce que tu fais régulièrement avec un moteur de recherche), tu dois DL l'intégralité du framework pour finalement pas beaucoup de chose vraiment utile (l'information que tu cherches vraiment).
    Dans le cadre d'une application métier je vois l'utilité (je l'utilise même). Mais pour un site grand publique là j'ai déjà plus de mal à voir l'intérêt (il doit avoir des cas où ça se justifie j'en suis persuadé mais pas la majorité des cas).
    L'expérience est une lanterne que l'on porte sur le dos et qui n'eclaire jamais que le chemin parcouru.

    La nature fait les choses sans se presser, et pourtant tout est accompli.

  7. #7
    Membre éclairé Avatar de 4sStylZ
    Homme Profil pro
    Null
    Inscrit en
    novembre 2011
    Messages
    245
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Null
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 245
    Points : 705
    Points
    705

    Par défaut

    +1 pour la comparaison complètement foireuse avec Angular. Ces framework (Angular et autres) sont fait pour répondre au challenge des Single-page-application. C’est à dire une appli web en une page qu’on met en cache une fois et qui ne sera longue à démarrer que si la version de l’appli change ou si l’utilisateur vide son cache / n’en utilise pas.

    Une fois l’appli chargée, tout n’est que web-service et communication essentielle. On ne charge rien du tout des polices etc.

    Bref c’est pas fait pour des sites web classique à grand trafic.

  8. #8
    Membre expert
    Avatar de Metalman
    Homme Profil pro
    Doctorant - Ingénieur Sys/Réseau/Sécu
    Inscrit en
    juin 2005
    Messages
    1 044
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Doctorant - Ingénieur Sys/Réseau/Sécu
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2005
    Messages : 1 044
    Points : 3 454
    Points
    3 454

    Par défaut

    Je n'ai "jamais" compris l'intérêt des "single-page-application"... quand je fais "refresh", je perds tout... quand je fais "back", je reviens sur un autre site...
    En fait : tout ce qui faisait que l'on "pouvait" naviguer sur le web dans de bonnes conditions est aujourd'hui évité....... sachant que nos browsers sont censés avoir été optimisés entre temps...

    Bref : vivement la fin de JS et autres frameworks cassant http.... OU alors inventez autre chose que http ! Je sais pas... JStp, tiens...
    --
    Metalman !

    Attendez 5 mins après mes posts... les EDIT vont vite avec moi...
    Les flags de la vie : gcc -W -Wall -Werror -ansi -pedantic mes_sources.c
    gcc -Wall -Wextra -Werror -std=c99 -pedantic mes_sources.c
    (ANSI retire quelques fonctions comme strdup...)
    L'outil de la vie : valgrind --show-reachable=yes --leak-check=full ./mon_programme
    Et s'assurer que la logique est bonne "aussi" !

    Ma page Developpez.net

  9. #9
    Nouveau membre du Club
    Profil pro
    Inscrit en
    avril 2008
    Messages
    35
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : avril 2008
    Messages : 35
    Points : 35
    Points
    35

    Par défaut

    Ca ressemble un peu à ça quand même :-)
    https://fr.wikipedia.org/wiki/Paradoxe_de_Jevons

  10. #10
    Expert éminent sénior

    Avatar de Neckara
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2011
    Messages
    6 917
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 25
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2011
    Messages : 6 917
    Points : 18 398
    Points
    18 398

    Par défaut

    Citation Envoyé par Metalman Voir le message
    Je n'ai "jamais" compris l'intérêt des "single-page-application"... quand je fais "refresh", je perds tout... quand je fais "back", je reviens sur un autre site...
    Personnellement j'ai un vrai-faux site one-page.

    Tu navigues comme sur un site normal, alors qu'en réalité il n'y a qu'une seule page qui ne se recharge pas, et au sein de laquelle des éléments apparaissent ou disparaissent.

    Derrière, je gère l'historique via JS, donc si tu fais un refresh ou un "back", tu auras le même comportement que sur un site multi-page.
    On dit "chiffrer" pas "crypter" !

    On dit "bibliothèque" pas "librairie" !

    Ma page DVP : http://neckara.developpez.com/

  11. #11
    Membre éprouvé
    Profil pro
    Inscrit en
    mai 2011
    Messages
    424
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2011
    Messages : 424
    Points : 908
    Points
    908

    Par défaut

    Citation Envoyé par Metalman Voir le message
    Je n'ai "jamais" compris l'intérêt des "single-page-application"... quand je fais "refresh", je perds tout... quand je fais "back", je reviens sur un autre site...
    En fait : tout ce qui faisait que l'on "pouvait" naviguer sur le web dans de bonnes conditions est aujourd'hui évité....... sachant que nos browsers sont censés avoir été optimisés entre temps...

    Bref : vivement la fin de JS et autres frameworks cassant http.... OU alors inventez autre chose que http ! Je sais pas... JStp, tiens...
    Si tu as jamais developpé de logiciel tu ne peux pas comprendre. Mais en gros le développement copie exatement les mêmes trucs que le développement logiciel. L'eau chaude est la même depuis plsu de 10 ans, c'est juste que c'était pas possible en web. En gros tout ce que tu vois dans swing va venir dans le web. Un SPA c'est simplement un logiciel mais dans le browser. Tu regardes un peu Flutter, on dirait du swing en version dart. Les Web Components sont des components comme en logiciel, la flexbox, sa vient de la stack (mode horizontal, vertical). Si tu veux voir vers quoi on va, va juste developper un logiciel. Ce sera exactement ça.

  12. #12
    Membre à l'essai
    Inscrit en
    mai 2007
    Messages
    2
    Détails du profil
    Informations forums :
    Inscription : mai 2007
    Messages : 2
    Points : 11
    Points
    11

    Par défaut

    Si tu as jamais developpé de logiciel tu ne peux pas comprendre. Mais en gros le développement copie exatement les mêmes trucs que le développement logiciel. L'eau chaude est la même depuis plsu de 10 ans, c'est juste que c'était pas possible en web. En gros tout ce que tu vois dans swing va venir dans le web. Un SPA c'est simplement un logiciel mais dans le browser. Tu regardes un peu Flutter, on dirait du swing en version dart. Les Web Components sont des components comme en logiciel, la flexbox, sa vient de la stack (mode horizontal, vertical). Si tu veux voir vers quoi on va, va juste developper un logiciel. Ce sera exactement ça.
    le principe même des SPA est une aberration; à l'origine, le web a été fait pour partager du contenu essentiellement, avec quelques traitements graphiques limités fait en Javascript. D'ailleurs, le fait que Javascript soit entièrement dynamique venait justement que l'on manipulait un DOM que l'on ne connaissait pas du tout. Avec les SPA, c'est tout autre chose; les applications sont en gros des applications client-serveur classique, sauf pour le déploiement qui est fait par le web, parce que les exploitant n'ont JAMAIS été foutu de gérer correctement le déploiement d'application (c'est de loin la principale raison pourquoi ils adoptent les applications web). Le problème, c'est que la quantité de code javascript devient beaucoup plus importante et comme le langage n'est absolument pas adapté pour cela (en gros, pas de modularité, du code tellement dynamique qu'il devient impossible de comprendre son fonctionnement par la lecture ce qui oblige à généraliser le test automatique et rajoute donc du temps de développement qui rend le langage moins productif qu'un langage statiquement typé), les applications deviennent des cauchemars de maintenance et sont très difficile à optimiser.
    Après, certains me diront qu'il existent des solutions pour rendre le javascript plus typé et plus modulaire (par exemple typescript), c'est à dire à utiliser autre chose que javascript...et dans ce cas, pourquoi le défendre? quand on voit les performances déplorables de ce langage (ouais, je suis fier d'avoir refait doom en javascript aussi rapide que la version native vieille de....plus de 20 ans) et les efforts faits pour le rendre utilisable (intégration d'un compilateur dans le browser) ne serait-il pas plutôt plus intelligent de revenir au bon vieux client-serveur en généralisant les appStore pour le déploiement?
    Je rappelle quand même que si l'application javascript devient lourde à déployer, ça revient au même en terme de performance au démarrage de le faire dans une application client serveur classique. En plus cette dernière offre bien d'autres avantages: déploiement à la demande (et non pas systématiquement comme en web, je n'ai pas nécessairement envie d'utiliser la dernière version buggée de l'appli), application plus réactive (la comparaison entre du code natif d'IHM et du code javascript), code plus maintenable et plus rapide...

    La folie autour du javascript me rappelle celle autour de XML; à l'époque, certains avaient proposé de TOUT spécifier en XML; on avait par exemple du langage de requête type SQL en XML (et bien sûr totalement illisible) et maintenant au final on laisse tomber le XML partout soit disant parce qu'il n'a pas tenu ses promesses....qui n'ont jamais été d'être utilisé partout. C'est pareil pour javascript: laissons le pour les petits scripts d'affichage et l'appel de web services (et surtout pas au niveau du serveur, quel horreur!) et programmons avec des langages adaptés pour les grandes quantités de code (au hasard, Java, C#) pour les applications.

  13. #13
    Membre éprouvé
    Profil pro
    Inscrit en
    mai 2011
    Messages
    424
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2011
    Messages : 424
    Points : 908
    Points
    908

    Par défaut

    Citation Envoyé par xmornard Voir le message
    La folie autour du javascript me rappelle celle autour de XML; à l'époque, certains avaient proposé de TOUT spécifier en XML; on avait par exemple du langage de requête type SQL en XML (et bien sûr totalement illisible) et maintenant au final on laisse tomber le XML partout soit disant parce qu'il n'a pas tenu ses promesses....qui n'ont jamais été d'être utilisé partout. C'est pareil pour javascript: laissons le pour les petits scripts d'affichage et l'appel de web services (et surtout pas au niveau du serveur, quel horreur!) et programmons avec des langages adaptés pour les grandes quantités de code (au hasard, Java, C#) pour les applications.
    Ah je ne connaissais pas cette histoire de XML qui voulait remplaçé le SQL. Je crois que même aujourd'hui on l'a toujours pas résolu de problème de déploiement malheuresement.

  14. #14
    Membre éprouvé

    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2013
    Messages
    466
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2013
    Messages : 466
    Points : 1 237
    Points
    1 237

    Par défaut

    <citation>
    Angelsafrania - Membre confirmé
    le 07/08/2018 à 11:16
    ...
    J'ai fait des cours d’accessibilité de page web y'a 10 ans et la taille des pages était un critère
    </citation>

    Désolé le lien répondre avec citation n'était pas accessible.

    Tu as fait quoi lors de tes cours d'accessibilité ?
    Ca m'intéresse car beaucoup de développeur ne sont pas sensibilisé ou formés

    La taille du document est un facteur.
    En premier lieu plus il y a d'informations, et plus on doit rechercher le contenu, mais ce n'est pas un problème de Js.
    C'est pourquoi si le contenu est sous un titre de niveau 1, ça aide à trouver.

    Surtout que le lecteur d'écran analyse la page et fait une version à plat, et il doit attendre que la page soit chargée.
    Sans parler du Js qui ne gère pas le clavier.

    Il y a aussi une fronde d'utilisateur, qui sont agacés de télécharger de mo pour rien, surtout sur mobile.
    Une des idées du projet Weboob était d'aller à l'essentiel, de faire un navigateur textuel

    https://fr.wikipedia.org/wiki/Weboob

    Et pour tester l'accessibilité on peut aussi on peut travailler depuis un navigateur textuel comme Lynx
    Consultez mes articles sur l'accessibilité numérique :

    Comment rendre son application SWING accessible aux non voyants
    Créer des applications web accessibles à tous

    YES WE CAN BLANCHE !!!

    Rappelez-vous que Google est le plus grand aveugle d'Internet...
    Plus c'est accessible pour nous, plus c'est accessible pour lui,
    et meilleur sera votre score de référencement !

Discussions similaires

  1. Serveur dedié et bande passante ?
    Par ShinJava dans le forum Hébergement
    Réponses: 9
    Dernier message: 03/06/2005, 10h29
  2. [Stratégie] Limiter la bande passante
    Par Neuromancer dans le forum Développement
    Réponses: 7
    Dernier message: 17/01/2005, 15h29
  3. Appication Client/serveur : Limiter la bande passante ?
    Par souch dans le forum Web & réseau
    Réponses: 8
    Dernier message: 25/07/2004, 14h53
  4. Limiter la bande passante
    Par naili dans le forum Réseau
    Réponses: 3
    Dernier message: 15/01/2004, 08h21
  5. [Bande passante]
    Par Alexr dans le forum Développement
    Réponses: 7
    Dernier message: 12/09/2003, 14h36

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo