JavaScript Responsable: Parte III
Por Jeremy Wagner. Original en inglés, traducido al español por Jesús Ricarte.
Has hecho todo lo que pensabas que era posible para solucionar el problema de JavaScript de tu sitio web. Has confiado en la plataforma web en los casos que has podido. Has dejado Babel de lado y has encontrado librerías alternativas más pequeñas. Has reducido el código de tu aplicación a la forma más simplificada posible. Sin embargo, tu web sigue sin ser lo suficientemente rápida. Cuando los sitios web no funcionan como los diseñadores y desarrolladores esperamos, inevitablemente nos volvemos contra nosotros mismos:
“¿En qué estamos fallando?” “¿Qué podemos hacer con el código que hemos escrito?” “¿Qué partes de nuestra arquitectura nos están fallando?”
Estas son preguntas válidas, ya que una buena parte de los problemas de rendimiento se originan en nuestro propio código. Sin embargo, culparnos únicamente a nosotros mismos nos ciega a la pura verdad de que un número considerable de nuestros problemas de desempeño proviene del exterior.
Cuando la tercera rueda arruina la fiesta
La comodidad siempre tiene un precio, y la web se ve destrozada por nuestra preferencia colectiva por ella. JavaScript, en particular, se emplea de una manera que sugiere una tendencia rápidamente creciente a subcontratar lo que sea que Nosotros (la primera parte) no queremos hacer. A veces, esta es una decisión necesaria; tiene un perfecto sentido financiero y operativo en muchas situaciones.
Pero no te equivoques, el JavaScript de terceros nunca es barato. Es un pacto con el diablo en el que los proveedores te seducen con soluciones a tu problema, pero convenientemente no te recuerdan que tienes poco o ningún control sobre los efectos secundarios que introduce esa solución. Si un proveedor externo agrega funciones a tu producto, tú sufres la peor parte. Si cambian su infraestructura, tú sentirás los efectos. Aquellos que usan tu sitio se sentirán frustrados y no se molestarán en lidiar con una experiencia de usuario intolerable. Puedes mitigar algunos de los síntomas del código de terceros, pero no puedes curar la dolencia a menos que elimines las soluciones por completo— y eso no siempre es práctico o posible.
En esta entrega de JavaScript responsable, adoptaremos un enfoque un poco menos técnico que en la entrega anterior. Vamos a hablar más del lado humano del código de terceros. Después, analizaremos algunas de las vías técnicas sobre cómo abordar el problema.
Obstaculizado por la conveniencia
Cuando hablamos del lamentable estado actual de la web, algunos nos apresuramos a señalar el papel que desempeña la conveniencia del desarrollador a la hora de contribuir al problema. Si bien comparto la opinión de que la conveniencia del desarrollador tiende a dañar la experiencia del usuario, no es el único tipo de conveniencia que puede convertir un sitio web en un desastre lento y descuidado.
Las comodidades operativas pueden convertirse en precursoras de una especie de deuda técnica muy espinosa. Estas comodidades son lo que buscamos cuando no podemos resolver un problema generalizado por nuestra cuenta. Representan soluciones de terceros que abordan problemas en ausencia de flexibilidad arquitectónica y/o recursos de desarrollo adecuados.
Siempre que surja un inconveniente, es el momento de debatir cómo abordarlo de una manera integral. Así que hablemos de cómo abordar ese tipo de escenario desde un ángulo más humano.
El problema es el sufrimiento
La razón por la que las soluciones de terceros entran en juego en primer lugar es el sufrimiento. Cuando quien toma las decisiones en una organización ha sentido suficiente sufrimiento en torno a un determinado problema, va a hacer algo muy humano, que es encontrar la manera más rápida de hacer que ese sufrimiento desaparezca.
Los mercados siempre encontrarán formas de abordar estos puntos débiles, incluso si la forma en que lo hacen no es sostenible o ni siquiera remotamente útil. Las capas de accesibilidad web — código de terceros que pretende solucionar automáticamente los problemas de accesibilidad — se encuentran entre los peores infractores. Primero, desembolsas tu dinero por una solución que no soluciona nada. Después, pagas un precio completamente diferente cuando esa “solución” daña la usabilidad de tu sitio web. Esta no es una regla para desacreditar la utilidad de las herramientas que brindan algunos proveedores externos, sino para ilustrar qué ocurre con la adopción de soluciones de terceros, incluso aquellas que son objetivamente horribles.
Por tanto, cuando un proveedor se presenta y promete resolver el problema tan doloroso que estamos teniendo, es muy probable que alguien pique el anzuelo. Si ese alguien está situado lo suficientemente alto en la jerarquía, ejercerá una presión hacia abajo sobre los demás para que acepten la solución de terceros, incluso eludiéndolos por completo en el proceso de toma de decisiones. Por el contrario, la adopción de una solución de terceros también puede ocurrir cuando los que están en las trincheras están bajo presión y carecen de recursos suficientes para crear las características necesarias por sí mismos.
Cualquiera que sea el catalizador, vale la pena reunir a tus compañeros y formar colectivamente un plan para navegar y mitigar los problemas a los que te enfrentas.
Crea un plan de mitigación
Una vez que las personas de una organización se hayan aferrado a una solución de terceros, aunque sea desacertada, la dificultad que encontrarás para forzar un cambio de rumbo dependerá de cuan urgente sea la necesidad de esa solución. De hecho, no deberías intentar convencer a los proponentes de la solución de que su decisión fue incorrecta. Tales esfuerzos casi siempre son contraproducentes y pueden hacer que las personas se sientan atacadas y más reticentes a lo que les estás diciendo. Peor aún, esos esfuerzos podrían crear acritud y hacer que las personas dejen de escucharse entre sí por completo, y eso es un caldo de cultivo para que se desarrollen problemas mucho peores.
Si es necesario, quéjate y expresa tus sentimientos a tus compañeros—como yo mismo he hecho a menudo—pero deja tus quejas a un lado y elabora un plan de mitigación para guiar a tus colegas hacia mejores resultados. Los rincones y recovecos de tu enfoque específico dependerán de la propia solución de terceros y de la estructura de la organización, pero la esencia podría parecerse a la siguiente serie de preguntas.
¿A qué problema va dirigida esta solución?
Existe una razón por la que se seleccionó una solución de terceros, y esta pregunta te ayudará a determinar si la justificación para su adopción es sólida. Recuerda, hay ocasiones en las que se toman decisiones cuando no todas las personas necesarias están en la sala. Es posible que te encuentres en una posición en la que tengas que reaccionar ante las consecuencias de esa decisión, pero la respuesta a esta pregunta te llevará a una continuación natural.
¿Durante cuánto tiempo pretendemos usar esta solución?
Esta pregunta te ayudará a identificar la vida útil de la solución. ¿Se introdujo como un vendaje temporal, con la intención de quitarlo una vez que se haya abordado el problema subyacente, como en el caso de una capa de accesibilidad? ¿O la necesidad es más a largo plazo, como los datos proporcionados por un conjunto de pruebas A/B? La otra posibilidad es que la solución nunca pueda eliminarse de manera efectiva porque tiene un propósito crucial, como en el caso de los códigos de analítica. Es como tirar un colchón en una piscina: es fácil de tirar, pero casi imposible de sacar.
En cualquier caso, no podrás saber si un código de terceros está para quedarse si no preguntas. De hecho, si descubres que la solución es temporal, puedes crear un plan para eliminarla eventualmente de tu sitio web una vez que se haya resuelto el problema subyacente que aborda.
¿Quién es el punto de contacto si surgen problemas?
Cuando se implementa una solución de terceros, alguien debe ser el punto de contacto para cuando surjan—no si surgen—problemas.
He visto lo que sucede (con demasiada frecuencia) cuando un código de terceros se sale de control. Por ejemplo, cuando el JavaScript de un administrador de etiquetas o de un marco de pruebas A/B crece lenta e insidiosamente porque los especialistas en marketing no están limpiando las etiquetas antiguas o las pruebas A/B completadas. Es precisamente por estas razones por las que la responsabilidad sobre las soluciones de terceros que se utilizan actualmente en tu sitio web debe atribuirse a una persona específica de tu organización. Lo que implica esa responsabilidad diferirá en cada situación, pero podría incluir:
- Monitorización periódica de la huella del código de terceros;
- mantenimiento para garantizar que el código de terceros no crezca sin control;
- reuniones ocasionales para debatir sobre el futuro de la relación de ese proveedor con tu organización;
- identificación de superposiciones de funcionalidad entre múltiples códigos de terceros, y si se pueden eliminar posibles redundancias;
- e investigación continua, especialmente para identificar alternativas más rápidas que puedan ser mejores reemplazos para códigos de terceros lentos.
La idea de responsabilidad en este contexto nunca debe ser una obligación onerosa y draconiana con la que unir a tus compañeros de equipo, sino más bien un ejercicio para fomentar la atención plena de tus colegas. Porque sin la atención plena, los efectos nocivos de un código de terceros en tu sitio web se pasarán por alto hasta que se conviertan en un ogro gruñón en la sala que ya no se puede ignorar. Asignar responsabilidades por el código de terceros puede ayudar a evitar que eso suceda.
Garantizando el uso responsable de soluciones de terceros
Si puedes elaborar un plan de mitigación y hacer que todos participen, puedes comenzar el trabajo de garantizar el uso responsable de las soluciones de terceros. Afortunadamente, el trabajo técnico real será más sencillo que tratar de discutir con la gente. Si has llegado hasta aquí, todo lo que se necesita para obtener resultados es tiempo y perseverancia.
Carga sólo lo necesario
Puede parecer obvio, pero carga sólo lo necesario. A juzgar por la cantidad de JavaScript no utilizado que veo cargado—por no hablar del JavaScript de terceros—es claramente un problema. Es como tratar de limpiar tu casa metiendo desorden en los armarios. Independientemente de si realmente se necesita, no es extraño que se cargue código de terceros en cada página, así que consulta a tu punto de contacto para averiguar qué páginas necesitan qué código de terceros.
Por ejemplo, uno de mis antiguos clientes utilizó una popular herramienta de terceros en varios sitios de marcas para obtener una lista de minoristas de un producto determinado. Demostró un valor claro, pero ese código sólo necesitaba estar en la página de detalle de producto de un sitio web. En realidad, se cargaba con frecuencia en todas las páginas. La extracción de este código de las páginas a las que no pertenecía mejoró significativamente el rendimiento de las páginas que no eran de productos, lo que redujo ostensiblemente la fricción en la ruta de conversión.
Averiguar qué páginas necesitan qué código de terceros requiere que realices un trabajo decididamente poco técnico. De hecho, tendrás que levantarte de tu escritorio y hablar con la persona a la que se le ha asignado la responsabilidad de la solución de terceros con la que estás lidiando. Este es un trabajo muy difícil para mí, pero es gratificante cuando se produce una colaboración de buena fe y, como resultado, se obtienen buenos resultados.
Aloja tu propio código de terceros
Este consejo no es un secreto ni mucho menos. Incluso lo mencioné en la entrega anterior de esta serie, pero debe gritarse desde los tejados en cada oportunidad: debes alojar tantos recursos de terceros como sea posible. Si esto es factible depende de cada código de terceros en particular.
¿Es algún marco que está tomando de las bibliotecas alojadas de Google, cdnjs, u otro proveedor similar? Alójalo inmediatamente.
Casper encontró una manera de alojar su código de Optimizely y redujo significativamente el tiempo de renderizado inicial. Realmente deja claro este punto el hecho de que uno de los mayores perjuicios de los recursos de terceros es que su mera existencia en otros servidores es uno de los peores cuellos de botella de rendimiento que encontramos.
Si estás buscando alojar una solución de analítica o un tipo de código similar, existe un mayor nivel de dificultad con el que lidiar para alojarlo. Es posible que descubras que algunos códigos de terceros simplemente no pueden ser auto-alojados, pero eso no significa que no valga la pena averiguarlo. Si encuentras que el auto-alojamiento no es una opción para un determinado código de terceros, no te preocupes. Hay otras mitigaciones que puedes probar.
Enmascara la latencia de conexiones de origen cruzado
Si no puedes alojar tus scripts de terceros, lo mejor que puedes hacer es pre-conectarte a los servidores que los alojan. La vista de conexión de WebPageTest hace un trabajo fantástico mostrándote de qué servidores tu sitio recopila recursos, así como la latencia involucrada en el establecimiento de conexiones con ellos.
Las pre-conexiones son efectivas porque establecen conexiones con servidores de terceros antes de que el navegador las descubra. Analizar HTML lleva tiempo, y las hojas de estilo y otros códigos a menudo bloquean los analizadores. Donde no puedas auto-alojar código de terceros, las pre-conexiones adquieren mucho sentido.
Quizás no pre-cargues código de terceros
La pre-carga de recursos es una de esas cosas que suenan fantásticas al principio—hasta que consideras que puede ser contraproducente, como señala Andy Davies. Si no estás familiarizado con la pre-carga, es similar a la pre-conexión, pero va un paso más allá al indicarle al navegador que busque un recurso en particular mucho antes de lo que normalmente haría.
El inconveniente de la pre-carga es que, si bien es excelente para garantizar que un recurso se cargue lo antes posible, cambia el orden de descubrimiento de ese recurso. Siempre que hacemos esto, estamos diciendo implícitamente que otros recursos son menos importantes—incluidos los recursos cruciales para el renderizado o incluso la funcionalidad principal.
Probablemente sea una apuesta segura que la mayor parte de tu código de terceros no es tan crucial para la funcionalidad de tu sitio como tu propio código. Dicho esto, si debes pre-cargar un recurso de terceros, asegúrate de hacerlo solo para código de terceros que es fundamental para el renderizado de la página.
Si te encuentras en una posición en la que el renderizado inicial de tu sitio depende de código de terceros, consulta tu plan de mitigación para ver qué puedes hacer para eliminar o mejorar tu dependencia. Depender de un tercero para la funcionalidad principal nunca es una buena posición, ya que estás cediendo gran parte del control a otras personas que podrían no tener tus intereses en mente.
Retrasa la carga de código de terceros no esencial
La mejor solicitud es la que no se realiza. Si tienes un código de terceros que no necesita cargarse de inmediato, considera cargarlo de forma diferida con Intersection Observer. Así es como se cargaría de forma diferida un botón Me gusta de Facebook cuando se haga visible en el navegador:
En el fragmento anterior, primero establecemos una variable para realizar un seguimiento de si hemos cargado el JavaScript del SDK de Facebook. Después de eso, se crea un IntersectionListener que verifica si el elemento observado es visible en el navegador y si se ha cargado el SDK de Facebook. Si el JavaScript del SDK no se ha cargado, se inyecta una referencia en el DOM, que iniciará una solicitud.
No podrás cargar de forma diferida cada código de terceros. Algunos de ellos simplemente necesitan hacer su trabajo en el momento de la carga de la página o, de lo contrario, no pueden ser aplazados. A pesar de todo, investiga si es posible cargar de forma diferida al menos parte de tu JavaScript de terceros.
Una de las preocupaciones comunes que escucho de compañeros de trabajo cuando sugiero la carga diferida de código de terceros es cómo puede retrasar cualquier interacción que proporcione dicho código. Es una preocupación razonable, porque cuando cargas algo de forma diferida, puede producirse un retraso notable a medida que se carga el recurso. Puedes evitar esto, hasta cierto punto, con la pre-captación de recursos. Es diferente a la pre-carga, que discutimos anteriormente. La pre-captación consume una cantidad comparable de datos, sí, pero a los recursos de pre-captación se les da una prioridad más baja y es menos probable que compitan por el ancho de banda con recursos críticos.
Mantente al tanto del problema
Vigilar tu JavaScript de terceros requiere una atención plena que bordea la hipervigilancia. Cuando reconozcas un rendimiento pobre causado por la deuda técnica, naturalmente entrarás en un estado de ánimo en el que la reconocerás y la abordarás como lo harías con cualquier otro tipo de deuda técnica.
Mantenerse al tanto de los terceros es refactorizar, de modo que requiere realizar tareas periódicamente, como limpiar administradores de etiquetas y pruebas A/B, consolidar soluciones de terceros, eliminar las que ya no son necesarias y aplicar las técnicas de codificación discutidas anteriormente. Además, deberás trabajar con tu equipo para abordar esta deuda técnica de forma cíclica. Este tipo de trabajo no se puede automatizar, así que sí, tendrás que ponerte manos a la obra y tener conversaciones cara a cara con personas reales.
Si ya tienes el hábito de programar “sprints de limpieza” en algún intervalo, ese es el tiempo y el espacio para que puedas abordar la deuda técnica relacionada con el rendimiento, independientemente de si se trata de código propio o código de terceros. Hay un tiempo para el desarrollo de funciones, pero ese tiempo no debe abarcar la totalidad de tus horas de trabajo. Las organizaciones que se centran solo en el desarrollo de características están destinadas a ser consumidas por completo por la deuda técnica inevitablemente resultante.
Así que en la cuarta y última entrega de esta serie discutiremos lo que significa hacer el arduo trabajo de usar JavaScript de manera responsable en el contexto del proceso. Allí, exploraremos lo necesario para unir a tu organización bajo el lema de hacer que tu sitio web sea más rápido y más accesible y, por tanto, más útil para todos, en cualquier lugar.
