Quand l'amélioration progressive est-elle rentable pour une application qui a de toute façon besoin de JavaScript ?

Question ouverte

L'amélioration progressive construit une page en couches : du HTML qui fonctionne seul, du CSS qui améliore la présentation, du script qui ajoute du comportement. Le manuel des services du GOV.UK recommande cette approche pour les services publics. Le wiki aimerait savoir à quoi ressemble la décision pour des applications qui, légitimement, ne peuvent pas fonctionner sans script, comme les éditeurs, les tableaux de bord, le chat et les outils temps réel. Quelles parties d'une telle application méritent malgré tout une base qui fonctionne sans script ou avec un chargement de script partiellement échoué, et comment une équipe devrait-elle décider à partir de preuves ?

Sous-questions :

• Quelle part des pages vues perd le script pour un public donné, et pour quelles causes : téléchargements échoués ou expirés sur des réseaux lents, blocage par des proxys ou des extensions, erreurs d'exécution sur des navigateurs plus anciens, script servi avec le mauvais type MIME ? Comment cette part se mesure-t-elle de façon fiable ?
• Le rendu serveur avec hydratation, que de nombreux frameworks pratiquent par défaut, apporte-t-il déjà l'essentiel du bénéfice (premier rendu, indexabilité, résilience pendant le chargement du script), au point qu'un parcours sans script séparé apporte peu ?
• Quelles interactions ont la plus grande valeur par ligne de code de repli ? Les formulaires et la navigation sont les candidats habituels ; le glisser-déposer ou la collaboration en direct ne le sont pas.
• Que coûte le second chemin de code sur la durée de vie d'un projet, en tests et en dérive, et quand ce coût est-il inférieur aux incidents qu'il évite ?
• Comment les agents et les robots d'indexation qui n'exécutent pas de script modifient-ils le calcul pour le contenu qui doit rester trouvable ?

Ce qu'une réponse utile contient

• Un protocole de mesure pour « le script ne s'est pas exécuté » (par exemple un signal dans un élément noscript combiné à une comparaison côté serveur entre les envois de formulaires HTML classiques et les envois basés sur fetch), avec des résultats répartis par classe d'appareil et par réseau.
• Une règle de décision avec des catégories : repli recommandé, facultatif, non rentable, chacune avec son raisonnement.
• Des observations de coût provenant d'au moins une application protégée par connexion, en nommant le réglage du framework (rendu serveur, hydratation, îlots ou client seul) afin que les chiffres soient comparables.
• L'angle accessibilité : quels replis vers des contrôles natifs aident les utilisateurs du clavier et des lecteurs d'écran indépendamment du script.
• Des limites explicites : quels publics et quels types d'application la réponse couvre, et lesquels elle ne couvre pas.