Los formularios que declaran restricciones nativas de HTML producen menos rechazos de validación en el servidor por envío que los formularios validados solo con JavaScript personalizado

Hipótesis

La validación en el servidor es obligatoria; la validación en el cliente existe para que la mayoría de los envíos nunca la activen. Hay dos formas de ofrecer la parte del cliente: los atributos de restricción nativos en los controles (required, type, pattern, min, max, maxlength), que el navegador comprueba antes de un envío interactivo, o un script personalizado que inspecciona los valores y bloquea el evento submit. La guía de MDN sobre la validación de restricciones describe el mecanismo nativo y sus límites: un atributo novalidate en el formulario desactiva la validación interactiva, y llamar al método submit() del formulario envía los datos al servidor aunque no cumplan las restricciones. Un patrón habitual es escribir validación personalizada para los estilos y los mensajes, y dejar por el camino los atributos nativos. La hipótesis es que los formularios cuyos atributos nativos reflejan las reglas del servidor producen menos rechazos de validación en el servidor por envío que los formularios validados solo por script, y que la diferencia procede sobre todo de las sesiones en las que el script no se ejecutó: no se cargó, lanzó un error antes de asociar sus manejadores, o no cubrió las rutas de autocompletado y de pegado.

Predicción

En una comparación A/B del mismo formulario con y sin atributos de restricción nativos, manteniendo ambas variantes el mismo script personalizado y las mismas reglas de servidor, la variante con atributos nativos muestra una tasa menor de rechazos de validación en el servidor por envío. La brecha se concentra en las sesiones con un error de script o sin el marcador de disponibilidad del script, y es cercana a cero donde el script se ejecutó; las categorías de rechazo que se reducen son las que los atributos nativos pueden expresar (campos obligatorios ausentes, correo electrónico mal formado, números fuera de rango), no las reglas entre campos. Si las tasas de rechazo son iguales, o la brecha no se concentra en las sesiones con fallo del script, la hipótesis es falsa.

Prueba propuesta

1. Elegir un formulario público con unos pocos miles de envíos al mes y un servidor que devuelva errores de validación estructurados por campo.
2. Construir la variante A con atributos nativos que coincidan con las reglas del servidor campo por campo, y la variante B con esos atributos eliminados; mantener idénticos el script, el diseño y los mensajes. Asignar a las personas visitantes mediante un hash estable.
3. Añadir un campo oculto que el script establezca cuando se asocian sus manejadores, de modo que el servidor pueda saber si el script se ejecutó; registrar los errores del script junto con la variante.
4. Durante cuatro semanas, registrar por envío: la variante, el marcador de ejecución del script, si hubo rechazo (sí o no) y los campos rechazados con sus categorías de regla.
5. Comparar las tasas de rechazo por variante en conjunto y desglosadas por el marcador; informar los recuentos y los intervalos, y enumerar las categorías de regla que difieren.

Estado

No se afirma ningún resultado. Si el script es fiable y en los navegadores de la audiencia rara vez deja de ejecutarse, la diferencia puede ser demasiado pequeña para medirla en cuatro semanas; ese resultado indicaría por sí mismo cuánto aporta la capa nativa para esa audiencia.