La innovación no puede mantener la Web rápida

De vez en cuando, los frutos de la innovación dan frutos en forma de mejoras en las capas fundamentales de la web. En 2015, HTTP/2 se convirtió en un estándar publicado en un esfuerzo por actualizar un protocolo antiguo. Esto era necesario y estaba atrasado, ya que HTTP/1 convirtió el rendimiento web en una especie de disciplina arcana en forma de extrañas soluciones a sus limitaciones. Aunque la proliferación de HTTP/2 no es absoluta (y aún quedan problemas por resolver ), no creo que sea exagerado decir que la web está mejor gracias a ella.

Desafortunadamente, la implementación de HTTP/2 ha presidido un aumento medio del 102% en bytes transferidos a través de dispositivos móviles en los últimos cuatro años . Si observamos el percentil 90 ^de ese mismo conjunto de datos (porque en realidad es la larga cola de rendimiento que necesitamos optimizar), vemos un aumento del 239 % . Desde 2016 (advertencia en PDF) hasta 2019 , la velocidad promedio de descarga móvil en los EE. UU. aumentó un 73%. En Brasil e India, las velocidades promedio de descarga móvil aumentaron un 75% y un 28%, respectivamente, en ese mismo período de tiempo.

Si bien el peso de la página por sí solo no necesariamente cuenta toda la historia de la experiencia del usuario, es, como mínimo , un fenómeno vagamente relacionado que amenaza la experiencia colectiva del usuario. La historia que HTTPArchive cuenta a través de los datos adquiridos de Chrome User Experience Export (CrUX) se puede interpretar de diferentes maneras, pero este hecho es firme e implacable: la mayoría de las métricas obtenidas de CrUX en los últimos años muestran poco, si ninguna mejora a pesar de varias mejoras en los navegadores, el protocolo HTTP y la propia red.

Dadas estas tendencias, todo lo que se puede decir sobre el impacto de estas mejoras en este momento es que han ayudado a detener la marea de nuestros excesos, pero muy poco a reducirlos . A pesar de cada mejora significativa en los cimientos de la web y las redes a través de las cuales accedemos a ella, continuamos construyendo para ella de maneras que sugieren que estamos contentos con la interminable paradoja de Jevons en la que trabajamos.

Si queremos avanzar en la creación de una Web más rápida para todos, debemos reconocer algunos de los impedimentos para lograr ese objetivo:

1. El deseo implacable de monetizar cada centímetro cuadrado de la web, así como el ejército de proveedores externos que alimentan la investigación exigida por esfuerzos tan febriles.
2. Culturas en el lugar de trabajo que favorecen el desarrollo desenfrenado impulsado por funciones. Esta práctica se suma a lo que les transmitimos a los usuarios, pero rara vez les resta valor.
3. Comodidades para el desarrollador que facilitan el trabajo del desarrollador, pero que pueden suponer un coste cada vez mayor para el cliente.

Contrariamente a la intuición, los propietarios de bases de código maduras que incorporan algunos o todos estos rasgos continúan tomando el mismo camino insostenible hacia la rentabilidad que siempre han tenido. Lo hacen bajo su propio riesgo, en lugar de reconocer el hecho repetidamente establecido de que las prácticas de desarrollo que priorizan el rendimiento harán tanto (o más) por sus resultados y la experiencia del usuario.

Es con este entendimiento que he llegado a aceptar que nuestro enfoque actual para remediar el bajo rendimiento consiste en gran medida en técnicas de ingeniería que surgen de los efectos nocivos de nuestro negocio, gestión de productos y prácticas de ingeniería. Somos buenos aplicando torniquetes, pero no tan buenos cosiendo heridas profundas.

Cada vez está más claro que el rendimiento web no es únicamente un problema de ingeniería, sino también un problema de personas . Se trata de una evaluación poco atractiva, en parte porque las soluciones técnicas son comparativamente indiscutibles. La compresión de contenido funciona. La minificación funciona. La sacudida de árboles funciona. La división de código funciona . Son innegablemente soluciones efectivas a lo que pueden parecer problemas enteramente técnicos.

La intersección entre el rendimiento web y las personas, por otro lado, es confusa e inconveniente. A diferencia de una solución técnica tan claramente beneficiosa como HTTP/2, ¿cómo calificamos cómo son las culturas de desempeño exitosas? ¿Cómo calificamos los enfoques exitosos para llegar allí? No sé exactamente cómo se ve eso, pero creo que un buen modelo es la siguiente combinación de principios culturales y de ingeniería:

1. Una organización no puede tener éxito en priorizar el desempeño si no puede asegurar el apoyo de sus líderes . Sin ese elemento crucial, resulta extremadamente difícil para las organizaciones crear una cultura en la que el desempeño sea la característica principal de su producto.
2. Incluso con el apoyo del liderazgo, no se puede priorizar el desempeño de manera efectiva si no existe la telemetría para medirlo. Sin medición, resulta imposible explicar cómo el desarrollo de productos afecta el desempeño. Si no se tienen los números, a nadie le importará el desempeño hasta que se convierta en una aparente crisis.
3. Cuando se cuenta con el apoyo del liderazgo para hacer del rendimiento una prioridad y la telemetría para medirlo, todavía no se puede lograrlo a menos que toda la organización comprenda el rendimiento web. Este es el momento en el que se desarrolla e implementa capacitación, documentación, mejores prácticas y estándares que la organización puede adoptar. En cierto modo, este es el espacio en el que las organizaciones ya han pasado mucho tiempo, pero el trabajo desafiante consiste en establecer circuitos de retroalimentación para evaluar qué tan bien entienden y han aplicado ese conocimiento.
4. Cuando todas las demás piezas finalmente estén en su lugar, podrá comenzar a crear responsabilidad en la organización en torno al desempeño. La responsabilidad no se presenta en forma de represalias cuando su telemetría le indica que el rendimiento ha sufrido con el tiempo, sino más bien en forma de barreras de seguridad colocadas en el proceso de implementación para alertarle cuando se han cruzado los umbrales.

Ahora viene lo bueno: incluso si todas estas cosas se juntan en su lugar de trabajo, no se garantizan buenos resultados. Salvo alguna regulación que nos obligue a abordar los sitios web de bajo rendimiento a nuestro cargo (similar a cómo la ADA nos mantiene alerta con respecto a la accesibilidad), será necesario un evangelismo y presión continuos para garantizar que el rendimiento siga siendo una prioridad. Como gran parte del trabajo que hacemos en la web, el trabajo de mantener una buena experiencia de usuario en bases de código en evolución nunca termina. Espero que 2020 sea el año en el que reconozcamos de manera significativa que el desempeño tiene que ver con las personas y nos adaptemos en consecuencia.

A medida que surgen innovaciones tecnológicas como HTTP/3 y 5G , debemos tener cuidado de no dormirnos en los laureles y simplemente asumir que curarán nuestros males de una vez por todas. Si lo hacemos, seguramente volveremos a tener esta discusión cuando surjan los sucesores de esas tecnologías. La innovación por sí sola no puede mantener la Web rápida porque hacer que la Web sea rápida (y mantenerla así) es el trabajo duro que sólo podemos lograr trabajando juntos.