¿Cuándo resulta rentable la mejora progresiva en una aplicación que de todos modos necesita JavaScript?

Pregunta abierta

La mejora progresiva construye una página por capas: HTML que funciona por sí solo, CSS que mejora la presentación, script que añade comportamiento. El manual de servicios de GOV.UK recomienda este enfoque para los servicios públicos. La wiki quiere saber cómo se plantea esta decisión en aplicaciones que legítimamente no pueden funcionar sin script, como editores, paneles de control, chats y herramientas en tiempo real. ¿Qué partes de una aplicación así siguen mereciendo una base que funcione sin script o con una carga de script parcialmente fallida, y cómo debería decidir esto un equipo con evidencia?

Subpreguntas:

• ¿Qué proporción de las vistas de página pierde el script para una audiencia determinada, y por qué causas: descargas fallidas o que exceden el tiempo de espera en redes lentas, bloqueo por proxies o extensiones, errores en tiempo de ejecución en navegadores antiguos, script servido con el tipo MIME incorrecto? ¿Cómo se mide esa proporción de forma fiable?
• ¿El renderizado en servidor con hidratación, como hacen muchos frameworks por defecto, ya aporta la mayor parte del beneficio (primer renderizado, rastreabilidad, resiliencia mientras carga el script), de modo que una vía separada sin script aporta poco?
• ¿Qué interacciones tienen el mayor valor por línea de código de reserva (fallback)? Los formularios y la navegación son los candidatos habituales; el arrastrar y soltar o la colaboración en vivo no lo son.
• ¿Cuánto cuesta la segunda vía de código a lo largo de la vida de un proyecto, en pruebas y desviación (drift), y cuándo es ese coste menor que los incidentes que evita?
• ¿Cómo cambian los agentes y los rastreadores que no ejecutan script el cálculo para el contenido que debería ser localizable?

Qué contiene una respuesta útil

• Un protocolo de medición para «el script no se ejecutó» (por ejemplo, una baliza en un elemento noscript combinada con una comparación en el servidor entre envíos de formularios HTML planos y envíos basados en fetch), con resultados desglosados por tipo de dispositivo y red.
• Una regla de decisión con categorías: fallback recomendado, opcional, no rentable, cada una con su razonamiento.
• Observaciones de coste de al menos una aplicación que requiere inicio de sesión, indicando la configuración del framework (renderizado en servidor, hidratación, islas o solo cliente) para poder comparar las cifras.
• El ángulo de accesibilidad: qué alternativas de controles nativos ayudan a las personas usuarias de teclado y lector de pantalla independientemente del script.
• Límites explícitos: qué audiencias y tipos de aplicación cubre la respuesta y cuáles no.